Recently we implemented DFS on our Network. For this we had to adopt our Backup strategies to correctly backup the DFS Shares.
So not only selecting the Folders itself....
but also selecting the Shadow Copy Components.
We are using Backup Exec 2010 R3 fully patched.
So far so good. Looks like we have made a successfull backup!
Time for a restore try.... (always good to test right?)
What did I do?.....
I renamed one of my folders: Folder1 --> Folder1.old
Checked both of my DFS servers and both servers showed this folder renamed.
Then, time for a restore.
Created a restore job.
Created a selection list and found no data in my folders..
Hmm, thats right. Wrong place. Needed to look at the Shadow Copy Components
Voila, I found the correct files.
Now lets restore my folder I just renamed.
The folder is not available anymore on the server. Available though on backup.
Started the Restore and voila..a few minutes later the files appeared back on my storage server.
Restore successfull right?
Unfortunately not... :(
After a few minutes the following event showed up in my DFS Event Log of the server I just restored to (Windows Server 2008)
Closer investigation revealed that my just restored folder was not replicating at all to my other server.
Worse yet... No replication at all. That is... Not on this replication group. Others work fine luckily.
After about 30 min the next event showed up in the EventLog
The DFS Replication service initialized the replicated folder at local path D:\Data\Departments and is waiting to perform initial replication. The replicated folder will remain in this state until it has received replicated data, directly or indirectly, from the designated primary member.
After again approx 30 min the first 4202 & 4204 logs appear
Event: 4202: The DFS Replication service has detected that the staging space in use for the replicated folder at local path D:\Data\Departments is above the high watermark. The service will attempt to delete the oldest staging files. Performance may be affected.
Event: 4204:The DFS Replication service has successfully deleted old staging files for the replicated folder at local path D:\Data\Departments. The staging space is now below the high watermark.
It looks like DFS is doing something.. Rebuilding its DFS database or rechecking its entire folder structure.. Who knows..
But anyway...Now 5 hours later. My folder is still not replicated to the other server :(
Couple of things that came to mind....
- The files restored from Backup have most likely the same or older date/timestamp. Therefore the DFS conflict mechanism might start to intervine. The restored file might end up in de "\DfsrPrivate\ConflictAndDeleted" folder because a newer file exists on the other server. I guess it is like restoring Active Directory. The restore must be authoritive of some sort. Unfortunately I cannot find any documentation about this.
- I have not tried a redirected restore. A direct restore should work in my opinion. Also, there might not be enough diskspace to handle data twice in case of large restores.
Question: What is the correct way to restore files to a DFS server? Why did Backup Exec break my DFS? Anything I can do in the meantime except being patience?
Thanks for reading my post? Your thoughts are greatly appreciated!
Remko de Koning
Accepted Solutions
After approx 24 hrs my DFS shares are in sync again. The DFS Share is approx 300 GB With a staging qouta of 16 GB. I guess DFS did a full check to get back in sync again.
Seems like my problem has resolved itself.
I am afraid though that a second restore will do the same.
I guess I will try to create a new DFS share (without production data 
) and start my Backup & Restore procedure again.
Question remains why my DFS "broke".
Thanks for your thoughts
Remko
