Na vicat 无法真正实现跨多台数据库的定时备份，因其计划任务仅限客户端本地触发，依赖电脑长期开机、登录及软件常驻，属伪自动；可靠方案需用mysqldump/pg_dump配合cron或Windows任务计划程序。
Na vicat 里没法真正“自动”跨多台数据库做定时备份
很多朋友可能没意识到，Na vicat 本身并不提供服务器级别的调度能力。它的“计划任务”功能，本质上只是一个客户端本地的触发器。这意味着什么？意味着一旦你的电脑关机、退出软件，或者只是切换了登录账号，这个所谓的“自动”任务就立刻停止了。所以，它依赖的是一个相当脆弱的前提：运行 Na vicat 的那台电脑必须长期开机、保持登录状态，并且软件得一直挂着。这哪里是真正的自动化？充其量只能算是一种“伪自动”。
用 Na vicat 手动建“计划任务”时，必须注意这三点
即便你只在单机环境下使用 Na vicat 的计划任务，也常常会因为一些细节问题导致失败。这里有几个关键点，不注意就容易踩坑：
- 导出路径必须写绝对路径，并且要确保 Na vicat 进程有写入权限。举个例子，在 Windows 系统下，尽量避免使用像
C:\Program Files\...这类受保护的目录，优先选择类似C:\backup\这样权限宽松的位置。 - 每个任务只能绑定一个数据库连接。如果你想备份多台服务器上的数据库，那就得老老实实创建多个任务，别指望在一个任务里填上多个主机地址就能搞定。
- 任务执行时，如果数据库连接已经断开——比如 SSH 隧道超时，或者网络出现波动——Na vicat 并不会尝试自动重连，而是会直接报错，提示
Connection refused或Lost connection。
替代方案：用命令行 + 系统定时器才靠谱
那么，真正可靠的多库定时备份方案是什么？答案是回归到数据库的原生命令行工具，再配合操作系统的定时器。以 MySQL 为例，把备份逻辑从图形界面挪到脚本里，可控性和可靠性都会大幅提升。
你可以写一个类似下面的 backup_all.sh 脚本：
#!/bin/bash mysqldump -h192.168.1.10 -uuser1 -p'pass1' --single-transaction db1 | gzip > /backup/db1_$(date +%F).sql.gz mysqldump -h192.168.1.11 -uuser2 -p'pass2' --single-transaction db2 | gzip > /backup/db2_$(date +%F).sql.gz
然后，将这个脚本添加到系统的 cron 计划任务中，例如设定每天凌晨2点执行：0 2 * * * /path/to/backup_all.sh。对于 PostgreSQL 数据库，原理完全一样，只需把命令换成 pg_dump 即可。
这里有几个操作要点需要特别留意：
- 密码安全：不要将密码直接硬编码在命令行里（否则可能会被
ps等命令看到）。更安全的做法是使用配置文件，比如 MySQL 的~/.my.cnf或 PostgreSQL 的~/.pgpass。 - 减少业务影响：备份时记得加上
--single-transaction（MySQL）或--lock-free（PG 15+）这类参数，可以最大程度减少锁表对线上业务的影响。 - 先测试再上线：务必先手动执行脚本，确认备份能够成功完成，然后再把它放进系统定时器里。
Na vicat 的“同步”和“备份”按钮根本不是一回事
这一点对新手来说尤其容易混淆：界面上好几个地方都带着“备份”字眼，但它们的功能天差地别。
Tools → Dump SQL File 是单次导出操作；Tools → Batch Job → Backup 才是进入计划任务的入口；而那个 Tools → Data Sync，其实是双向数据比对与同步工具——它不会生成任何备份文件，也不保留历史版本，如果误操作，甚至可能覆盖目标数据库里的数据。
记住一个原则：真正意义上需要留痕、可回滚、能审计的备份，只认准压缩的 SQL 文件或物理文件快照。在 Na vicat 里，除了手动生成 .sql 或 .sql.gz 文件，其他选项严格来说都不能算作备份。
说到底，跨库备份这件事，图形化工具只是一个入口。底层的核心逻辑，永远绕不开命令、权限、路径和时间点这四要素。任何一个环节出了纰漏，整个备份链条就可能从那里断开。
