Chris Wilson schrieb:
What I've started doing to work around this is to rsync the original
data (not the rdiff-backup copy) offsite and run rdiff-backup locally on
the remote server. Not perfect, I end up with two copies of all the data
on the remote server, but at least it does work and appears to save
bandwidth.
Cheers, Chris.
Another interesting approach.
> On Mon, 17 Mar 2008, Greg Freemyer wrote:
>> The bad news is that if my first set gets corrupted, then rsync will
>> relay the corruption out to the offsite copy. My reason for two
>> copies is disaster recovery, not backup repository corruption. May
>> need to rethink that based on this discussion.
I approached the corrupted backup problem by keeping multiple versions
of the first backup (the rdiff-backup copy) on the remote server, with
identical files hard-linked as described here:
http://www.mikerubel.org/computers/rsync_snapshots/ (basically, it's the
--link-dest rsync option).
All the work is done by rsync, so this is as bandwidth-efficient as it gets.
For me, this takes only little more space than keeping a single copy,
but that depends on the volume of changed files of course.
Jakob
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
