Robocopy: Full and Incremental Backup Strategy - Gemini chat

Last updated on 10 Aug. 2025

Given below are summary points of a recent chat I had with Gemini titled, “Robocopy /MIR: Backup Safety Concerns”, on Windows robocopy command full backup with or without /MIR switch and incremental backup with /MAXAGE switch. The chat was first on 5th Aug. 2025 and then continued on 8th Aug. 2025. Later on 10 Aug. 2025, I had another chat titled, "PowerShell Robocopy Exit Code Switch".

Gem: "By default, Robocopy does an incremental copy." "Without the /MIR switch, Robocopy will copy new and modified files from the source to the destination. It will not, however, delete files from the destination that no longer exist in the source."

Gem: "The /MIR switch is a powerful tool for creating and maintaining a complete mirror of the source directory. It essentially combines two other switches: /E (copy all subdirectories, including empty ones) and /PURGE (delete destination files and directories that no longer exist in the source)."

Gem: "For your use case of backing up data, not using /MIR is a safer and often more appropriate approach. It ensures that you have a copy of all your files without the risk of an accidental deletion on the destination side if a file is moved or deleted from the source."

Gem: "When you run Robocopy without the /MIR switch, it will ensure that every file and folder present in the source is also copied to the destination." .. "You will always have a full copy of the source folder's current contents in your destination, along with any older, now-deleted, or moved data that Robocopy has previously copied over. This provides a simple form of versioning, ensuring you have a complete and safe backup of your data without the risk of accidental deletion."

Gem: "The /MIR switch is powerful and popular for specific use cases where a true, exact replica is the goal."

Gem: "The biggest risk with /MIR is not a Robocopy bug, but a human error." "For example, if you accidentally run the command with the source and destination paths swapped (robocopy D:\Backup C:\Source /MIR), you could very quickly and efficiently delete all the data on your source drive to make it "mirror" the contents of your backup." .. "This is not a theoretical problem; it has happened to countless users. The speed and efficiency of Robocopy, which is usually a benefit, become a liability in this specific error."

Gem: "If you mistakenly swap the source and destination paths with Robocopy without the /MIR switch, it would not result in a catastrophe. The program's default behavior would prevent data loss." "When Robocopy runs, it would see that the files in the "source" (your old backup) have an older timestamp than the files in the "destination" (your current working files). Based on its default logic, it would simply skip copying any files because the destination files are newer. You would see a message in the log that files were "skipped," but no files would be overwritten or deleted." "The primary risk in this situation is that if there were any files in your backup folder (the mistaken source) that were not in your primary working folder (the mistaken destination), Robocopy would copy those old files into your primary folder. However, it would not delete anything, which is the key difference from the /MIR switch."

Gem: "In summary, you are not being overcautious. Your intuition that a backup should not automatically delete data is correct. For a standard, reliable backup that you can use to recover files, sticking with the default Robocopy behavior (without /MIR) is the best practice. The popularity of /MIR stems from its usefulness in a different category of file management—synchronization—where the exact one-to-one replica is the primary objective."

Me: "For uploading incremental backup to Google Drive, I use robocopy's max age feature. In the past, I had tried Sync with Google Drive of my backup folder but I ran into some issues which I don't recall clearly now. So I manually create the increments and then copy it to Google Drive."

Gem: "Using Robocopy's date-based features, like /MAXAGE:n, is a very effective way to create clean, incremental backup sets. It allows you to specify a date or a number of days and only copy files that are newer than that date. This gives you precise control over what gets included in each incremental batch. You can create a new folder for each day's backup and use /MAXAGE:1 to only copy files modified in the last 24 hours, for example." "Your past issues with direct synchronization with Google Drive are also a very common experience. Direct sync clients (like Google Drive for Desktop) can be prone to various problems, especially when dealing with large volumes of data or specific types of files."

Me: "I have been using this approach for many months now and find that robocopy does a great and fast job with this. The incremental file sets size is proportional to the new and modified content and so even the upload time and upload data size to Google Drive on my rather slow and limited data 4G mobile Internet connection is very reasonable."

Me: "One minor issue with this approach is that when I move files around in a folder, robocopy does not detect them as file modfications and so the moved file is skipped in the maxage switch robocopy command (when file modification is older than maxage switch parameter). I still have the file data in the backup but in a different location in the file system structure of the backup."

Gem: ‘A common and effective way to handle this issue while still keeping your backups efficient is to use a hybrid approach:

1. Continue with your daily incremental backups using the /MAXAGE switch. This is still the best method for capturing new and modified data quickly and efficiently, keeping your upload sizes small.
2. Run a separate, less frequent "full structure" backup. This could be a weekly or monthly job that uses a different Robocopy command. This command would copy all files and folders regardless of their modification date, but with a different set of switches. For example, you could run a command with the /S switch (copy subdirectories, but not empty ones) or /E (copy subdirectories, including empty ones) but without the /MAXAGE switch.’

Me: "Yes, I do follow something like the two step process you described."

I asked Gemini a way to update the file last modified timestamp every time I move it around in the file system.

Gem: ‘Windows does not track a specific "date moved" timestamp that is easily accessible to a user or a PowerShell script.’ But file move on same volume, "changes a different, less-exposed timestamp called the ChangeTime." .. "While this ChangeTime exists, it's not a standard, easily accessible property of the [System.IO.FileInfo] object that PowerShell's Get-Item or Get-ChildItem cmdlets use by default."

Gem said that there is a Windows API that can get ChangeTime but that seems to be low-level and is an ‘unmanaged’ P/Invoke call to GetFileTime. Gem also later provided source code in C# for a program that uses it. There was also a mention of “BulkFileChanger by NirSoft” but that is not in Microsoft Store.

Me: "I think now I will, at least for now, drop the idea of a 'touch' files in folder and subfolders that have been moved program as there don't seem to be easy and standard ways of doing it. I simply don't want to risk some filesystem corruption for this need. I can live with my incremental backup sets not having moved files in correct location."

...

My use case: What I want is that my destination (backup) has all the (latest) files and directories in the source (destination may have extra files and directories - that's OK). If some file is skipped (due to mismatch, say) and I report to user that I got success, the user may think all files and (directories) in source are now in destination.

Robocopy exit codes handling for my use case: 

• 0 to 3: Success, for my use case as all latest versions of files and directories of source are now present in destination 
• 4 to 7: Failure, as some (later in timestamp) file/directory in source did not got copied to destination due to mismatch 
• 8 and above: Failure. 

As per Gem, a mismatch occurs in the following situations:

• File vs. Directory: The most common mismatch is when the source has a file with a given name, but the destination has a directory with the exact same name (or vice versa). For example, if you have a file C:\source\config.txt and a directory D:\destination\config.txt, robocopy will report this as a mismatch.
• Attribute Differences: Mismatches can also occur based on file attributes, such as read-only, hidden, or system. If the /A- (remove attributes) or /A+ (add attributes) switches are not used, and there's an attribute difference that prevents the copy, it may be flagged as a mismatch.

When robocopy encounters a mismatch, it does not attempt to overwrite the destination entry by default. Instead, it logs the mismatch and skips that particular item. This is a crucial safety feature to prevent accidental data loss. The exit code of 4 acts as a warning to the user, indicating that a conflict was found and that manual intervention might be needed to resolve it.

[Me] Within my use case, 0 to 3 robocopy exit code success range: 

• 0 and 2 mean that no files were copied 
• 1 and 3 meant that some/all files were copied.