Navicat 不支持自定义备份文件命名规则，文件名固定为“数据库名_时间戳.nb3”，时间戳为毫秒级内部元数据且不可干预；替代方案是备份完成后用脚本重命名，或直接调用mysqldump/pg_dump实现可控命名。
Navicat 本身不支持自定义备份文件命名规则——你无法在界面中设置类似 dbname_YYYYMMDD_HHMMSS.nb3 或添加环境标识（如 _prod、_test）的模板。
所有备份文件名均由 Navicat 内部生成，格式固定为：[数据库名]_[时间戳].nb3，其中时间戳是毫秒级、带时区偏移的内部元数据，**不是文件系统修改时间，也无法被用户干预**。
为什么不能改命名规则？
navicat 的备份模块设计目标是“一键快照”，而非归档管理工具。它不暴露命名逻辑的配置入口，也不提供变量占位符（如 $db_name、$env、$date）。即使通过高级设置或注册表/配置文件硬改，也会导致备份失败或还原异常——官方从未开放该能力，第三方 patch 风险极高。
实际可行的替代方案：用外部脚本重命名
既然 Navicat 不让改，就等它生成完再动手。关键前提是：确保备份任务完成后，文件已写入且不再被占用（Navicat 不会锁住已生成的 .nb3 文件）。
- Windows 下可用 PowerShell 脚本，监听备份目录变化，匹配
*.nb3，提取原始文件名中的数据库名和内部时间戳（需解析.nb3文件头，但更简单的是依赖文件修改时间 + 命名规律做近似映射） - Linux/macOS 下推荐用
find+mv组合，例如：mv "/backup/prod_db_20260612_142305.nb3" "/backup/prod_db_prod_20260612_1423.nb3"
- 必须在
Navicat备份任务执行完毕后触发重命名——可通过任务计划器延时 30 秒执行，或监听文件大小稳定后再操作 - 重命名前务必检查目标路径权限，避免因
Permission denied导致归档中断
更可靠的做法：绕过 .nb3，直接调用 mysqldump/pg_dump
如果你真正需要可控的命名与归档逻辑，Navicat 的图形化备份应被视作“临时应急手段”，长期归档建议放弃 .nb3 格式：
- 用
Navicat的「自动运行」功能执行外部命令，例如：mysqldump -u root -pPass123 mydb > /backup/mydb_prod_$(date +\%Y\%m\%d_\%H\%M).sql - 这样命名完全由 shell 控制，可嵌入环境变量、Git commit hash、甚至调用 API 获取版本号
- 生成的
.sql文件体积更大，但可读、可 diff、可 gzip 压缩，也方便接入logrotate或rsync归档流程 - 注意：需确保执行用户对目标路径有写权限，且
mysqldump在 PATH 中（Windows 下需写全路径，如C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqldump.exe）
容易忽略的关键点
很多人试图用定时任务扫描 .nb3 文件并按名称重命名，却忘了 Navicat 在备份过程中会先写一个临时文件（如 tmp_XXXX.nb3），再重命名为最终名——若脚本过早介入，会把临时文件误处理。真正安全的时机是：文件存在、大小稳定 ≥ 10 秒、且 Navicat 日志里出现 “Backup completed successfully” 记录之后。
