Navicat 17 的 .psc/.nb3 备份文件无内置 CRC/SHA 校验，仅解析文件头即视为可用，损坏常延迟至还原中途才报错；可靠验证须改用「转储 SQL 文件」并手动检查结构、数据及语法有效性。
备份文件本身不支持 Navicat 17 内置校验
Navicat 17 的 .psc（PostgreSQL）或 .nb3（MySQL）备份文件**没有内置 CRC/SHA 校验机制**，点击「还原」时也不会自动验证完整性。它只做格式头解析：能读出元数据就认为“可用”，哪怕后续解密失败或数据块损坏，错误也常延迟到还原中途才抛出，比如卡在“正在恢复表结构”后报 Decryption failed 或 Invalid backup file format。
必须用还原前的 SQL 导出 + 手动执行验证
真正可落地的验证方式，是绕开 .psc/.nb3，改用标准 SQL 路径生成可执行、可检查的备份：
- 右键数据库 → 【转储 SQL 文件】→ 勾选「结构和数据」+「兼容目标版本」（如 MySQL 5.7）
- 导出前手动执行
SET SESSION sql_mode = '';，避免严格模式导致导入失败 - 导出的
.sql文件可用文本编辑器打开，快速确认开头有CREATE DATABASE、中间含INSERT INTO ... VALUES (...)、结尾无截断（最后一行不是半截 INSERT） - 用命令行快速验证语法有效性（不实际执行）：
mysql -h localhost -u user -p --one-database your_db -e "source /path/to/backup.sql;" 2>/dev/null || echo "SQL 语法错误"
自动化场景下必须依赖外部工具链
如果你已用 Navicat 17 的「导出为脚本」功能生成了 mysqldump 或 pg_dump 命令，验证逻辑就得移出 GUI：
- 对
mysqldump输出：用head -n 100 backup.sql | grep -q "CREATE TABLE"确认头部结构存在 - 对
pg_dump输出：用grep -m1 "COPY public\." backup.sql >/dev/null && echo "数据段存在" - 检查文件大小是否异常：空备份通常 5MB；若大小与历史备份偏差超 30%，需人工抽查
- 别依赖
file backup.nb3命令——.nb3是自定义加密包，file只会返回 data，无实质判断价值
最容易被忽略的损坏信号是「还原成功但数据缺失」
很多用户看到「COMPLETED SUCCESSFULLY」就以为完事，结果上线后发现某张表没数据、某个字段全为 NULL。这往往不是文件损坏，而是备份时权限不足或查询被中断导致部分对象未写入：
- 还原前先查原库：运行
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'your_db'; - 还原后立刻查目标库：执行同样语句，比对数量；再挑 2–3 张大表，对比
COUNT(*)和MAX(id) - Navicat 17 的「备份执行日志」窗口里若出现
skipped view xxx或no rows exported for table yyy，这些就是静默丢失点，必须记录并补漏
