Navicat无法直接还原SQL Server的.bak文件，仅可作为执行RESTORE DATABASE语句的窗口；真正还原由SQL Server实例完成，需先用RESTORE FILELISTONLY查逻辑名，再执行含WITH REPLACE、RECOVERY、MOVE的完整语句，并确保SQL Server服务账户对备份及目标路径有权限。
navicat 无法直接还原 sql server 的 .bak 文件——它压根不提供该能力，也不是“转sql”就能绕过去的。所谓“在 navicat 中还原”，实际只是用它当个 sql 执行器，真正干活的是 sql server 实例本身。
Navicat 根本没有「导入 .bak」功能
你在菜单、右键、备份/还原面板里找不到入口，不是操作遗漏，是 Navicat 确实没做这个功能。它不解析 .bak 结构，不调用 Windows 文件系统权限，也不具备 sysadmin 权限提升能力。常见现象包括：
-
Failed to import backup file或Unrecognized file format - 拖入
.bak到查询窗口，报错Incorrect syntax near '0x'（那是二进制文件头） - 点“从文件还原”后卡住，或弹出空设备列表——因为 Navicat 尝试读取路径时，根本没权限访问 SQL Server 服务账户能读的目录
必须先查清逻辑文件名，否则 RESTORE DATABASE 必报错
.bak 里存的是原始数据库的逻辑名（LogicalName），不是你猜的 mydb_data 或 mydb_log。硬写 MOVE 子句会触发：
Logical file 'xxx' is not part of database
正确做法是在 Navicat 查询窗口中先执行：
RESTORE FILELISTONLY FROM DISK = 'D:\backup\mydb.bak'
看返回结果中的两列：LogicalName（必用）和 Type（D=data，L=log）。之后的 MOVE 必须严格匹配这两个名字。
还原语句里三个参数不能少：WITH REPLACE、RECOVERY、MOVE
漏掉任意一个，都会导致失败或数据库处于不可用状态：
-
WITH REPLACE：跳过“目标数据库已存在”的拦截 -
RECOVERY：让数据库立刻上线；缺它会卡在RESTORING状态，连不上、查不了 -
MOVE：重定向数据/日志文件路径；不写就默认还原到原服务器路径（大概率不存在）→ 报错Directory lookup failed
最小可用语句示例：
RESTORE DATABASE [mydb] FROM DISK = 'D:\backup\mydb.bak' WITH REPLACE, RECOVERY, MOVE 'mydb_main' TO 'D:\data\mydb.mdf', MOVE 'mydb_main_log' TO 'D:\log\mydb.ldf'
路径权限才是最大隐形坑
不是你 Windows 登录账户能打开那个 .bak，SQL Server 就能读——它用的是自己的服务账户（如 NT Service\MSSQL$INSTANCENAME）。常见翻车点：
- 把
.bak放桌面、文档、U盘，SQL Server 服务无权访问 - 路径含中文或空格，未用
N''前缀包裹（应写N'D:\备份\mydb.bak'） - 目标
.mdf/.ldf路径不存在，且父目录无写权限（SQL Server 不自动建目录）
最稳妥做法：把 .bak 拷到 SQL Server 服务器本地磁盘（如 C:\temp\），再执行还原。远程 UNC 路径或网盘直连，极易因 SMB 超时卡死。
