Redis RDB 和 AOF 怎么选？数据恢复点与恢复时间取舍
先判断丢失数据会发生什么
本文讨论 Redis 7、8 系列自建实例的 RDB 与 AOF。先把数据分成能从数据库重建的缓存、短期会话，以及不能直接重建的队列或业务状态。同样丢失十分钟数据，缓存可能只是使数据库短时变忙，队列却可能漏掉尚未处理的任务，配置不能只按实例大小复制。
为每类数据写下允许回退到多久以前，以及服务最多停多久。前者约束恢复点，后者约束恢复过程。还应估算没有缓存时数据库能否承受请求；选择不持久化的缓存，也需要限流、预热和故障期间的降级方案。
RDB 与 AOF 保留的是不同记录
RDB 保存某一时点的数据集，文件便于制作有时间标记的副本，但最新快照之后的变化可能丢失。AOF 记录写入操作，按同步策略在性能与耐久性之间取舍。常见的 everysec 通常把风险窗口缩小到约一秒量级，但不能把它宣传为任何故障下最多丢一秒的硬保证。Redis 持久化说明
若业务要求更小的损失窗口，应结合存储故障模型、写入延迟与应用补偿验证同步策略。RDB 和 AOF 同时启用也不代表无需外部备份。错误写入或误删除同样可能进入持久化文件，副本复制也会传播这些变化，恢复仍需要独立保留的历史版本。
看实际状态，而非只看配置开关
在有权限的认证会话中读取持久化状态，不需要为监控开放全部管理命令。记录实例版本和磁盘位置后，可先查看这一只读信息：
INFO persistence
重点观察最近 RDB 保存及 AOF 写入、重写是否成功，后台操作是否仍在进行，以及待同步情况。字段随版本与启用功能变化，以该实例返回为准。状态中的错误要结合服务日志和文件系统剩余空间解释，不要因为进程仍在运行就认为备份健康。INFO 字段参考
保存与重写也消耗资源。变更频繁的数据集在后台生成文件期间可能增加写时复制内存压力，磁盘还需同时容纳旧文件和新文件。制定阈值时应留出余量，并观察延迟是否与后台操作重叠，而不是只给数据文件大小乘一个固定倍数。
已有实例切换策略要保护数据
先完成可验证的备份，再按对应版本的官方流程在运行实例上过渡，等待新持久化文件生成成功，最后同步长期配置。不要仅修改 appendonly 后立即重启：启动时选择哪套文件会影响恢复结果，旧的或不完整的文件可能与当前内存数据不一致。
Redis 7 以后 AOF 采用多文件组织，包含清单以及基础、增量文件。备份时不能只寻找一个旧教程里的 appendonly.aof。应采用能够保持文件集合一致性的备份流程，记录版本、相关配置和文件清单；随意复制正在切换的文件集合，不足以证明它能恢复。
用隔离恢复决定策略是否合适
把副本恢复到不接收生产流量的独立实例，先核对启动日志，再抽查关键键、类型、业务序号与剩余有效期。恢复后已经过期的键不一定继续存在，不能把键总数差异直接判定为文件损坏。用应用实际读取路径验证关键状态，才能发现格式兼容或逻辑缺失。
记录备份完成时间、恢复用时和最后可确认的业务记录，与最初的恢复目标对照。若改动带来明显延迟或恢复超时，保留新旧备份，恢复先前经过验证的策略，并明确回退期间是否有新增写入。任何策略调整都应保持至少一份已验证的恢复材料。