Recently, I have had to start Robocopying from a restore point of a file server. I need to seed data from a server whose physical hardware can’t handle DFS being turned on. I also wanted to be able to continue updating the data from newer restore points until the sync could fall inside an acceptable maintenance window. This has the added benefit that the restore point can be mounted on another system, keeping the file copy away from a machine known to have File IO issues.
The command I am using is:
robocopy "%source%" "%destination%" /copyall /mir /r:1 /w:1 /fft /xo /mt:32 /xd DfsrPrivate "$RECYCLE.BIN" "System Volume Information"
/copyall – Copies all attributes of the file (aka /copy:datsou)
/mir – Makes directory structure mirror source (empty directories and all)
/r:1 and /w:1 – Retries on files and wait between retries in seconds. The default is 1,000,000 and 30. You can see how that would go offtrack quickly.
/fft and /xo – /xo excludes old files. This enables me to use a newer restore mount to update the files. /fft really is for “FAT File Time,” but is useful where a network share could have file times off by a couple seconds. Basically, if a file has a timestamp that is one second after an existing one, it will still be skipped.
/mt:32 – This useful feature was added in the Windows 7 era of OSes. It makes the command run in multiple threads as opposed to the traditional one. It can make the process much faster as long as resources allow. The max is 128, but the server that is hosting my restore point had issues with much higher than 32.
/xd – Excluded directories. These are some common ones that most people won’t want to spend the time to copy.
This command can be run over and over to update the data as long as I change the destination to reflect the new restore mount. Also, not a bad poor man’s backup.