Navicat 备份加密功能实际不可用。它不提供对.sql或.ncb备份文件的AES/SM4等加密选项，“加密备份”是误将连接密码保存加密当作备份加密；SQL导出为纯文本，压缩不等于加密；.ncb格式未公开加密机制，不建议用于合规场景；可靠方案需绕过GUI，采用“导出→加密→归档”三步法，如用gpg或7-Zip命令行加密，并严格管理密钥与验证恢复流程。
Navicat 备份加密功能实际可用吗？
不可用。navicat 本身不提供对备份文件（如 .sql 或 .ncb）的加密保护功能——它没有“加密备份”开关，也没有 aes/sm4 等加密选项。所谓“开启备份文件加密保护”，是常见误解，源于把「连接密码保存加密」或「数据库用户密码策略」误认为备份加密。
为什么 Navicat 不加密导出的 SQL 文件？
因为 SQL 导出本质是纯文本操作：mysqldump、pg_dump 等底层命令默认不加密输出；Navicat 只是图形化调用它们，未做额外封装。即使你勾选了“压缩”，压缩 ≠ 加密，.zip 或 .gz 文件解压后仍是明文 SQL。
- Navicat Premium 16+ 支持导出为
.ncb（Navicat Cloud Backup）格式，但该格式仅用于同步到 Navicat Cloud，本地无法直接解密验证，且官方未公开加密机制，不建议用于合规性场景 - MySQL 8.0+ 的
mysqlpump和 PostgreSQL 的pg_dump均不支持原生命令行加密输出 - 试图用 Navicat “导出向导”里勾选“密码保护”只会加密导出任务配置，不影响生成的文件内容
真正能落地的备份加密方案（三步走）
必须绕过 Navicat 的 GUI，用系统级工具链补足加密环节。核心思路：导出 → 加密 → 归档。推荐组合：
- 用 Navicat 执行「导出为 SQL 文件」，路径设为固定位置（如
/backups/app_20240520.sql），取消自动压缩 - 立即用
gpg加密：gpg --symmetric --cipher-algo AES256 /backups/app_20240520.sql（会生成app_20240520.sql.gpg） - 删除原始
.sql文件，只保留.gpg；解密时用gpg --decrypt app_20240520.sql.gpg > restored.sql - Windows 用户可用
7-Zip命令行：7z a -p"yourpass" -mhe=on backup.7z data.sql（注意：-mhe=on才加密文件头，否则密码易被绕过）
容易被忽略的关键细节
加密不是加个密码就完事。很多团队卡在权限、路径和恢复验证上：
-
gpg默认使用 UTF-8 密码，若含中文或特殊符号，在非 Linux 环境可能解密失败；建议用英文+数字组合 - Navicat 导出的 SQL 文件默认带
SET NAMES utf8mb4等语句，加密后若用错误编码打开，会显示乱码——但这只是查看问题，不影响gpg --decrypt后的可执行性 - 别把加密密钥存在和备份文件同一台机器上；更别写在 Navicat 的「计划任务」脚本注释里
- 定期用
gpg --list-packets xxx.sql.gpg验证加密是否生效（应看到symkey encrypted字样）
备份加密真正的难点不在工具选择，而在密钥生命周期管理和恢复流程演练。没试过用密钥还原过一次完整数据库，就不算真正启用加密。
