物理备份的思路
物理备份很直接：等后台快照成功后，把 RDB 文件本身拷到备份目录或对象存储。它的优点是恢复路径直观——把文件放回 dir 指向的位置再启动即可；对运行时几乎没有额外压力。代价是每次都是全量，文件大小约等于数据集大小，集群部署必须逐节点执行。最关键的纪律是「先确认快照完成、再拷文件」，直接拷贝正在生成的临时文件会拿到不完整副本。
基本信息
| 前置条件 | BGSAVE 成功产出新的 RDB 文件 |
|---|---|
| 完成判断 | LASTSAVE 时间戳发生变化，或与源文件比对校验值 |
| 拷贝对象 | dir 与 dbfilename 指向的最终文件 |
| 集群场景 | 每个主节点都要单独备份，从节点可按需备份 |
| 保留策略 | 按日/周分级保留，并保留异地副本 |
| 敏感度 | 文件含全量业务数据，默认不加密 |
典型使用场景
- 每日低峰做一次全量冷备，作为误删除后的最后一道防线
- 重大变更前额外备份：版本升级、换机迁移、批量脚本执行
- 恢复演练：把备份文件挂到独立实例上验证数据可用
- 跨机房容灾：把快照同步到异地对象存储或备份服务器
- 给分析团队提供离线数据，避免直接连线上实例跑大查询
备份脚本要点
备份脚本要点
BEFORE=$(redis-cli LASTSAVE) # 记录当前快照时间戳
redis-cli BGSAVE # 触发后台快照
while [ "$(redis-cli LASTSAVE)" = "$BEFORE" ]; do sleep 2; done # 等新快照落地
md5sum /data/redis/dump.rdb # 生成校验值，恢复时对账
cp /data/redis/dump.rdb /backup/redis/dump-$(date +%F).rdb
find /backup/redis -name 'dump-*.rdb' -mtime +30 -delete # 按保留策略清理过期备份
# 集群环境需按节点循环执行上面两步关键环节对照
| 环节 | 做法 | 原因 |
|---|---|---|
| 触发 | BGSAVE 后等 LASTSAVE 变化 | 避免拷到未完成或上一轮的文件 |
| 校验 | 记录并比对 md5 | 发现传输与存储损坏 |
| 存放 | 异地对象存储并保留版本 | 本机磁盘故障时备份不能一起丢 |
| 权限 | 限制读权限，必要时加密上传 | 文件包含全量业务数据 |
脚本一定要判断快照是否真的完成：LASTSAVE 没变化说明这次 BGSAVE 没有产出新文件（可能因为上次持久化失败仍在拒绝新的后台保存），此时拷到的是旧快照，恢复后数据会比预期更旧。