I’ve been getting the following error the past few days when running my backup jobs and they aren’t completing.
The database was attempted repaired, but the repair did not complete. This database may be incomplete and the backup process cannot continue. You may delete the local database and attempt to repair it again.
When I’ve run the Recreate on the database from the GUI it appears to finish, but I still get the error above. I then ran the repair from the command line targeting a different database file as suggested in https://forum.duplicati.com/t/fail-to-repair-database/2561 and got the following error message.
System.Exception: Unexpected difference in fileset 24, found 21146 entries, but expected 21155
at Duplicati.Library.Main.Database.LocalDatabase.VerifyConsistency(IDbTransaction transaction, Int64 blocksize, Int64 hashsize, Boolean verifyfilelists)
at Duplicati.Library.Main.Operation.RecreateDatabaseHandler.DoRun(LocalDatabase dbparent, Boolean updating, IFilter filter, NumberedFilterFilelistDelegate filelistfilter, BlockVolumePostProcessor blockprocessor)
at Duplicati.Library.Main.Operation.RecreateDatabaseHandler.Run(String path, IFilter filter, NumberedFilterFilelistDelegate filelistfilter, BlockVolumePostProcessor blockprocessor)
at Duplicati.Library.Main.Operation.RepairHandler.RunRepairLocal(IFilter filter)
at Duplicati.Library.Main.Operation.RepairHandler.Run(IFilter filter)
at Duplicati.Library.Main.Controller.RunAction[T](T result, String& paths, IFilter& filter, Action1 method) at Duplicati.Library.Main.Controller.Repair(IFilter filter) at Duplicati.CommandLine.Commands.Repair(TextWriter outwriter, Action1 setup, List1 args, Dictionary2 options, IFilter filter)
at Duplicati.CommandLine.Program.RunCommandLine(TextWriter outwriter, TextWriter errwriter, Action`1 setup, String args)
How can I recover the database and backup so that it will continue running?
I’m running Duplicati v2.0.2.1_beta_2017-08-01 on Windows 10 Professional v1709 build 16299.309.
Hi @jstruebel, welcome to the forum - and sorry for the delay in catching your post!
This message happens when a database repair is interrupted (such as by a power outage or forced Windows update reboot - gee, thanks Microsoft). Did you start a repair at some point and, if so, what prompted you to do so?
By “different database file” do you mean a different pre-existing database or not-yet-existing file?
This message comes up when double checking the database list of source files and indicates a 9 file difference between what the database expects and what is actually found at the destination.
Since a repair seems to have failed, doing a recreate is the only way to be able to keep doing backups with this backup set (though restores should still be possible).
I’d suggest adding the --log-file=<path> and --log-level=profiling parameters to your job then trying a recreate again. This will generate a (probably large) text file at <path> that we can look at if the error happens again.
Do you recall how long the recreate took the first time?
I don’t remember off-hand why I had start the repair since it was back at the end of February, but it would have been due to some error reported by Duplicati. I had tried just a repair from the GUI and then a Delete and Repair when that didn’t solve the problem. Sorry I don’t have more specific information on that. What is the best way to capture all of the information in the log? When I’ve clicked on the log items in the GUI they don’t generally seem to have much specifics beyond the message that pops up.
I mean a not-yet-existing file.
Is this a difference in the actual backup files stored in the destination or the files within the backup that came from my machine?
I think the recreate took 15-20min. It wasn’t excessive, but as is hopefully clear from my post it didn’t recover the backup. I will keep this in mind the next time something like this happens. I got impatient waiting and since this particular backup was only 3.5GB of source I just deleted the entire backup and started over. It finished fine and has been running correctly the past two days (I have it scheduled to run daily overnight).
I’m not too worried about this backup since I had been running it without issue for the past 3-4 months with only minor things. When it failed I was running another long-process (multiple days) on the same machine that was heavily using the disk. This was the first time that I wasn’t able to recover a backup failure using the methods that made sense. Thank you for responding even though I ended up just starting over.
I believe it’s a mismatch between what the database thinks had been backed up and what the destination says has been backed up.
Generally the list of loggedb events shows the same test at the pop-up, but often (but not always) clicking on that line expands it to show additional info or even a code trace (which can help narrow down what part of the code was in use when the error happened).
Sorry we took so long to get back to you, but I’m good to hear you were able to start fresh OK.