[Top][All Lists]

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

Re: [rdiff-backup-users] backups failing

From: Richard Hector
Subject: Re: [rdiff-backup-users] backups failing
Date: Tue, 6 Feb 2018 00:42:40 +1300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 06/02/18 00:27, Dominic Raferd wrote:
> On 5 February 2018 at 10:59, Richard Hector <address@hidden> wrote:
>> Hi all,
>> I have a problem with an (inherited) rdiff-backup setup - actually used
>> from backupninja.
>> When I try to run a backup, I get:
>> OSError: [Errno 2] No such file or directory:
>> <redacted>/foo.2018-01-30T08:55:35Z.dir
>> I get the same thing if I run with --check-destination-dir.
>> I'm not clear why the file is missing, but probably due to a backup that
>> stopped part way through for some reason.
>> I'm also not clear why the file needs to be there in the first place -
>> should there be one for every directory for every backup (that hasn't
>> been deleted yet)?
>> I've tried just copying the previous one to the name that's missing
>> (they're all size 0), and am re-running --check-destination-dir. I
>> suspect it won't be the only file affected though.
>> It's a bit fiddly, because I don't have shell access to the destination
>> machine - it's rsync.net, and I can only run certain provided commands.
>> I guess that also means I couldn't patch the remote copy of
>> rdiff-backup, if I found a way to fix it.
> This could be tricky. I would suggest doing what you are already doing
> i.e. manually create dummy files for any that are reported missing
> when you run rdiff-backup --check-destination-dir and repeat as
> nauseam until you hopefully get it to work.

Gah. I thought I was doing better than that - many of the directories
are similarly named (00 through FF), so I used a for loop to create all
the missing ones, and confirmed they existed.

Then I re-ran with --check-destination-dir ... and now a whole bunch of
them have gone again.

I think I need something I understand better ...

> For the future, I recommend that you verify an archive before adding a
> new increment and ideally take a backup of said archive in between:
> - verify (primary) archive
> - if successful, update your backup of archive
> - if update of you backup of archiveis successful, add increment to
> (primary) archive

Both the machine being backed up and the one being backed up to are
halfway round the world somewhere, and the backups use about 150G. I'm
not keen to drag that all down if I can avoid it ...

I have to confess, being much more familiar with dirvish, I find it
rather easier to comprehend ... it doesn't work in push mode though.


reply via email to

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