Navicat的“Encrypt backup file”选项仅对.ncb文件做私有封装加密，不支持标准AES/SM4，.sql导出始终明文；真正可用的加密须绕过GUI，用gpg或7-Zip命令行实现“导出→加密→归档”。
navicat 的“备份文件加密”功能在界面操作上看似存在，但实际无法提供真正可用的、符合安全合规要求的文件级加密保护。它不生成 aes/sm4 加密的 .sql 或 .ncb 文件，所谓“加密”只是对备份任务配置或连接凭据做了混淆，并未作用于导出内容本身。
Navicat 备份界面里的 “Encrypt backup file” 是什么
这个选项只在部分版本（如 Navicat Premium 16+）的「Backup Database」向导中出现，勾选后会要求输入密码。但它实际做的是：
- 对内部生成的
.ncb文件使用私有封装加密封装（非标准 PKCS#7），仅限同版本 Navicat 解密 - 不支持导出为标准加密格式（如
.sql.gpg或.sql.enc） - 若你导出的是
.sql文件，该选项根本不起作用——.sql始终是明文，哪怕勾了“加密”也照样裸露PASSWORD字段和所有数据
为什么“压缩 + 密码”不等于加密
Navicat 的「Compress backup file」和「Encrypt backup file」是两个独立开关，但它们的组合仍不可靠：
- 压缩用的是 zlib，解压后仍是明文 SQL ——
unzip backup.zip就能直接cat查看所有表结构与数据 - 某些版本声称“密码保护压缩包”，实则只是给 ZIP 加了密码，且未启用
-mhe=on（即未加密文件头），导致密码极易被暴力绕过 - 导出为
.ncb并加密后，你无法用任何命令行工具验证其完整性或解密内容，也无法做增量比对或自动化校验
真正能落地的加密方案：绕过 Navicat GUI
必须放弃依赖界面按钮，改用系统级工具链实现“导出 → 加密 → 归档”。推荐以下路径：
- 在 Navicat 中执行「导出为 SQL 文件」，路径设为固定位置（如
/backups/app_$(date +%Y%m%d).sql），取消勾选「Compress backup file」 - 立即用
gpg对称加密：gpg --symmetric --cipher-algo AES256 /backups/app_20260427.sql（生成.sql.gpg） - 删除原始
.sql：rm /backups/app_20260427.sql；解密时用gpg --decrypt app_20260427.sql.gpg > restored.sql - Windows 用户可用 7-Zip 命令行：
7z a -p"yourpass" -mhe=on backup.7z data.sql（注意必须带-mhe=on）
容易被忽略的关键细节
很多团队卡在看似微小但致命的环节上：
-
gpg默认按 UTF-8 解析密码，若含中文或 emoji，在 macOS 或 Windows 上可能解密失败；建议只用英文+数字+常见符号 - 别把加密密钥或口令文件和备份文件存同一台机器；更别写在 Navicat 的「计划任务」脚本里
- Navicat 导出的 SQL 默认含
SET NAMES utf8mb4，加密后用文本编辑器打开显示乱码是正常现象——只要gpg --decrypt输出可执行 SQL 即可 - 定时任务（如 crontab）调用
gpg时，必须显式设置GPG_TTY、--batch --yes和--passphrase-file，否则静默失败
加密不是点一下“Encrypt”就完事的事。真正的安全边界，藏在你是否控制了密钥生命周期、是否验证了解密流程、以及是否让明文在磁盘上停留过零秒。
