I’ll look at trying out 7Zip on my machine, but I did see an option in WinRAR to convert an archive, so perhaps that could be useful? Force it to use the same type of compression like the recovery tool does.
Maybe, but it could use a more expert opinion because I don’t think conversion is done much, and you might be bypassing some of what conversion does. I’m not familiar with the internal operation.
RecoveryTool help (at least in some cases) calls for database recreate because database knows an expected size and hash for the file – but you changed it, so it will probably not download right.
A dindex file also knows the size and hash of its dblock, so you may need to adjust values in that.
{"blocks":[{"hash":"AxbTM+jwwcXMDZLbvoT6RTA/NQNa2oGpDys3Hkm58h0=","size":104},{"hash":"LoWLQQxtyckn6ZZO2jIu6OSyp9NBB76EmYvX3PvGnSQ=","size":137}],"volumehash":"GnuVwWzAXfaoms7Jh1bKCJZpvWfcuckgp26BWpe/uRI=","volumesize":773}
is an example of a dindex vol file. It says what blocks are in its dblock, and has info on dblock file.
Are you still unwilling to share files with the developer, or just trying to get back up with least loss? Typically people with dblock files that are unreadable just do the purge-broken-files procedure which then allows next backup to replace removed files. You do lose some historical data though.
As a side note, you don’t yet know what other files in Destination might have a similar latent issue, however you now have a way to survey (although it will mean downloading the files for the check).
The suggested tests will also show if this is a new bug. It may well be a rare old one, so this whole discussion could get moved out of this release announcement. Developer can look at files for you.
Yeah, there’s too many sensitive files in there and not that I don’t trust the people here, you still never know what could happen in the future.
I don’t care so much about the file history, for this server anyway, so I will look at the purge procedure and see how it goes.
Anyway, I’ll still have the downloaded files in case the devs ever ask more about this, but thank-you so much for helping out and putting up with some of my daft questions.
On to the next release…
Just for reference, I performed the purge after renaming the broken file, and nearly 12hrs later got a completed backup.
I thought you were completing backups previously, however if you mean you can now stop using the no-auto-compact, there would have been some extra time spent catching up on the compact.
As for figuring out which of your blocks from your troublesome dblock is the bad one, a possible method is to make a backup of the folder which has its blocks (use the previous LZMA settings), then see if you can restore all to another folder. I think Duplicati 2.0.9.x no longer defaults to the shortcut of using local blocks, so restore will likely have to read your new dblock files, and these should contain all the previous blocks that your troubled dblock has, except now each block is a small file. I think restore names files that don’t restore, and this might find the troublesome block.
Yes, exactly that because as you stated backups would fail before with that not present.