Windows共享认证失效导致SQL Server异地备份失败解决方法

文中 IP 均为脱敏后的示例地址，适用于实际故障排查场景。

这类问题，许多运维工程师都曾遇到过。本地备份一切正常，但异地备份却始终无法获取文件。反复排查后，往往发现并非网络不通或共享目录配置错误，而是最容易被忽视的环节——Windows 的 SMB 共享认证已经失效。本文将通过一个典型场景，深入剖析问题根源，并给出完整的解决步骤。

一、示例环境

先明确环境配置，方便对照排查。以下为脱敏后的示例信息，实际应用时请根据自身 IP 和路径进行替换。

异地备份服务器已将本地 F: 盘设为共享，共享路径为：

\\10.10.20.192\f 

因此，异地服务器本地的目标目录为：

F:\10.10.10.113 

数据库服务器要写入文件时，需要通过网络路径：

\\10.10.20.192\f\10.10.10.113 

注意，目录名 10.10.10.113 是按照数据库服务器的 IP 命名，便于识别管理。

二、问题现象

SQL Server 本地备份正常执行，备份文件按照预期生成在 F:\database\bak 目录下，例如：

F:\database\bak\ES.EMS_backup_2026_07_05_020003.bak 

但执行完传输脚本后，前往异地备份服务器检查——F:\10.10.10.113 目录下却没有任何文件。

手动尝试复制命令：

copy /Y "F:\database\bak\ES.EMS_backup_2026_07_05_020003.bak" "\\10.10.20.192\f\10.10.10.113" 

系统返回错误信息：

用户名或密码不正确。 已复制 0 个文件。 

再检查返回码：

echo 返回码：%errorlevel% 

输出结果为：

返回码：1 

问题瞬间明朗——并非文件丢失，而是传输过程受阻。

三、问题定位

先冷静地进行全面排查，已确认以下信息：

• 本地备份文件确实存在且完整；
• 数据库服务器与异地备份服务器之间的网络连通性正常；
• 异地共享目录已成功创建；
• 使用其他机器测试，可以正常写入该共享目录；
• 唯独当前这台数据库服务器，手工复制时提示用户或密码错误。

综合这些条件，问题焦点变得清晰：当前 Windows 执行账户缺少有效的异地 SMB 共享认证，或者原有的共享连接中保存的认证信息已经失效。

SMB 认证连接何时会失效？虽然没有固定的过期时间，但以下情况都可能导致认证失效：

• 数据库服务器或异地备份服务器重新启动；
• Windows 用户注销或切换账户；
• 异地备份服务器上的账户密码被人修改；
• Windows 凭据管理器中存储了旧密码未清除；
• 网络临时中断，导致原有 SMB 会话断开；
• 计划任务使用了不同的账户运行；
• 手工认证时使用的账户与计划任务实际运行的账户不一致。

虽然可能原因较多，但处理思路高度统一——删除旧的认证，重新建立连接。

四、处理步骤

1. 查看当前共享连接

首先检查数据库服务器上现有的网络连接状况：

net use 

查看列表中是否包含异地共享路径：

\\10.10.20.192\f 

2. 删除原有共享连接

net use "\\10.10.20.192\f" /delete 

如果系统提示找不到该连接，无需处理，直接跳过即可。

接着检查 Windows 凭据管理器中是否保存了旧凭据：

cmdkey /list 

如果发现与异地服务器有关的旧凭据，果断删除：

cmdkey /delete:10.10.20.192 

3. 重新认证异地共享

现在重新建立 SMB 连接：

net use "\\10.10.20.192\f" /user:10.10.20.192\Administrator * 

根据提示输入异地备份服务器的管理员密码。注意，CMD 窗口中输入密码不会显示，不要误以为键盘失效。

认证成功的标志是：

命令成功完成。 

这里有一个小技巧：认证到共享的根目录即可，无需包含子目录。

4. 验证异地目录能否访问

dir "\\10.10.20.192\f\10.10.10.113" 

如果能正常列出目录内容，说明共享路径和认证均无问题。

5. 验证异地目录写权限

echo test>"\\10.10.20.192\f\10.10.10.113\write_test.txt" 

然后到异地备份服务器上检查文件是否存在：

F:\10.10.10.113\write_test.txt 

测试完成后记得删除该文件：

del "\\10.10.20.192\f\10.10.10.113\write_test.txt" 

6. 手工复制备份文件

确认一切就绪后，开始正式传输：

copy /Y "F:\database\bak\ES.EMS_backup_2026_07_05_020003.bak" "\\10.10.20.192\f\10.10.10.113" 

如果备份文件达到几十 GB，copy 命令不会显示进度条，命令窗口可能长时间没有返回提示符，这表示传输仍在进行中，请勿强行关闭窗口。

传输完成的标志是：

已复制 1 个文件。 

同时检查返回码：

echo 返回码：%errorlevel% 

正常结果：

返回码：0 

7. 验证异地文件

在数据库服务器上查看：

dir "\\10.10.20.192\f\10.10.10.113\ES.EMS_backup_2026_07_05_020003.bak" 

在异地备份服务器本地也确认：

dir "F:\10.10.10.113\ES.EMS_backup_2026_07_05_020003.bak" 

最好对比本地原始文件的大小：

dir "F:\database\bak\ES.EMS_backup_2026_07_05_020003.bak" 

两侧文件字节数一致，才能确认传输完整无误。

五、传输脚本整改

原有脚本在复制完成后直接输出“传输成功”，这存在隐患。正确做法是必须检查返回码。

xcopy "%source_path%\%today_file%" "%dest_path%" /Y /Z
if errorlevel 1 (
    echo [失败] 文件传输失败，返回码：%errorlevel%
    exit /b 1
)
echo [成功] 文件传输完成。

此外，传输大文件时更推荐使用 robocopy：

robocopy "F:\database\bak" "\\10.10.20.192\f\10.10.10.113" "ES.EMS_backup_2026_07_05_*.bak" /Z /R:3 /W:10 

返回码判断：

if errorlevel 8 (
    echo [失败] Robocopy传输失败，返回码：%errorlevel%
    exit /b 2
)

注意，robocopy 返回码小于 8 时，通常不代表复制失败，但保留判断逻辑会使脚本更加严谨。

传输完成后，再增加一道验证——检查异地文件是否真实存在：

if not exist "\\10.10.20.192\f\10.10.10.113\备份文件名.bak" (
    echo [失败] 异地目录未找到备份文件。
    exit /b 3
)

六、计划任务注意事项

经常遇到的情况是：手工复制可以成功，但计划任务运行时却依然失败。这里的关键点在于——SMB 认证是跟随 Windows 运行账户的。

因此需注意以下几点：

• 计划任务必须指定一个固定的 Windows 账户来运行；
• 该账户必须与手工执行 net use 时使用的账户保持一致；
• 尽量避免使用 SYSTEM 账户，因为它没有共享认证；
• 不要忘记勾选“使用最高权限运行”选项；
• 脚本中务必记录复制返回码，便于排查；
• 传输完成后，必须校验异地文件是否存在，以及文件大小是否一致。

七、结论

回顾整个问题，本次故障既不是备份文件本身的问题，也不是网络中断，更不是异地共享目录配置错误。真正的“元凶”是：数据库服务器当前 Windows 执行账户缺乏有效的 SMB 共享认证。

解决方案并不复杂——重新建立认证连接：

net use "\\10.10.20.192\f" /user:10.10.20.192\Administrator * 

然后再次执行复制操作：

copy /Y "F:\database\bak\ES.EMS_backup_2026_07_05_020003.bak" "\\10.10.20.192\f\10.10.10.113"

文件成功到达异地服务器的 F:\10.10.10.113 目录下，返回码为 0，问题彻底解决。

虽然看似是一个小问题，但排查过程颇为曲折。希望本次的梳理能帮助你在下次遇到类似场景时，少走弯路，快速定位并解决 SQL Server 异地备份失败的问题。