我们目前正在执行DR战略。 而不是SAN-SAN复制，已决定通过DFSR复制2个活动文件服务器。 但是，我不知道这是不是一个好主意。 示例：DFS不复制locking的文件。 比方说，用户有一个电子表格打开了几个星期。 他们会定期保存，但文件仍然保持打开状态。 然后，活动文件服务器closures，用户被redirect到另一个服务器，文件尚未被复制。 有没有办法来缓解这种情况？ 我误解了什么？ 还是DFSR不是被devise成DR技术？ 编辑：除了我上面的例子之外，DFSR还有什么其他的缺陷？
我有两个2008r2服务器安装在全网状多用途复制组中。 （01和02）。 01是源服务器。 最初的同步刚刚完成，昨天晚上有两个文件夹没有出现在任何一台服务器上，但是他们被困在积压的变化中，从02推到01.从01到02的积压是清楚的，并且正在复制完美。 我试图重新启动02，这没有做什么。 两台服务器的事件查看器都没有任何帮助。 我试图创build和删除“蝙蝠侠”文件夹，希望能清除它。 它没有。 当我在01上创build它时，它将它推到02.当我在02上创build它时，它在积压时创build了一个冗余项。 还有一些其他的随机文件卡在积压。 他们是不必要的，所以我刚刚从01中删除他们，并清理他们从积压。 我希望只是对文件夹做同样的事情… 有什么地方可以帮我们find为什么这些文件夹卡住了？ 编辑： 我也从DFSRdebugging日志中find了这个（昨天晚上初始同步正在完成时发生这种情况）： 20140513 23:27:39.254 2372 CSMG 6769 ContentSetManager::Initialize csId:{2D9CF1D7-50E2-4B3E-AC6B-3D60C6B026EB} csName:Art rootPath:E:\Art state:InitialSync(Sync) ptr:0000000000F83D50 20140513 23:27:39.254 2372 CSMG 5547 ContentSetManager::CheckContentSetState Updating content set record csId:{2D9CF1D7-50E2-4B3E-AC6B-3D60C6B026EB} csName:Art ghosted:0 readOnly:0 readOnlySince:16010101 00:00:00.000 20140513 23:27:39.254 2372 CSMG 5590 ContentSetManager::CheckContentSetState Content set csId:{2D9CF1D7-50E2-4B3E-AC6B-3D60C6B026EB} state:InitialSync(Cleanup) 20140513 23:27:39.395 2372 […]
希望这个问题是客观和适当的ServerFault … 我已经在很多地方看过，DFS-Replication不支持CSV，但是还没有遇到任何信息，这些信息解释了为什么它不被支持，以及如果我们在我们的DFS文件服务器上部署DFS文件服务器可能会遇到什么样的问题存储集群。 我们正在运行Windows Server 2012 R2。 任何有关这方面的信息将不胜感激。 提前致谢。
警告，提前提出主观问题！ 但希望有一个不会closures的好的 。 场景： 我有一个分支机构，目前没有内部服务器。 他们通过12Mbps广域网链路（MPLS）访问所有设备，包括DC。 链路不饱和，平均利用率为20％左右。 该电路非常稳定，具有很高的SLA和良好的正常运行时间。 但是，通过WAN从文件服务器进行大文件传输（主要是读取，而不是写入）可能会很慢。 我们目前不使用DFS。 研究完成： 我知道WAN加速，例如使用专用硬件（Riverbed）或专用软件VM（Silver Peak）。 但是价格不在我们目前的预算之内，而且从我们的angular度来看还不是那么需要（因为这个问题主要是在“拉”的情况下，不一定是推/拉）。 我主要考虑在此分支机构部署Windows服务器，并使用DFS-R或BranchCache。 看一下表比较，并假设我们正在查看一个“托pipe的分支caching服务器”，而不是简单分发： 即使两者都“托pipe”在服务器上，似乎对两者都有好处。 问题我实际上有： 在哪些情况下，这些技术的每一个都会闪耀，你在哪里select一个呢？ 查看一个托pipe的Branchcache服务器，可以设置中央文件服务器上的某些文件夹/文件的“预取”，以便在分支机构本地立即访问它们？ 你必须按时间表（如果可能的话）这样做吗？ 看看DFS-R，我的担心（显然是用第三方应用程序解决的）是文件locking，并确保文件在写操作期间得到正确更新（即，确保是否访问了两个副本，并且都写入了哪个文件优先级和变化发生了什么？）。 理想似乎是locking数据的任何替代副本，但这真的是一个大问题？ Branchcache是否locking中央文件进行编辑？ branchcache是否只将delta发送回已经改变的中央文件？ 如果分支机构服务器也将被用作域控制器，那么这两种技术都不会被build议吗？
问题：有没有办法使这个35万文件的积压工作更快完成？ 对于几乎每个文件，唯一的变化是每个受影响文件的ACL更改。 一些文件已经改变了内容，但在这种情况下并不常见。 这可能是固定的。 我将在一段时间和validation后编辑这个文本以确认成功/失败。 在这个问题文本的末尾，我已经详细介绍了最近可能修正的变化。 我们有一个DFSR复制组，大约有45万个文件，占用1.5TB的空间。 在这种情况下，有两台距离大约500英里的Windows Server 2008 R2服务器。 还有其他服务器，但它们不参与此复制组。 服务器ALPHA是主要的服务器，是大多数工作人员使用的服务器。 服务器BETA是远程办公室的服务器，不太繁忙。 以下是此复制组 （在Google Drive上托pipe的PNG） 的积压图表，显示慢同步进度。 我需要删除该复制组的根目录中的权限条目，这当然是在大多数子文件夹中inheritance的。 我在服务器ALPHA上做了这个改变。 在此之后，DFSR有35万个文件积压。 已经有一个多星期了，现在是26.7万。 唯一改变的（最初）是单个权限更改。 这就是发生了什么事（这不是解决scheme，只是解释导致此问题的原因）： http : //blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -因为，它匝数出周五夜-为-好吧换fighting.aspx＃DFSR 在服务器BETA上发生的任何更改都会非常快速地复制到服务器ALPHA，因为在该方向上没有积压。 任何在BETA上更改的文件都可以顺利地进入ALPHA。 它将一个24端口全速复制，一端连接50Mbps连接，另一端连接100Mbps光纤。 每台服务器上的临时区域为100GB。 事件日志根本没有什么有趣的地方。 有一个不相关的高水位事件显示了一个不相关的复制组，既不适用于此特定的复制，也不适用于此ALPHA / BETA服务器对。 特别是没有高水位事件日志条目和连接错误。 ALPHA对复制组的看法： 带宽节省 ：减less99.83％（复制30.85 MB而不是18.1 GB） 我相信自从我上次重启ALPHA和BETA的DFSR服务以来，发生了30.85MB / 18.1GB。 如果是这样，这表明，即使它花了很长的时间（比我认为应该花费的时间更长），它实际上并不是通过networking传输文件内容。 复制文件夹 ：1.46TB（实际大小），439,387（文件），52,886（文件夹） 冲突和删除文件夹 ：100.00GB（ 已configuration大小），34.01GB（实际大小），19,620（文件），2,393（文件夹） 暂存文件夹 ：200.00GB（已configuration大小），92.54GB（实际大小） 日志中（5月14日晚7点）我得到了一个高水印错误，所以从100GB升级了200GB的升级配额。 我知道微软批准的路线是增加20％，但我并没有在这方面玩弄。 […]
这里有几个与DFSR和Shadow Copies一起使用的问题，但没有一个表示Shadow Copies是否复制。 也就是说，如果我在服务器A上有一对DFS副本和卷影副本，我可以将该文件恢复到服务器B上的以前版本吗？ 如果是这样，那么将这种回复复制回服务器A？ 我怀疑不是，VSS是一个本地NTFSfunction，不在复制的范围内，但目前我无法validation自己。
我们有一个小存根办公室，目前有一个单一的服务器2003域控制器，并在我们的主要办公室举行的文件存储的DFS-R副本。 我们大概可以复制大约100Gb的数据，我猜想最大的20Gb在两端都是积极使用的。 我们有（相对）缓慢的站点之间的ADSL链接。 对于我们来说，复制大多对我们非常有效，除了在一些复制文件上对安全性进行更改的情况。 – 这导致了大量积压的变化，似乎需要几天时间才能清除。 我一直在阅读一些关于问题的文章 ，以及Windows 7和Server 2008 R2必须提供的新分支cachingfunction，据我了解，优点和缺点如下： 分支caching 优点 没有版本冲突 快速访问后续访问 缺点 第一次访问速度慢 慢写访问 DFSR 优点 在任何时候都可以快速读取/写入数据 有限的额外数据安全性 缺点 积压事件很容易发生 版本冲突可能是积压问题 复制可能需要很长时间 – 不适合在办公室之间实时访问文件。 有没有人testing过分支caching？ 我想知道如果分支caching如何在现实世界中执行？ 对于我们的设置，它会比DFSR更好吗？ 我可以想象，如果我能够预取大块数据（我想我可以用robocopy手动执行并删除！），这可能会非常有用。 我唯一担心的是数据写入会很慢。 我也一直在考虑在我们的主要办公室实施共享点。 我认为这可能只是支持分支caching。 很显然，如果我决定使用分支caching，那么就必须通过testing，但是我只是想知道是否有其他可能会说服我的优点或缺点。 我可能会保留我们的AD部署软件作为DFS-R复制，甚至可能是用户特定的数据（如主页目录和configuration文件），否则写入肯定会导致客户端延迟？