I have a ReadyNAS NVX running 4.2.26. It has a share used for our ESXi server backups. I then have a ReadyNAS backup job that runs everyday and copies the backups from the NVX share to a USB drive attached to the NVX. The USB drive gets swapped weekly (or when my client remembers, which is more like monthly) among a set of 3 drives and stored off-site.
My problem is that our daily incremental backups are only 5-10GB, but instead of copying just these new files, the job copies ALL 2TB of old backup files EVERY DAY. And, yes, I DO have "Schedule full backup: First time" and no, "Remove the contents of the backup destination" is NOT checked, and yet the job still copies ALL files every day.
I can watch real-time in a folder comparison utility as the job re-copies existing files in seemingly random order. This is killing by backups--taking over 200-400x longer to complete and wearing out my drives 200-400x faster. Help!
Re: Backup job copies ALL files instead only changes
It's a standard Backup Job via ReadyNAS interface from a ReadyNAS "Share: Name" to a ReadyNAS "USB Device: Port". There is no option to select a specific protocol in the job, and I have no idea what protocol ReadyNAS uses behind the scenes to perform the backup.
Re: Backup job copies ALL files instead only changes
Perhaps the ESXI server is altering some attribute of the existing files that is making them appear to the Readynas as needing backing up. I don't know how the ESXI backup works. There has also been an issue described where timestamps on different filesystems had different resolutions, leading to similar behaviour to that you have described. I thought it had been fixed though and it occurred in os6
Re: Backup job copies ALL files instead only changes
The backup is actually done by Acronis vmProtect. Each backup is done to a separate file, and to my knowledge the old files do not change. Thus, all I need is to copy the non-existent files. This should be the easiest incremental backup possible...and yet it copies EVERYTHING. Ugh!
I have looked at rsync using 127.0.0.1 as the "remote" server. However, I'm skeptical that rsync can do better. I know rsync is supposed be faster because it copies only the changed portions of files, but how does it determine what's changed? Seems to me there's only two possible ways.
Does it do a timestamp and size comparison and skip ones that are the same? That would be nice if it worked, but since the current backup can't accomplish that--possibly because of the problems with different filesystems that you mention--why would rsync perform any better?
Or does it read both the source and destination files, perform some sort of checksum, and then copy only the pieces that changed? I can see that being quite efficient with a client/server over a low-bandwidth connection with mostly static data. However, within the same box that takes almost as long as flatout copying everything because everything in both the source and destination will need to be read once, checksum calculated, plus a possible write to the destination. In fact, worst case it could actually take longer if all files changed.
Also, with rsync I have another failure point: username and password. With Share > USB, I don't have to worry about disabled accounts or changed passwords.
However, I can't continue as is, so unless someone can offer a fix, I guess I'll have to try rsync after the current job gets done copying everything again.
Re: Backup job copies ALL files instead only changes
rsync has the capability of updating portions of files based on checksums, but the ReadyNAS command line used in frontview backup doesn't set those options. So it should only copy changed files (based on the usual attributes of timestamp and size).
You shouldn't need a username/password in your case, and the data remains in the unit, since the address is 127.0.0.1.
Your problem might be the use of NTFS. If for some reason the timestamp granularity differs, then the timestamps might never match. Did you check the full timestamps using ssh?
Re: Backup job copies ALL files instead only changes
Hmmm...I didn't think to check full timestamps beyond seconds. Turns out the NVX (ext3?) stores seconds to a precision of 9 decimal places, while NTFS stores to only 7. If both the standard backup and rsync are checking seconds to greater than 7 decimal points accuracy (e.g., HH:MM:SS.123456789...that's a billionth of a second...i.e., a nanosecond. Seriously??? Isn't ten millionths of second enough???), then I'll have to sync ReadyNAS Share to ReadyNAS USB via a remote computer and take the network hit. Unfortunately, the main backups run at night and these secondary backups are scheduled during the day. That's not a problem when they're isolated to the ReadyNAS, but if I have to copying gigabytes and sometimes terabytes of data across the network TWICE while users are there, the huge network hit will NOT be appreciated.
But before I do that, I'll give rsync a try. Just have to wait until the current backup is done re-copying the 465GB backup file it already started. 😛
Re: Backup job copies ALL files instead only changes
There is also a way to set rsync to use 1 second granularity (--modify-window=1). I think there might be a way to edit the default settings the NAS uses to include this - but am not sure. mdgm likely knows. It's also possible that frontview backup already uses this with rsync - there are similar problems with different versions of linux, including the linux used in OS6 and OS4.
Alternatively you could probably write a simple script to truncate the timestamps on the ReadyNAS volume, and put that in a cron job. If it runs before the backup, then the timestamps would match (after an initial sync).
ext4 format will also work (using your existing job), and will be faster than ntfs. ext3 will not. Though as mgdm says, using ext4 requires formatting/data loss (and also means you need ext support on whatever machine might be used to restore the backups or verify them).
Re: Backup job copies ALL files instead only changes
I'd be interested in learning how to set time granularity.
Formatting EXT is NOT an option. My clients run Windows only. If something happens to the ReadyNAS, I need a way to restore backups (yes, I do have restore backups on a regular basis...my clients are extremely computer-illiterate and find all kinds of unique ways to screw things up). And no, I'm not about to install EXT drivers on my clients' Windows PCs and have my clients complain that "My computer doesn't work ever since you <updated IE/installed that printer/cleaned my monitor/...>" They complain enough as it is and that's just adding fuel to the fire. 🙂
Re: 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. 🙂
Re: Backup job copies ALL files instead only changes
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.
Re: Backup job copies ALL files instead only changes
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.
