navicat 不支持自动上传云盘，需通过本地备份+系统级工具同步实现；备份路径须设在云盘同步目录内，定时任务须先保存批处理再调度，且需保存密码、控制文件大小、手动清理旧备份。
Navicat 本身不支持「自动上传到网盘或云存储」，所有所谓“自动上传”都是两段独立流程的叠加：Navicat 定时生成本地备份文件 + 系统级工具（如 rsync、rclone、iCloud 同步目录、OneDrive 文件夹）把该文件挪走。跳过这个认知，直接在 Navicat 界面里找“上传到阿里云/腾讯云/百度网盘”的选项，注定失败。
Navicat 备份路径必须落在云盘同步目录内
这是整个方案成立的前提。Navicat 只负责写文件，云盘只监听特定路径——两者之间没有 API 或回调机制。
- macOS iCloud：必须设为
~/Library/Mobile Documents/com~apple~CloudDocs/Navicat-Backups或访达中打开 iCloud 云盘后新建的子文件夹（如iCloud 云盘/Navicat-Backups） - Windows OneDrive：路径需是
C:\Users\{user}\OneDrive\Navicat-Backups，且该文件夹不能是符号链接（OneDrive 不跟踪 symlink） - Linux + rclone：Navicat 备份路径可任意，但后续要用
rclone copy命令推送到远程，不能依赖 Navicat 自身调度 - ❌ 错误示例：设成
~/Documents/Backups并指望 iCloud 自动同步——除非你手动开启“桌面与文稿文件夹”同步（不推荐，风险高），否则文件永远不会上云
Navicat 定时任务必须先保存批处理再设调度
很多人点开「自动运行」→「新建批处理作业」→ 直接点「Set Task Schedule」，结果按钮灰掉或调度无效。根本原因是 Navicat 要求 Batch Job 必须已保存、有明确名称和路径，才能被调度器识别。
- 右键数据库 →「备份数据库」→ 勾选「导出为 SQL 文件」→ 下一步取消「立即执行」，勾选「保存为批处理文件」（Windows）或「保存为 Shell 脚本」（macOS/Linux）
- 保存后，在「自动运行」列表中找到该任务，右键 →「Set Task Schedule」才可用
- 调度设置页的「常规」选项卡中，务必勾选「不管用户是否登录都要运行」（Windows）或「Run whether user is logged in or not」（macOS launchd 场景下等效）
- 连接密码必须已在 Connection 属性中勾选「保存密码」，否则定时执行时会因认证失败静默退出
云盘同步不是即时传输，大备份文件容易卡住
Navicat 生成的 .nbu 或压缩 SQL 文件一旦超过云盘单文件限制，就会停留在“仅在线”状态（云朵图标），无法下载、还原，且 Navicat 日志仍显示 success——这是最隐蔽的故障点。
- iCloud 单文件上限为 15GB；OneDrive 是 250GB；但实际建议单个备份控制在 2GB 以内，避免同步延迟或断连重传失败
- Navicat 不支持自动分卷。若数据库超大，需改用
mysqldump+split或pg_dump --file分片导出，再由外部脚本统一上传 - 时间戳命名必须由 Navicat 或脚本控制，例如
mydb_$(date +\%Y\%m\%d_\%H\%M).sql.gz，否则多个备份会覆盖，云盘也只会同步最后一个 - 旧备份清理不能靠云盘自动完成——iCloud / OneDrive 不提供“保留最近 N 个版本”逻辑，得用脚本定期
find /path -name "*.sql.gz" -mtime +7 -delete
真正可控的自动化，是把 Navicat 当作“备份生成器”，而不是“云同步中枢”。它的强项是图形化建模和一键导出，弱项是跨系统调度与文件生命周期管理。越早接受这个边界，越少在凌晨三点盯着一个带云朵图标的 .nbu 文件发呆。
