SQL Server 还原 BAK 卡顿本质是 sqlservr.exe 同步读取远程文件导致网络敏感，应优先落地本地磁盘、还原前用 RESTORE HEADERONLY/FILELISTONLY 验证、合理设置 STATS/BUFFERCOUNT/MAXTRANSFERSIZE 参数，并避免 UNC/URL 直连。
SQL Server 还原 BAK 文件时网络卡顿，本质是 RESTORE DATABASE 在拉取远程文件
不是还原慢，而是 sql server 进程（sqlservr.exe）自己去读取远程路径——比如 \192.168.10.5ackupprod.bak 或 https://mystorage.blob.core.windows.net/backups/prod.bak。它不走你本地的下载工具或加速代理，所有 io 都由 sql server 的线程同步发起，一旦网络延迟高、丢包多，就会卡在 restore 的“正在读取备份头信息”或“正在处理页”阶段，甚至报错 operating system error 121 (the semaphore timeout period has expired)。
实操建议：
- 别用 UNC 路径直连远端 SMB 共享——Windows SMB 协议对高延迟/丢包极敏感，尤其跨公网或跨 AZ 时；
- 避免用
RESTORE FROM URL直接还原 Azure Blob，除非已启用WITH CREDENTIAL且存储账户启用了 HTTPS + 服务端加密； - 优先把 BAK 文件先落地到数据库服务器本地磁盘（哪怕只是临时目录），再执行
RESTORE DATABASE ... FROM DISK = 'C: empprod.bak'； - 如果必须远程触发，用
robocopy /J /R:2 /W:3（启用无缓冲复制、重试 2 次、每次等 3 秒）代替copy或拖拽上传，减少因 TCP 重传导致的挂起。
还原前用 RESTORE HEADERONLY 和 RESTORE FILELISTONLY 验证文件可读性
很多人跳过这步，直接 RESTORE DATABASE，结果卡住 10 分钟才报错。其实这两个命令能快速暴露底层 IO 问题：它们只读备份文件开头几 KB，耗时短，但同样走 SQL Server 的文件访问栈。
常见错误现象：
-
Msg 3203, Level 16, State 1: Read on "\servershare ile.bak" failed—— 网络中断或权限不足； -
Msg 3013, Level 16, State 1: RESTORE HEADERONLY is terminating abnormally—— 文件损坏或被其他进程锁住（如杀毒软件正在扫描）； - 命令执行超 30 秒没返回 —— 基本可判定是网络层或 SMB 服务响应异常。
使用场景：只要 BAK 来源不是本机物理盘，每次还原前都应跑一遍：
RESTORE HEADERONLY FROM DISK = '\10.20.30.40ackupprod.bak';
成功后立刻跟一句：
RESTORE FILELISTONLY FROM DISK = '\10.20.30.40ackupprod.bak';
确认逻辑名、文件路径、大小无误，再进正式还原。
还原命令里加 STATS = 5 和 WITH BUFFERCOUNT 控制节奏
默认还原行为是“全速冲”，但网络不稳定时，大 buffer 容易积压未确认数据包，触发 TCP 重传风暴，反而更慢。适当降低吞吐节奏，反而更稳。
参数差异与影响：
-
STATS = 5：每完成 5% 输出一行进度，方便你判断是否真卡死，还是只是慢； -
WITH BUFFERCOUNT = 32（默认通常是 7–16）：增加并发 buffer 数可提升吞吐，但超过 64 可能挤占 SQL Server 内存，引发RESOURCE_SEMAPHORE等待； -
MAXTRANSFERSIZE = 4194304（4MB）：比默认 65536（64KB）更适合千兆以上稳定链路；若丢包率 > 0.1%，建议改回131072（128KB）减少单包失败代价； - 别加
RECOVERY直到最后一步——先用NORECOVERY还原，确认数据文件写入完成再恢复，避免因日志重做阶段网络抖动中断。
Linux 上 SQL Server 还原 BAK 必须用本地路径，且注意 SELinux 和挂载选项
SQL Server for Linux 不支持 UNC 或 URL 还原，所有路径必须是本地文件系统。如果你把 BAK 放在 NFS 或 CIFS 挂载点下，很容易因挂载参数不当导致还原失败或极慢。
容易踩的坑：
- NFS 挂载漏了
noac（关闭属性缓存）或hard,intr，会导致 SQL Server 读文件时被内核挂起； - CIFS 挂载没加
cache=none和uid=mssql,gid=mssql，权限和缓存策略不匹配； - SELinux 开启时，
restorecon -Rv /var/opt/mssql/backup/必须执行，否则sqlservr进程无法读取文件（报错Operating system error 5(Access is denied.)）； - 不要用
/tmp或/var/tmp存 BAK——很多发行版会自动清理 tmpfs 下内容，或设置 noexec。
最稳妥做法：用 rsync -avz --partial --progress user@remote:/path/to/prod.bak /var/opt/mssql/backup/ 同步完再还原，rsync 自带断点续传和校验，比 scp 更耐丢包。
网络 IO 是还原过程里最不可控的一环，而 SQL Server 对它的抽象又很薄——它不重试、不降速、不换路径。所以优化重点从来不在“怎么让还原更快”，而在于“怎么让 SQL Server 少碰网络”。落地、验证、节流、锁权，四步做完，90% 的远程还原卡顿就消失了。
