Hi all,
On Thu, 4 Sep 2014, Dominic Raferd wrote:
If I had enough space for the LVM snapshot, I would probably rsync the
current
data and run rdiff-backup locally on the destination every time rsync
succeeds.
This would provide - in our setup - the same protection as LVM with respect
to broken increments, but also resume a partial session after network
shortage
and server restarts.
You are facing quite a tough situation! You didn't comment on the idea of
lengthening the ssh timeouts, but given the severity of the situations you
have to allow for, maybe this can't help. I should point out that using an
LVM snapshot should not need nearly as much space as rsync because it only
has to store the differences between the old rdiff-backup archive and the
new, and it does not have to persist once the backup is complete. Still rsync
is a simpler (and more familiar) solution and surely the lack of disk space
is cheaper to fix than the value of your time recoding rdiff-backup?
That gives me an interesting idea. Since the rdiff-backup destination is a
mirror of the source, we can rsync over it. Of course if we did this on a
real repository it would destroy it, but we could safely do this:
* create a writable LVM snapshot containing the rdiff-backup repository,
* delete the rdiff-backup-data directory from it,
* rsync from the target over the snapshot's rdiff directory,
* run rdiff-backup from the snapshot back to the original location,
* then discard the snapshot.
Cheers, Chris.
--
_____ __ _
\ __/ / ,__(_)_ | Chris Wilson <chris+...@qwirx.com> Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |
_______________________________________________
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
