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

[Dominic Raferd]

Hello Marco

If you want to do some coding work on rdiff-backup then that would be welcome, but I think you will be on your own. rdiff-backup is not under active development at present, sadly.

An alternative is to see if you can prevent the problem of a broken archive arising in the first place.

Automatic regression
As you probably know, if rdiff-backup is interrupted so that the archive is left in an inconsistent state then on the next run it should automatically 'regress' the archive back to its previous consistent state. (There is no official way to force this regression unless rdiff-backup considers that there has been an error, but there is an unofficial way.) So in theory your archive can always be restored to its previous consistent state, but I am not sure if this can be relied upon if you pile failed session upon failed session. 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.

Lengthening session time-out interval
It has been reported that rdiff-backup can work reliably over an unreliable internet connection if you set

ServerAliveInterval 300

in the (Linux) client machine's /.ssh/config file; similarly you can set

ClientAliveInterval 300

in the (Linux) server machine's /etc/ssh/sshd_config. Both machines will then keep an ssh connection open for 5 minutes (300 seconds) which might be enough to give a very high probability that any temporary service drop will not affect the ongoing rdiff-backup session.

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)
• Mount this snapshot and run rdiff-backup to the repository therein i.e. on the snapshot - not the original repository location
• If and only if rdiff-backup completes ok, use LVM's lvconvert --merge function to replace the original data with the snapshot data - for details see http://www.thegoldfish.org/2011/09/reverting-to-a-previous-snapshot-using-linux-lvm/
  
• Conversely, if rdiff-backup fails for any reason, you can discard the snapshot and the original repository remains unaffected
• The risk of rdiff-backup failure has been replaced by the risk of LVM merge failure, but as this activity is entirely local the risk should be much lower
• For the very cautious, make/update a separate backup (e.g. with rsync) of the rdiff-backup repository onto a separate physical volume before starting the procedure above
• As an alternative to LVM (upon which you can mount any filesystem), I think btrfs offers its own built-in snapshot capability
  

Dominic

On 03/09/2014 16:48, Marco Mariani wrote:

On 09/03/2014 05:37 PM, Marco Mariani wrote:

Now I can add some constraints, and avoid content changes between a 
failed
backup and a resume.

To be clear, I do not care about the case of changing files in the 
folder that is being backed up,
like some of the previous proponents of the resume feature.
But I do care about preserving partially transferred files. I don't only 
have slow connections,
but they can unexpectedly drop. I reckon this may not be a common use case.


Regards,
Marco


_______________________________________________
rdiff-backup-users mailing list at address@hidden
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

--
TimeDicer: Free File Recovery from Whenever