我们有一个用于 BizTalk 的 VM 和一个用于 SQL 后端的单独 VM。我们使用 Veeam 进行备份，这基本上会启动虚拟机的快照。在 SQL VM 上完成此快照时，应用程序服务器上的 BizTalk 服务将失败。通常它们会自动重新启动，但有时这需要手动干预才能启动服务。下面的错误记录在 BizTalk 服务器上。
是否有任何超时设置或配置更改允许 BizTalk 服务在快照过程中保持正常运行？
发生错误，需要终止 BizTalk 服务。最常见的原因如下： 1) 意外的内存不足错误。或 2) 无法连接或失去与 BizTalk 数据库之一的连接。该服务将在 1 分钟后关闭并自动重启。如果有问题的数据库仍然不可用，则此循环将重复。
错误消息：[DBNETLIB][ConnectionRead (recv()).]一般网络错误。检查您的网络文档。错误来源：
BizTalk 主机名：BizTalkServerApplication Windows 服务名称：BTSSvc$BizTalkServerApplication
我们在使用 BizTalk 2009 和 BizTalk 2013 时遇到了相同的情况和错误，每个都设置有两台应用服务器和一台 SQL DB 服务器。
当我们的 VMware 在应用程序服务器上执行快照备份的最后一步时，它会冻结应用程序服务器大约 10 秒，阻止它接收数据包。在 SQL Server 2008 和 2012 上，默认情况下它将每 30 秒（30,000 毫秒）向客户端发送一次保持活动数据包。如果 SQL Server 未能接收到来自 App 服务器的响应，它将每隔 1 秒（1,000 毫秒）发送 5 次重试（默认设置）的 keep-alive 请求。如果 SQL 仍然没有收到响应，它将终止连接，这将导致应用服务器上的 BizTalk 主机重置，在我们的例子中，当我们的德国制造的 ERP 系统在此期间将其 EDI 文档发送到 BizTalk重置期间，传输将失败。
我们通过在 DB 和 App 服务器上运行 NetMon 来解决问题，等待下一条错误消息。经过检查，我们看到五个 SQL keep-alive 数据包以 1 秒的间隔发送到应用服务器，同时应用服务器上根本没有收到任何数据包。乍一看，人们可能会认为它们“只是丢弃了网络数据包”，但这种情况很少见。然后，我们对 VM 快照的时间进行了关联，现在确认每天每次快照完成时，应用服务器都会冻结。
作为中短期解决方法，我们通过添加注册表值 TcpMaxDataRetransmissions 并将其设置为 30（因此在 SQL 声明连接前 30 秒），提高了在声明连接失效之前的 SQL 重试次数（默认为 5）。客户无反应）。这暂时掩盖了我们的问题，请自行决定使用。
我们还在研究基于代理的虚拟机快照版本，它可能会缓解服务器冻结的情况。
是否有任何超时设置或配置更改允许 BizTalk 服务在快照过程中保持正常运行？
我不知道，但是您可能希望在 BizTalk 安装目录中的btsntsvc.exe.config文件中使用 Google 配置选项。
通过 BizTalk 的所有消息都写入 BizTalkMsgBoxDb，如果您正在运行跟踪、BAM 等，则涉及其其他数据库。唯一可以缓存“资料”和处理数据库中断的服务是企业单点登录 (ESSO)服务。因此，BizTalk 需要与数据库服务器建立持久连接以保持“启动”状态，这就是为什么您的主机实例 (BizTalkServerApplication) 正在停止 - 如果数据库不存在，它根本无法处理消息。
我要补充一点，Microsoft 可能不支持您的备份方法，我进一步建议您认真考虑在备份期间使数据库服务器脱机的方法是否可行？
BizTalk 为产品中内置的各种数据库提供了一个非常强大的备份解决方案，我建议您看看使用这种受支持的方法。
如果您确实需要拍摄数据库系统的快照（例如每晚一次），您可能需要考虑停止 BizTalk 主机实例，执行快照，然后通过某些脚本任务重新启动主机实例。
您可能还需要考虑检查累积更新中是否包含针对您的 BizTalk Server 版本的任何修补程序，这些修补程序可能有助于解决您的问题。