我们目前正在为 Windows 文件服务器实施 DR 策略。我们已经排除了存储复制，因为它是一个预览功能，并且故障转移集群是为高可用性而设计的，而不是 DR。DFSR 在复制打开/锁定文件方面也存在缺陷，因此不适合该任务。
文件服务器 VM 的 SAN 到 SAN 复制对我来说似乎是最好的方法，尽管我已经被警告不要这样做，因为复制是未在更高级别合并的原始副本，可能导致不一致文件系统或损坏的文件。但是，对于以这种方法复制的任何服务器，这一事实都是正确的，这也是我们 DR 计划中用于其他服务器的方法。VSS/以前的版本也总是可以用来恢复任何损坏的文件。
进行 SAN 复制的好处是否大于文件损坏的风险？或者有没有更好的方法对文件服务器进行 DR？也许有一种产品可以执行更高级别的复制/快照，从而最大限度地减少数据中的逻辑不一致？
注意：集群运行 vSphere 5.5
SAN 到 SAN 复制是您在宣布灾难后尽快使文件服务器恢复联机并尽可能减少损失的最佳选择。请注意，这种类型的 DR 保护不能保护与本地备份相同的东西 - 例如，您不能使用复制的 SAN 卷来取消删除上个月的文件。
损坏的文件不是 SAN 到 SAN 复制的危险，除非是主站点上的文件服务器损坏了它们。每个提供基于块的存储 (LUN) 复制的 SAN 都有一些机制来防止损坏和保证一致性。这是一个比大多数人知道的更棘手的问题，因为出于优化原因，即使没有复制，写入也经常无序地应用于磁盘。这就是为什么大多数存储的写入缓存具有某种电源故障安全网（如电池或 UPS）：如果没有仅保存在缓存中的写入，则底层磁盘可能已损坏。通常这是可以的，但是如果你断电，你需要确保存储确认的最后一次写入被保存到磁盘，以使磁盘在启动时保持一致。
复制根据您的复制方式以不同方式处理此问题：
所有这些机制都为您提供“崩溃一致性”。磁盘处于与突然关闭服务器电源时相同的状态。从崩溃一致性副本中运行文件系统和数据库需要一些工作，但它总是可行的。如果您想要更多的东西（您在问题中提到的“更高级别”），您需要将您的复制与您的应用程序集成。这通常意味着暂停应用程序的写入，等到所有内容都被转移到存储中，然后启动复制的一致性点。这称为“应用程序一致性”。它通常会提供稍早的恢复点，但恢复时间比崩溃一致性略短。
您需要为多层次和多类型的灾难做好准备，包括完全的恶意破坏（黑客）和所有硬件的完全损失（史诗般的天气）。这将要求您将一些数据卸载到sneaker-net 分发方法（读取，外部存储，如磁带/硬盘驱动器）、某种形式的只写一次的解决方案或在线备份服务（昂贵）。
灾难恢复与简单的复制不同。在决定任何事情之前，您需要确定这一点：“我可以丢失多少数据？ ”不要以千兆字节为单位，以TIME为单位。我可以丢失 4 小时的数据，我可以丢失一天的数据吗？您选择的方法将取决于您对该问题的回答。我们都想要一个零损失的解决方案，但对于正在减轻的风险来说，这通常不是一项可行的投资。您还需要将每月/每年备份的副本保留一段时间，因为您也可能会发生您在很长一段时间内不知道的灾难（用户删除他们需要的废话）。
SAN 到 SAN 复制是恢复站点灾难的最快方法，但由于固件错误，我在 IT 生活中经历了 SAN 损坏，并且它可能会变得丑陋
您忘记编写您使用的管理程序。但如果您使用 ESX，我建议使用 SAN 复制 vReplicator 产品。默认情况下每 15 分钟复制一次，并且您的远程 VM 处于准备就绪状态。vReplicator 需要一个 vCenter 许可证和一个物理主机来保存复制的 VM。（可能比另一个 SAN 成本更低，但就像 @IceMage 所说的那样，这取决于您可以释放多少时间）
Veeam 和其他使用快照的备份产品违反了 VMware 最佳实践，因为它们不经常这样做。它将使服务器瘫痪并且几乎没有响应。想象一下 50 台服务器做 15 分钟的快照，一天 1200 个快照？难以管理，大量存储。像 Zerto 这样的 CDP 技术为 VMware 和 Hyper-V 解决了这个问题。
我建议将 Veeam 用于文件服务器虚拟机的低 RPO 复制。它支持 VSS，可用于在本地复制以及复制到 WAN 和云目标，具有多个保留点。
设置滚动的 15 分钟快照，在场外发送每小时或日报。它的成本非常强大。
如果您有一个远程 Hypervisor，您可以配置一个部分运行手册，以使用适当的网络和 IP 设置启动一个复制的 VM。