DFS-R，如何在文件夹 ACL 不匹配的情况下重新回到复制轨道

Question

有 2 台服务器安装了 DFS-R。服务器 A 在一个位置，服务器 B 在另一个位置

从昨天早上开始我们就处于一种不知道如何摆脱的境地。

情况：

我们接到一个电话，说有人不再有权访问特定的 DFS 命名空间。检查后，我们发现，在 ServerA 上，有人首先删除了此文件夹上的共享，并且不再有 ACL。

第一步，在 DFS 命名空间上，我们禁用了 ServerA 上的文件夹目标。以允许用户访问他们的文件。

复制看起来非常慢。drfsdiag backlog 给出复制两端各 101000+ 和 78000+ 个文件。我猜可能是因为 ACL 不匹配。

使这一情况重新回到正轨的最佳方法是什么？

• 停止 ServerA 到 ServerB 的复制？
• 删除 ServerA 上的文件夹？
• 以 ServerB 为主要源重新创建复制？
• 重新创建 ACL 并在 ServerA 上共享？
• 所有这些步骤都按特定顺序进行吗？
• 等待积压工作结束后再行动？

DFS-R 确实是新手，我们不知道如何进行以及所有可能的影响。

任何线索都将不胜感激。

Answer 1

如果您更改了整个大型文件夹的 ACL，则必须等待积压工作完成。对于类似情况，请参阅这里和这里

如果这是不可接受的，您可以：

• 停止复制
• 删除受影响的文件夹（仅限一侧！）
• 使用robocopy​种子前现在空无一人的目的地
• 重新启用复制

但是，上述每个步骤都存在停机时间，如果出现问题，情况也可能恶化。一如既往，请先备份。