我们明年将转向 SQL Server 2014 Expensive Edition Q1。现在我们使用的是 SQL Server 2005 Standard Edition，因此我们无法访问非常棒MIRROR TO的备份选项（我们使用 Ola Hallengren 的脚本）。
现在我们正在使用 robocopy 将文件复制到网络共享，以防我们存储在本地的备份损坏、丢失或决定休个长假。我的问题是，当我们使用该MIRROR TO选项时，它是否比仅使用 robocopy、xcopy 或 Powershell 解决方案占用更多/更少的资源？MIRROR TO当我们在 SQL Server 中使用时到底发生了什么？如果可能的话，寻找一些“具体细节”的答案。
我在这里根据我的实施方式猜测
MIRROR TO：如果您使用
MIRROR TO. 这意味着他们读取的每个块都被写入了两次。数据流有一个分支。他们肯定没有做的是一次写入数据然后将其复制过来。这将 a) 导致对数据进行额外的读取传递，并且 b) 还会打开一个数据损坏的窗口，同时只存在一个备份副本。从实现者的角度来看，分叉流的工作更少，而且结果更好。这就是我认为他们这样做的原因。
这意味着
MIRROR TO与备份成功后复制数据文件相比，它占用的资源更少。它还具有更小的数据损坏空间。数据损坏很少见，但却是一个实际问题。内存、磁盘和网络都可能有未检测到的位翻转。（是的，TCP 并不能 100% 防止这种情况发生。）鉴于企业版将对您可用这一事实，建议：使用
MIRROR TO. 它导致更少的资源使用和更少的（未检测到的）备份损坏的可能性。它还可以自动执行手动操作时可能出错的内容。SQL Server 的测试肯定比大多数内部脚本开发要好。不使用它的唯一原因是如果您的备份过程不能轻易修改以使用它。补充一点：如果不能写入镜像备份就会失败。这可能是一个不利因素（您可能超出了 RPO 目标）。这可能是一个好处，因为更容易检测到错误。
正如 Paul White 在评论中提到的那样：如果其中一个备份目的地速度很慢（或者所有数据都在同一个饱和网络链路上流动），备份可能需要比以前更长的时间。在网络链接饱和的情况下，在目标服务器上本地复制备份文件可能会更快。
可以测试该理论：使用 MIRROR TO 将数据库备份到两个具有相同性能特征的 IO 设备。如果我是正确的，您应该只观察到一点点减速，因为写入是流式和并行的。
我自己执行了这个基准测试。从 SSD（非常快）备份到两个（几乎）相同的磁驱动器。使用数据压缩（但 CPU 未达到极限）。
这种减速（1:37 对 1:14）完全在我的理论的容忍范围内。似乎有一些开销，但肯定没有单独的镜像/复制阶段。使用 Process Explorer，我观察到以 MB/秒为单位测量的 IO。这是相当稳定的。这也暗示没有单独的阶段。写入似乎与两个驱动器并行。