Taming Robocopy

Last Updated on November 29, 2015 by Dave Farquhar

A prolific commenter mentioned yesterday how much he dislikes Robocopy. Perhaps worse than I dislike Windows 7. And the nightmare scenario he describes sounds plausible. I’ve trashed directories with errant copy and xcopy commands, and I know I’m not the only one. And those are comparatively very simple.

I suppose one could put training wheels on a tool like Robocopy, but to me, that defeats much of its purpose. When I play the Robocopy card, it’s generally because I have a copy task that potentially will take several hours–if not days–and it’s going to run into errors, and I want it to just do the best it can, without asking me any questions, so I can walk away and let it chew on the problem for however long it takes.

I won’t say Robocopy is one of those things that can make or break a career, but it’s certainly allowed me to swoop in and save the day on several occasions, and that’s always good. So here’s how.

Rule #1: Give yourself time to test

Never let yourself get into the situation where you’re running Robocopy in a hurry. If someone’s breathing down your neck to get it done, point out that you’re using a tool that can delete just as easily as it copies, and the more distracted you are, the more likely you are to make a mistake.

Also point out that once this thing actually starts working, it’s just about the fastest and most reliable way to get the job done because if it gets interrupted, you can run it again and it’ll pick right back up where it left off.

Rule #2: Use a batch file

When I’m developing a procedure using Robocopy, I rarely type it straight into a command line. The command has nearly 90 switches for you to keep straight. Some of them are extremely dangerous, like /MIR and /PURGE, because they delete files as well as copying them.

Typically I only use more like six of them, but even six switches is enough to be obnoxious. So I put the command in a batch file, framed by pause commands. Like so:

rem scarycopy.bat
pause
robocopy c:\here c:\there *.* /e /z
pause

The first pause command is so that if I accidentally run it, I can hit ctrl-c to stop it. The second pause is so that I can see what it actually did when it finishes.

You can even add another REM line telling what the arguments are intended to do. It helps to refresh your memory. Or to explain your intent to any coworkers who might examine the file.

The other thing I’ve noticed is that I rarely use Robocopy in a particular way just once. Usually when I use it, it’s not long before someone wants me to do it again. If I have a batch file, then when I need to do the same thing again next month or next quarter, I can just run it again. Maybe with revisions, maybe without.

As an aside, one of my coworkers says you don’t want to hire the sysadmin who’s running around with his hair on fire all the time. You want the one who lounges around with his feet up on his desk and looks like he never does anything, because that’s the guy who has his whole job automated and he isn’t causing new problems, and he has time to solve problems when they occur naturally. He’s onto something with that thought.

Rule #3: Be explicit

Just to keep my head clear about what I’m doing, I always specify full paths and filespecs. Even when the default behavior is what I want. Better safe than sorry.

Specifying full paths and filespecs also helps keep me from putting switches in the wrong place and causing Robocopy to behave differently from how I want.

Rule #4: Stage and test

The next thing I do is stage a test run. I make a copy of a bunch of data, so I have something I don’t care about to test with. I copy it somewhere. Then re-read the documentation, double-check my Robocopy command in my batch file, and then I add a /L switch.Then I run it. That tells it to list what it’s going to do, but not actually do it. Once I’m confident, I’ll go back, remove the /L switch and run it again for real, on practice data. Periodically, I’ll add and remove the /L switch several times as I develop a solution.

Look at it like a power tool.What happens if I just grab my jigsaw and start cutting? One of two things. I hurt myself, or I end up with something that looks like I cut it with a can opener. So I clamp the work piece onto my workbench, measure, line up my straight edge and clamp that into place, measure again in case anything slipped, and then I’m finally ready to cut. I’m no carpenter, so the results still may not look professional, but they look a lot better if I do the prep work.

Yes, it’s a lot of prep work, but if you’re using Robocopy for something important–in the past I’ve usually used it to copy entire file servers to new machines, or to stage system builds hundreds or thousands of miles away–it’s worth making sure you got it right. Unless you like rebuilding servers (and your boss likes you rebuilding servers).

Rule #5: Examine the results, then repeat until it’s right

There’s not a lot to be said about this. Open the destination directory and see what the command did. If it worked, that’s great. If it didn’t work, re-read the documentation and see what went wrong. It’s test data, right? There’s no shame in having to do it again.

Rule #6: Revise for the real world

Once you’re confident that it worked, go back to the file and change your test directories into the actual directories or UNCs that you’ll be using in the real world.

Ideally, now you can walk away. Let your head clear, and take a look at it again in the morning (or at least in an hour) and see if it still makes sense. Then run it.