>>> I was worried more about corruption *on the system being backed up*, >>> which would not be detected for a long time, and then you have bad bits >>> and want to find old backups. >> >> I see. As long as the rdiff-backup repository has not experienced >> corruption independently, it should be able to recover your good data >> by regressing through the bad recent files back to good earlier >> ones. In fact this is a critical attribute of rdiff-backup and a >> reason why it is so valuable. > > Fair enough, but you're then left with a single point of media failure. > Hence my focus on multiple tape/disk back in time. But I agree > rdiff-backup does a tremendous amount of good.
How about pushing from the clients to the backup server, updating an rdiff-backup repository of the pushed data on the server, then pulling the rsynced data from the backup server to another system, and updating an rdiff-backup repository of the pulled data on the other system? Would that eliminate the "single point of media failure" problem? A third set of backups in a third geographical location could even be added. With a redundant system like that, are offsite tape backups only necessary if you periodically prune the rdiff-backup repository? - 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
