Navicat On-Prem Server 不管理备份文件，仅同步协作对象；“过期备份”实为用户上传至文件管理模块或本地路径的手动/自动导出文件，清理须定位实际存储位置，而非在服务界面操作。
Navicat On-Prem Server 的备份文件不归它管
navicat on-prem server 本身不生成、也不管理数据库备份文件——它只负责同步连接配置、查询、bi 工作区等协作对象。你看到的“过期备份”，实际是团队成员用 navicat desktop 手动或通过自动运行任务导出的 .sql、.xlsx 或其他格式文件，被上传到 on-prem server 的“文件管理”模块里，或是直接存放在某台 windows/macos 主机的本地路径（比如 d:\navicat_backups\）。所以清理动作必须落在具体存放位置上，而不是在 on-prem server 界面里点几下就能删掉。
Windows 上用 PowerShell 脚本按日期自动删旧备份
如果备份文件统一放在某台 Windows 服务器的固定目录（如 D:\navicat_backups\），且命名含标准时间戳（例如 mydb_20260720_143022.sql），可以直接复用已验证的 PowerShell 逻辑：
Get-ChildItem "D:\navicat_backups\*.sql" | ForEach-Object {
if ($_ -match '_(\d{8})_\d{6}\.sql$') {
$date = [datetime]::ParseExact($matches[1], 'yyyyMMdd', $null)
if ((Get-Date) -gt $date.AddDays(7)) {
Remove-Item $_.FullName -Force
}
}
}
- 正则
_(\d{8})_\d{6}\.sql$必须和你实际文件名格式一致；若用短横线分隔（如mydb-2026-07-20-143022.sql），就得改成-(\d{4}-\d{2}-\d{2})-\d{6}\.sql$ - 没匹配上的文件（比如手动改名的、带中文的、非 SQL 格式）会被跳过，不会误删
- 脚本需以管理员权限运行，否则可能因权限不足跳过某些文件
macOS/Linux 用 find + 时间判断更稳妥
macOS 或 Linux 服务器上不建议硬解析文件名日期（容易因时区、命名不规范失败），直接按文件修改时间删更可靠：
find /path/to/backups -name "*.sql" -type f -mtime +7 -delete
-
-mtime +7表示“修改时间超过 7 天”，不依赖文件名，兼容任意命名规则 - 首次运行前先去掉
-delete，换成-ls看哪些文件会被删，避免误操作 - 如果备份目录里混着重要日志或配置文件，加
-maxdepth 1限制只扫当前层，不进子目录
On-Prem Server 文件管理里的“过期”其实是人为标记
On-Prem Server 的 Web 界面中，“文件”模块没有自动过期策略。所谓“过期”，往往指：团队成员上传后忘了归档、没人维护、版本混乱。这时候不能靠脚本，得靠协作规范：
- 强制所有备份上传前重命名为
project_dbname_YYYYMMDD_HHMMSS.sql，便于识别和筛选 - 在 On-Prem Server 新建专用文件夹，如
/backups/production/和/backups/staging/，禁止混传 - 设置项目角色权限：普通成员只有“上传+查看”，删文件权限只给 DBA 或运维负责人
真正难清理的从来不是文件本身，而是谁上传的、为什么留着、有没有被下游系统依赖——这些信息不会出现在 mtime 或文件名里，得靠人对齐，不是工具能解决的。
