必须停掉Redis进程后再替换RDB文件，否则重启时会自动生成空或旧的dump.rdb覆盖备份；验证需查CONFIG GET dir/dbfilename、用redis-check-rdb检测完整性、od查看文件头及rdb-tools统计键数。
直接替换 RDB 文件并强制重启前必须停掉 Redis 进程，否则新启动时会自动生成空或旧的 dump.rdb，覆盖你刚放进去的备份文件——这是多数“换完文件数据仍不对”问题的根源。
确认当前 RDB 文件是否真为“过旧”
别只看文件名或修改时间。执行以下命令验证：
-
查 Redis 实际加载的 RDB 路径：连接 redis-cli，运行
CONFIG GET dir和CONFIG GET dbfilename，确认它读的是哪个目录下的哪个文件 -
检查 RDB 文件时间戳与内容一致性：用
redis-check-rdb /path/to/dump.rdb检测完整性；再用od -c dump.rdb | head -5看开头是否为REDIS，并比对文件大小和最近 key 数量（如用rdb-tools --command json dump.rdb | jq 'length'统计键数） - 核对业务时间线：确认“数天前”是否恰好是某次误操作（如 flushall）、配置变更（save 规则被注释）或磁盘满导致 RDB 写入失败的时间点
安全替换 RDB 文件的三步操作
跳过任何“边运行边复制”的做法，必须保证 Redis 完全停止：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
第一步：彻底停止服务：用
redis-cli shutdown save（确保落盘），或kill -9 $(pgrep redis)后检查进程是否清空 -
第二步：原子替换文件：把确认无误的较新 RDB（例如
dump.rdb.2026-05-18）拷贝为dump.rdb，并chown redis:redis dump.rdb && chmod 644 dump.rdb -
第三步：静默启动验证：启动 Redis（
redis-server /etc/redis/redis.conf），立即连上执行INFO keyspace查各数据库 key 数量，再抽样GET几个关键业务 key 的值和 TTL
避免下次再踩坑的关键配置
单靠人工备份不可靠，需系统性加固：
-
启用 AOF + RDB 混合持久化：在 redis.conf 中设
aof-use-rdb-preamble yes，这样重启时优先加载 RDB 快照，再重放 AOF 尾部增量，兼顾速度与数据新鲜度 -
限制 RDB 自动覆盖行为：关闭
auto-aof-rewrite-on-bgsave-error no，并确保stop-writes-on-bgsave-error yes，让写失败立刻报警而非静默降级 -
增加 RDB 备份保留策略：用定时任务每天压缩归档一次 RDB，并带上时间戳和
redis-cli info server | grep uptime输出，便于事后定位“最后有效快照”
如果已启动且数据错乱，临时抢救方案
不建议等下一次重启，可尝试在线恢复部分数据：
- 若从节点存在且同步延迟小，立刻在从节点执行
SAVE，拿到最新 RDB 后按上述三步替换主节点 - 若 AOF 文件仍存在（即使没开启），用
redis-check-aof --fix appendonly.aof尝试修复并重放 - 使用
rdb-tools解析旧 RDB 导出 JSON，人工比对缺失 key，通过业务日志或数据库源补录关键字段
