|Subject:||Re: [rdiff-backup-users] adding --resume back|
|Date:||Thu, 04 Sep 2014 11:21:07 +0100|
|User-agent:||Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0|
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.
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
in the (Linux) client machine's /.ssh/config file; similarly you can set
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 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
|[Prev in Thread]||Current Thread||[Next in Thread]|