New DFSR Data Restoration Script

Artykuł
01/04/2008

Hi, Ned here. Just a quick heads up - there is a new DFSR data recovery script posted below. This allows you to restore data from the ConflictAndDeleted or PreExisting folders within DFSR, primarily during disaster recovery. As always, we prefer you use your backup system to do this, as the script is 'at your own risk' and unsupported.

Updated 10/15/10

The latest script is now hosted on Code Gallery: https://code.msdn.microsoft.com/restoredfsr

Update 6/12/14

Well that gallery is kaput. Now hosted from here.

This old script is really gross, I recommend instead using our new Windows PowerShell cmdlet Restore-DfsrPreservedFiles instead. You can restore from 8.1 client if you install RSAT, or from a WS2012 R2 server. Can either run locally or just map a drive to \\dfsrserver\h$ or whatever the root drive is, then restore.

Take a look at https://blogs.technet.com/b/filecab/archive/2013/08/23/dfs-replication-in-windows-server-2012-r2-restoring-conflicted-deleted-and-preexisting-files-with-windows-powershell.aspx for steps on using this cmdlet.

-----------------------------------------------

Remember, this script must be run from a CMD prompt using cscript. Don't just double-click it.

CSCRIPT.EXE RESTOREDFSR.VBS

The script also requires to edit three paths (your source files, a new destination path, and the XML manifest you are calling) . If you fail to edit those the script will exit with an error:

'=======================================================================
' Section must be operator-edited to provide valid paths
'=======================================================================

' Change path to specify location of XML Manifest
' Example 1: "C:\Data\DfsrPrivate\ConflictAndDeletedManifest.xml"
' Example 2: "C:\Data\DfsrPrivate\preexistingManifest.xml"

objXMLDoc.load("C:\your_replicated_folder\DfsrPrivate\ConflictAndDeletedManifest.xml")

' Change path to specify location of source files

' Example 1: "C:\data\DfsrPrivate\ConflictAndDeleted"
' Example 2: "C:\data\DfsrPrivate\preexisting"

SourceFolder = ("C:\your_replicated_folder\DfsrPrivate\ConflictAndDeleted")

' Change path to specify output folder

OutputFolder = ("c:\your_dfsr_repair_tree")

'========================================================================

- Ned Pyle

Comments

Anonymous
January 04, 2008
PingBack from http://geeklectures.info/2008/01/04/new-dfsr-data-restoration-script/
Anonymous
April 15, 2008
The comment has been removed
Anonymous
April 15, 2008
Hi, Can you paste in this section from your script: '======================================================================= ' Section must be operator-edited to provide valid paths '======================================================================= ' Change path to specify location of XML Manifest ' Example 1: "C:DataDfsrPrivateConflictAndDeletedManifest.xml" ' Example 2: "C:DataDfsrPrivatepreexistingManifest.xml" objXMLDoc.load("C:your_replicated_folderDfsrPrivateyourManifest.xml") ' Change path to specify location of source files ' Example 1: "C:dataDfsrPrivateConflictAndDeleted" ' Example 2: "C:dataDfsrPrivatepreexisting" SourceFolder = ("C:your_replicated_folderDfsrPrivatepreexisting") ' Change path to specify output folder OutputFolder = ("c:dfsr_repair_tree") '========================================================================
Anonymous
April 15, 2008
The comment has been removed
Anonymous
April 16, 2008
Your script entries looked perfect - the only other time I've seen this error is when the XML file itself is damaged. A couple questions:

How big is your conflictanddeletedmanifest.xml?
Will it load into Internet Explorer with no errors?

Anonymous
April 16, 2008
Hi, It's 11 mb in size. It opens into IE without any errors, but IE does freeze up for 5-10 seconds immediately after I open it, before it renders the page.
Anonymous
April 16, 2008
That's very odd. Can you create a simple test RG/RF, add some data, delete the data on one server, go to the other server, modify the restore script to point to your test paths, and attempt to restore?
Anonymous
April 17, 2008
I created a new namespace, added some data, deleted one of the files and then changed the script and ran it. It reads the XML file correctly and restored the file correctly. I was just browsing through the XML file and noticed when rendered in IE that it displays the following info at the bottom "The XML page cannot be displayed Cannot view XML input using XSL style sheet End tag 'ConflictAndDeletedManifest' does not match the start tag 'path'. Error processing resource" If I open it in firefox it says "XML Parsing Error: not well-formed" So I guess the problem was the XML file after all. I'll have a play around and see if I can get it working. Thanks for your help.
Anonymous
April 17, 2008
Thanks for the script. I understand that it is not supported, "As Is", but I ran the script and seemed to get some of the folders back, but none of the documents. Is there something I'm doing wrong? My script is below.

'========================================================================== ' ' ' NAME: RestoreDFSR.VBS ' ' AUTHOR: NedPyle, EPS, Microsoft Corporation ' ' ' COMMENT: Disaster Recovery script for pulling DFSR data out of 'ConflictAndDeleted' ' or 'PreExisting' folders and putting it back into a usable directory tree, ' preserving paths, names, and security descriptor info. ' ' USAGE: Replace the 3 variables in the "operator-edited" section below ' with valid paths. The Script will copy the contents of the source folder ' to a specified path, returning files to original names and adding back ' their folder structure at the time of deletion. ' ' It is important to note that duplicate conflicts (i.e. multiple versions of ' the same file that were conflicted) will be restored with only the latest version. ' ' Finally: this tool can only copy files that were preserved in ConflictAndDeleted ' by quota (by default, 660MB). If the quota prevented all files from being saved ' this script is not going to help for those that were trimmed out. The PreExisting ' folder does not have a quota so all data should be restorable. ' ' VERSION HISTORY: ' ' 2.00 / 12/17/07 - ' Coalesced restoreconflicted.vbs and restorepreexisting.vbs into single script ' Multiple bugfixes, improved folder restore logic ' ' 1.01 / 09/25/06 - ' Whitespace bug fixed ' ' 1.00 / 08/25/06 - ' First working version ' ' KNOWN ISSUES: ' ' If the script halts processing with errors, there are typically two possible issues: ' ' 1) Your paths are incorrect in the "operator-edited" section ' 2) Your XML file is corrupt and unreadable (We've seen this after disk failures) ' ' ' This script is provided "AS IS" with no warranties, and confers no rights. ' For more information please visit ' http://www.microsoft.com/info/cpyright.mspx to find terms of use. ' '========================================================================== Dim Source Dim Dest Const quote = """" ' Startup XML Set objXMLDoc = CreateObject("Microsoft.XMLDOM") objXMLDoc.async = False ' Set File Move Environment Set objShell = WScript.CreateObject("WScript.Shell") '======================================================================= ' Section must be operator-edited to provide valid paths '======================================================================= ' Change path to specify location of XML Manifest ' Example 1: "C:DataDfsrPrivateConflictAndDeletedManifest.xml" ' Example 2: "C:DataDfsrPrivatepreexistingManifest.xml" objXMLDoc.load("e:SharesAGBDfsrPrivateConflictAndDeletedManifest.xml") ' Change path to specify location of source files ' Example 1: "C:dataDfsrPrivateConflictAndDeleted" ' Example 2: "C:dataDfsrPrivatepreexisting" SourceFolder = ("e:sharesAGBDfsrPrivateConflictedAndDeleted") ' Change path to specify output folder OutputFolder = ("e:sharesAGB") '======================================================================== set objRootNodes = objXMLDoc.documentElement.ChildNodes For Each objRootNode In objRootNodes Set objChildNodes = objRootNode.ChildNodes For Each objChildNode in objChildNodes If objChildNode.nodeName = "Path" then StrFullPath = objChildNode.firstChild.nodeValue end if If objChildNode.nodeName = "Attributes" then FileorFolder = objChildNode.firstChild.nodeValue end if If objChildNode.nodeName = "NewName" then GuidName = objChildNode.firstChild.nodeValue If GuidName <> "" then Length = Len(StrFullPath) StrExtract = Mid(strFullPath, 7, Length-6) Source = SourceFolder & GuidName Dest = OutputFolder & strExtract if FileorFolder = 10 then ' It's a folder wscript.echo "CMD /C XCOPY " & quote & Source & quote & " " & quote & Dest & quote & " " & "/Q /H /R /X /Y /E /I /C" objShell.Run "CMD /C XCOPY " & quote & Source & quote & " " & quote & Dest & quote & " " & "/Q /H /R /X /Y /E /I /C /F",0,TRUE elseif FileorFolder = 30 then ' It's a folder wscript.echo "CMD /C XCOPY " & quote & Source & quote & " " & quote & Dest & quote & " " & "/Q /H /R /X /Y /E /I /C" objShell.Run "CMD /C XCOPY " & quote & Source & quote & " " & quote & Dest & quote & " " & "/Q /H /R /X /Y /E /I /C /F",0,TRUE else ' It's a file wscript.echo "CMD /C XCOPY " & quote & Source & quote & " " & quote & Dest & quote & " " & "/Q /H /R /X /C /Y" objShell.Run "CMD /C ECHO F | XCOPY " & quote & Source & quote & " " & quote & Dest & quote & " " & "/Q /H /R /X /F /Y",0,TRUE end if end if end if Next Next

Anonymous
April 17, 2008
Thanks for the script. I understand that it is not supported, "As Is", but I ran the script and seemed to get some of the folders back, but none of the documents. Is there something I'm doing wrong? My script is below.

Anonymous
April 17, 2008
Hi, Do you have the issue if you remove the trailing backslash from OutputFolder = ("e:sharesAGB") So that it's instead: OutputFolder = ("e:sharesAGB")
Anonymous
April 17, 2008
Thank you for the quick response and I apologize for the duplicate post. And yes, I get folders, but no documents.
Anonymous
April 17, 2008
In the midst of the script there is a comment "NtFS_Pre-existing_See_Event_Log_" then the file name, is that relevant?
Anonymous
April 17, 2008
@ mdabney - you mean as it's running you see that? Sounds like you used to replicate data with FRS and someone deleted that folder within DFSR? If you actually look in the conflict manifest XML files, do you see any files, or is it just folders listed?
Anonymous
April 17, 2008
Yes, and you are probably correct about the deletion. Our network admin attempted to change the topology remotely while it was running and the .xml file does have files.
Anonymous
April 17, 2008
Ah good - so does the C&D folder actually contain some of the files referenced in the XML file?
Anonymous
April 17, 2008
Yes it does. And I tried another folder. At first it didn't look like it restored. Then I checked that pre-existing folder and lo and behold, the missing database files were there. I could be on to something here.
Anonymous
April 17, 2008
All the other folders seem to be doing OK. My life and job have been saved! Thank you!!!!!
Anonymous
April 17, 2008
:-D Excellent. Have a great day.
Anonymous
September 11, 2008
Hello, everyone Below you have a compilation of some very interesting blog posts from AskDS and Extreme
Anonymous
November 19, 2008
We’ve been at this for over a year (since August 2007), with more than 100 posts (127 to be exact), so
Anonymous
December 14, 2009
The comment has been removed
Anonymous
December 15, 2009
No issues that I am aware of specific to 2008, but there are definitely some scenarios where the script won't work. :-/ Use the email contact form on the website to send me a mail and when I reply, you can can send me your XML file. I'll take a look.
Anonymous
April 01, 2010
Hi, I have a 2-node DFS set up using 2k3 R2. I had the node in sync and they were perfectly happy for quite some time. I recently moved our equipment to a new server room and subsequently noticed the DFS was no longer replicating (one node was actually expecting initial rep). I set the primary flag on one of the nodes and it caused the data in the other node to be moved to preexisting. I ran the recovery script but it appears some data that is missing wasn't recovered by the script. Is there some point in replication where a file could be removed from the DFS and not yet have been written to preexisting? Many thanks.
Anonymous
April 01, 2010
When you moved your equipment was the only change the physical move? DFSR wasn't disabled, reconfigured, changed, etc in any software way? That version of the script is pretty old and ratty, and has some bugs that can miss data with esoteric attributes. I attached a better one to the article above.
Anonymous
April 03, 2010
Thanks for the prompt reply! When the equipment was moved the public IPs of the servers were changed and everything was shutdown. Once everything was in it's new location everything was started together and seemed to work fine. A week later, I checked the DFSR logs in preparation for adding a 2k8 node to the DFS to transition off of 2k3. The logs indicated communications issues between the two existing servers and that the node that everyone gets referred to first is waiting for initial replication. I then ran dfsradmin to check the status of the isprimary flag which was no for both nodes (as it should have been). In an attempt to get replication going I mistakenly set the other node to primary. The next morning I was faced with as mess as many files were moved to preexisting and since it was the node everyone was getting referred to, I got reports of data missing. I then stopped the dfsr service and ran your script to recover as much of the moved data as I could. After the script finished it seemed as if there were still several files still missing. I am wondering how could anything be missing from both the preexisting folder and the dfs. Unfortunately backups were being run from the node that wasn't first in the referral list so the missing data was never backed up (due to the interruption in replication). I searched the preexisting manifest for some of the known files and didn't find anything. The actual preexisting folder is so large it takes forever to perform any kind of operation on it (searching or otherwise). Is there any way data could have not been copied to preexisting before being removed from the dfs? Are the files tied up in the mysterious staging folder?
Anonymous
April 05, 2010
Nothing could be missing unless it happened outside of DFSR's knowledge - preexisting is pretty simple and unsophisticated. It has no quota, no deletion mechanism, no ties to staging. Any files that do not exist on the upstream but do exist on the downstream server during initial sync get moved into PE, that's it. If you know of several files that are missing, and you know their path info, you can examine the DFSR debug logs to see more about what happened.
Anonymous
April 05, 2010
Hmm, it appears that the dfsr logs have maxed out and only extend back to the 1st. We are making a second pass through the preexisting folder using the new script. Is it possible for files to be in preexisting but not in the manifest? We have certainly confirmed that there are several files missing from several different folders and don't know how the files are on neither server nor in the preexisting folder. I just want to give you many thanks on the help you have provided.
Anonymous
April 05, 2010
Remember that the manifest may only contain folder names for some paths, so not all files will be referenced in the manifest. Usually the only time that they do not reconcile is if someone manually deleted files in PE, but still referenced in xml.
Anonymous
April 06, 2010
The comment has been removed
Anonymous
April 06, 2010
The comment has been removed
Anonymous
April 06, 2010
The comment has been removed
Anonymous
April 06, 2010
I sent an email with the preexistingmanifest.xml in a zip per your instructions. Thanks for taking a look at it. -Keith
Anonymous
April 07, 2010
I got the new script and ran it. I even piped the output to a log file. It appears that there are two cases where attribute 14 and attribute 2000 are not handled but that only occurred with a folder containing 6 files and an individual file. The results of the script don't seem to have yielded much more data compared to the older scripts (750GB total compared to the 2TB of preexisting) After indexing the preexisting folder and sorting by date created, it appears there is nothing with a date stamp from the middle of February to the end of March however there are many item modified during that gap. It seems that the data we are missing are items that would have been created during that time. I know you made a comment about the only way files could be missing is if the DFS wasn't aware of them. I am under the impression that would imply the files had to be deleted manually while the DFSR service is not running. If the files went missing during initial rep then the DFS had to be aware of everything that was moved which wouldn't explain why a chunk of recent data would be missing from preexisting. Could it be that it started moving data to preexisting, was interrupted by a restart of the server, then when it continued after the restart the manifest was recreated rather than appended to...effectively making everything in preexisting up to that point an orphan?
Anonymous
April 07, 2010
The other explanation would be that someone has deleted a preexistingmanifest and it was created by the service later. If this is Win2008+ then the manifest could have been corrupted by a disk issue - if so, DFSR would have recreated it. That would only explain a gap where everything prior to X was not in the manifest. I have no explanation for your manifest right now, never seen this before. If it was as easy to run into as your theory, I'd suspect we would have seen it at least a 100 times in 5 years. Anything's possible though. Please send me the original path of a few folders that are now in PE that are not restoring with the new script, so I can compre them to your manifest file.
Anonymous
April 07, 2010
I did a dir /b on the preexisting directory and piped the results to a file. There were 106603 lines in the resulting document indicating just that many items at the root of preexisting. I then counted the number of entries in the manifest and came up with 2089 items. I have a feeling these numbers should be the same but aren't. We aren't missing data before a certain date, more like data created after a certain date. It seems that there aren't any items created between Feb. 9th and March 30th that exist in the preexisting folder. So despite users being able to access their data via the DFS all the way up to when the initial sync happened on March 30th, the data created after Feb 9th was either not logged in the manifest and moved or simply lost by the DFS somehow. Is it possible that the data somehow was sent upstream to the staging folder of the upstream server then removed from the downstream server (as if somehow the intial rep changed directions for some amount of time)? Is there any way to peek into the staging files to figure out what files or parts of files are there?
Anonymous
April 07, 2010
No, they don't have to be the same - look closely at the manifest. It typically refers to FOLDERS, not files. It also only refers to the base folders and files in the PE folder - the subfiles/folders are not referenced as they are implied within base folders. It's much more likely that someone deleted the data. Please follow my previous directions - I am about to be gone until next week so you only have about 30 minutes for me to figure this out before I leave. Otherwise you must open a support case.
Anonymous
April 07, 2010
here are some paths. sorry about overlooking your instruction .D:DFSFSHNSharePersonalfayedongMy Data Sources .D:DFSFSHNSharePersonalplaweckiMy Data Sources .D:DFSFSHNSharePersonaltcummingMy Data Sources .D:DFSFSHNSharePersonalhelfericEmail Archive2.pst
Anonymous
April 07, 2010
I don't need the folders you see in the manifest but are explained (these have the 14 attribute you mentioned before)- I need some folders that do not restore at all. I need to see if they are mentioned anywhere in the path of the manifest. If not in the manifest, not going to be restored. Simple as that. I am out until next week. Please open a support case in the meantime to get a resolution here.
Anonymous
April 07, 2010
It appears after looking at the properties of files in preexisting, the size was due to the preexisting being populated on different occurrences of the server doing an "initial sync" over the time the DFS has existed. That would explain why the script doesn't result in the same amount of data as the preexisting folder. What isn't clear is where the data that was moved in this most recent sync ended up. I suppose that is a question for whoever we talk to after creating a ticket. Thanks for all of your help. It has been invaluable. -Keith
Anonymous
October 10, 2010
Hi, great script, however i am running into some trouble. I think it may be related to xcopy on windows 2008. i have tried manually running one of the lines from the script output. eg. XCOPY "(source full path and filename)" "(destination full path and filename)" /Q /H /R /X /C /Y and xcopy responds: Does (destination full path and filename) specify a file name or directory name on the target (F = file, D = directory)? ? so it appears xcopy isn't copying my files because it is unsure if they are files or folders... Any suggestions? changing to robocopy won't work coz it copys folders and copy is too basic, it won't copy some of the needed information.
Anonymous
October 11, 2010
The comment has been removed
Anonymous
October 13, 2010
The comment has been removed
Anonymous
October 14, 2010
You need to run it with cscript.exe restoredfsr.vbs. Otherwise it will use wscript and prompt.

Udostępnij za pośrednictwem

New DFSR Data Restoration Script

Comments

Dodatkowe zasoby