On 12/18/2013 05:29 AM, Ron Leach wrote:
On 16/12/2013 15:28, Dominic Raferd wrote:
Ron, see my utility here:
http://www.timedicer.co.uk/programs/help/rdiff-backup-regress.sh.php
[SNIP]
So, I'd prefer to do something 'manually', if it were possible, so that I could
be aware of what changes were happening.
The net result of the script, after a lot of checking, is to
create a second "current_mirror" file named to match the 2nd most
recent "mirror_metadata" file, making it appear that the most
recent backup did not complete successfully. (The final action of
a successful backup is to remove the old "current_mirror" file.)
Then it invokes rdiff-backup with the --check-destination-dir
option to regress this apparently failed backup. For example, if
you had
mirror_metadata.2013-12-14T22:13:45-06:00.diff.gz
mirror_metadata.2013-12-15T20:15:48-06:00.snapshot.gz
current_mirror.2013-12-15T20:15:48-06:00.data
it would create
current_mirror.2013-12-14T22:13:45-06:00.data
Note that regressing a backup can take quite a long time even if
there were only a few changes. rdiff-backup needs to search
through the entire increments tree since the metadata files for
that session might not be complete.
If you do not trust rdiff-backup to regress a failed or aborted
backup, you really shouldn't be using it.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
_______________________________________________
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
