Navicat 不支持自动上传备份到 FTP 服务器。其导出向导中的“远程服务器”选项仅调用脆弱的内置 FTP 客户端，无断点续传、无错误重试、不校验完整性，且不随计划任务自动执行；真正可行方案是 Navicat 生成本地备份后，用 lftp/curl 等命令行工具定时推送并校验。
navicat 本身不支持“自动上传备份到 ftp 服务器”这个完整动作——它能生成备份文件，也能在导出向导里填 ftp 参数，但那个「保存到远程服务器」选项实际调用的是非常脆弱的 ftp 客户端逻辑，极易因超时、权限、被动模式失败而静默中断，且无法校验上传完整性。
Navicat 导出向导里的“远程服务器”到底在做什么
这个功能本质是 Navicat 内置了一个简易 FTP 客户端，在导出 SQL 文件的同时尝试直连 FTP 服务器并上传。但它不支持断点续传、无重试机制、不校验 MD5、不处理 530/425/426 等常见 FTP 错误码，且一旦网络抖动或服务器启用了 PASV 模式限制（比如云厂商默认关闭），就会卡住或报错后丢弃文件。
更关键的是：它和 Navicat 的「自动备份」计划完全解耦——你设了每天凌晨 2 点自动备份，但导出向导里的 FTP 上传只在手动点击「开始」时触发一次，不会随计划任务自动执行。
- 导出向导中选「远程服务器」后填的
host、port、username、password都是明文存在 Navicat 配置里，无加密保护 - 路径必须写绝对路径（如
/backup/），不能用变量或时间戳，导致每次覆盖同名文件 - 不支持 SFTP 或 FTPS，仅限传统 FTP（明文传输账号密码）
真正可行的自动上传方案：本地备份 + 外部工具推送
把 Navicat 当作“备份生成器”，用操作系统原生能力完成上传——稳定、可调试、可加校验、可集成日志监控。
核心步骤只有三步：固定备份路径 → 生成带时间戳的文件名 → 用命令行工具上传。
- 在 Navicat 备份配置中，把保存路径设为固定目录，例如
C:\navicat_backups\（Windows）或/Users/me/navicat_backups/（macOS/Linux） - 勾选「使用时间戳命名」或手动在文件名中加入
$(date +%Y%m%d_%H%M)类变量（Linux/macOS）或$(Get-Date -Format 'yyyyMMdd_HHmm')（PowerShell） - 上传命令示例：
ftp -n ftp.example.com <<EOF\nuser username password\nbinary\ncd /backup\nlcd C:\navicat_backups\nmput backup_*.sql\nquit\nEOF——但更推荐用lftp或curl替代原生ftp，它们支持重试和 SSL
为什么别用 Windows 任务计划直接调 Navicat.exe 执行上传
Navicat 的 GUI 进程在无桌面会话时（比如服务账户后台运行）会卡在 FTP 连接阶段，因为它的 FTP 模块依赖 Windows GDI 和交互式网络栈，不是纯命令行工具。
你看到任务计划里显示“已运行”，但日志里没有成功标记，FTP 目录里也没有文件——大概率是进程挂起在连接握手阶段，没报错也没退出。
- 即使强制指定
navicat.exe -batchjob "b1.nbk"，它也只执行备份，不触发导出向导里的 FTP 步骤 - 想绕过 GUI 调用 FTP，得用 AutoHotKey 或 UI Automation 模拟点击，极难维护且一升级就崩
- 真正的自动化必须脱离 GUI 上下文：用
mysqldump+lftp组合，或用 Navicat 生成 .nbk 后，用脚本解析其内容提取连接参数再调外部命令
最易忽略的一点：Navicat 生成的 .ndb 文件（加密备份）无法被 lftp/curl 直接上传校验——它内部是二进制封装，FTP 上传后若损坏，还原时才会报错。建议统一用 SQL 文本备份，体积大点但可管道校验、可 grep 抽样、可 diff 对比。
