Robocopy: The IT Manager's Pocket Guide to File Server Migrations

Why Robocopy still matters

Robocopy (Robust File Copy) has shipped inside Windows since Vista/Server 2008, and two decades later it’s still the tool most IT teams reach for when a file server has to move, mirror, or get backed up. Xcopy and plain Copy-Item don’t survive a dropped VPN tunnel, don’t preserve NTFS permissions, and don’t retry a file another process has locked for half a second. Robocopy does all three, natively, with zero extra installs — which is exactly why it earns a place in a migration runbook instead of a third-party tool.

The reasons it keeps winning the job:

• Restartable copies. A multi-terabyte transfer over a WAN link will hiccup. Robocopy resumes mid-file instead of starting the whole job over.
• Full metadata fidelity. NTFS ACLs, owner, auditing (SACL), and timestamps can all travel with the data — non-negotiable when a migrated share still has to honor the same security groups on day one.
• Retry logic built for real file servers. Locked files, antivirus scans, and transient share glitches are handled automatically instead of killing the whole job.
• Mirroring for cutover. Run it once to seed a few terabytes over a weekend, then run it again minutes before go-live to copy only what changed — the classic “seed, then delta-sync, then cutover” migration pattern.
• Machine-readable exit codes and logs. It slots into scheduled tasks, monitoring, and change records without extra tooling.

The flip side: it’s a blunt instrument with switches that can silently delete data (/MIR, /PURGE) or silently drop security metadata if you’re not running with the right privileges. The rest of this guide is the reference you want open the next time you’re building a migration or backup job.

How the options are grouped

Robocopy’s help text dumps everything in one wall of text. In practice you only ever reason about six buckets: what to copy, how hard to push it, what to leave out, how to handle failures, what to log, and how to package it as a repeatable job.

1. Copy options — what actually gets copied, and how aggressively

2. Throttling — protecting production while you copy

3. File selection — what to include or skip

4. Retry behavior — the difference between “resilient” and “hung forever”

5. Logging — your audit trail and your troubleshooting tool

6. Job files — for repeatable, standardized runs

/SAVE:jobname writes the current parameters to a reusable job file; /JOB:jobname runs from one. Worth setting up if you’re rolling the same migration pattern across many file servers — it keeps every server’s job consistent instead of hand-editing command lines each time.

Switches to basically never reach for

A short list, because getting this wrong is how data gets deleted:

• /MOV / /MOVE — deletes from source as it copies. There’s no undo if the destination turns out wrong. Reserve for genuine one-way archival, never for a migration.
• /PURGE or /MIR without a /L dry run first. These are the two switches that delete data. Get in the habit of running the exact same command with /L added before you ever run it for real.
• Leaving /R and /W at their defaults. A million retries at 30 seconds apart on a single locked file will make your “5 minute” script look hung for days.
• /256 — disables long-path support. Modern server file trees routinely exceed 256 characters; this switch causes quiet, hard-to-diagnose failures on exactly those paths.
• /FAT — mangles filenames to 8.3 format. There’s essentially no reason to use this outside genuine legacy FAT targets.
• /SEC or /COPYALL run from an account without backup/restore/security privileges. Robocopy won’t always error loudly — owner and audit info can silently fail to copy, and you won’t notice until someone asks why permissions look wrong post-migration.
• /MT combined with /IPG or /EFSRAW. Documented as incompatible by Microsoft — don’t fight it.
• /REG — unless you deliberately want to change the registry-wide default retry behavior for every future Robocopy invocation on that machine.

Matching switches to the job

Annotated walkthrough of a real migration script

This is the script from the originally used file-server-to-local-volume migration/backup job — with every switch explained in context.

New-item -path C:\Robocopy -Type Directory -ErrorAction SilentlyContinue
New-item -path C:\Robocopy\Scriptlog -Type Directory -ErrorAction SilentlyContinue
Add-Content "C:\Robocopy\UPrivate-backup-robocopyUUPD.log" "script running"

#Input the variables for the robocopy script

$Source = "\\IPAddress of server\F$"
$Destination = "F:\"
$Retries = 10
$MonitorSourceFiles = 1
$TimeInterval = 15
$MultiThreaded = 20

#This is the Robocopy script
Robocopy.exe $Source $Destination /E /ZB /DCOPY:T /COPYALL /MIR /MON:$MonitorSourceFiles /MOT:$TimeInterval /MT:$MultiThreaded /R:$Retries /W:5 /TS /FP /J /xd '$RECYCLE.BIN' 'System Volume Information' '._nfs' /log+:C:\Scriptlog\box1-backup-robocopyUUPD.log /tee

Switch by switch:

• /E — copies the full tree including empty folders. Right call; a file server migration shouldn’t silently drop empty directories users or applications expect to exist.
• /ZB — restartable mode with backup-mode fallback. Correct for a 5 TB job over a network path — it survives interruptions and can bypass ACL read restrictions on files the copying account owns but doesn’t have explicit read rights to. Requires the account running this to hold Backup/Restore privileges for the fallback to actually work.
• /DCOPY:T — preserves original folder timestamps. Without it, every migrated folder shows today’s date as its modified time, which is confusing for both users and anyone auditing the migration later.
• /COPYALL — copies data, attributes, timestamps, NTFS security, owner, and auditing info. This is what makes it a true migration rather than a plain data copy — permissions and ownership come across intact. Double-check the account running this script has SeBackupPrivilege, SeRestorePrivilege, and SeSecurityPrivilege, or owner/audit info can fail to copy without an obvious error.
• /MIR — mirrors destination to source exactly, deleting anything in destination not present in source. This is the highest-risk switch in the script. It’s appropriate for a final backup/migration pass where you want destination to be an exact replica — but it should have been run with /L first at least once to confirm source and destination are the right way around before it ever ran for real.
• /MON:1 /MOT:5 — re-runs automatically after 1 change or every 5 minutes. This turns the job into a continuous near-real-time mirror rather than a single pass — sensible for a live backup/DR job, but worth knowing it means the script doesn’t exit after one copy; it keeps running and re-syncing.
• /MT:20 — 20 threads. Reasonable for a 5 TB job on a decent network path; worth tuning down if the source or destination storage shows contention rather than assuming higher is always better.
• /R:10 /W:5 — 10 retries, 5 seconds apart, instead of the dangerous default (1,000,000 retries / 30s). This is exactly the override called out above as mandatory — good that it’s explicit here.
• /TS /FP — logs source timestamps and full paths. Good for an audit trail on a job this size.
• /J — unbuffered I/O, appropriate given large files are likely present on a 5 TB share.
• /xd '$RECYCLE.BIN' 'System Volume Information' '._nfs' — excludes recycle bin, NTFS system metadata, and NFS metadata folders. Correct and necessary set of exclusions for a full-volume copy.
• /log+:... /tee — appends to a persistent log and mirrors it to the console. Good for a job that’s likely being watched interactively or reviewed afterward; on a scheduled/unattended run, /tee can be dropped since nothing is watching the console.

One thing worth flagging on this specific script: because /MON//MOT make it loop indefinitely and /MIR is active from the very first pass, this is really running as a continuous mirror, not a staged migration. For a true file server migration (as opposed to an ongoing backup mirror), the safer pattern is to run the seed passes without /MIR first — using /E /ZB /COPYALL /DCOPY:T — and only add /MIR for the final cutover pass once source is frozen or offline. Using this exact script as a standing backup/DR job, on the other hand, is a solid, well-configured use of the tool.

Quick reference: never / always

Always: override /R and /W, dry-run /MIR//PURGE with /L first, use /COPYALL only from a privileged account, log with /LOG+ and /TS /FP on anything you’ll need to reference later.

Never: /MOVE//MOV on a migration, /256 or /FAT without a genuine legacy requirement, /MT paired with /IPG or /EFSRAW, or a /MIR run you haven’t dry-run at least once against the real source and destination.