Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Unable to restore backup: blocksize mismatch in manifest #2323
Duplicati Version: 126.96.36.199_experimental_2017-02-03
Attempting to restore a backup results in the error:
After this error is thrown, no files are listed for restoration on the Restore Files page.
Steps to reproduce
The following messages are logged:
Expected result: Files are listed for restoration in the Restore Files dialogue
It should work without configuration, but for some reason it does not automatically detect the new block size in your setup. You can set the block size in the "Advanced options" on the second page of the restore (the first page also has a section with "Advanced options" but these are for the destination.
Hey @kenkendk, thanks for the reply.
I've tried passing the option
I've tried substituting 1048576 with 1073741824 in my supplied options, but Duplicati tells me this is too big for a block size.
as advanced options throws the same error as above.
I'm having the same problem, I can't run a restore. This has shaken my confidence in Duplicati. I was planning on switching my main backups over, but I'm now wondering if the software is ready. I figured after 2 years in beta it'd be ok, but maybe with backups I need to be more prudent and try CloudBerry or similar.
I have my files backed up to Amazon S3 (plus some others locally, but that's not relevant here). I customised the block size and upload volume size before my initial backup, with a block size of 200kb (204800 bytes) and an upload volume size of 500.
I installed Duplicati on a different machine and did a test restore and got this error message.
Failed to process file: duplicati-20170520T074022Z.dlist.7z.aes => Invalid manifest detected, the field Blocksize has value 204800 but the value 102400 was expected
Based on this bug report I added the "--blocksize=204800" parameter in the advanced section.
I ran the restore again and I got a very similar error message, but with different numbers and referring to a different file
Failed to process file: duplicati-20170522T073218Z.dlist.7z.aes => Invalid manifest detected, the field Blocksize has value 204800 but the value 209715200 was expected
I note that 209715200 / 1024 = 204800, but I don't know how that's relevant.
-- Env info --
EndTime: 5/22/2017 7:42:28 PM
BeginTime: 5/22/2017 7:42:25 PM
EndTime: 5/22/2017 7:59:05 PM
BeginTime: 5/22/2017 7:59:00 PM
referenced this issue
May 23, 2017
Restoring from PC with local database is without problem.
My backup parameters:
I find workaround:
If I export backup backup job from computer with database and read additional information - (dblock-size), then I can use it for restore.
So if I restoring with parameters:
no error will appear and I can browse versions but this is not very intuitive...
I had the exact same issue as mrflibble, except for one thing: I was too late for the workaround. I set up a backup ages ago and customized block- and dblocksize. As would be expected, I forgot the exact block sizes I chose. Using the Duplicati GUI, I regularly checked whether my backup was maintained well, by opening the "Direct restore" option and trying to restore any random file. Actually, I did so last week and it worked just fine. To restore, I never had to bother about the block size, as the system was nice enough to remember it for me.
Inevitably, the big crash happened. I had to restore my complete system and as import stuff was stored in the cloud anyways, I took the chance to start from a clean OS install. Which meant I had to reinstall Duplicati as well - and although the backupped database was untouched, I could not restore the files anymore as neither I nor the all-fresh Duplicati installation remembered my customized block sizes.
The workaround @mr-flibble suggests only works if one of you systems still has the original setup. Mine didn't. However, it's not too difficult to find the parameters required.
Workaround for @mr-flibble's workaround
If you have a backup with customized block/dblock sizes and you don't remember how big they were
Find block size
Luckily, the error you get already mentions one of the missing values. In my case:
so the blocksize is 409600B.
Find dblock size
For those who are as lazy as me and use the Duplicati GUI:
Restore > Direct restore from backup files
Adding to this issue, the
@tomwaldnz: You can do as @loesvs suggests, and snag the value from the error message. When setting the size, be aware that the parameter expects
You need to change:
Without testing, it should also be possible to use
@tomwaldnz, I believe it's in the 188.8.131.52 release which must have come out pretty much as you were typing your message. :-)
@JonMikelV yes the canary came out, but I found another bug that prevents restore. It looks like an old one that was closed, so I commented there, but I'll probably open a new bug later today as there's no way I can see to reopen the existing bug.
It's disappointing to wait a year for a bug fix only to find another bug that prevents restores.
Sorry if I understood it wrong but on the latest canary (duplicati-184.108.40.206_canary_2019-02-06), I get the same error if I don't add the --blocksize option.
On step 4 if I add my --blocksize value as an advanced option it works without a warning.
Confirming @Onurtag finding of an incomplete fix while looking at Restores on non standard parameters. Made a test backup on 220.127.116.11, then confirmed failure on 18.104.22.168, 22.214.171.124, and 126.96.36.199 (where I did further debugging using a debugger). The key is step 5. The newest version comes up properly and automatically when advancing to screen 3 to select files, and the code fix is used. For the others, the code fix is bypassed because autoDetectBlockSize is set to false. Viewing Configuration table of temporary folder dup-<GUID> database (fish around -- it's probably the very latest file) finds blocksize with a value of 102400 despite the manifest. Editing it to 102401 causes that number to be reported on the eventual error, so I think issues are 1) default value gets in DB, and 2) it's read/used. Also ran 188.8.131.52, and it failed on the transition to screen 3, so the fix is at least able to get the latest without adding manual --blocksize in screen 2 Advanced Options.