我们有一个用于BizTalk的虚拟机和一个用于SQL后端的单独虚拟机。我们使用Veeam进行备份，这基本上是启动了虚拟机的快照。当这个快照在SQL虚拟机上完成时，应用服务器上的BizTalk服务就会失效。通常它们会自动重启，但有时这需要手动干预才能启动服务。在BizTalk服务器上记录了以下错误。
是否有任何超时设置或配置更改可以让BizTalk服务在快照过程中保持运行？
发生了一个错误，需要终止BizTalk服务。最常见的原因有以下几种。1）意外的内存外错误。或 2）无法连接或失去对 BizTalk 数据库之一的连接。 该服务将在1分钟内关闭并自动重新启动。如果有问题的数据库仍然不可用，这个循环将重复进行。
错误信息。DBNETLIB][ConnectionRead (recv().]一般网络错误。请检查您的网络文档。错误来源：[DBNETLIB][连接读取(recv().]一般网络错误。
BizTalk主机名：BizTalkServerApplication Windows服务名：BTSSvc$BizTalkServerApplication。
我们在使用BizTalk 2009和BizTalk 2013时都遇到了同样的情况和错误，每个都设置了两个App服务器和一个SQL DB服务器。
当我们的VMware在Application服务器上进行快照备份的最后一步时，它会冻结Application服务器10秒左右，使其无法接收数据包。 在SQL Server 2008和2012上，默认情况下，它每隔30秒（30000毫秒）就会向客户端发送一次keep-alive数据包。如果SQL服务器未能收到App服务器返回的响应，它将间隔1秒（1000毫秒）发送5次重试（默认设置）的keep-alive请求。 如果SQL仍然没有收到响应，它将终止连接，这将导致App服务器上的BizTalk主机复位，在我们的案例中，当我们的德国制造的ERP系统在该复位期间将其EDI文档发送过来给BizTalk时，传输将失败。
我们通过在DB服务器和App服务器上运行NetMon，等待下一条错误信息来捕捉这个问题。 经过检查，我们看到5个SQLkeep-alive数据包相隔1秒被发送到App服务器，同时Application服务器上根本没有收到数据包。 乍一猜测，大家可能会认为它们是 "刚丢的网络数据包"，很少有这样的情况。 然后，我们将其与虚拟机快照的时间进行了关联，现在确认每天每次快照结束时，App服务器都会冻结。
作为短期到中期的解决方法，我们通过添加注册表值TcpMaxDataRetranmissionss并将其设置为30（因此在SQL宣布客户端无响应前30秒），提高了SQL在宣布连接死机前的重试次数（默认为5）。这对我们来说暂时掩盖了这个问题，大家自行斟酌使用。
我们也在研究基于Agent的虚拟机快照版本，可能会缓解冻结服务器的状况。
是否有任何超时设置或配置更改可以让BizTalk服务在快照过程中保持运行？
据我所知，没有，不过你可能想在谷歌的配置选项中搜索一下。btsntsvc.exe.config. 文件，它位于您的BizTalk安装目录中。
所有通过BizTalk的消息都会被写入BizTalkMsgBoxDb，如果你正在运行跟踪、BAM等，就会涉及到它的其他数据库。唯一能缓存 "东西 "和处理数据库中断的服务是企业单点登录（ESSO）服务。因此，BizTalk需要一个与数据库服务器的持久连接来保持 "启动"，因此，为什么您的主机实例(BizTalkServerApplication)会停止--如果数据库不在那里，它根本无法处理消息。
我想补充的是，您的备份方法可能不受微软的支持，我进一步建议您认真考虑在备份期间让您的数据库服务器离线的方法是否可行？
BizTalk在产品中内置了一个相当强大的各种数据库的备份解决方案，我建议你看看使用这个 支持 方法。
如果您确实需要对数据库系统进行快照--比如每晚一次--您可能需要考虑停止BizTalk主机实例，执行快照，然后通过一些脚本任务重新启动主机实例。
您还可能要考虑检查是否有任何针对您的BizTalk Server版本的热修复程序包含在累积更新中，可能有助于解决您的问题。