Sometimes I need to migrate a large amount of shared files on a network from one drive or system to another for better organization, more space, security concerns, or whatever the reason might be. However, a migration like this can interrupt network users who need access to those files. In this post I’ll show you a better method for file migration, which is now a staple in my IT arsenal, as it has proven useful many times.
I would love to schedule the migration during off-hours when nobody is working, but we have a “unique scenario” where some remote laptop users like to do their work at home at night (who wouldn’t?).
Honestly, there should be some definite off-hours reserved for the IT department to perform routine maintenance, but that’s not the case. We schedule and treat most IT operations as if they are occurring during regular business hours.
Don’t move, incremental copy instead!
Rather than bring these shared network files offline for several hours to perform the migration, we will copy the files over to the new destination instead of moving them. That way, users retain access to the original files and can continue working with them while the copy takes place.
Now you might be thinking, what if a user changes an original file after it has already been copied to the destination? That’s where a second incremental copy solves our problem.
We will be using a command line utility called ROBOCOPY whose job is too simple, to mirror a source directory to a destination directory.
…What does that mean, and how does it all tie in?
You’ll end up running the command twice. The first time will copy everything from the source to the destination, since nothing exists in the destination yet. The second time will copy only the files from the source which are newer than those in the destination, as well as delete any files and folders in the destination which no longer exist in the source.
Here’s exactly how the process works for us:
- Run the command to start copying. We don’t notify users yet.
- When the command is finished copying, we give our users a chance to save their document/complete their transfers/finish their work, so we give them a time window of about 30 minutes. We email them to let them know that access to their files will be temporarily unavailable in approximately 30 minutes. Keep in mind some users might not even read the email within 30 minutes, in which case we know who those users are and we call to notify them.
- Wait 30 minutes for the users to save up their work, then disable the old share. Users will lose access to the files temporarily, but they should expect that by now.
- Run the command a second time to copy over any changes since the last full copy. Hopefully this doesn’t take too long, but it depends on the amount of files that have been modified/added/deleted since the initial full copy. For us it was about 2 minutes.
- Set up the new share at the destination using the same share name. Users are now able to access the shared files again. Even though the files and share were moved physically to a different location, the share name stayed the same, which means the users don’t need a reconfiguration.
- Notify the users that they may access the shared files again.
- Delete the old files once we have determined everything is good, after we have a full backup of the new share.
OK, how do I use this mighty ROBOCOPY?
The command is relatively simple, you just call it from a command prompt (MS-DOS):
ROBOCOPY SRC DST /MIR
You’ll need to replace SRC with your source folder path, and DST with your destination path (making sure to include double quotes around any path containing one or more spaces).
The /MIR switch tells ROBOCOPY to mirror the source folder (and all contents) to the destination folder, deleting any files or folders in the destination folder which no longer exist in the source folder.
If the ROBOCOPY command doesn’t work, your computer doesn’t have the utility, so you may download the Windows Server 2003 Resource Kit Tools from Microsoft, which includes ROBOCOPY.