On 04/09/2014 13:01, Marco Mariani wrote:
Even if it does, it isn't much use if your communication drops are so
frequent that you rarely complete a single backup session, because
your last
usable backup data might be too old for your purpose.
Not only at the level of backup sessions, I must consider the case of
single
files that are so big they won't go though in a single session. The
network
may be mobile or in a hostile environment. It may be up only part of
the day.
Servers may be restarted or have power failures once per day.
_*Backup to a snapshot*_
If your rdiff-backup repository is on a non-root LVM-based volume,
you could try
the following:
* On the server (destination), create a read/write LVM snapshot of
the volume
holding your (consistent / good) rdiff-backup repository
(discarding any
pre-existing snapshot, and allowing the snapshot plenty of
additional space)
[...]
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.
Thanks a lot for your reply, I think that my only option is to change
the code.
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?
My practice FWIW is to run rdiff-backup locally and use rsync with
--link-dest to synchronise a remote copy of the rdiff-backup repository.
If you do decide to work on the code, I think you should start from the
1.3.3 (or 1.2.8) codebase. I expect that the latest in cvs has been
messed around with over the last 5 years and its consistency is unknown
whereas 1.3.3 and 1.2.8 are stable. I am sure all users would be
grateful for your contribution.
Dominic
_______________________________________________
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
