我正在寻找以下问题的解决方案：
服务器 A（站点 A）- Win 2008 R2 - 约 10 TB（最多 15 TB）数据 - 超过 800 万个文件
服务器 B（站点 B）-Win 2008 R2
我想将服务器 A 的卷异步复制到服务器 B 上的卷以实现数据冗余。当服务器 A 因机器问题、灾难等原因而瘫痪时，我可以告诉我的用户“到这里获取数据”。
Windows 2008 R2 确实有 DFS，但是微软显然不支持这么大的数据集（或者更准确地说，超过 800 万个文件 - 根据我能找到的文档）。
我也研究了 Veritas Volume Replication，但这似乎太多了，因为我还需要 Veritas Volume Manager。
有许多“备份”软件可以进行 1-1 备份，这没什么问题，但由于它将通过互联网传输，所以我想要像 DFS 那样在传输过程中进行压缩的软件。
有人对此有什么建议吗？
答案1
我用过双重移动在互联网上移动大型数据集。它们使用字节级复制，并跟踪文件更改。还有一个不错的带宽限制调度程序，白天使用较少，晚上和周末使用较多。如果发生某种连接中断，它也能很好地恢复。
现在，我假设这是连接到物理机器的某种 MSA，但如果您使用 SAN，请咨询您的 SAN 供应商以了解异步复制选项。
无论使用哪种复制，都需要考虑以下几点：
- 源端和目标端的带宽
- 文件变化率
如果源端的变化率太高，并且您没有足够的带宽来克服它，那么您将永远无法获得良好的复制。
重新索引数据库、碎片整理以及批量文件移动/添加/删除都曾经让我头疼。
希望我过去的痛苦能够帮助读到这篇文章的人！:D
答案2
2003 R2 中的 DFSR（2008 和 2008 R2 可能更具可扩展性，因为是 x64）对我们来说非常有效，75 台服务器都位于不同的 WAN 链路（1-10MB）上，在不良、缓慢或饱和的 WAN 链路上同步总计至少 500GB（每台服务器乘以 75）的文件，我建议您尽一切可能让 DFSR 正常工作。我们发现它比 Veritas 更容易管理整个组织，但这是 2003 R2 发布后的 2006-7 年。GPO 控制 BITS 带宽是您的好帮手。
DFSR 的一个特点是它会保留一个文件夹，其中包含需要发送的所有已更改块的副本，因此您需要对存储进行自由分配。我对您引用的限制感到好奇，因为我认为在资源充足（RAM、CPU、磁盘）的情况下，8M 文件就足够了。我不知道我们的文件数量。
此外，过去 DFSR 与备份、A/V 和其他软件不兼容。2008-2009 年，我们发现 Netbackup 不喜欢 DFSR，报告文件服务器备份成功，但实际上什么都没有备份。只有在测试恢复时，我们才发现 Netbackup 中存在这个可怕的错误。如果有一件事是你永远不希望备份系统做的，那就是报告备份成功，但实际上磁带是空的。
无论如何，我对 DFSR 充满信心，尤其是其第 3 版 2008 R2，如果您找不到明确表示已测试过您的方案的供应商产品，您应该尝试一下。通常，微软官方支持的产品比他们知道的要保守得多。显然，您的里程可能会有所不同，您必须确定自己愿意承担的风险水平。
答案3
查看复制的关键是寻找一组被复制的“一致”数据。例如：数据库和相应的日志文件应以“一致”的方式复制，以便数据可在其他复制站点上使用。
要查看的第二个重要特征是 - 如果连接中断，恢复所需的时间。复制是否从中断的地方开始？它是否重新启动复制？
第三，它们在不同的网络条件下的表现如何（或更差），以及带宽利用率是多少。
需要注意的其他重要事项包括 - 文件权限是否得到维护？其他文件属性是否得到维护，例如，压缩文件夹会怎样？加密文件会怎样？打开的文件是否被复制？等等。
综上所述，基于块的复制解决方案比基于文件的复制要好得多。基于主机的块的复制比“脱离主机”的基于块的复制更便宜。
答案4
虽然带有 Veritas Volume Replicator 选项的 Veritas Volume Manager 并不便宜，但它可以提供一些优势，例如：
- 它在块级别工作，因此不需要复制整个文件，或者等待文件关闭后才能复制保存。
- 写入顺序保真度得以保持，因此在主服务器上更改数据的顺序就是在辅助服务器上更改数据的顺序 - 这对于数据库等来说很有用。
- 如果您必须将故障转移到辅助数据库，那么您对辅助数据库的修改将很容易同步回主数据库。
- 传输的压缩和节流。
有一个工具（VRAdvisor）可用于监视数据变化率，然后它将告诉您需要多少带宽才能将从服务器保持在主服务器给定的数据变化量范围内。