具有大量積壓的儲存伺服器上的 DFS 2003：恢復選項？
我們目前有一個 2003 年的 DFS 伺服器，它有幾 GB 的積壓。這僅適用於單個 DFS 共享。它不是在本屆政府期間建立的，我們只是在處理它的影響。
我們目前正在執行一個腳本來嘗試恢復一些數據，但 DFS 仍在執行並阻礙。（腳本連結：http: //blogs.technet.com/b/filecab/archive/2008/01/02/a-script-to-restore-data-from-the-dfsr-conflictanddeleted-or-preexisting-folders -for-disaster-recovery-purposes.aspx）而且，腳本啟動後對文件所做的任何修改都可能被腳本忽略，只是放在隊列的後面（不是 VBscript 的人，所以我不了解腳本組件的實現細節）
首先，如果我們停止並解除安裝 DFS，數據是否會保留在 DFS 創建的文件夾（dfsprivate 等）中，以便我們繼續執行恢復腳本？如果這是可能的，這似乎是盡可能快地恢復盡可能多的數據的最簡單方法（我能想到的）。
如果上述方法不可行，你們還有什麼其他建議可以更快地恢復數據嗎？如果這有助於解決問題，我們完全可以刪除 DFS。在我們獲得更可靠的系統之前（可能是 2008 年），我們已將所有使用者驅動器映射更改為直接指向文件伺服器。然而，這只是一個臨時解決方案，因為他們的大部分數據仍然失去。
如果需要更多資訊，請告訴我，我可以為您提供。
禁用所有 DFS 會使 Dfsprivate 中的文件保持完整，以便腳本可以恢復它，而無需將其他數據添加到積壓中。這似乎是恢復數據的唯一方法，而且幾乎是最快的。更快地做到這一點的唯一方法可能是編寫我自己的腳本來同時複製多個文件（假設我們的磁碟 I/O 沒有被最大化，我認為這不是因為我們根本沒有那麼快地複制。 ..)，提供的腳本由於實現的原因相當明顯（它開始復製文件的速度比完成文件的速度更快，因為沒有調度等）。
另一種選擇可能是在 linux 上的 liveCD 環境中啟動並編寫一個腳本來解析 Preexisting.xml，然後呼叫 dd 進行文件傳輸，因為 dd 只是一個野獸。是的，如果可能的話，我下次會這樣做。