I had a corrupt file…
Listing remote folder …
remote file duplicati-i8427bf0f54754ad09a9624cc603a833a.dindex.zip.aes is listed as Uploaded with size 0 but should be 97421, please verify the sha256 hash “mBBAE0MUxJliwwoPTwx5YNZU7vrVkfepCT8qSmTAu8s=”
But I could not figure out which --version the .aes file was in. So I had to continue to delete version 0 till I got the version with the corrupt file. This would have been a lot easier if I could have just listed the versions and their .aes files or searched for it somehow. Then deleted JUST the version with the bad file.
The best way to handle these is to delete dindex and let Repair upload it again, provided the database still has needed information which can be lost if the database is recreated from destination that’s already bad.
The affected command doesn’t appear to handle dindex files with the nice output it produces for dblock. There’s a similar non-result (at least for me) for The LIST-BROKEN-FILES command for missing dindex.
There may be room for enhancement in the tools. You could open an issue to track, but backlog is larger than available resources. Anybody able to help with Duplicati in any way (including forum) is encouraged.
That might be oversimplifying. A given version’s blocks can move to different dblock files due to compact.
EDIT:
and although the initial creation of a version uploads a specific set of files, they are just the changed parts, meaning the blocks already on the destination in other dblock files are referenced and not uploaded again.
Every dblock file ordinarily has a dindex file to index its contents, however I’m not sure of any easy way to map an index file name into its associated dblock file name for use with the usual damage-analysis tools.
A not-easy way is to open the database with a browser such as DB Browser for SQLite and work with the Remotevolume and IndexBlockLink tables. In below, volume 4 dindex file goes with volume 3 dblock file.
NO! NO NO NO! Delete and Repair is NEVER an option. I have sat for over a month watching it try to complete that process at times. All that while it is not backing up. I mean if you have a couple gig and it is on a local drive… sure that may work. But not for computers that have a 500gb backup over an sftp connection. Backups have to be surgically repaired. You are literally better off deleting everything and starting over than doing a delete and repair.
The information is obviously there and available. The question is, if there is a command to retrieve it. If there is not… there very much needs to be one. Truly this should all be able to be made automatic with an argument. The lack of self realization and automation is the biggest flaw with duplicati and has been the thing keeping it from becoming super popular.
I will play with the “AFFECTED” command next time I have this issue and see if that helps me.
Please note exact wording: “delete dindex and let Repair upload it again”. You’re almost certainly talking about a different option to delete database and let Repair recreate it by downloading files (maybe many), which isn’t at all the same repair. The repair I describe looks over the file list, finds missing dindex, fixes.
Here’s an About → Show log → Live of the dindex file being replaced from database info after I deleted it:
You’re clearly talking about database delete. I don’t fully agree with you, but the delete here is dindex file.
Good luck. I don’t think it will help you with any missing dindex if it works for you the way it worked for me.
The method that I gave will help you. Feel free to test all this out on a test backup in advance if you prefer.
I am sorry if I misunderstood you. I am looking to keep this quick and SIMPLE. If I can list what image version the corruption is in I can just delete that version and move on with my life. Clearly the program knows as when I delete the version it is in, it lists the .aes file right there.
See earlier note about “might be oversimplifying”, but a corrupted destination file can affect many versions because its blocks might affect source files far into later versions. I just tried a test where all were affected because files existed into later versions. I had deleted a dblock from first version and run a list-broken-files which, along with purge-broken-files, would produce a surgical repair by purging only affected source files.
Recovering by purging files explains the process but forgot to say corrupted dblock needs manual deletion (assuming file is damaged and not already missing) to get detailed damage report of source files/versions.
The problem, as mentioned earlier, is that the tools don’t seem to work on dindex damage. Unsure why not.
You can file an issue, as mentioned earlier, if you see the same issue I did. I didn’t notice the issue filed yet.
Issues are tracked (which doesn’t mean they’re fixed fast – resources are low). Requests in forum are not.
Thank you so much for your responses and support. I do appreciate you.
In this circumstance I needed to get the backup on-line so I went ahead and just kept deleting the zero version till it got the file it was complaining about. I lost maybe 3 versions. I was just hoping to find a more precise way as this sort of stuff happens often. As I have now solved it I will put it to bed till it happens again. Thank you!!
