-
Notifications
You must be signed in to change notification settings - Fork 873
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Direct restore fails with non-default blocksize #5196
Comments
Are you sure? New default went into master on April 21, which would have been between Experimental and Beta, so unlikely. |
You are right, the reproduction is for the current master branch. You should be able to reproduce it with a blocksize of 1MB in the released version. |
The cause why it only fails for direct restore is here: duplicati/Duplicati/Library/Main/Operation/RecreateDatabaseHandler.cs Lines 344 to 345 in a89ccde
duplicati/Duplicati/Library/Main/Operation/RecreateDatabaseHandler.cs Lines 178 to 188 in a89ccde
For the first run, this is called before the detection, so it saves the default blocksize in the database instead of the correct one. 355ef92 added an extra duplicati/Duplicati/Library/Main/Operation/RecreateDatabaseHandler.cs Lines 240 to 247 in a89ccde
c7e1ece added a fix because the duplicati/Duplicati/Library/Main/Operation/RecreateDatabaseHandler.cs Lines 198 to 204 in a89ccde
As a side note, this will also fail when changing the hash algorithms. I don't know why the |
Confirmed. I'm surprised it hasn't been seen before. Maybe need of old version helps. I know increased blocksize is sometimes used, e.g. for performance on larger backups. Wouldn't increased default blocksize on .NET 8 versions increase the visibility of issue? Any workaround spotted yet? |
I guess most people don't use direct restore, but import the job and recreate the database fully. And those who do were probably only interested in the latest version.
You should be able to set the blocksize explicitly in advanced options underneath the password to fix it temporarily. |
Confirmed, but not underneath the screen 1 Password, but underneath the screen 2 Passphrase. It's easiest if you know the size exactly in the somewhat picky option format, e.g.
If one doesn't know the blocksize, it seems like hiding dlist files of undesired later dates works, e.g. by changing prefix (if possible). |
Fixed issue by changing order options are written and verified. Some whitespace changes due to renaming a method
It took a bit to figure out what is going on exactly. I reworked the logic around when the values are written, so they are always written if anything has been parsed from a manifest file, and changed the logic so the default values are not written in this operation. There is a bit of logic involved, but essentially, the operation can only work if there already exists a remote file list, and this will naturally provide the correct values. I think a later refactor should split the validation of parameters and the saving of parameters to make it more clear what is intended. |
…ocksize-issue Implemented test for reproducing issue #5196
Environment info
Description
Direct restore does not save the detected blocksize from an existing backup. Instead, it tries to use the default value.
The detection works for the first partial recreate, which creates the latest version. However, the default blocksize is saved in the temporary database instead of the detected version.
Steps to reproduce
--blocksize=100KB
,--upload-unchanged-backups
to a local folderA warning is shown and the list of files is empty.
The older version should show in the list and be restored without any problems.
The text was updated successfully, but these errors were encountered: