Redis优化：清理旧dump.rdb文件方法

Redis默认不会自动清理旧的RDB快照文件，导致dump.rdb及其时间戳变体在磁盘中不断堆积，可能引发磁盘告警甚至持久化失败；本文详解了问题根源、误删风险及安全清理的核心原则——通过find命令精准识别并删除已结束写入、超期（如7天以上）且非当前主文件（dump.rdb）和非临时文件（dump.rdb.tmp）的RDB副本，并提供了可直接部署的Shell脚本与定时任务集成方案，兼顾安全性、可维护性与线上稳定性，帮你告别磁盘爆满焦虑，轻松实现Redis快照生命周期的自主可控管理。

为什么 dump.rdb 会越积越多？

Redis 默认开启 RDB 持久化后，每次触发 save 或 bgsave 都会生成新的 dump.rdb 文件——但旧文件不会自动删除。尤其在定时任务配置不当、备份脚本重复执行、或手动误操作多次调用 bgsave 的场景下，目录里可能堆满几十个历史 dump.rdb.20240501-142305 类似命名的文件（如果你用了带时间戳的重命名逻辑），或者干脆就是多个同名覆盖失败残留的副本。

常见错误现象：ls -lh /var/lib/redis/ | grep dump 显示一堆大小相近的 dump.rdb* 文件；df -h 发现磁盘突然告警，而 Redis 实际数据量根本没变大。

• Redis 本身不管理 RDB 文件生命周期，清理完全靠外部脚本或运维动作
• 不同版本 Redis 对 dbfilename 配置支持一致，但不会帮你做“保留最近 N 个”的事
• 直接 rm dump.rdb* 有风险：正在写入的临时文件（如 dump.rdb.tmp）也可能被误删，导致下次 bgsave 失败

用 find + 时间戳精准清理，避开运行中文件

核心思路是：只删「确定已结束写入」且「超过指定天数」的 RDB 文件，跳过当前正在使用的 dbfilename 和任何带 .tmp 后缀的临时文件。

假设你的 RDB 存放在 /var/lib/redis/，Redis 配置中 dbfilename 是 dump.rdb，那么安全清理命令是：

find /var/lib/redis/ -maxdepth 1 -name "dump.rdb*" -not -name "dump.rdb" -not -name "dump.rdb.tmp" -type f -mtime +7 -delete

说明：

• -maxdepth 1 防止递归进子目录误删其他配置或日志
• -not -name "dump.rdb" 保留当前生效的主快照文件（即 Redis 正在读取的那个）
• -not -name "dump.rdb.tmp" 必须加——这是 bgsave 写入中途的临时文件名，删了会导致持久化中断
• -mtime +7 表示“修改时间超过 7 天”，比 -atime 更可靠（访问时间易被监控工具干扰）
• 先用 -print 替代 -delete 测试，确认列出的全是目标文件再执行真实删除

Shell 脚本怎么集成到定时任务里？

别把清理逻辑硬塞进 crontab 一行，可维护性差还容易漏转义。写个独立脚本更稳妥：

#!/bin/bash
# /usr/local/bin/clean-redis-rdb.sh
RDB_DIR="/var/lib/redis"
CURRENT_RDB="dump.rdb"
<h1>确保 Redis 进程存在，避免误操作</h1><p>if ! pgrep -x "redis-server" > /dev/null; then
exit 0
fi</p><h1>查找并删除旧 RDB（保留当前文件和 .tmp）</h1><p>find "$RDB_DIR" -maxdepth 1 -name "${CURRENT_RDB}*" \
-not -name "$CURRENT_RDB" \
-not -name "${CURRENT_RDB}.tmp" \
-type f -mtime +7 -delete 2>/dev/null</p>

然后加到 crontab：

0 3 * * * /usr/local/bin/clean-redis-rdb.sh

注意点：

• 脚本开头必须有 #!/bin/bash，cron 默认用 sh，不支持 [[ 等高级语法
• 路径全部用绝对路径，$PATH 在 cron 中极简，find 可能找不到
• 加 pgrep 检查是为了防止 Redis 停机期间脚本误删——虽然概率低，但线上值得多这一行
• 输出重定向 2>/dev/null 是因为 find 在无匹配时会报错，但不影响逻辑

为什么不用 logrotate？它不适合 RDB 清理

logrotate 设计目标是滚动日志，依赖文件内容追加和重命名机制。而 RDB 是原子写入：每次 bgsave 都生成全新文件，旧文件与新文件无继承关系，也没有“轮转”概念。

强行用 logrotate 会出问题：

• 配置 copytruncate 对 RDB 无效——它不是日志，截断会破坏二进制结构
• 用 rename 或 compress 会干扰 Redis 自身对 dbfilename 的加载逻辑
• logrotate 的 dateext 生成的时间戳格式（如 dump.rdb-20240501）和 Redis 实际生成的不一致，规则难对齐

真正需要关注的是：RDB 文件是否真的该存这么多天？如果业务允许，把 save 触发条件调宽松（比如从 save 900 1 改成 save 3600 100），比天天清理更治本。但无论怎么调，外部清理脚本仍是兜底必需项——毕竟没人能保证 Redis 进程永远不崩溃重启后多留一个快照。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。