Fatal error: Detected non-empty blocksets with no associated blocks

Support
41

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 v2.0.4.21-2.0.4.21_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.

42

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.

43

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 2.0.4.5, 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 2.0.4.5 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).

1 Like
44

Is there an update on this? I can confirm that the issue seems to happen when stopping now or restarting the host mid backup.

45

Is this when using the “Stop now” and you get an error saying “Thread was being aborted”?

46

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.

1 Like
47

@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.

48

What Duplicati version? The new code intended to fix this isn’t in anything but canary releases so far.

v2.0.4.29-2.0.4.29_canary_2019-09-17

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.

49

Version is 2.0.4.23_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”.

50

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.

51

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.

52

2.04.23_beta_2019-07-14

53

Are you willing to try Release: 2.0.4.34 (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).

54

I’ll give it a go later this week if workload permits. On another note I commend everyones efforts in trying to produce this product and help if possible.

Thanks

55

I received the same error. I recreated the database from the Web UI and the backup works fine.

56

One source of this error has been fixed:

1 Like
57

Hello,

I have the same issue with one of my backup jobs since one week :slight_smile:
“Failed: Detected non-empty blocksets with no associated blocks!
Details: System.Exception: Detected non-empty blocksets with no associated blocks!”

I updated Duplicati from 2.0.4.23_beta_2019-07-14 to 2.0.5.1_beta_2020-01-18, tried a “repair database” from web UI : same issue.

What can or should i do now ?

Thanks :slight_smile:

58

See reply here for options, however if your issue actually arose one week ago (Jan 17), then it predates 2.0.5.1 (Jan 18). This would make me feel better, as 2.0.5.1 was supposed to fix a major cause of these caused by files growing while being backed up, and tricking the backup logic into becoming inconsistent.

would be worth trying if you haven’t already. If the Repair was after a Delete, it’s basically a Recreate…

59

Hello :slight_smile:

Yes, i first had this issue when i was on 2.0.4.23_beta_2019-07-14. I only updated to 2.0.5.1_beta_2020-01-18 yesterday. Then i started the backup job : same issue; then i “repaired” the database then started the backup : same issue.

Thanks, but now i’m with 2.0.5.1_beta_2020-01-18, maybe it is better to restart it from scratch ? It is not a big deal for me to lose this actual backup (i don’t have a old history and have others parallels backup solutions).

If yes, what’s is the good steps to do that : simply click on “régénération (delete and repair)” from the web UI ? or “Réinisialiser” ? (what’s are the difference ?)
And/or should i delete remote backup files too ?

This is my french web UI :

image
image1024×370 68.6 KB

Thanks

60

Some people have reported that the Database button for `Recreate (Delete and Repair) seemed to remove the error. It may be worth a try, but fresh start (Delete DB and remote) is more sure to work.

EDIT:

Different sections, and only the first (Maintenance) is active (blue) on your screenshot.
Emplacement (Location) is active if you edit the path. Réinisialiser (Reset) resets path.