Navicat Cloud 不支持同步数据库备份任务，因其依赖本地绝对路径、系统级权限及操作系统定时器，仅同步书签、查询、ER模型、偏好设置和连接分组名称等轻量元数据。
Navicat Cloud 不同步数据库备份任务——它根本**不支持**该功能。
你看到的“同步”列表里没有备份计划，不是操作遗漏，而是设计如此。所有备份任务都绑定在本地，换设备后必须重配。
为什么 Navicat Cloud 无法同步 backup.xml 或备份计划？
备份任务不是纯配置元数据，它依赖三类本地强约束：
-
backup.xml（Windows）或 SQLite 配置文件（macOS/Linux）中硬编码了绝对路径，比如C:\navicat_backups\或~/Documents/db_bak/；直接复制到另一台机器，Navicat 会尝试往旧路径写文件，失败且无明确报错 - 调用
mysqldump、pg_dump等工具需要本地可执行权限和环境变量，云端无法校验或代理 - 触发机制依赖操作系统级定时器：
Windows Task Scheduler或launchd，这些服务不通过 Navicat Cloud 注册或暴露接口
Navicat Cloud 实际同步哪些内容？
它只同步与「连接上下文」相关的轻量元数据，包括：
- 数据库连接信息（主机、端口、用户名；但密码不上传，仅本地加密存储）
- 书签、常用查询语句、ER 模型、BI 工作区
- 连接分组名称、偏好设置（字体、主题、快捷键等）
-
不包含：任何表数据、SQL 备份文件（
.sql）、私有格式文件（.ncb）、备份计划、定时器配置
换电脑后怎么恢复备份能力？
别试图迁移 backup.xml，风险高、成功率低。正确做法是手动重建 + 外部脚本化：
- 在新设备上打开 Navicat → 进入「自动运行」→ 新建批处理作业 → 添加「备份」动作 → 指定目标库、导出路径、格式（务必选
SQL File，避免.ncb私有格式） - 导出路径建议设为云同步目录（如 OneDrive/Google Drive 的子文件夹），让文件生成即同步
- 若需跨平台或集中管理，把备份逻辑抽成独立脚本：
mysqldump -h host -u user db_name > /path/to/bak_$(date +%Y%m%d).sql，再用rclone或aws s3 cp推送到对象存储 - 用系统级定时器（
crontab或 Windows 任务计划程序）调用该脚本，而非依赖 Navicat GUI 的「设置任务计划」
容易被忽略的关键细节
很多人以为勾选了「同步」就万事大吉，但真正危险的是静默失效——备份任务在新设备上看似存在，实则路径错误、权限缺失、触发器未注册，导致某天发现「最近一次备份时间」停留在三个月前，而日志里没有任何错误提示。
最稳妥的做法永远是：在新设备上手动跑一次完整备份流程，确认文件真实生成、可读、路径可访问，再交由系统定时器接管。
