Robocopy One-Way Sync on Windows 10 & 11: Safe /MIR, Monitoring and Logging Guide

What Robocopy is, and how old it is​

Microsoft's reference describes Robocopy as a tool that copies file data from one location to another. Its documentation applies to Windows 10, Windows 11 and supported Windows Server releases.

The "over 20 years" framing undersells its age. Wikipedia dates Robocopy to 1996 and Windows NT 4, and says it has been included with Windows since Vista. So it is roughly three decades old. It was an Resource Kit utility for much of that time and became a standard part of the OS later.

The author's setup​

Mishra wanted to keep a folder on his main PC in step with a VM that holds downloads and scripts. He didn't want to shuttle files by hand or run a heavier sync app.

• He created a shared folder named Robosync on the VM and gave it full control permissions.
• He checked that the share opened from the host in File Explorer, using the UNC path \\192.168.0.106\Robosync.
• He started with a plain copy command, using the source folder C:\sc:

robocopy "C:\sc" "\\192.168.0.106\Robosync" /E /Z

Per Microsoft's option table, /E copies subdirectories, including empty ones. /Z is restartable mode. If a file copy is interrupted, Robocopy can resume it rather than recopy the whole file.

Treat "full control" as what worked on his lab VM, not as a recommendation. Grant the account that runs the job only the access it needs on the share.

Why that first command isn't a sync​

This command only adds and updates files at the destination. The author notes that a file deleted from the source stays at the destination. Re-running the command restores anything he deleted from the destination and skips files that already match. So it never makes the two sides identical.

The script, and the /MIR caveat​

To get something closer to a sync tool, he wrapped Robocopy in a PowerShell script with the help of Gemini and ChatGPT. As he describes it, the script includes:

• a watchdog function that looks for differences between source and destination;
• debouncing, to control how quickly it reacts to changes;
• logging, error detection and retries after a wait period;
• a Task Scheduler task to keep it running.

When it detects a change, it copies using /MIR. He first found detection too slow, so he cut the wait to one minute. He reports about 50 MB of memory use. He calls the result one-way and "barebones" next to Syncthing.

The script itself wasn't published, so none of this can be audited. The 50 MB figure, the timing and the reliability are his own reports. Whatever detects changes is the PowerShell layer, not Robocopy.

/MIR is the part to handle with care. Microsoft's reference defines it as mirroring a directory tree, equivalent to /e plus /purge. The /purge half removes destination files and directories that no longer exist in the source. Microsoft's own mirror example says it deletes destination files that aren't in the source. The same reference notes that /MIR combined with /E on an existing destination overwrites the destination directory's security settings, which /E plus /PURGE does not.

In practice, a mirror will faithfully copy your mistakes. PDQ's Robocopy guide advises making sure you won't need data that was accidentally deleted from the source. A mirror is not a versioned backup. Nor is it two-way sync, since changes made only at the destination never flow back.

Built-in monitoring switches​

Robocopy can repeat itself without a custom script. /mon:<n> runs again when more than n changes are detected, and /mot:<m> runs again in m minutes if changes are detected. IONOS shows them combined in a backup example, alongside /MIR, retry and log switches. These switches don't prove the author's script is equivalent. His watchdog and debounce logic may behave differently, and nothing here shows it is better or worse. For many home setups, though, the built-in switches are the simpler thing to try first.

Logs and exit codes​

Microsoft recommends writing a log so you can review a run afterward. /LOG:<file> overwrites it, and /LOG+:<file> appends. The retry options /R:<n> and /W:<n> set the retry count and the wait in seconds. Microsoft documents the defaults as one million retries and a 30-second wait. That is a long time to hang on a dead share, so set your own values.

Exit codes matter if you script around Robocopy. Microsoft says values of 8 or higher mean at least one failure. Codes 0 through 7 cover outcomes such as nothing to copy, files copied, or extra or mismatched files, none of them failures. A script that treats any nonzero code as an error will raise false alarms. A script that checks only for zero will do the same.

A cautious way to try it​

1. Make two disposable test folders, then run the first command with /E /Z and confirm the files arrive.
2. Add /LOG+: to a log file and read the summary after each pass.
3. Use /L to list what would happen without copying or deleting. PDQ's guide describes it as a dry run.
4. Only then switch to /MIR, with /R and /W set to sensible values.
5. Add /MON or /MOT, or schedule the job, once the manual runs behave.
6. Before pointing /MIR at a real folder, double-check which path is the source and which is the destination.

Where it fits​

For one-way copies between a PC and an external drive or a share, Robocopy is built in, free and needs no account. That is the author's case. If you need two-way sync, conflict handling, file versioning or sync across many devices, a dedicated tool such as Syncthing is the better choice. Even for one-way jobs, a mirror should not be your only copy of data you care about.