必须停掉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，通过业务日志或数据库源补录关键字段