备份aof文件前必须确保bgrewriteaof未运行，通过info persistence确认aof_rewrite_in_progress为0；需用config get appendfilename和dir获取真实路径；对一致性要求高时应debug sleep 1再复制。
备份 AOF 文件前必须停掉重写（BGREWRITEAOF）
Redis 在执行 BGREWRITEAOF 时会 fork 子进程生成新 AOF 文件，此时原 appendonly.aof 仍在被主进程持续追加写入。若在此期间直接复制该文件，极大概率拿到的是不一致的中间状态 —— 比如尾部命令截断、长度字段错位，导致后续 redis-check-aof --fix 也救不回来。
实操建议：
- 先用
redis-cli info persistence | grep aof_rewrite_in_progress确认返回值为0，表示无重写进行中 - 若为
1，可等其自然完成，或手动触发redis-cli BGREWRITEAOF后等待（观察aof_rewrite_scheduled是否变0） - 不要依赖「重写快结束」的猜测 —— 即使只剩几秒，文件仍处于开放写入状态，复制即风险
用 redis-cli BGSAVE + CONFIG GET appendfilename 定位当前 AOF 文件
AOF 文件名可能被自定义（如 appendfilename "redis-node-7001.aof"），不能默认硬编码为 appendonly.aof。且 Redis 启动后若发生过重写，旧文件可能已被 rename 为 appendonly.aof.1.base.rdb 等临时名，真正生效的只有当前配置指向的那个。
实操建议：
- 运行
redis-cli config get appendfilename获取真实文件名 - 运行
redis-cli config get dir获取数据目录路径 - 组合出完整路径，例如：
/var/lib/redis/redis-node-7001.aof - 避免直接
cp /var/lib/redis/appendonly.aof /backup/这类想当然的操作
备份时是否要停 Redis？取决于你对「一致性」的要求
不停服务也能备份，但需接受「最多丢失 1 秒数据」的现实 —— 因为 appendfsync everysec 是默认策略，最后一秒缓冲区内容可能尚未落盘。如果你备份的是刚写入的 key，它可能只在内存缓冲里，没进磁盘文件。
实操建议：
- 对一致性要求高（如金融类场景）：执行
redis-cli DEBUG sleep 1等待内核缓冲刷盘，再cp文件 - 对可用性优先：跳过等待，但要在备份脚本里记录
redis-cli info stats | grep instantaneous_ops_per_sec当前写入速率，用于事后评估潜在丢失量 - 绝对不要用
SAVE或停服务来「确保一致」——这既没必要，又会造成业务中断
redis-check-aof --fix 不是万能的，别把它当备份兜底
这个工具只能修复因崩溃导致的**末尾命令不完整**（比如 *3\r\n$3\r\nSET\r\n$1\r\nk 缺少 value 部分），但它无法识别逻辑错误：比如重写中途被 kill，导致新旧 AOF 混杂、SELECT 数据库指令错乱、或某条命令被重复写入两次。这种损坏恢复后数据可能完全错乱，但 redis-check-aof 仍会声称「已修复」。
真正可靠的备份验证方式只有一个：把备份文件拷到测试环境，启动 Redis，用 redis-cli --scan | head -n 1000 | xargs redis-cli exists 快速抽检 key 存在性，并比对 INFO keyspace 中各 db 的 keycount 是否与源一致。
