rdiff-backup-users
[Top][All Lists]
Advanced

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

Re: [rdiff-backup-users] [bug] AssertionError: Bad index order


From: Ilario
Subject: Re: [rdiff-backup-users] [bug] AssertionError: Bad index order
Date: Wed, 4 Jan 2017 19:54:50 +0100

2017-01-04 17:44 GMT+01:00 Dominic Raferd <address@hidden>:
> On 4 January 2017 at 16:08, Ilario <address@hidden> wrote:
>> 2017-01-04 15:53 GMT+01:00 Ilario <address@hidden>:
>>> 2017-01-04 15:17 GMT+01:00 Ilario <address@hidden>:
>>>> AssertionError: Bad index order: ('long_filename_data', '820') >=
>>>> ('backup-20140716', 'progetti', 'GeBuRi', '20121101-Progetto GeBuRi',
>>>> 'articoli', 'calcoli')
>>>
>>> The fact that in that directory there's also a file with a long
>>> filename could be a reason?
>>
>> It would not be a problem to remove entirely that directory from
>> remote and all its backup history from rdiff-backup as I still have
>> the original to copy over.
>> Is it possible?
>
> I'm not sure, but I think a better idea would be, since you still have
> the original files (two are indicated in your message), to copy them
> manually into the required directories of the rdiff-backup repository.
> You might or might not have to alter some of the file's permissions
> (depending how the original backup was done) - hopefully not. If this
> is the only problem in the repository then this might enable the
> regression to run. If it's possible it would be wise to take a backup
> of your repository before trying this. Regressions are complex.

Thanks for the suggestion!!!
But in a rush I deleted the whole corrupted dir on the remote side and
every entry referring to it in the mirror_metadata and
extended_attributes files.
The backup is still on going but it looks like the workaround did the job.

Do you think it's worth to dig into this bug?

> In principle I always verify my repositories before adding a new
> backup and I maintain a secondary copy of all the repositories - on
> another machine, so if things break (usually because of a disrupted
> rdiff-backup session) I can fix them immediately and if the worst
> happens and all regression attempts fail I should be able to go back
> to the secondary repositories.

Ok, sounds like a good practice! I will try :)
Thanks,
Ilario



reply via email to

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