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?