Backup job copies ALL files instead only changes

ESXi attaches the ReadyNAS share as a store via NFS, then vmProtect writes to the ESXi store.

FIXED! (Sorta.) I am happy to report that rsync fixes the problem--rsync copies only the missing files and ignores the granularity difference between EXT to NTFS. And StephenB is correct on username/password--none needed. This works on both NVX v4.2.26 and NV+ v4.1.6.

Big downside is that rsync writes the truncated time (nearest second) to the destination time. Be nice if it used that for comparisons only but copied the FULL time (let the destination truncate to its highest granularity). E.g., I've previously used the non-rsync method to copy files without issue from NTFS system to ReadyNAS then ReadyNAS to NTFS USB. Works fine because the granularity was already truncated by the original NTFS system to 7 decimals. However, if I try the same with rsync, the copies get truncated to the nearest second, and their timestamps no longer match the original. Now if I compare timestamps with something other than rsync (which isn't included in Windows...see illiterate user comment above)--or even rsync but with the default, untruncated granularity--the timestamps don't match and I've got the same problem again. Argh! I guess that's why my clients pay me the big bucks to bang my head against the desktop over problems like this so they don't have to...hmmm...maybe they're not such stupid users after all. :)

Thanks for providing your resolution.

On the windows issue, robocopy has quite a few options, some of which might help.

Robocopy is my go-to copy app because it's one of the few that accurately copies all file attributes, and even works on folder timestamps, which virtually every other copy program neglects. It has an /FFT switch with 2 second granularity.

However, robocopy has similar issues with timestamps. Without /FFT, older versions checked and copied to millisecond granularity, while newer versions copy full NTFS granularity, resulting in the same problem as above. Stupid, but even so, it's rarely encountered because it requires comparing the same files with different versions of robocopy (i.e., different OS), unlike the above which fails on the same machine repeating the exact same operation.

I was thinking about /maxage in particular. If you doing these copies periodically, you might not need strict timestamp checks.

Nope. Can't use /maxage. My clients have multiple USB drives that rotate between one onsite and others stored offsite. The swapped drive is weeks out-of-date.