On 4 January 2017 at 16:08, Ilario <iocheson...@gmail.com> wrote: > 2017-01-04 15:53 GMT+01:00 Ilario <iocheson...@gmail.com>: >> 2017-01-04 15:17 GMT+01:00 Ilario <iocheson...@gmail.com>: >>> 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. _______________________________________________ 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