这个问题是驱使我坚果！
我们将所有生产数据库备份到networking共享中，然后每晚备份到磁带上。
星期一至星期五晚8点 – 完整备份，然后进行日志备份
周一至周五早上7点至下午7点，以半小时为间隔 – 备份日志
自从3年前我们从SQL Server Standard 2000迁移到2008年以来，我们的备份一直以这种方式工作。 最近，星期一的第一次日志备份失败了。 不是每一次，但几乎每一次！ 剩下的一周，我们没有任何问题。 我想这个问题可能与在没有备份的周末之后尝试的日志备份的大小有关。
现在到这个问题上，我需要一个修复…
所有这一周，我们最大的两个数据库上的每个完整备份都失败了（两个备份压缩均小于1GB）。 源服务器和目标服务器上有足够的磁盘空间。 我猜问题是完成这些数据库的备份所需的时间和/或完成这些备份所需的备份文件的大小。 将备份目标更改为本地存储可以正常工作（而且速度非常快）。
从工作经历，我可以find一些提示，问题可能是…
代码：0xC002F210（总是这个代码，但混合以下描述…）
“操作系统在'\ drserver \ SQLBackups \ Database.bak'上尝试'SetEndOfFile'时，返回错误'64（未能检索到此错误的文本。原因：1815）'。BACKUP DATABASEexception终止。
“操作系统在'\ drserver \ SQLBackups \ Database.bak'上尝试”FlushFileBuffers“时，返回错误'64（未能检索到该错误的文本。原因：1815）'。BACKUP DATABASEexception终止。
请帮助保存我的头发和理智！
错误64意味着“指定的networking名称不再可用”，这是一种有关networking问题的通用错误消息。 错误0xC002F210似乎是来自SQL Server的通用错误，意味着作业失败。 所以你看到这个问题有一个莫名其妙的原因。
Red-Gate网站上的build议build议您将registry项HKLM \ SYSTEM \ CurrentControlSet \ Services \ LanmanWorkstation \ Parameters中的SessTimeout值增加（或设置）为更高的值。 300被build议（显然45是默认的）。
如果更改此值，则可能必须在更改生效之前重新引导客户端（SQL Server）。