We have 2 branch offices with local file servers synced to our central office and file server via DFS-R. Mostly data is copied from the central fileserver to both branch offices, but the sync is both ways since occasionally data is also generated in the branch offices and has to appear centrally as well as in the other branch office. Our central server and one branch office is Win2003R2 std and the other branch office is Win2008R2 std

Last night somehow we lost a lot of data (800GB) by accidental delete or some rogue script (still under investigation). We only have central backups, which is currently being recovered on our central server. However due to limited bandwidth, having DFS-R sync everything back to our branch offices is not a viable option.

So once our central server is restored again, I would like to prepare 2 USB disks with all central data mirrored onto, and send them off to our branch offices, so they can be locally filled again with the data.

The question is, how to do this in a supported way that won't break DFS-R. I wouldn't want DFS-R to see the remote data as 'new' data, and start copying everything over again, or worse, deleting everything centrally or something...

Some time ago we had to reinstall a file server in one branch office, back when I used 'robocopy /MIR /SEC /SECFIX' (to ensure the data is as close to 1:1 as possible, to prevent DFSR form seeing a difference and re-syncing anyway) to copy the central data onto the USB disk, and used the same command to copy it back to the local server from the USB disk. After that I added the server (which was reinstalled and thus not a member of the replication group anymore) back to the replication group, this worked fine.

But since now the server is still known and a member of the replication group, i don't know if the same approach will work.

I have 2 possible scenarios in mind which I think might work, however some confirmation (or better ideas even) might be welcome: Both ideas will use a disk prepared by copying everything of the central server using 'robocopy /mir /sec /secfix'

  • First option (least effort): temporarily disable the connection between the central and branch office servers, after the branch office server is re-synced locally using robocopy, enabled the connections again and hope for the best
  • Second option: Remove the branch office servers completly from the replication groups, and after they've been locally re-synced, add them back which will (i think) do an initial replication. This is essentially the same as I've done with the re-installed server so I'm quite confident this will work.
  • Did you have Shadow copy enabled on the drives? If so you might be able to restore from "previous versions". Though 800GB of data might have exceeded the VSC storage limits. I have done what you are asking in Windows Server 2003 and it borks it. DFSR isn't smart enough to know the file is the same and it simply recopies it. I had some luck with Server 2008 R2 using robocopy like you mentioned. I would be inclined to go with your 2nd option if you know it works. I noticed this was a week or so ago, what did you end up doing? – MikeAWood Sep 17 '13 at 23:07
  • The branch offices have just finished copying the USB disks that I sent them, so I'll be trying to re-enable DFS-R later today, will report back. To be on the safe side, I'll just completely remove the members from the replication group and re-add them. This should trigger an initial replication which we've done in the past and I'm quite confident it will see the remote files as being the same. It's however very important to use robocopy since a regular copy will not copy attributes and permissions, and thus the files will ultimately differ from the original ones. – Alex Sep 18 '13 at 8:14
  • robocopy is your hero and mine in cases like this.. Good luck and let us know how it works out. – MikeAWood Sep 18 '13 at 8:17

Unfortunately I didn't get any answers to this. To be on the safe side I went with my 2nd option: Completely removing the remote member servers from the replication group and re-adding them (after waiting for a 4010 event on the remote server confirming it was removed from the group). The backlogs were huge at first but it seems DFSR realized the files were the same and the disappeared from the backlog without them being copied across the line.

So, for future reference, here's how to do an off-line sync of one or more DFS-R member servers:

  1. Remove the remote members for which you want to do an offline-resync from the appropriate replication group. Note that anything you add on the 'master' server in the meantime will not be copied across anymore.
  2. Copy the files to your offline media (NFTS formatted USB disk/stick/whatever) using the following command: robocopy /MIR /SEC /SECFIX <source> <destination>
  3. On the remote server, copy everything back using the above robocopy command with offcourse now the USB source as the parameter
  4. After everything is copied, re-add the members to the replication group
  5. Monitor your backlogs, in my case i had a lot of backlogged files, but they disappeared without re-copying them, probably because DFSR realized they were actually the same.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.