The Ginzu knife of file copy, backup, and transfer
One of the Microsoft Windows Server 2003 Resource Kit's most versatile utilities is Robocopy (aka the Robust Copy Utility). Yes, Robocopy copies files, but before you get bored and turn the page, give this interesting utility a chance. Robocopy can handle copy operations involving huge chunks of data, and it lets you make certain specifications that other copy utilities—such as Copy and Xcopy—don't understand. For example, you can use Robocopy to copy a certain directory tree but only three levels down, and you can specify that Robocopy not use more than a third of the network bandwidth during a given copy operation.
If Robocopy has a weakness, it's syntax. The resource kit's robocopy.doc file doesn't really do anything except explain Robocopy's syntax—and it's 32 pages long. So let's dive in and check out some Robocopy basics.
In its simplest form, Robocopy has a slight resemblance to other command-line copy tools:
robocopy <source directory> <destination directory> <filenames> <options>
Say I want to copy everything from the C:\stuff directory to the C:\stuffbak directory. I'd type
robocopy C:\stuff C:\stuffbak
So far, so good. That looks just like a Copy or Xcopy operation. But what if I want to copy only the text files whose names start with "s"? In Xcopy, I'd type something such as
xcopy C:\stuff\s*.txt C:\stuffbak
However, that syntax won't work with Robocopy. Instead of cramming together the source and destination directories with the file specifications and filters, Robocopy has a separate place for the latter items. To copy just the aforementioned text files, for example, you'd type
robocopy C:\stuff C:\stuffbak s*.txt
So far, I've used source and destination examples that are merely local file folders, but Robocopy can also handle Universal Naming Convention (UNC) names, such as
robocopy \\marksws\myfiles \\centralserver\marksfiles
That command would copy everything in the myfiles share on the marksws machine over the network to a share named marksfiles on a machine named centralserver. Such functionality might be useful, but now that we've added networks to the mix, we'll need to worry about network reliability.
Any network copy operation can be interrupted by any of dozens of potential network problems. In many cases, network problems clear themselves up after a little while, so you need only try the operation again after a short wait. But who wants to babysit a big network file transfer? Fortunately, you can tell Robocopy to retry a copy operation after a specified number of seconds in the event of failure (with the /w:xx option), and you can specify the number of times it retries (with the /r:yy option). So, to tell Robocopy that you'd like your network file-copy job to retry as many as 13 times and to wait 30 seconds between retries, you'd type
robocopy \\marksws\myfiles \\centralserver\marksfiles /w:30 /r:13
If you don't specify a waiting period or a number of retries, Robocopy uses a default of 1 million retries for /r and 30 seconds for /w. In theory, then, a simple Robocopy command over an unresponsive network could take just under a year to complete (not that I've actually tested that).
Sometimes, a network copy job fails for a simple but annoying reason. For example, you might not have permission to read all the files you're trying to copy. (Such can be the case when you're trying to back up a user's profile or home directory.) If you need to back up some files but you don't have the NTFS Read permission, check to see whether you have Backup rights to the files—remember, they're not the same thing! If you do, you can use Robocopy with its /b or /zb options to back up the files. The /b option tells Robocopy to use the Backup permission, and the /zb option tells the tool to first try a standard copy operation, then try the Backup-based copy should that fail.
Just a Start
My intention here was to scratch the surface of Robocopy and tempt you to take a gander at the tool's online documentation. Next time, I'll share some more Robocopy functionality.