Navicat 17 的自动化备份必须依赖操作系统级调度器，无法独立运行；Windows 用 Task Scheduler，macOS/Linux 用 launchd 或 cron；需导出为脚本并配置安全认证与绝对路径，且须手动添加日志与错误处理。
Navicat 17 的自动化备份任务**不能脱离操作系统级调度独立运行**，尤其在 Windows 上必须依赖 Task Scheduler，macOS/Linux 则完全不支持内置计划功能。所谓“点几下就全自动”是常见误解，真实可用的路径只有一条：用 Navicat 生成可执行命令 + 外部定时器驱动。
Navicat 17 不再提供「计划任务」图形界面入口
navicat 16 及更早版本中可见的「计划」或「自动运行」菜单，在 navicat 17 中已被移除。官方文档明确说明：该功能已整合进「批处理作业」+ 系统任务调度的组合模式，不再内置触发器配置面板。
这意味着你无法在 Navicat 17 界面里设置“每天 2:00 执行”，所有时间控制必须交由外部完成：
- Windows 用户必须使用
taskschd.msc（任务计划程序）调用脚本 - macOS 用户需用
launchd或crontab -e - Linux 用户只能靠
cron+ 命令行工具
必须用「导出为脚本」代替「立即执行备份」
右键数据库 → 「备份数据库」→ 下一步时，关键动作是：取消勾选“立即执行”，勾选“保存为批处理文件”（Windows）或“保存为 Shell 脚本”（macOS/Linux）。
生成的脚本内容类似：
mysqldump --host=192.168.1.100 --port=3306 --user=admin --password=secret --databases myapp > "/backup/myapp_20260601.sql"
⚠️ 这个写法极危险——密码明文暴露。应立刻替换为安全方案：
- MySQL：用
mysql_config_editor set --login-path=prod --user=admin --password，再把脚本中--user=...改成--login-path=prod - PostgreSQL：删掉
--password=...，改用.pgpass文件，并确保脚本开头有export PGPASSFILE="/path/to/.pgpass" - 路径必须用绝对路径，
%date%类变量在脚本中不可用，得用date +"%Y%m%d"（Linux/macOS）或for /f循环（Windows）动态拼接
Windows 任务计划程序里最容易失败的三个配置点
哪怕脚本双击能跑，放进任务计划后大概率失败，原因几乎都卡在这三项：
-
“起始于”字段为空或填错：必须填脚本所在目录的绝对路径，例如C:\navicat_backups\，否则mysqldump找不到、输出路径报错或日志写入失败 -
未勾选“不管用户是否登录都要运行”：默认只在用户桌面会话中运行，服务器锁屏或远程断开即失效 -
未勾选“不存储密码则只在用户登录时运行”下方的复选框：这个隐藏选项决定能否后台静默执行；不勾它，任务会卡在“准备就绪”但永不启动
建议脚本末尾加日志重定向：2>&1 >> "C:\navicat_backups\backup.log"，否则失败时连 Access is denied 或 command not found 都看不到。
别信「Navicat 自带服务」能扛住生产环境
Navicat 曾提供可选的后台服务（NavicatSchedulerService），但在 Navicat 17 中该服务已废弃。当前所有备份行为都依赖前台客户端进程或你手动注册的系统级任务。
这意味着：
- 如果 Navicat 客户端没启动，且你没配系统任务，备份就彻底停摆
- 没有失败通知机制——不会发邮件、不弹窗、不写 Windows 事件日志，除非你自己在脚本里加
curl调 webhook 或用PowerShell Send-MailMessage - 旧备份清理必须手写逻辑，比如
forfiles /p "D:\backups" /s /d -7 /c "cmd /c del @path"（Windows）或find /backup -name "*.sql" -mtime +7 -delete（Linux/macOS）
真正防丢数据的关键，从来不是“有没有自动”，而是“失败了能不能被发现”。脚本里少一行日志或一个错误判断，就可能让连续一周的备份静默失败而不自知。
