防线不止一层
单机持久化只解决本机进程重启不丢，它挡不住磁盘损坏、机房故障、误操作与人为破坏。完整防线是四层叠加：单机持久化、多副本、异地独立备份、恢复演练。缺任何一层，某类故障就会直接变成数据事故。
分层防线
| 故障场景 | 对应手段 | 缺失后果 |
|---|---|---|
| 进程崩溃或重启 | 增量日志每秒刷盘，或定期快照 | 重启即丢最近一段时间的数据 |
| 磁盘损坏 | 主从副本、集群多副本 | 只能等备份恢复，恢复时间很长 |
| 机房或可用区故障 | 跨机房复制与异地备份 | 业务整体中断且没有副本可用 |
| 误删键或逻辑写坏 | 独立代次快照、审计与权限收敛 | 复制会实时同步误操作，副本救不了 |
| 勒索或人为破坏 | 离线或异地不可写备份 | 备份与生产一起被加密 |
落地要点
- 备份动作放在从库上做，避免在主库上触发分支影响延迟
- 备份内容包含数据文件与配置文件，配置里记录了持久化参数与认证信息
- 备份后校验可读性，用官方检查工具验证快照与日志文件完整
- 定期在隔离环境做一次真实恢复，记录耗时并留档
- 明确数据丢失窗口与恢复时间目标：每秒刷盘最坏丢 1 秒，快照间隔越长丢得越多
现状盘点
现状盘点
redis-cli INFO persistence | grep -E 'aof_enabled|aof_last_write_status|rdb_last_bgsave_status'
redis-cli INFO replication | grep -E 'connected_slaves|master_link_status' # 有几份副本
redis-cli -h 10.0.0.12 BGSAVE # 在从库上生成快照，减轻主库压力
redis-check-rdb /backup/redis/dump.rdb # 校验快照文件可读
redis-check-aof /backup/redis/appendonly.aof # 校验增量日志文件完整
ls -lh /backup/redis/ && du -sh /backup/redis/ # 盘点备份内容与容量复制不是备份：主从是实时同步的，一次误删会在毫秒级传到所有副本。只有带时间维度、不会被复制覆盖的独立副本才算备份。
想收紧写入的持久化语义，可以要求最少健康从库数量才允许写入，或在关键写入后等待指定数量的副本确认。两者都会牺牲可用性或增加延迟，需要按业务取舍并在压测中验证。
备份必须与生产拉开物理与权限距离：同一台机器、同一个可写存储账号里的备份，在误删目录、权限泄漏或勒索时和生产一起消失。异地或离线保存加多代保留才有恢复弹性。