@codeHaiku
Rsync should work. If you're having issues, you might look into using a different filesystem on the receiving computer(ZFS) and ensure you are using the right rsync flags.
@codeHaiku oh yeah, if it gets corrupted on the source then you're SOL with rsync.
@Demosthenes And that, Sir, is my issue at hand.
@codeHaiku @Demosthenes rsync isn't a backup tool, it's a transfer/sync tool. Some backup tools are built on top of it though.
Something you might find useful: If you use "rsync -arin src dest" then it'll give you an itemized preview of what it's going to do. This is particularly valuable if whatever you are backing up is mainly archival in nature, as you can see which files will be added/deleted/modified. Then just drop the -n to do it for real.
@urusan @Demosthenes Thanks. I have done the "dry run" of rsync before. However, with thousands of files it is difficult to know which has been corrupted when performing the rsync. The only time you know is when you try to open a file and find that is has been corrupted. Then you check the rsync destination drives, hoping to have a good copy of it, and it, too, is corrupted. You are right, rsync is a transfer tool. I have been using it incorrectly for backups.
@codeHaiku @Demosthenes Well, the reason I mentioned it was good specifically for archival purposes is that in that case you are likely only creating (and occasionally deleting) files. It's not like a final work, ready to be archived will have any further modifications. In that case, any file modification is a likely sign of corruption occurring, which can be checked out prior to committing to it...but only if modifications are rare.
Also, renaming shows up as deletion and reappearance
@Demosthenes I use rsync -av --delete <source> <destination>. The problem is as a file gets corrupted on the source it is cascaded over to the destination.