DFS 2003 on Storage Server with Huge Backlog: Recovery Options?

Question

We currently have a 2003 DFS server that has a backlog of several gigabytes. And that's for just a single DFS share. It was not set up during this administration, we have simply been dealing with it's effects.

We are currently running a script to attempt to recover some of the data, but DFS is still running and getting in the way. (link to script: 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) And, any modifications made to files after the script has started will likely be ignored by the script and just put at the back of the queue (not a VBscript guy, so I don't know the implementation details of the script components)

First and foremost, if we stop and uninstall DFS, will the data remain in the folders DFS creates (dfsprivate, etc) for us to continue the recovery scripts? If this is possible, it would seem like the simplest approach (that I can think of) to recover as much data, as quickly as possible.

Do any of you have any other suggestions for recovering the data in a faster way if the above method is not possible? We are completely okay with removing DFS if that helps the situation. Until we get a more reliable system (2008 perhaps), we have changed all of our users drive mappings to point directly to a file server instead. However, that is only a temporary solution as much of their data is still missing.

Let me know if anymore information is needed, and I can provide you with it.

Answer 1

Disabling all of DFS leaves the files in Dfsprivate intact so that the script can recover it without additional data being added to the backlog. It seems to be the only way to recover the data, and just about the fastest. The only way to do it faster might be to write my own script to copy multiple files simultaneously (assuming our disk I/O isn't maxed out, which I don't think it is because we are not copying that fast at all...), which the provided script does not do for fairly obvious reasons given the implementation (it would start copying files quicker than they could be completed as there is no scheduling, etc).

Another option might be to boot up in a liveCD environment on linux and write a script to parse the Preexisting.xml and then call dd for the file transfers because dd is just a beast. Yeah, I'm doing that next time, if possible.