.nb3 文件损坏时无法恢复数据，因其是加密结构化存档，中断备份会导致文件头校验失败，Navicat 直接拒绝加载；手动提取无效，应优先检查其他备份或启用 binlog 回滚。
.nb3 文件损坏时，Navicat 无法从中恢复数据。
Navicat 的原生备份（.nb3）是加密、结构化存档，不是普通 SQL 文件。它依赖完整写入和校验机制 —— 只要备份过程被中断（如断电、强制退出、磁盘满），生成的 .nb3 文件大概率无法加载，还原界面会直接不显示该文件，或点击后报错 Invalid backup file 或 Failed to load backup metadata。
为什么“未完成的 .nb3 备份”基本不可用
navicat 在创建 .nb3 时会先写元数据头，再流式写入压缩数据块，最后写校验尾。中断发生在任意阶段都会导致文件结构断裂。它不像导出 sql 那样能部分读取 —— .nb3 加载器在解析开头就失败，根本不会尝试读后续内容。
遇到中断备份，优先检查有没有其他可用备份源
- 查看 Navicat 设置里的默认备份路径（
工具 → 选项 → 其他 → 备份文件保存路径），确认是否还有更早的、完整的.nb3文件 - 检查是否启用了「自动备份策略」，对应时间戳的备份可能已成功落盘
- 翻找数据库服务器本地是否有
mysqldump或pg_dump生成的 SQL 文件（比如通过定时任务或脚本导出） - 确认 binlog 是否开启且保留足够久：MySQL 可用
mysqlbinlog回滚到中断前一秒，但需知道确切时间点或 position
别指望从 .nb3 文件里手动提取数据
有人尝试用十六进制编辑器打开 .nb3，想找回表结构或部分 INSERT 语句 —— 这几乎无效。Navicat 对内容做了 LZMA 压缩 + 自定义序列化 + AES 加密（即使没设密码，也含空密钥加密层），没有官方解包工具，逆向成本远高于重建。
真正能救急的替代方案只有两个
一是用 Navicat 的「导出向导」导出为 .sql 文件（非备份，而是实时查询结果导出），这类文件即使中途失败，也可能生成部分可用的 SQL 片段；二是直接连上数据库，用 SELECT ... INTO OUTFILE 或客户端命令行做紧急快照 —— 它们不依赖 Navicat 备份机制，失败时至少有可读文本残留。
.nb3 文件，就等于它已被 Navicat 主动拒绝 —— 不是权限问题，也不是路径错误，而是文件头校验通不过。这时候花时间折腾文件，不如立刻切到 binlog 或日志审计查最近变更。
