我们目前有一台 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 年）之前，我们已将所有用户的驱动器映射更改为直接指向文件服务器。但是，这只是一个临时解决方案，因为他们的大部分数据仍然丢失。
如果需要更多信息，请告诉我，我可以为您提供。
答案1
禁用所有 DFS 会使 Dfsprivate 中的文件保持完整，这样脚本就可以恢复它，而无需将额外的数据添加到积压中。这似乎是恢复数据的唯一方法，也是最快的方法。更快的唯一方法可能是编写我自己的脚本来同时复制多个文件（假设我们的磁盘 I/O 没有达到最大值，我不认为这是因为我们的复制速度根本没有那么快……），提供的脚本没有这样做，原因很明显，考虑到实现（由于没有调度，它会以比完成速度更快的速度开始复制文件，等等）。
另一个选择可能是在 Linux 上的 LiveCD 环境中启动并编写脚本来解析 Preexisting.xml，然后调用 dd 进行文件传输，因为 dd 简直就是一头野兽。是的，如果可能的话，我下次会这样做。