“备份保留份数”仅对宝塔网站/数据库页面触发的备份生效，需在对应计划任务编辑页设置，下次执行时自动删除最老备份；手动上传、脚本生成或非默认路径文件不受影响。
宝塔计划任务里“备份保留份数”到底管不管用
管用，但只对通过宝塔【网站】或【数据库】页面点击“备份”生成的文件生效，且必须在对应备份任务的编辑页里设置——不是在计划任务总列表里设。它不清理已存在的旧文件，只从下次备份开始执行覆盖逻辑。
- 进入【计划任务】→ 找到你创建的“网站备份”或“数据库备份”任务 → 点击【编辑】
- 滚动到底部，找到【备份保留份数】下拉框，选 3 / 5 / 10（别设 1，容易丢数据）
- 保存后，下一次该任务执行备份时，会先检查同名目标目录下的已有备份数，超出即删最老的一个
- 注意：这个机制对手动上传、脚本生成、或放在
/www/backup/site以外路径的文件完全无效
用 find 命令按天数清理 /www/backup/ 下的过期文件
这是最直接、最可控的方式，尤其适合清理历史遗留的大量备份，或自定义路径（比如你把备份存到了 /data/backups）。
-
find的-mtime +N表示“修改时间早于 N 天”，不是“超过 N 天”，所以-mtime +30删的是 31 天及更早的文件 - 务必先加
-print测试，例如：find /www/backup/site -name "*.zip" -mtime +30 -print，确认列出的确实是你要删的 - 删除命令建议写成一行并用
&&连接多个路径，避免部分失败导致清理不全：find /www/backup/site -name "*.zip" -mtime +30 -delete && find /www/backup/database -name "*.sql.gz" -mtime +30 -delete - 别用
-exec rm -f {} \;替代-delete，前者在大量文件时性能差，且容易触发参数长度限制
为什么“保留最近 N 个文件”不能只靠 ls -t | tail
因为 ls -t 排序依赖文件系统修改时间（mtime），而很多备份工具（如 mysqldump + gzip）生成的 .sql.gz 文件，mtime 是压缩完成时间，不是原始数据库导出时间；如果中途 touch 过、解压再重压、或 NFS 挂载同步，mtime 就不可信。
- 想按“文件名含日期”来保最新 N 个，得用 shell 循环或 Python 解析，比如匹配
site_20260328.zip中的20260328 - 单纯
ls -t | tail -n +2001 | xargs rm -f在文件名含空格、换行符时会崩溃，必须加-print0和-0配合：find . -name "*.zip" -print0 | sort -z -t'/' -k5,5r | tail -z -n +2001 | xargs -0 rm -f - 该命令对子目录无效，
ls -t默认不递归，而find可控深度，更稳妥
清理前必须确认的三个隐藏风险点
很多用户删完发现网站打不开、数据库恢复失败，问题往往出在这三处，不是命令写错了。
- 检查备份文件是否被其他进程占用：
lsof +D /www/backup/site，如果有输出，说明某个服务正读取这些备份，强行删除可能引发 I/O 错误 - 确认磁盘配额（quota）没被触发：运行
repquota -a，若显示block grace或soft limit exceeded，删文件可能不立即释放空间，需等 quota daemon 刷新 - 宝塔 v7.9+ 的“清除过期备份”任务类型，底层调用的是
/www/server/panel/class/backup.py，它会跳过正在被 OneDrive 插件标记为.pending的文件——如果你同时用了 OneDrive 同步，得先看同步状态，否则可能删掉待上传的关键备份
