Trouble "Detected non-empty blocksets with no associated blocks!"

I was running a new backup with Google Teams and after hours it stops and give the error “Detected non-empty blocksets with no associated blocks!”
I’m running Duplicati - 2.0.5.1_beta_2020-01-18 on a FreeNAS 11.3U5 jail. In the past I had trouble getting things to work so I deleted the database and removed all the files from the Google Teams and the backup started to work.
I’ve review all the similar topics but have not found the answer. I’m not able to edit database manually.

  at Duplicati.Library.Main.Database.LocalDatabase.VerifyConsistency (System.Int64 blocksize, System.Int64 hashsize, System.Boolean verifyfilelists, System.Data.IDbTransaction transaction) [0x0017d] in <8f1de655bd1240739a78684d845cecc8>:0 
  at Duplicati.Library.Main.Operation.Backup.BackupDatabase+<>c__DisplayClass34_0.<VerifyConsistencyAsync>b__0 () [0x00000] in <8f1de655bd1240739a78684d845cecc8>:0 
  at Duplicati.Library.Main.Operation.Common.SingleRunner+<>c__DisplayClass3_0.<RunOnMain>b__0 () [0x00000] in <8f1de655bd1240739a78684d845cecc8>:0 
  at Duplicati.Library.Main.Operation.Common.SingleRunner+<DoRunOnMain>d__2`1[T].MoveNext () [0x000b0] in <8f1de655bd1240739a78684d845cecc8>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <0e06830de9a44394a7e366951eabca52>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0003e] in <0e06830de9a44394a7e366951eabca52>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in <0e06830de9a44394a7e366951eabca52>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in <0e06830de9a44394a7e366951eabca52>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.GetResult () [0x00000] in <0e06830de9a44394a7e366951eabca52>:0 
  at Duplicati.Library.Main.Operation.BackupHandler+<RunAsync>d__20.MoveNext () [0x01033] in <8f1de655bd1240739a78684d845cecc8>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <0e06830de9a44394a7e366951eabca52>:0 
  at CoCoL.ChannelExtensions.WaitForTaskOrThrow (System.Threading.Tasks.Task task) [0x00050] in <9a758ff4db6c48d6b3d4d0e5c2adf6d1>:0 
  at Duplicati.Library.Main.Operation.BackupHandler.Run (System.String[] sources, Duplicati.Library.Utility.IFilter filter, System.Threading.CancellationToken token) [0x00009] in <8f1de655bd1240739a78684d845cecc8>:0 
  at Duplicati.Library.Main.Controller+<>c__DisplayClass14_0.<Backup>b__0 (Duplicati.Library.Main.BackupResults result) [0x0004b] in <8f1de655bd1240739a78684d845cecc8>:0 
  at Duplicati.Library.Main.Controller.RunAction[T] (T result, System.String[]& paths, Duplicati.Library.Utility.IFilter& filter, System.Action`1[T] method) [0x0026f] in <8f1de655bd1240739a78684d845cecc8>:0 
  at Duplicati.Library.Main.Controller.Backup (System.String[] inputsources, Duplicati.Library.Utility.IFilter filter) [0x00074] in <8f1de655bd1240739a78684d845cecc8>:0 
  at Duplicati.Server.Runner.Run (Duplicati.Server.Runner+IRunnerData data, System.Boolean fromQueue) [0x00349] in <c5f097a49c0a4f1fb0f93cf3f5f218b1>:0 ```

I know it’s hard to say, but do hours or backup size seem about right for a full backup of the source?
This check is (I think) run both before and after the backup, and yours sounds like it failed at the end.

Can you clarify the edit attempt? Are you talking about trying a manual repair (or look) with a DB tool?
Creating a bug report is a nice way to get a sanitized DB dump prepared, e.g. to post here with a link.

Or maybe you’re saying you don’t want to even think about going in with an editor (it IS kind of tricky)?

If you can figure out how these happen, or get reliable steps (the simpler the better), it’d be wonderful.
One theory has been that files changing in certain ways during backup are related. Testing of different source areas (changing versus less changing), and maybe different times might help narrow it down.