We make use of the following script to backup a folder (quite large - approx. 400GB), to a NAS with EXT4 Filesystem:
robocopy "Source_Directory" "\\NAS\Destination\Directory" /MIR /FFT /COPYALL /W:5 /r:10 /log:"C:\RoboTest\robotest.log"
Research indicated that the /FFT switch is required to make up for time differences; however the issue still persists and all files are marked as modified.
Any help on this would be greatly appreciate.
After lots of trial and error I think I found the reason: the Archive attribute.
When Robocopy comes across a file with the Archive attribute set, it will systematically display the file as "Modified" in its logs and count the filesize toward the total amount of data copied to destination (Copied column). However this is misleading, because unless the file was really modified (timestamp is more recent, for example), Robocopy doesn't really copy the file and skips it instead.
Try it with a large file. Add a big file to your source tree, one that would take some time to transfer to the destination server. Run Robocopy the first time: it should mark the file as "New File" in the logs, and take some time to complete the transfer. Next, make sure the Archive bit is set on that file using the attrib +a <filename> command. Launch Robocopy once more. You should find that it will be listed as "Modified", but notice time that this second run is much faster: Robocopy didn't really transfer the file again over the network. Then, at last, remove the Archive bit with attrib -a <filename> and run Robocopy one last time. It will skip the file as expected.
Unfortunately I could not find this behavior documented anywhere, even on Microsoft's own documentaion pages. (If someone does, please let us know!)
The solution is to either ignore files marked as "Modified" in the logs, or run attrib -a /s on your source files before running Robocopy.
Several people have reported this problem on the Microsoft forums.
You can add /a-:a to the robocopy commandline to remove the archive bit during the process.
