Database repair not working

So, I’m getting a database repair warning (sort-of similar to some others in this Duplicati Support forum, but also sort-of different). So I try to fix it (by running the database repair function). But it’s not fixing the problem. See the attached screenshot.

Help?

Oops, meant to attach this PDF (inside the ZIP, because this forum doesn’t accept PDF files, sigh), instead of that screenshot.duplicati.zip (457.0 KB)

OK - so it looks like:

  • 2018-04-06 @ 10:07 AM you started a rebuild (not repair) at which point it started downloading 522 filelists (as it should)
  • 2018-04-06 @ 10:50 AM it started downloading 2,027 index files (as it should)
    - 2018-04-06 @ 11:17 AM it noticed the …9eef.dblock.zip.aes file included in the index files did could NOT be found on the destination
  • 2018-04-06 @ 11:24 AM it started processing 110 blocklist volumes
  • 2018-04-06 @ 01:16 PM it finished the recreate and started a verification
  • 2018-04-06 @ 01:17 PM it finished the verification and flagged the recreate as complete
  • 2018-04-06 @ 01:19 PM it seems to have started a “missed” backup (likely scheduled to run during the repair) and complained about the missing …9eef.dblock.zip.aes file
  • 2018-04-06 @ 2:00 PM (and hourly thereafter) it continues to complain about the missing file)

So the final error message you’re dealing with (in plain text to make searching easier) is:
Backend verification failed, attempting automatic cleanup Duplicati.Library.Interface.UserInformationException: Found 1 files that are missing from the remote storage, please run repair

Did you:

  • verify the file really doesn’t exist at the destination (I suspect it doesn’t)?
  • try running Repair (not recreate / rebuild) on the database?

I think this same situation may have happened to me (a recreate turned around to complain about a missing file) so I’m wondering if the recreate process ONLY recreates what’s in the dlist and dindex files without ‘fixing’ any potentially previous issues (such as a missing file).

Oh, and for future reference you could just copy / paste your log info into the forum as plain text. It should be a lot faster than the screen shot or pdf solution, plus it makes it easier to edit out any info you don’t want AND allows it to be searchable in the forum. :slight_smile:

Right, the claimed non-existent file does not in fact exist at the storage site.

When I first started receiving the nastygrams, I did try repair first, but it failed, after which I tried recreate, and that failed too. Both have continued to fail, after multiple tries. So what I’m going to do now is nuke and start over. Sigh.

(And, sorry about the bad formatting …)

Cheers, and thx!

Just a follow-up from yesterday. I did blow away the old backup (which couldn’t be repaired/recreated), and instantiated a brand new one. The new one has been populated successfully, and is now working correctly.

So I’m now squared-away, but I sure hope the bug gets found/fixed. (I don’t think the disappearing file on the server was disappeared by the server, out-of-band of Duplicati; I’m the only person with access to it, and I haven’t been monkeying with it.)

I suspect you are correct - I too have a destination that only I have access to which as reported missing files a few times in the last few weeks after months of no problems.

My guess is there’s a scenario where the file is successfully deleted from the destination but the local database doesn’t record it as such. However in my case database repairs (via the awesome new “Repair” button on the warning) have resolved the issue.


Oh, I should also point out that the backup that you nuked was likely still viable for restores even if you couldn’t add more recent backup versions to it.

Thanks, JonMikelV, esp. for the info about viability for restores.

FYI, I too am technical, so understand about transactionality, thus I sympathize with you & the rest of the Duplicati devs … But thanks for the great job anyway! :slight_smile:

1 Like