Navicat 不支持自动清理备份文件，需依赖操作系统定时任务配合脚本实现；Linux 用 find + cron 按修改时间清理，Windows 推荐 PowerShell 脚本，并强调命名规范与删除前验证。
Navicat 本身不支持自动清理备份文件
navicat 是数据库客户端工具，不是任务调度器或文件系统管理器。它能触发备份（比如通过 自动运行 功能调用 mysqldump 或 pg_dump），但不会主动扫描、判断、删除本地磁盘上的旧备份文件。
所谓“定期自动清理”，必须靠外部机制实现——操作系统级定时任务（cron / Task Scheduler）配合脚本完成。
- Navicat 的
自动运行只能执行一次命令（如生成新备份），无法链式执行“清理+备份” - 它的
备份计划界面里没有“保留最近 N 个”或“删除 7 天前文件”的选项 - 如果你在 Navicat 日志里看到“清理成功”，那其实是手动点的，或背后另有脚本在跑
Linux 下用 find + cron 清理 MySQL 备份文件最可靠
假设你用 Navicat 定时导出到 /backup/mysql/，文件名含日期（如 prod_20240520.sql.gz），清理逻辑就很简单：按修改时间删老文件。
别用 rm -rf /backup/mysql/* 这类暴力操作——万一路径写错，核心数据目录可能被连带清空。
- 先测试命令是否选对文件：
find /backup/mysql -name "*.sql.gz" -mtime +7 -print - 确认无误后加
-delete执行清理：find /backup/mysql -name "*.sql.gz" -mtime +7 -delete - 加入 crontab 每天凌晨 2 点运行：
0 2 * * * find /backup/mysql -name "*.sql.gz" -mtime +7 -delete -
-mtime +7表示“修改时间超过 7 天”，注意不是“创建时间”——Navicat 导出的文件修改时间即备份时间
Windows 上用 PowerShell 脚本替代批处理更稳妥
Windows 自带的 forfiles 命令对路径空格、特殊字符支持差，容易失败；PowerShell 的 Get-ChildItem 更健壮。
把下面内容存为 cleanup_backups.ps1：
Get-ChildItem "D:\navicat_backups\*.sql" | Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-7) } | Remove-Item -Force然后用任务计划程序调用：
- 操作 → “启动程序”，程序填
powershell.exe - 参数填
-ExecutionPolicy Bypass -File "D:\navicat_backups\cleanup_backups.ps1" - 务必勾选“不管用户是否登录都要运行”，并启用“使用最高权限”
- 避免用
.bat调del：它不识别 Unicode 文件名，且/D参数只认“创建时间”，而 Navicat 写入的文件创建时间可能和备份时间不一致
备份文件命名不规范会导致清理失效
如果 Navicat 导出时没固定命名规则（比如每次用随机字符串或不带日期），find 或 Get-ChildItem 就没法靠文件名过滤，只能依赖时间戳——但多个备份在同一秒生成时，-mtime 或 LastWriteTime 会一并误删。
- 在 Navicat 备份设置中，把文件名模板设成：
prod_${date:yyyyMMdd_HHmmss}.sql.gz - 这样既能人工识别，也方便后续用
ls prod_2024*.sql.gz | head -n -3留最新 3 个（比时间更精确） - 别用
${time}单独命名——不同年份的文件混在一起时，字符串排序会错乱（如10:00排在9:59前面） - 清理脚本上线前，先手动改一个旧文件的修改时间测试：
touch -d "2020-01-01" old_backup.sql.gz
真正要防的不是“删不掉”，而是“删多了”——备份目录一旦被误清，Navicat 里再也没法回溯。所有清理动作，优先加 -print 或 Write-Host 验证目标，再动手删。
