Windows DFSR - 更改了複製目錄權限，現在有超過一周的 350,000 積壓
問題：有沒有辦法讓這 350,000 個文件積壓更快地完成？對於幾乎每個文件，唯一的更改是更改每個受影響文件的 ACL。某些文件已更改內容，但在這種情況下並不常見。
這可能是固定的。經過一段時間和驗證後，我將編輯此文本以確認成功/失敗。在這個問題文本的結尾，我詳細介紹了最近可能修復它的更改。
我們有一個 DFSR 複製組，大約有 450,000 個文件，佔用了 1.5TB 的空間。在這種情況下，有兩台 Windows Server 2008 R2 伺服器相距約 500 英里。還有其他伺服器，但它們不參與此複製組。伺服器 ALPHA 是主伺服器，是大多數員工使用的伺服器。伺服器 BETA 是遠端辦公室的伺服器，不太忙。
這是此複製組（託管在 Google Drive 上的 PNG）的積壓圖表，顯示了緩慢的同步進度。
我需要刪除該複製組的根目錄中的一個權限條目，這當然是在大多數子文件夾中繼承的。我在伺服器 ALPHA 上進行了此更改。緊接著，DFSR 就積壓了 350,000 個文件。已經一個多星期了，現在是267,000。（最初）唯一改變的是單個權限更改。
這就是發生的事情（這不是解決方案，只是對導致此問題的原因的另一種解釋）：http: //blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -因為事實證明，星期五晚上沒問題。aspx#dfsr
伺服器 BETA 上發生的任何更改都會非常快速地複製到伺服器 ALPHA，因為該方向沒有積壓。在 BETA 上更改的任何文件都可以毫無問題地進入 ALPHA。
它通過一端 50Mbps 的連接全速 24/7 複製到另一端的 100Mbps 光纖。每台伺服器上的暫存區域為 100GB。事件日誌中沒有任何有趣的內容。有一個不相關的高水位線事件顯示為一個不相關的複制組，該複製組既不用於此特定複製，也不用於此 ALPHA/BETA 伺服器對。特別是沒有高水位線或連接錯誤的事件日誌條目。
ALPHA 對複制組的看法：
頻寬節省：減少 99.83%（複製 30.85 MB 而不是 18.1 GB）
我相信自從我上次在 ALPHA 和 BETA 上重新啟動 DFSR 服務後，就出現了 30.85MB/18.1GB。如果是這樣，這表明即使花費了很長時間（比我認為應該花費的時間還要長），它實際上並沒有通過網路傳輸文件內容。
複製文件夾：1.46TB（實際大小）、439,387（文件）、52,886（文件夾）
衝突和刪除文件夾：100.00GB（配置大小）、34.01GB（實際大小）、19,620（文件）、2,393（文件夾）
暫存文件夾：200.00GB（配置大小），92.54GB（實際大小）
我在日誌中發現了一個高水位線錯誤（5 月 14 日晚上 7 點），因此將暫存配額從 100GB 提高到 200GB。我知道微軟批准的路線是增加 20%，但我不是在玩這個。我們在暫存磁碟陣列上有足夠的磁碟空間可供使用。
在所有伺服器上禁用防病毒軟體並沒有幫助，儘管我認為它會有所幫助。現在我已經重新啟用了防病毒，但將複製組的路徑設置為從掃描中排除，以便從等式中刪除該變數。
有沒有辦法讓它更快？我也會在伺服器 BETA 上進行此更改，但是有些文件在 ALPHA 上已更改但尚未復製到 BETA，並且通過對 BETA 進行繼承權限更改會將OLD文件從 BETA 推送到 ALPHA（因為 DFSR 似乎在比較哪個文件是衝突的贏家時忽略文件時間戳）。發生這種情況將是相當糟糕的。
積壓正在緩慢減少。非常非常緩慢。不過，它正在向前發展。但按照這個速度，它還需要幾週的時間才能完成。我正在考慮將數據集的副本推送到 3TB 驅動器並將其運送到遠端辦公室。有沒有更好的辦法？
5 月 16 日，美國太平洋時間凌晨 4 點：什麼可能解決了這個問題（假設它已經被誠實地解決了，無論如何）：
我對很久以前應該進行的 DC 進行了多次更改。問題是這個網路是從可能從其他人那裡繼承的其他人那裡繼承的，等等。我不能保證哪個更改解決了這個問題。在這裡，它們沒有特別的順序：
- 所有 DC 都不在“域控制器”OU 中。我從未見過在其他地方擁有 DC 的 Windows 域。我把他們搬回了他們所屬的地方。他們以前在按每個辦公室所在城市的名稱分隔的 OU 中。（我覺得我現在搬家了，我有一些管道工作要處理，但目前一切似乎都還好……）
- AVG Anti-Virus 正在所有 DC 和 DFSR 參與伺服器上執行。我從活動/按訪問掃描中排除了複製文件夾和暫存文件夾。我認為這不能解決問題，我可能會稍後測試這個問題，看看撤消該更改是否會干擾 DFSR 的複制速度。這是另一天的挑戰。
- dcdiag.exe抱怨有關 RODC 的 DNS 問題。即使我們在域上根本沒有 RODC，我也解決了這個問題。我懷疑這是否解決了任何問題。
- 其中一個 DC（不是 DFSR 伺服器之一）缺少 _ldap._tcp.domain.GUID._msdcs.DOMAIN.NET SRV 記錄之一，我對此進行了補救。我認為這也沒有幫助。
- 有一次我重新啟動了伺服器 BETA，它抱怨 DFSR 數據庫的關閉不正確（事件 2212），然後它繼續花費數小時來重建數據庫。完成後，它報告了事件 2214，讓我知道它完成了。在那之後，複製仍然執行得非常緩慢，但它可能有助於解開卡住的東西。
- 其中一個 DC 在其介面配置中沒有 127.0.0.1 作為輔助 DNS 伺服器。我添加了它。這不是 DFSR 伺服器之一，因此可能與它無關。
- 我關注了TechNet 部落格：在 DFSR中為 DFSR 伺服器調整複製性能推薦的系統資料庫設置。我使用了所有“測試的高性能值”值，除了AsyncIoMaxBufferSizeBytes設置為*4194304，*它比高值低一個檔次。這可能有助於解決問題……或者可能沒有。很難判斷一個人何時更改了太多變數。
- dcdiag.exe抱怨在 BETA 上與 RPC 服務通信時出現問題，但前提是已經進行了上述更改。這似乎是最有可能發生的問題，但我沒有採取任何措施來糾正它。VPN 執行正常，防火牆沒有阻止它。上述項目之一可能是導致 RPC 問題的原因並隨後對其進行了補救，或者這可能是簡單的巧合。我現在沒有收到該錯誤，目前複製執行順利。
這個故事的寓意是：一次改變一件事，否則你永遠不會真正知道是什麼修復了它。但我很絕望，沒有時間來修復它，所以我只是對這個問題開了一堆子彈。如果我查明修復，我會在這里報告。不過，不要指望我縮小範圍。
編輯 2012 年 5 月 21 日： 我昨天用備用伺服器 (GAMMA) 開車大約七個小時到遠端辦公室解決了這個問題。GAMMA 現在充當他們的主要本地伺服器，而他們的常用伺服器（BETA）趕上複製。自從我把它安裝到位以來，伺服器的複制速度已經提高了一倍。雖然這告訴我這可能是一個與 VPN 相關的問題，但我不太願意相信這是因為所有新的更新似乎都從 ALPHA 複製到 GAMMA 非常快並且進展順利。
編輯 5/22/2012： 現在是 12000，應該在幾個小時內完成。我將發布一個從緩慢開始到快速結束的進度圖。問題是，唯一真正“修復”它的是本地伺服器連接。我目前認為 VPN 可能是問題的一部分。如果是這樣的話，我覺得這個問題還沒有完全回答。在我有更多時間檢查事物是如何通過 VPN 進行複制並查看任何故障之後，我將調試並報告進度。
如果有什麼變化，我會在這裡更新。
很奇怪的問題，尤其是在審閱編輯之後。
我將檢查位於此處的 DFSR 調試日誌：%systemroot%\debug 預設情況下，應該有 9 個以前的日誌文件已被 GZ 歸檔，一個目前正在寫入。
在文本文件中打開它，然後搜尋文本“警告”或“錯誤”。您可以查看此部落格系列以獲取有關調試日誌的更多詳細資訊：http: //blogs.technet.com/b/askds/archive/2009/03/23/understanding-dfsr-debug-logging-part-1-日誌記錄級別-日誌格式-guid-s.aspx
其他問題/建議：
查看資源監視器時有什麼不合適的地方嗎？超出基線的額外硬碟驅動器或 CPU 活動？
如果可能的話，我會重新啟動 Alpha 和 Beta 伺服器。如果它解決了您的問題，您可能永遠不知道真正的問題是什麼，但如果問題很快得到解決，那麼值得一試。
根據問題更新進行編輯
您提到了與 850 MB 文件相關的兩個條目，以及 DFSR 調試日誌中的一個錯誤。
您可以嘗試將暫存位置更改為每台伺服器上的不同文件夾或驅動器嗎？如果目前正在暫存的文件已損壞或以某種方式阻止複制。