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

[Dominic Raferd]

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?
>
> On the remote side I found this message in backup.log file:
>
> ===
> Previous backup seems to have failed, regressing destination now.
> Warning: Could not restore file
> backup-20140716/progetti/GeBuRi/20121101-Progetto GeBuRi/Progetto
> GeBuRi.tar.gz!
>
> A regular file was indicated by the metadata, but could not be
> constructed from existing increments because last increment had type
> None.  Instead of the actual file's data, an empty length file will be
> created.  This error is probably caused by data loss in the
> rdiff-backup destination directory, or a bug in rdiff-backup
> Warning: Could not restore file
> backup-20140716/progetti/GeBuRi/20121101-Progetto
> GeBuRi/articoli/Effective transport properties for polymer electrolyte
> membrane fuel cells.pdf!
>
> A regular file was indicated by the metadata, but could not be
> constructed from existing increments because last increment had type
> None.  Instead of the actual file's data, an empty length file will be
> created.  This error is probably caused by data loss in the
> rdiff-backup destination directory, or a bug in rdiff-backup
> Previous backup seems to have failed, regressing destination now.
> ===
>
> 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.

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.