redis-check-rdb能修复局部损坏（如单个key解析失败、CRC错误、AOF混入末尾），但无法修复头部魔数错误、版本错乱或文件截断；修复须用-f参数且Redis必须停止。
redis-check-rdb 能修什么、不能修什么
它能检测并跳过损坏的键值块，修复校验和错误，甚至用 -f 强制重写尾部结构；但修不了头部魔数（"REDIS"）被覆盖、版本号错乱、或整个 RDB 被截断成半截二进制的情况。换句话说：它不是万能编辑器，而是“尽力而为”的解析器。
常见错误现象包括 Redis 启动时报 RDB file is corrupted、Invalid RDB magic header 或直接静默失败（日志里只有一行 Failed to load RDB）。
- 能修：单个 key 解析失败、CRC 校验不通过、AOF 混入 RDB 文件末尾等局部问题
- 不能修：文件开头 5 字节不是
REDIS、od -c dump.rdb | head -1看不到该标识、文件大小明显小于 1KB（极大概率头部损毁） - 修复前务必先备份原文件：
cp dump.rdb dump.rdb.bak
执行 redis-check-rdb 的正确姿势
别直接跑 redis-check-rdb dump.rdb 就走人——它默认只做检查，不修改文件。真要修复，必须加 -f 参数，且得确认 Redis 已完全停止（否则可能读到脏数据或触发锁冲突）。
实操建议：
- 先检查：
redis-check-rdb dump.rdb—— 观察输出是否含Checksum OK或具体报错位置（如 offset 0x2a7f） - 再尝试修复：
redis-check-rdb -f dump.rdb—— 它会自动跳过无法解析的段，重写 footer 并更新 checksum - 验证结果：
redis-server --test-memory 1 --dbfilename dump.rdb --dir .快速加载测试，不启动服务也能校验可读性
修复失败后还能抢救数据吗
能，但得换思路：不强求恢复完整 RDB，转而提取可用键值。这时候 rdb-tools 比官方工具更实用，尤其当损坏是中间段而非头部时。
场景举例：运维发现 redis-check-rdb -f 报错 Unexpected EOF，说明文件被截断，但前 80% 可能完好。
- 安装：
pip install rdbtools（注意 Python 版本兼容性，3.8+ 更稳） - 导出 JSON：
rdb --command json dump.rdb > data.json—— 它会自动跳过解析失败的键 - 导入新实例：
cat data.json | redis-cli --pipe，前提是目标 Redis 已清空或确认无键冲突 - 注意：
rdb-tools不支持带过期时间的 key 导出为 TTL，需额外处理expire命令
权限、路径、配置三处最容易漏掉的坑
很多修复失败根本不是文件损坏，而是环境卡住：Redis 启动时找不到文件、读不了、或加载后为空数据库。
-
CONFIG GET dir查到的路径未必真实有效——检查该目录是否存在、是否挂载、是否有写权限（ls -ld /var/lib/redis） - RDB 文件权限必须是 Redis 进程用户可读（通常是
redis:redis），chown redis:redis dump.rdb比chmod 777安全得多 - 配置项
dbfilename和实际文件名不一致？redis-server --dbfilename mybackup.rdb --dir /data才能精准加载，别依赖默认名 - 若用
redis-server --dir /path --dbfilename f.rdb启动后仍没数据，立刻查INFO persistence看rdb_last_bgsave_status:ok是否为ok
真正棘手的从来不是命令会不会敲，而是修完之后 Redis 加载了文件，却说“我加载了”，然后 KEYS * 返回空——那八成是路径、权限、或配置名对不上。
