我有两台 Windows 2012 r2 服务器,它们具有相同的路径和驱动器名称(并非故意的)。
如果我在服务器 A 上创建一个文件夹,该文件夹会立即复制到服务器 B。但是,如果我在服务器 B 上创建一个文件夹,它不会复制到服务器 A。
我运行了 DFS Diagnostics,没有发现任何错误。但是,当我从服务器 B 运行到服务器 AI 的传播测试时,没有出现错误。只是出现测试不完整警报。
我有一个 6 天前的测试(文件复制测试)。该测试文件的复制状态停留在“等待到达”。
请记住,从服务器 A 到 B 的删除操作可以正常复制。从 B 到 A 的任何操作均无效。
据我所知,一切设置正确,没有错误。
数据约为 6TB,是事先预先植入的。复制是在文件服务器集群和单个服务器之间进行的。DFS 关系已建立超过 3 周。
有想法吗?
答案1
复制失败的原因有很多。不幸的是,单靠症状并不能解决问题。
您是否可以查看以下信息http://blogs.technet.com/b/askds/archive/2009/04/09/dfsr-debug-log-series-wrapup-and-downloadable-copies.aspx然后使用您从两个服务器看到的任何特定调试日志条目来更新问题?
由于您使用的是 2012 R2,因此该博客有点过时,但它仍然有帮助。
请仅提供特定于此文件夹的条目。
或者,我建议执行以下操作使用 A 重新初始化 B。
备份 B。如果您的最终用户在 B 上提交了更改但没有意识到尚未复制到 A,则此操作是必要的。以下步骤将把 B 上的所有数据恢复到 A 的版本,如果尚未备份 B 更改,这可能会导致一些“数据丢失”。
使用 B 上的 DFS 控制台禁用 B 作为该复制文件夹 (RF) 的成员。这将更新最靠近 B 的 DC 上的拓扑配置(或者更确切地说,B 正在使用一个 DC)。
在 B 上执行“dfsrdiag pollad”,使其从 AD 读取拓扑变化
运行“wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicatedfoldername,replicationgroupname,state”。确保该文件夹未出现在列表中。(已编辑:已修复 wmic 命名空间)。
查找事件 4114,指示文件夹已停止复制
还可以选择在调试日志中查找 ldbmanager::deleteidrecords 的任何条目,这些条目表明数据库已被清理。
使用 B 上的 DFS 控制台重新启用 B 成员。
在 B 上执行“dfsrdiag pollad”以确保它获取更改
如果 A 和 B 位于不同的站点,并且您在 A 意识到之前禁用/启用了 B,那么您不需要对 A 执行任何操作。否则,您可能还必须考虑 Ad 复制延迟,并等待 AD 更改收敛到 A 使用的 DC。然后执行“dfsrdiag pollad”以确保它获取您执行的每个拓扑更改(即禁用然后启用成员)。
运行“wmic /namespace:\root\microsoftdfs path dfsrreplicatedfolderinfo get replicatedfoldername,replicationgroupname,state”。确保文件夹最终达到状态 4。有关状态的更多详细信息,请参见此处http://blogs.technet.com/b/filecab/archive/2008/10/27/how-to-check-if-the-initial-replication-was-completed-successfully.aspx
如果仍然无法修复,则需要调试日志条目来给出更具体的答案。
恐怕我无法反复回答基于故障排除的问题。如果您需要进一步的帮助,我建议您向 Microsoft 支持部门提出案例。否则,网站上的其他人可能有时间帮助您。
答案2
您是否碰巧通过克隆虚拟磁盘或整个虚拟机(未进行系统准备)来创建这些卷?这听起来像是驱动器序列号或卷序列号在两台服务器之间不是唯一的,这将导致 DFS-R 失败。