>>> rdiff-backup preserves metadata in separate files so it doesn't need to >>> be root on the storage node. If you can make that work, you can avoid >>> the rsync-to-root and use an rdiff-backup-specific non-root user. >> >> I've been informed on this list before that rdiff-backup has >> shortcomings when used to transfer data over the internet and it is >> better to use rsync over the internet and rdiff-backup locally on one >> side of the other. I did find out that rsync --fake-super will store >> permissions and ownership in ACLs so that negates the need for remote >> root. > > Well, if you have that much extra space, perhaps. I do rdiff-backup > over the internet (as root on some box, to a non-root user on another > box) all the time, and haven't had trouble.
Sometimes I'm on the road with my laptop tethered to my cell phone and then I have trouble using rdiff-backup over the internet. >>> The scary risk is silent corruption and losing old backups. So you need >>> to keep periodic backups essentially forever. >> >> If the clients rsync data to the backup server and the server runs >> rdiff-backup locally on that rsynced data, and another system pulls >> that rsynced data from the server and maintains its own rdiff-backup >> repository, I think I should very likely be OK as far as corruption. >> Offsite backups would negate the corruption threat completely I think. >> Does that sound right? > > No, but this is really hard. What if the backup disk has bad bits in > the block of some file? What if the bits go bad on the machine being > backed up? What if you then diligently copy those bits for 2 years, and > only keep 1 year of backups? That's true, corruption really is still a problem. What can be done? - Grant _______________________________________________ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki