Hi
oldgreyguy — your assumption is basically correct:
Robocopy should skip files that are identical by name, size, and timestamp. A second run taking
7 hours usually means one of these is happening:
Most likely causes
- It is not recopying everything, but it is slowly scanning/comparing everything
- Robocopy still has to walk the whole source and destination tree.
- If the eM Client folder contains many small files, a USB flash drive can be painfully slow at metadata reads.
- The flash drive is the bottleneck
- Many 1 TB USB flash drives have terrible sustained write/read performance.
- Some also slow down badly after the first large write because their cache fills.
- Timestamps are not matching exactly
- Even on NTFS, removable drives/controllers sometimes cause timestamp precision weirdness.
- Add
/FFT to allow a 2-second timestamp tolerance.
/V is making the run much slower/V creates verbose output for skipped files too.- Console output is surprisingly expensive when there are many files.
- Something is touching the eM Client files
- eM Client may not be open, but Windows Search, antivirus, backup software, or sync tools may still touch files.
- If timestamps or attributes change, Robocopy may think files are different.
First thing I would try
Run this version instead:
robocopy "C:\Users\curtis\Documents\em client" "E:\Email" /E /COPY:DAT /DCOPY:DAT /R:3 /W:5 /FFT /XJ /MT:8 /NP /NFL /NDL /LOG:"%USERPROFILE%\Desktop\emclient-robocopy.log"
What changed
/COPY:DAT explicitly copies data, attributes, timestamps./FFT relaxes timestamp comparison./XJ avoids junction-point weirdness./MT:8 uses 8 threads./NP removes percentage progress output./NFL /NDL suppresses file/folder listing./LOG: saves the useful summary without flooding the console.
To find out whether it is really recopying files
Do a
test-only dry run:
robocopy "C:\Users\curtis\Documents\em client" "E:\Email" /E /COPY:DAT /DCOPY:DAT /R:3 /W:5 /FFT /XJ /L /V /TS /FP /LOG:"%USERPROFILE%\Desktop\emclient-dryrun.log"
Important
/L means
list only. It will not copy, delete, or change anything.
After it finishes, check the summary at the bottom of the log. Look especially at:
Code:
Files : Total Copied Skipped Mismatch FAILED Extras
Bytes : Total Copied Skipped Mismatch FAILED Extras
If
Copied is near zero, Robocopy is skipping correctly and the delay is mostly scanning/logging/USB speed.
If
Copied is large, then timestamps/attributes/content are changing.
If you want the destination to be an exact backup mirror
You can use
/MIR, but be careful:
Warning: /MIR deletes files from E:\Email that no longer exist in the source.
Test first:
robocopy "C:\Users\curtis\Documents\em client" "E:\Email" /MIR /COPY:DAT /DCOPY:DAT /R:3 /W:5 /FFT /XJ /MT:8 /NP /L
If the preview looks safe, remove
/L:
robocopy "C:\Users\curtis\Documents\em client" "E:\Email" /MIR /COPY:DAT /DCOPY:DAT /R:3 /W:5 /FFT /XJ /MT:8 /NP /NFL /NDL /LOG:"%USERPROFILE%\Desktop\emclient-mirror.log"
My practical recommendation
For this job, I would use:
robocopy "C:\Users\curtis\Documents\em client" "E:\Email" /E /COPY:DAT /DCOPY:DAT /R:3 /W:5 /FFT /XJ /MT:8 /NP /NFL /NDL /LOG+:"%USERPROFILE%\Desktop\emclient-backup.log"
If the second run still takes hours, I would strongly suspect the
USB flash drive, especially if the log shows most files were skipped.
A proper external SSD will likely make this job dramatically faster than a 1 TB thumb drive.
One question
Can you post the
Robocopy summary section from the bottom of the second run? That will tell us immediately whether it spent 7 hours
copying or just
scanning/comparing.
AT /R:3 /W:5 /V 
