全量备份应选RDB；因其文件小、恢复快，适合作为每日基线备份，而AOF仅宜作为增量补丁，不可替代RDB承担全量角色。
全量备份选 RDB 还是 AOF？得看恢复速度和磁盘压力
RDB 是快照式备份，save 或 bgsave 生成的 dump.rdb 文件小、恢复快，适合做每日基线备份；AOF 记录每条写命令，体积大、恢复慢，但数据丢失少——它不适合当“全量”用，只该作为增量补丁存在。企业级策略里，rdb 是主干，aof 是毛细血管。
- 线上 Redis 实例内存 > 4GB 时，
bgsave可能触发 fork 延迟，需监控latest_fork_usec -
appendonly yes开启后，aof_rewrite会自动压缩 AOF，但重写期间仍写旧 AOF 文件，磁盘空间可能瞬时翻倍 - 不要把
save配置成save 1 1这类高频策略，小概率写入抖动也会触发 RDB，加重 fork 压力
怎么让 AOF 真正变成“可落地”的增量备份
AOF 默认是追加写，但直接 rsync 或 cp 正在写的 appendonly.aof 文件，大概率损坏——因为文件末尾可能是半条命令。必须靠 Redis 自身机制切出干净片段。
- 用
bgrewriteaof触发重写，完成后 Redis 会原子替换 AOF 文件，新文件可安全归档 - 配合
CONFIG SET appendfilename "appendonly-$(date +%s).aof"动态改名（需提前在 config 中启用appendfilename可写），再执行bgrewriteaof，就能按时间戳分片存档 - 别依赖
fsync always：它让每次写都落盘，QPS 掉 3–5 倍；fsync everysec是平衡点，最多丢 1 秒数据，但吞吐稳定
备份文件放哪？本地磁盘只是中转站
所有备份文件（dump.rdb、appendonly-*.aof）必须离开 Redis 所在机器。本地磁盘故障是单点，且备份过程本身会争抢 I/O。
- 用
rsync --remove-source-files把刚生成的 RDB/AOF 推到另一台专用备份机，避免残留 - 云环境优先走对象存储：
aws s3 cp dump.rdb s3://my-redis-backup/prod/20240520/，注意加上--sse加密 - 别用 NFS 挂载远程目录当 backup dir：Redis 写 RDB 时若 NFS 卡住，整个实例会阻塞在
write(2)
恢复时最容易被忽略的两个检查点
备份再全，恢复失败就归零。真正上线前必须验证两件事：RDB 文件是否完整、AOF 是否能被 Redis 安全加载。
- 用
redis-check-rdb dump.rdb检查 RDB 结构，返回 0 才算合法；非 0 就别往生产实例上试 - 临时起一个隔离 Redis（
redis-server --port 6380 --appendonly yes --appendfilename test.aof），然后cat appendonly-1716201600.aof >> test.aof，再看日志有没有Bad file format reading the append only file - 恢复后务必连上去跑
INFO persistence，确认aof_current_size和rdb_last_bgsave_status:ok都正常，而不是只看进程起来了
备份不是存完就结束的事。RDB 的生成时机、AOF 的切片节奏、归档路径的 I/O 隔离、恢复前的格式校验——每个环节断掉，整条链就失效。最常出问题的是以为 bgrewriteaof 后文件立刻可用，其实重写完成到文件落盘之间仍有毫秒级窗口，直接挪走可能截断。
