Home / server / Questions / 538026
Accepted
Alex
Asked: 2013-09-12 01:02:17 +0800 CST

DFS-R: how to offline re-sync, large amount of data deleted

  • 772

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.
windows

1 Answers

  1. Best Answer

    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.
    • 2