不能直接共享含密码的连接配置来备份团队数据库，因Navicat Cloud同步的.navicat_project文件若含Save password设置，导出.npz后可解包获取SSH隧道参数、内网地址、用户名等元数据，组合即构成攻击链路；正确做法是DBA为每人创建独立只读备份账号，本地定时任务执行备份并统一路径治理与还原验证。
不能直接共享含密码的连接配置来备份团队数据库——这等于把钥匙和锁一起发出去。真正安全的做法是：让每个成员用自己的账号、权限、本地环境去执行备份，而不是靠 navicat cloud 同步一个“谁点谁连”的连接。
为什么共享连接做备份极危险
Navicat Cloud 的「共享连接」同步的是 .navicat_project 文件，里面若保存了密码（勾选了 Save password），即使加密存储，导出为 .npz 后仍可解包看到 ssh_host、mysql_host、user 等元数据。一旦有人本地有对应私钥或复用密码，就能直连生产库——这不是备份，是授权攻击入口。
- Owner 删除项目 ≠ 所有成员本地缓存清空，旧版 Navicat 可能仍保留已同步的连接副本
- Manager 角色成员双击连接即可尝试登录，权限控制在数据库层，不在 Navicat Cloud 层
- SSH 隧道参数 + 内网地址 + 用户名 = 完整跳板链路，比单个密码更致命
正确做法：每人独立建只读备份账号 + 本地定时任务
备份行为必须绑定身份、权限与执行环境，不是“共享一个连接”，而是“统一规范+分散执行”：
- DBA 在数据库侧为每位成员创建独立用户，如
backup_dev01，仅授予SELECT权限，且限制到具体库/表，禁用INSERT/UPDATE/DELETE/DROP - 每个成员用自己的 Navicat 连接该账号，右键数据库 →「备份」→ 设置路径到本地非系统盘（如
D:ackups）或挂载的网络盘 - 通过「自动运行」→「新建批处理作业」添加多个
Backup xxx任务，再设触发器（如每天 2:00），避免手动遗漏 - 所有备份文件名强制带日期和责任人标识，例如：
prod_orders_20260727_dev01.psc
多库批量备份时路径必须提前锁定
很多人备份后找不到文件，问题不在操作，而在路径继承逻辑混乱：
- 右键连接 →「编辑连接」→「高级」选项卡 → 找到
设置位置→ 点「浏览」指定统一根目录（如D: avicat_backups eam_prod） - 该设置影响该连接下所有数据库的备份路径，且新连接默认继承此值
- 改完后旧备份仍在原路径，新备份才走新路径；不要依赖默认的
C:Users...DocumentsNavicat，重装系统即丢 - SQL Server 备份需额外注意：脚本中
BACKUP DATABASE [xxx] TO DISK='\192.168.1.100ackup...'的共享路径必须提前在 Windows 服务里启用Server和Workstation服务，并确认防火墙放行 445 端口
还原前最易忽略的三件事
备份成功不等于能还原成功，尤其跨环境时：
- MySQL 还原前必须确认目标实例版本 ≥ 备份源版本，否则
.psc包可能报错Unsupported backup file version - PostgreSQL 还原时若用
pg_restore命令，要加-O（忽略 owner）和--clean（先删再建），否则权限冲突 - SQL Server 还原
.bak前，得先在目标实例上手动建同名空库，并指定与原库一致的排序规则（如Chinese_PRC_CI_AS），否则还原中途失败
真正的团队备份协作，核心不是“怎么传配置”，而是“怎么管权限、控路径、验还原”。配置共享只是表象，权限隔离和路径治理才是底线。
