Navicat 17 无法真正共享自动化备份配置，仅能导出不含调度逻辑的.psc/.nb3文件，需手动导入、重绑连接并单独配置系统调度器；团队协作应统一使用命令行脚本+版本化配置。
Navicat 17 无法共享“自动化备份配置”本身——它不保存计划时间、调度参数或系统级任务注册信息，只存连接名和路径等静态字段；所谓“共享备份任务”，实际只能共享.psc或.nb3备份定义文件，但对方必须手动导入+重新绑定本地连接+自行配置操作系统调度器。
Navicat 17 的备份任务文件（.psc/.nb3）本质是连接快照，不是可执行计划
右键数据库 →「备份数据库」→ 勾选「保存为批处理文件」后生成的.psc（MySQL）或.nb3（PostgreSQL）文件，只包含：connection_name、database_name、backup_path、压缩选项等，不含任何时间触发逻辑。它不记录“每天2:00执行”，也不含密码、登录路径或日志配置。
这意味着：
- 你发给同事一个
order_db.psc，他双击导入后，看到的是“备份 order_db 到 C:\mybackups\”，但这个路径在他机器上很可能不存在，connection_name也大概率不匹配他本地已有的连接 - 即使连接名一致，如果他的 Navicat 连接用的是
--login-path=prod，而你的.psc里硬编码了--password=xxx，导入后仍会失败 - .psc/.nb3 不带操作系统调度配置（如 Windows 任务计划程序里的“不管用户是否登录都要运行”），这部分完全无法导出或同步
真正能协作落地的只有脚本 + 文档 + 权限约定
团队要共用一套备份逻辑，必须绕过 Navicat 界面，统一使用命令行工具生成可版本化、可审查的脚本：
- MySQL 场景：用
mysql_config_editor set --login-path=team-prod --user=dba --password统一配置登录路径，所有成员在各自环境执行同一份backup_order.sh脚本 - PostgreSQL 场景：约定
.pgpass文件位置（如/etc/navicat/.pgpass），脚本开头强制export PGPASSFILE="/etc/navicat/.pgpass" - 文件名和路径必须用绝对路径 + 动态时间戳：Linux/macOS 用
date +"%Y%m%d_%H%M"，Windows 用for /f "tokens=1-4 delims=/ " %%a in ('date /t') do set YYYYMMDD=%%d%%b%%c - 把脚本、
.pgpass模板、mysql_config_editor初始化说明一起放进 Git 仓库，README 明确写清“首次运行前需执行哪三条命令”
Navicat 自动运行 → 批处理作业 ≠ 可共享的自动化方案
有人误以为在「自动运行」里新建一个批处理作业（含多个备份步骤），再导出为 .nba 文件就能共享。但事实是：
-
.nba文件只记录操作顺序（如“先备份 A 库，再备份 B 库”），不包含每个步骤的实际参数值，导入后所有步骤都变成“未配置”状态 - 批处理作业无法跨平台复用：Windows 上建的作业，macOS 用户导入后点击执行会直接报错“找不到 navicat.exe”或“命令行工具未启用图形环境”
- 它不解决最核心的权限问题：比如 A 同事有生产库
root权限，B 同事只有readonly，共享同一个作业会导致后者执行失败且无明确提示
真正需要团队协同的关键点，从来不是“怎么点开 Navicat 界面”，而是“谁负责维护 mysql_config_editor 的 login-path 更新”、“.pgpass 文件的权限是否设为 600”、“cron 的 PATH 是否包含 /usr/local/mysql/bin”。这些细节一旦写错，备份就会静默失败——而 Navicat 界面根本不会告诉你哪里错了。
