我在寻找解决scheme如下：
服务器A（站点A） – Win 2008 R2 – 大约10TB（最大15TB）的数据 – 超过800万个文件
服务器B（站点B） – 赢得2008 R2
我想要asynchronous地将服务器A的卷复制到服务器B上的一个卷上以获得数据冗余。 当服务器A由于机器故障，灾难等而死机时，我可以对用户说“去这里获取数据”。
Windows 2008 R2确实有DFS，但是微软并没有明显的支持这个庞大的数据集（或者更准确地说，超过800万个文件 – 根据我能find的文档）。
我还查看了Veritas Volume Replication，但是这似乎太多了，因为我还需要Veritas Volume Manager。
有许多“后备”软件，使1-1备份，这将是好的，但因为它将通过互联网传输，我想像DFS有传输过程中有压缩的东西。
有没有人有任何build议呢？
我已经使用了Doubletake Move在互联网上移动大型数据集。 他们使用字节级复制，并跟踪对文件的更改。 还有一个很好的带宽限制调度程序，在白天使用较less，并在晚上和周末进行debugging。 在某种连接中断的情况下，它也恢复得很好。
现在，我假设这是某种物理机器附带的MSA，但是如果您使用的是SAN，请与SAN供应商联系以获取asynchronous复制选项。
无论使用什么复制，都有几件事情需要考虑：
如果您的源代码的变化率太高，而您没有足够的带宽来克服它，您将永远无法获得良好的复制。
重新编制索引数据库，磁盘碎片整理和大容量文件移动/添加/删除都让我头痛。
希望我的过去的痛苦会帮助读这个的人！ ：d
DFSR在2003 R2（2008和2008 R2可能更具可扩展性，从x64开始）为我们提供了75台服务器，所有这些服务器都在不同的WAN链路上（1-10MB），同步文件总计至less500GB（每台服务器的时间为75 ）在坏的，慢的或饱和的广域网链路上，我只是build议你做什么才能让DFSR工作。 我们发现pipe理组织比Veritas更容易，但这是2003年R2之后的2006-7。 GPO的控制BITS带宽是你的朋友。
DFSR的一个特点是它保留一个文件夹，其中包含所有需要发送的块的副本，所以存储是你想要的。 我很好奇你引用的限制，因为我认为在大量资源（RAM，CPU，磁盘）的情况下，8M文件会很好。 我不知道我们的文件数量。
此外，过去的DFSR与备份，A / V和其他软件不兼容。 在2008 – 2009年，我们发现Netbackup不喜欢DFSR，并报告我们的文件服务器备份成功，但实际上没有任何备份。 只有在testing恢复时，我们才发现Netbackup中这个可怕的，可怕的错误。 如果有一件事情你永远不想要备份系统去做，报告一个成功的备份，但是确实有一个空的磁带。
无论如何，我给DFSR一个信心的投票，特别是在与2008 R2的第三个版本，如果你不能find供应商的产品，特别是他们已经testing你的scheme，你应该给一个镜头。 通常，微软官方支持的东西比他们知道的更为保守。 显然你的里程可能会有所不同，你必须确定自己的风险水平，你愿意采取。
查看复制的关键是查找被复制的“一致的数据集”。 例如：Db和相应的日志文件应该以“一致”的方式进行复制，以便数据可以在其他复制站点上使用。
需要注意的第二个重要特征是 – 在连接中断的情况下恢复所需的时间。 复制是从哪里开始的？ 它是否重新启动复制？
第三 – 它们在不同的networking条件下performance如何（或更糟糕）以及带宽利用率如何。
其他重要的事情要看 – 是文件权限保持？ 其他文件属性是否维护，例如。 压缩文件夹会发生什么？ encryption文件会发生什么？ 打开的文件是否被复制？ 等等
综合以上所述，基于块的复制解决scheme比基于文件的复制要好得多。 基于主机块的复制将比“脱离主机”基于块的复制便宜。
我有一位客户使用SureSync产品将数据复制到“热备份”文件服务器。 他们正在复制不到2TB，它的工作非常好。 它使用NTFS更改日志来跟踪文件更新并执行增量复制。
我没有find发布的产品限制，所以你可能会更好地检查“制造商”看到。
虽然具有Veritas Volume Replicator选件的Veritas Volume Manager不便宜，但它可能会提供一些优势，例如：
有一个工具（VRAdvisor）可用，您可以使用它来监视数据更改的速率，然后告诉您在给定的主数据更改数量内，需要多less带宽才能保留辅助数据。