[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dominic Raferd
Subject: Re: [rdiff-backup-users] adding --resume back
Date: Thu, 04 Sep 2014 14:40:01 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]