Re: [rdiff-backup-users] adding --resume back

[Dominic Raferd]

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