不能靠文件名日期判断rdb是否过期，因为dump.rdb等命名只是人工约定，redis不记录生成时间元数据；必须依赖文件系统mtime（最后修改时间）判断，它精确对应快照写入完成时刻，而ctime或atime均不可靠；手动拷贝、重命名或nfs挂载会导致文件名日期失真，引发误删或漏删。
为什么不能靠文件名里的日期判断RDB是否过期
Redis的dump.rdb或dump-2024-06-15.rdb这类命名只是人工约定，mtime才是真实可靠的生成时间依据。文件系统层面的mtime记录的是RDB写入完成时刻，而ctime（元数据变更）或atime（访问时间）都不反映快照实际产生时间。
常见错误是用date -d "2024-06-15" +%s解析文件名再比对当前时间——一旦遇到手动拷贝、重命名、NFS挂载导致mtime被重置，就会误删活跃快照或漏删真正陈旧的文件。
- 脚本必须用
find /path -name "*.rdb" -mmin +1440（对应24小时）这类基于mtime的判断 - 若Redis配置了
dbfilename redis-data.rdb，匹配模式要同步改成"redis-data.rdb"或通配"*.rdb" -
mtime在BGSAVE过程中尚未更新，所以仅靠时间筛选不够，必须配合排除当前加载路径
如何安全排除Redis正在使用的RDB文件
直接find ... -delete可能删掉Redis正加载或写入中的dump.rdb，导致重启失败或数据丢失。必须先查出运行时实际加载路径，再从清理范围中排除它。
关键步骤是组合CONFIG GET dir和CONFIG GET dbfilename，并用readlink -f处理软链接：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
REDIS_DIR=$(redis-cli CONFIG GET dir | tail -n 1) REDIS_FILE=$(redis-cli CONFIG GET dbfilename | tail -n 1) CURRENT_RDB=$(readlink -f "$REDIS_DIR/$REDIS_FILE")
-
find命令里必须加-not -samefile "$CURRENT_RDB"（要求 GNU findutils ≥ 4.2.0） - 如果Redis正在执行
BGSAVE，临时文件可能与CURRENT_RDB同名但未完成写入——-samefile能精准区分，避免误删 - 权限不一致（如脚本用root跑，Redis用redis用户）会导致
find扫描失败或rm静默跳过，需统一执行用户或加sudo -u redis
清理前为什么要检查lsof句柄占用
即使排除了CURRENT_RDB，某些RDB文件仍可能被Redis进程以只读方式打开（例如主从同步时从库加载快照），此时直接rm会失败，但更危险的是：某些Linux内核版本下，unlink后文件空间不会立即释放，直到进程关闭句柄——这会造成磁盘空间“假释放”。
- 执行
lsof +D /var/lib/redis/ | grep ".rdb"确认无其他RDB被打开 - 若发现残留句柄，优先排查Redis是否异常卡在加载状态，而不是强行删除
- 生产环境建议加
timeout 30s lsof ...防阻塞，避免定时任务hang住
Shell脚本里容易忽略的并发与权限细节
Redis进程通常以redis用户运行，而清理脚本常由root或crontab默认用户执行。权限错位会导致两个问题：一是find无法进入/var/lib/redis/目录扫描；二是rm报Permission denied却因没加set -e而静默继续，漏删关键文件。
- 脚本开头加
set -euo pipefail强制失败退出 - 用
sudo -u redis find ...确保扫描权限一致 - 删除动作前加
echo "Would delete: $file"和sleep 0.1便于调试，上线时注释掉 - 不要依赖
ls -t | head -n 10取最新文件——排序受locale影响，且无法处理软链接
真正麻烦的不是写脚本，而是确认CURRENT_RDB路径是否被readlink -f正确解析，以及-samefile在不同find版本下的兼容性——这两点不验证，清理就等于在生产环境玩俄罗斯轮盘。
