Link to my comment to this issue on github: Locked files seems to cause corrupt backup · Issue #3594 · duplicati/duplicati · GitHub
I had the same problem in a backup set.
I found a query in the log: SELECT * FROM “Blockset” WHERE “Length” > 0 AND “ID” NOT IN (SELECT “BlocksetId” FROM “BlocksetEntry”);
Only one row returned for me with the SQL Browser. I found a record in the BlocklistHash table (BlocksetID) so I deleted these 1-1 records from the BlocklistHash and BlockSet tables after a db backup.
And now my job is running again.
I’m basically going to say the same thing that gabor just did, but just reporting another case, and how I fixed it. I had this same issue happening on my macOS machine.
(And the obvious warnings here before anyone proceeds. I’m not a SQL expert. I’m not a Duplicati expert. Make sure you make a backup of your database before doing anything.)
On a mac, the database file is in: ~/.config/Duplicati/
It’s the long string of numbers ending in “.sqlite”. It will probably be a pretty big file.
I made a copy of the sqlite file as backup.
I then opened the sqlite file using https://sqlitebrowser.org/. (Or really whatever sql program you want.)
I ran the query as suggested by johnvk:
SELECT * FROM Blockset WHERE Length > 0 AND ID NOT IN (SELECT BlocksetId FROM BlocksetEntry)
That found exactly one entry in my database in the Blockset table. I deleted that entry.
In duplicati, I then repaired the database (don’t know if this was necessary or not).
Then the backup worked! Huzzah.
I also get “Detected non-empty blocksets with no associated blocks!” error.
Using Windows 7, Duplicati - 220.127.116.11_canary_2019-06-30.
Remote is Debian 8 SFTP.
I just ran into this error myself. Win10, Duplicati as a service, 18.104.22.168_beta_2018-11-28.
Remote is to a mapped network drive on my Asus router
Backups have been running fine for a while, otherwise (as far as I know - basically, I didn’t see errors).
The last backup was on Friday last week, and this just started happening after I returned from a business trip, so there was no tinkering involved along the way. I tried repair, and it didn’t find anything wrong. I’m currently in the middle of a “recreate database” which is taking a very long time (been running for about 12 hours now, which seems like a lot for such little data (relatively… I only have a 75GB backup).
In full disclosure, I did stop the backup on Saturday as it was backing up some large and unnecessary files. I stopped the backup in the interface, and told it to stop immediately (instead of waiting for the file to complete). I then deleted those files and restarted the backup. I thought it ran without issue, but maybe it didn’t and that’s what caused it?
I also wish I had seen gabor’s recommendation before so I could have tried that instead, but I’m in it now, so I’ll let it go until it finishes, I guess.
It surprises me that it would take this long to rebuild the DB. Again, I’m running local, so if I ran over the GBE wire, I should see 1Gbitps rates for a normal backup. 75GB = 600Gbit, so theoretically I’d get this backup done in 600 seconds, or 10 minutes. Theoretical speeds aside, even if I only got 10% of throughput, I’d expect to see 100 minutes, or less than 2 hours. Why does it take so long to rebuild since that’s not actually performing a backup? (I don’t see that much activity on the drive during this process… so it’s not network limited?) Or maybe my math is way off?
Still, I’d like to know what the official fix is… or what the workaround fixes are in case this happens again.
It looks like you can touch the DB files and it solves the issue.
Thanks… I’ll keep that in mind in the future. My database recreate just completed this morning finally, and I ran a subsequent backup and it completed successfully, so that’s good.
I do agree with your other post, it’s unacceptable for this to happen, and the software is simply not very fault tolerant as-is today. The fact that I stopped it, and told it to stop immediately… and that broke it? That’s ridiculous - don’t provide an option for which you can break the software! If I have to wait for the current file to finish, then tell me so…
But, furthermore, as in your case, if you can’t wait for it to finish and you hibernate or whatever, that shouldn’t break it either. Sure, the backup won’t complete, but it must be able to recover… and not force you to workaround and jump through hoops to fix it (or, as in my case, wait MANY hours to fix itself). Or, at least have a repair function that works for these cases…
I’m hoping something is done to improve this quickly…
Empty source file can make Recreate download all dblock files fruitlessly with huge delay #3747 is one possibility (and probably quite common) but not the only one. It’s fixed in recent canary (if you’re daring enough) or v22.214.171.124-126.96.36.199_experimental_2019-06-28 which is sort of a lead-in to an upcoming beta.
Unfortunately “no associated blocks” hasn’t been tracked down AFAIK. Ideally there would be test steps which reliably reproduces it so developers can look at it in depth, e.g. by –log-file-log-level=profiling plus --profile-all-database-queries=true. You can set that up on a –log-file if you like, but what to do with a log with some personal info in it (primarily pathnames) is a question. Ideal reproducible test is non-personal.
At least two of us have provided a way to replicate the problem - stop the backup (either with the “stop immediately” option, or via hibernate/sleep as the other user mentioned). Then when it fails and stops, retry and it should happen again. That’s what appears to have done it for us.
If you need me to replicate myself, I can generate a test backup and perform this, I just need to know exactly what log settings are required and what log files to provide. I’m happy to do this, just tell me how.
Thanks for the close reading. They originally looked more like leads than definite, but any leads are good.
“stop immediately” here as one of a chain of actions that preceded the problem. It might be a clue.
“hibernate or whatever” mentioned too as “shouldn’t break it either”, probably referring to post here.
Stop has been a trouble spot that got worse in 188.8.131.52, with some pushing for fix underway. Work is here. Interestingly an opening comment talks about it removing the stop button until corruption issues get fixed, however that corruption (at least based on the work at the bottom) was “Unexpected difference in fileset”.
It would be very helpful if you could play with it, using pathnames you don’t mind revealing, and a storage type that is very available. I usually like local file for that reason, but possibly the issue is storage-specific.
Possibly it’s also Duplicati version-specific. I did do quite a bit of stopping and sleeping but didn’t get this.
If you can get sure-fire test steps, logs become less important, but the most you can get is the following:
These go well with database bug reports which attempt to sanitize pathnames against ordinary browsers. Going past 184.108.40.206 will hit a regression though. It forgot to sanitize a new table. Use non-sensitive paths…
If you really want to get into it (and if not, a developer may), to debug issues that might have been caused awhile before the symptom showed up, sometimes keeping a trail of recent database content is valuable. Here is a script that I used while solving “Unexpected difference in fileset” test case and code clue #3800.
@herbert actually volunteered debug help earlier (thanks!) but the problem appeared more vague then. Running heavy debugs all the time gets painful. It’s a little easier if one has an idea on how to start debug. Sorry about the earlier non-response, but anybody who wants to jump into these steps is welcome to join.
Thanks, and I hope you can nail it with something anyone can do. If you get there, feel free to file an issue which is officially the tracking system (support requests are too numerous and have no tracking method).
Is there an update on this? I can confirm that the issue seems to happen when stopping now or restarting the host mid backup.
Is this when using the “Stop now” and you get an error saying “Thread was being aborted”?
Welcome to the forum @ShaneKorbel
CheckingErrorsForIssue1400 and FoundIssue1400Error test case, analysis, and proposal #3868 found steps to reproduce that and also “Detected non-empty blocksets with no associated blocks!”. The fix by @BlueBlock went in yesterday, so should be in Canary soon, then Experimental, and Beta, BUT issue had to do with the source files changing during the backup, and I don’t know which reports here that fits. Yours sounds different, and I’ll leave it up to the individual reporters here to decide if above fix helps any.
Fix ‘stop after current file’ #3836 and Fix pausing and stopping after upload #3712 are current efforts, but I’m not sure where they stand. Note you have the developer of the first named request talking to you now.
@BlueBlock: I can reproduce this too and yes it happens when you stop the backup job and restart it.When disabling snapshots it seems to work.
What Duplicati version? The new code intended to fix this isn’t in anything but canary releases so far.
Improved handling of the “Stop after current file” method, thnaks @BlueBlock
Also what exact sort of “stop the backup job” are you doing? Note the fix is only to one particular way.
I’m also thinking there are two paths to the same result. The other path is a file that’s changing while backup is running (does not require stop of any sort) while your problem apparently requires the stop.
Version is 220.127.116.11_beta_2019-07-14 'cause it is advised as the most stable. Good to hear it may already be fixed in a newer version.
I stop the backup job via the cross-button on top of the page, then “Stop now”.
I’ve got the same “Detected non-empty blocksets with no associated blocks!” error with the newest download installed just last week. We are using Windows small business server essentials 2016. We have been using duplicati for nearly a year and have only ever had 1 successful backup.
Welcome to the forum @CraigHamilton
Can you be more specific, i.e. give the version, or say if it’s Beta (which is a year old) or latest Canary? Beta channel versus Canary channel should be easily visible in the upper left corner of the home page.
Are you willing to try Release: 18.104.22.168 (canary) 2019-11-05 which seems to be doing well so far, except for a problem with “Stop after current file” that’s being worked on (don’t use that)? You can’t easily revert after using this (due to database format changes), but it sounds like your current backup situation is very poor, so maybe you can just give up, start again on the latest, see what happens, and report any issues.
Canary is unpredictable because it’s usually had little run time, but right now it’s nearly Beta quality, and you can avoid more Canary if you like by changing your Settings to Beta channel and awaiting its arrival.
If you’re not willing to pick up the fix in Canary form, a workaround for Beta might be to use –snapshot-policy to use Windows VSS to avoid the confusion caused by trying to backup a file while it’s growing…
Possibly it’s a different problem, but that’s the one that got fixed (but won’t be in a Beta until next Beta).