redis-check-rdb仅能校验RDB文件完整性，无法修复损坏；报“OK”表示结构合法可解析，报错如Invalid RDB checksum或Unexpected EOF说明文件不完整或校验失效，此时应丢弃损坏文件并回退至上一个可用快照。
直接用 redis-check-rdb 校验文件是否可解析
RDB 文件损坏最常见于磁盘写满、强制 kill -9 后残留不完整快照，或传输过程中被截断。不能靠 file dump.rdb 或 head -c 100 dump.rdb 判断——RDB 是二进制格式，魔数（"REDIS"）在开头，但中间任意字节错乱都会导致加载失败，且错误可能延迟到 Redis 启动时才暴露。
必须用 Redis 自带的校验工具：redis-check-rdb。它不依赖 Redis 进程，纯离线检查，能快速定位损坏位置：
- 运行
redis-check-rdb dump.rdb：输出 "OK" 表示结构合法、能被当前 Redis 版本解析；若报错如Invalid RDB checksum或Unexpected EOF，说明文件不完整或校验和失效 - 加
--fix参数仅对 AOF 有效，redis-check-rdb没有修复能力——损坏的 RDB 只能丢弃，回退到上一个可用快照 - 注意版本兼容性：高版本 Redis（如 7.2）生成的 RDB，用低版本（如 6.2）的
redis-check-rdb可能报 "Unknown RDB version"，必须用同版本或更高版本工具校验
启动 Redis 时观察日志是否报 Failed loading the DB
这是最贴近真实恢复场景的验证方式。很多团队只校验文件格式，却跳过实际加载测试，结果上线后才发现某些数据类型（如带过期时间的 Stream 或 Module 数据）在目标 Redis 版本中不兼容。
操作要点：
- 停掉当前 Redis 实例，把待测
dump.rdb放入配置的dir路径，确保文件属主和权限正确（Redis 进程需有读权限） - 用
redis-server /path/to/redis.conf --loglevel verbose启动，紧盯日志输出 - 关键判断点：
DB loaded from disk出现即表示加载成功；若卡在Reading RDB file...后无后续，或出现Failed loading the DB: Invalid argument，大概率是 RDB 版本不匹配或内部结构异常 - 特别注意
rdbchecksum yes配置：若原始 RDB 是关闭校验和生成的（rdbchecksum no），而当前 Redis 配置为yes，启动会直接拒绝加载——日志报RDB file checksum mismatch
对比 key 数量、类型与指纹值确认逻辑一致性
文件能加载 ≠ 数据没篡改。RDB 是二进制快照，但若生成时内存已脏（如 OOM 杀进程前写坏某页）、或使用了非标准序列化模块，可能加载出类型错乱、value 截断等问题。
建议在触发 RDB 前后做三重比对：
-
redis-cli dbsize和redis-cli info keyspace：确认 key 总数与各数据库 key 数量一致 -
redis-cli keys "*" | xargs -n 1 redis-cli type：抽样检查高频 key 的类型是否仍为 string/list/zset（避免哈希被误存成字符串） - 计算内容指纹：用
redis-cli --scan --pattern "*" | xargs -I {} sh -c 'echo -n "{}:"; redis-cli get {}' | md5sum（字符串类）或更稳妥的redis-cli --scan --pattern "*" | sort | xargs redis-cli mget | md5sum，重启后重跑对比——MD5 不一致说明至少一个 value 内容变了
留意 fork 时长与内存压力对 RDB 完整性的隐性影响
RDB 本身不丢数据，但生成过程受系统资源制约。如果 redis-cli info persistence | grep rdb_bgsave_in_progress 显示 1，同时 top 观察到 Redis 进程 RSS 内存暴涨、vmstat 显示大量 minor fault，说明 COW 导致物理内存翻倍，可能触发 OOM killer 杀掉子进程——此时产生的 RDB 文件虽能通过 redis-check-rdb，但实际是中途截断的，加载时会静默丢失部分 key。
排查线索：
- 检查
redis-cli info stats | grep rdb_last_bgsave_status：若为err，再看rdb_last_bgsave_time_sec是否异常长（>30s 通常可疑） - 日志中是否有
Can't save in background: fork: Cannot allocate memory—— 这是根本原因，不是 RDB 问题，而是系统没给足内存余量 - 生产环境务必配
stop-writes-on-bgsave-error yes，避免主进程继续写入而子进程已失败，导致“以为存了实则没存”
dump.rdb 就是个危险的幻觉。 
