How to sync two folders with ROBOCOPY

Syncing two folders with Robocopy is one of the most common tasks sysadmins use it for — but it is also where the most mistakes happen. The difference between “copy everything” and “mirror exactly” is a single flag, and using the wrong one can delete files you intended to keep. This guide covers the practical sync patterns, the behavioral differences between them, and when each one is the right choice.

Unlike a backup job where the destination only grows, a sync implies the destination should match the source — including removals. Understanding exactly what Robocopy does in each mode before running it on a production share is the difference between a clean sync and an accidental data loss.

Quick answer

Mirror source to destination — destination becomes an exact copy of source:

robocopy C:\Source D:\Destination /MIR /R:3 /W:5

/MIR vs /E — choosing the right mode

This is the most important decision when syncing with Robocopy. The two flags look similar but behave very differently.

Flag	Copies new files	Copies changed files	Deletes from destination	Includes empty dirs
`/E`	Yes	Yes	No	Yes
`/MIR`	Yes	Yes	Yes	Yes

Use /E when the destination is a backup or staging area and you want to accumulate files over time — deletions in the source should not remove files from the destination.

Use /MIR when the destination must be an exact replica of the source at all times — a file share kept in sync with a primary server, a deployment folder, or a replicated config directory.

Common mistake: Using /MIR when you meant /E. If files were deleted from the source by accident and Robocopy runs before anyone notices, /MIR will remove those files from the destination too — leaving no copy anywhere. For anything that requires a safety net, use /E and clean the destination manually on a schedule.

Sync scenarios

1. One-way sync — source to destination

The problem: You maintain a folder of scripts or configuration files on one server and need it to always match on a second server. Any change on the primary should appear on the secondary. Files removed from the primary should disappear from the secondary.

The solution: /MIR with retry flags and a log. Run it on a schedule and the secondary stays in lockstep with the primary.

rem One-way sync: primary server scripts to secondary server
rem /MIR      — mirror: copy new/changed, delete removed
rem /R:3      — retry 3 times on locked files
rem /W:5      — wait 5 seconds between retries
rem /LOG+:    — append result to log file
rem /NP       — suppress progress output (cleaner log)

robocopy \\SRV-PROD-01\Scripts$ \\SRV-PROD-02\Scripts$ /MIR /R:3 /W:5 /LOG+:C:\bat\sync-log.txt /NP

Note: Robocopy does not lock the source during a sync. If files are being modified on the primary while the job runs, the copied version may be partially written. For critical data, schedule syncs during low-activity windows or use VSS to snapshot the source first.

2. Sync without deleting — safe accumulation

The problem: You want to keep a destination folder updated with everything from the source, but you do not want Robocopy to delete files from the destination that were removed from the source — either because the destination is also a holding area for other files, or because you want a safety net against accidental deletions.

The solution: Use /E instead of /MIR. New and changed files are copied. Nothing is ever deleted from the destination.

rem Sync without deletion — copy new and changed, keep everything in destination
rem /E        — include all subdirectories including empty ones
rem /XO       — skip files where destination copy is already newer than source
rem /R:3 /W:5 — retry behavior
rem /LOG+:    — append to log

robocopy C:\SharedDocs \\SRV-FILE-01\Docs$ /E /XO /R:3 /W:5 /LOG+:C:\bat\sync-log.txt /NP

3. Sync a folder to a network share

The problem: You need to keep a local folder in sync with a UNC path — a file server share that multiple users access. The connection may be intermittent and you need the job to recover from drops without restarting everything from scratch.

The solution: Add /Z for restartable mode and increase the retry count for an unreliable network path.

rem Sync local folder to network share with resume support
rem /MIR      — mirror mode
rem /Z        — restartable mode: resume interrupted file transfers
rem /R:5      — more retries for unreliable network paths
rem /W:15     — longer wait between retries on WAN links
rem /LOG+:    — append to log

robocopy C:\Configs \\SRV-REMOTE-01\Configs$ /MIR /Z /R:5 /W:15 /LOG+:C:\bat\sync-log.txt /NP

Warning: /Z (restartable mode) is incompatible with /MT (multi-threading). Do not combine them. For network syncs where drops are a concern, use single-threaded restartable mode. For fast local syncs where speed matters, use /MT without /Z.

4. Sync with exclusions — skip noise files

The problem: The source folder contains temporary files, cache directories, or version control metadata that should not be synced to the destination. Including them wastes bandwidth and clutters the replica.

The solution: Use /XD to exclude directories and /XF to exclude file patterns before running the sync.

rem Mirror sync with common exclusions
rem /MIR          — mirror mode
rem /XD           — exclude these directory names at any depth in the tree
rem /XF           — exclude files matching these patterns
rem /R:3 /W:5     — retry behavior

robocopy C:\WebApp \\SRV-WEB-02\WebApp /MIR /XD .git node_modules Temp obj bin /XF *.log *.tmp *.user /R:3 /W:5 /LOG+:C:\bat\sync-log.txt /NP

Always preview before syncing

Before running any /MIR command on a folder you have not synced before — or after a long gap between runs — use /L to preview exactly what Robocopy would do. No files are copied, created, or deleted. The output shows what would be added, updated, and removed.

rem Dry run — preview the sync without making any changes
rem /MIR      — mirror mode (preview only with /L)
rem /L        — list only: show what would happen, do nothing

robocopy C:\Source D:\Destination /MIR /L

Result: Every file that would be copied, skipped, or deleted is listed with a prefix indicating the action. Review the output — especially the deletion list — before running the real sync. This step takes seconds and can prevent significant data loss.

Limitations of Robocopy sync

One-way only. Robocopy has no concept of two-way sync. It copies from source to destination — changes made directly on the destination are overwritten or ignored on the next run. For bidirectional sync, use DFS Replication or a dedicated sync tool.
No conflict detection. If both source and destination have been modified since the last sync, Robocopy copies the source version over the destination version without warning. Whoever ran last wins. There is no merge, no conflict flag, no notification.
Open files are skipped. Files locked by another process are skipped after the retry limit. They will not be synced until they are released. Check the FAILED and Skipped counts in the summary output after each run.
Timestamps must be reliable. Robocopy decides whether to copy a file based on size and last-write timestamp. If an application resets the timestamp on write, Robocopy may skip a modified file. In those cases, add /IS to force copy of files with matching timestamps but different sizes.

Official documentation

robocopy — Microsoft Learn — full command reference including all flags, copy options, and exit code table

Related tools

Windows Command Line (CMD) Cheat Sheet — quick reference for batch scripting used to automate Robocopy sync jobs
PowerShell Commands Cheat Sheet — PowerShell patterns for calling Robocopy and handling exit codes

Related guides

ROBOCOPY command in Windows — full command reference with all practical flags and examples
How to backup files with ROBOCOPY — backup patterns, scheduling, and log handling
DISKPART command guide — prepare destination disks before large sync operations
ATTRIB command — manage file attributes that affect which files Robocopy includes or skips