本文教你在生产环境上选对 Redis 持久化方案、设计可靠的备份策略、安全完成跨实例迁移，并在故障时按步骤恢复数据。读完会拿到一份 RDB 与 AOF 对比表、一份每日备份脚本模板、一份跨机迁移流程与一份恢复清单，帮助解决数据丢失与迁移中断这两类高风险问题。
一、为什么 Redis 必须做持久化
Redis 默认是内存数据库，进程退出数据就消失。生产环境如果只把 Redis 当缓存，挂了重启没关系；但如果存了 session、排行榜、限流计数、消息队列任务，断电就丢数据。持久化就是把内存里的键值定期或实时写到磁盘，进程重启时回放恢复。
Redis 自带两种持久化机制：RDB（Redis Database，全量快照）与 AOF（Append-Only File，追加日志）。两者各有取舍，生产推荐 RDB 与 AOF 同时开启互为备份。机器选型上 Redis 对内存与磁盘 IO 都敏感，相关海外节点选型可参考 美国 VPS 部署教程。
二、RDB 与 AOF 的取舍对比
RDB 是某一时刻的全量快照，通过 fork 子进程把内存写到 .rdb 文件，对主进程几乎无阻塞，文件紧凑、恢复速度快，缺点是两次快照之间断电会丢这段时间的写入。AOF 是把每条写命令追加到日志文件，断电最多丢一秒（fsync everysec 模式），但文件体积大、恢复速度慢。
生产环境建议：缓存场景只开 RDB，每天一次快照即可；持久化数据场景两个都开，AOF 设 everysec 保数据安全、RDB 用于快速恢复与备份归档。Redis 4.0 之后还支持混合持久化（aof-use-rdb-preamble 设为 yes），AOF 重写时把当前内存以 RDB 格式写在 AOF 头部，后续追加增量命令，兼顾两者优点。Web 服务的反代与缓存层配套配置可参考 Nginx 反向代理与负载均衡。
三、生产级备份策略
仅靠 Redis 自带持久化不算完整备份，因为 .rdb 与 .aof 都在同一台机器上，磁盘损坏一锅端。完整备份策略要包含三层：本地持久化（RDB 加 AOF）、本机定时归档、异地副本。
每日备份脚本要点：用 redis-cli BGSAVE 触发 RDB（异步不阻塞）；等 LASTSAVE 时间戳变化确认完成；把 dump.rdb 复制到归档目录并按日期命名；rsync 推到对象存储或异地服务器；用 redis-check-rdb 工具校验文件完整；保留近 7 天每日、近 4 周每周、近 12 个月每月共三层滚动。crontab 里挂 0 3 * * * 凌晨 3 点跑这个脚本。
恢复演练每月一次：在测试机上用归档的 .rdb 启动一个 Redis 实例、用 redis-cli ping 与 dbsize 验证、抽样查几个 key 比对。生产备份没演练过等于没备份。CDN（Content Delivery Network，内容分发网络）边缘缓存也常用类似的多层备份与异地归档模式，相关边缘策略可参考 Cloudflare CDN 中国区加速。
四、跨实例迁移方法
线上 Redis 换机器或换云的几种典型方法：
方法一：主从同步切换。新机器作为从节点用 replicaof 指令同步老机器全量数据，等 master_sync_in_progress 变 0，再 replicaof no one 提升为独立实例、把客户端连接切到新机器。优点是几乎零停机，缺点是要求新老机器版本兼容且同时在线。
方法二：RDB 文件复制。在老机器 BGSAVE 生成 dump.rdb、scp 复制到新机器、新机器配置 dir 与 dbfilename 指向这个文件、启动 Redis 自动加载。适合断网迁移或离线归档恢复，缺点是迁移期间老机器仍在写新数据，需要应用层短暂停写。
方法三：DUMP 与 RESTORE 命令。对部分 key 用 redis-cli –scan 配合 DUMP 与 RESTORE 命令逐个搬，适合只迁部分库或部分 key 的场景。redis-shake 与 RedisShake 等开源工具封装了批量逻辑，支持过滤与限速。
方法四：写双份切流量。应用层在迁移期间对老与新机器同时写，读还走老机器，确认新机器数据一致后切读、再停老机器。最稳但对应用代码改动大。
五、故障恢复流程
进程崩溃或服务器宕机后的恢复清单：
第一步，确认数据文件位置。看 redis.conf 里的 dir 与 dbfilename 字段、aof 相关字段；默认在 /var/lib/redis 目录下。
第二步，校验文件完整。redis-check-rdb dump.rdb 与 redis-check-aof appendonly.aof，发现损坏用 –fix 选项修复，会丢损坏点之后的数据但能让服务起来。
第三步，启动 Redis 进程。systemctl start redis-server 或前台命令 redis-server /etc/redis/redis.conf 看启动日志，载入 RDB 与 AOF 顺序是先 AOF（如果开启），再回放未持久化命令。
第四步，验证业务可用。redis-cli ping 返回 PONG、dbsize 看 key 数量是否匹配预期、抽几个核心 key 比对值、应用层探活成功后再让流量回切。SSH 远程恢复操作的加固可参考 Linux SSH 与 Fail2ban 加固。
六、典型坑与避坑指南
第一坑：fork 阻塞。BGSAVE 与 AOF 重写都用 fork，大实例（几十 GB 内存）fork 时 copy-on-write 内存翻倍，机器内存不够直接 OOM。生产监控 used_memory 与 used_memory_rss，预留至少一倍空闲。
第二坑：AOF 文件膨胀。AOF 是追加写，几个月就几十 GB。自动重写靠 auto-aof-rewrite-percentage 与 auto-aof-rewrite-min-size 触发，默认 100% 与 64MB。生产建议改成 100% 与 1GB，避免重写过于频繁占 IO。
第三坑：版本不兼容。低版本 Redis 的 RDB 文件高版本能读，反过来不行。迁移前对齐版本号到次版本一致最稳，跨大版本（如 5 到 7）务必做完整恢复测试。
第四坑：网络抖动断同步。主从同步默认 1MB/s 限速可调，repl-timeout 默认 60 秒，跨机房同步建议加大到 600 秒避免假死重连导致全量重传。
七、生产建议
Redis 是热数据层，可靠性投入需要与业务容忍度匹配。如果你的业务能接受丢一小时数据，单机 RDB 加每日异地备份就够；如果是支付或订单这类不能丢的，必须主从加哨兵架构、AOF everysec、加每日异地归档三件套都上。
可以考虑 Redis Sentinel 或 Redis Cluster 做高可用，前者管单 master 多 slave 自动故障转移、后者是分片集群，适用规模大但运维复杂度高。云厂商托管的 Redis 服务封装了备份与高可用，省心但灵活性差且费用高。如果你需要在多个机房做容灾，建议自建主从加 sentinel，再叠加每日 RDB 异地归档。
总结：Redis 持久化不是配几个参数就完事，而是包含 RDB 与 AOF 取舍、定时归档、跨机迁移演练、故障恢复演练在内的完整体系。建议把本文的脚本与清单整理成团队 Wiki 的 Redis 运维手册，每月做一次完整恢复演练，避免事到临头才发现备份不可用的尴尬。