Found inconsistency in the following files while validating database

Hi everyone

I’ve recently migrated from CrashPlan to Duplicati and I’m in the process of running my initial backup to B2.

The backup is about 50gb, and our internet connection is slow as crap, so this is going to take about a week to complete. Did I mention our internet drops out a couple of times a day also?

Two days in to running the backup and Duplicati is now refusing to backup, giving the following error -

Found inconsistency in the following files while validating database: 
 C:\somepath.example, actual size 458419144, dbsize 0, blocksetid: 1393
 . Run repair to fix it.

I can’t see any way to run a repair through the user interface, and I’ve googled this error and found other people with the same problem but no solution other than to completely start the backup from scratch.

What to do?

Update:

Found where to run the repair (Under database), ran it, the repair completed fairly quickly, but the backups continue to fail with the same error.

This is very disheartening, I thought I’d found a stable piece of backup software.

2 Likes

I am in a similar situation. Duplicati is a very nice and promising piece of software, but it has some rough edges. I suspect it will see a lot of Crashplan refugees in the coming months. It is curently in a beta stage, so problems are expected. It is a hobby project and does not have dedicated (and paid!) support staff like CP does.

I myself ended up moving from CP Home to CP Business. They are giving 75% off for the first year, if you migrate your archive. No reupload is needed. This one year I hope will give me time to reestablish a good backup elsewhere. Cannot really go wrong with a $2.50 a month per PC.

Whatever you do, I would advise not slamming the door on CP until a new backup is in a good shape, tried and tested.

1 Like

The next step would be to delete and rebuild the database. But before you do that, maybe @kenkendk wants some info that might help identify the cause of the problem?

@debugga: Yes, if you can run the “Bugreport” command, it will create an obfuscated version of the database (scrubbing filenames) that I can look at to see why it happens.

How would you like me to send this bugreport.zip file to you @kenkendk ?

Can you send the file via message in the forum?

@kenkendk I can’t, only image uploads are allowed. Here’s a Firefox Send link to download it - https://send.firefox.com/download/519a023b46/#ZKuO9jUomc4bdP35ioOabw

here’s mine:

Bug Report

Dropbox - duplicati sia bugreport.zip

Thanks for both the bug reports, I will have a look.

1 Like

Have ya had a look at this @kenkendk ?

Unfortunately not yet… I have a number of project deadlines that I need to deal with first :tired_face:

today I’m in the same situation of the OP:
Found inconsistency in the following files while validating database:
T:***.mkv, actual size 8083538704, dbsize 0, blocksetid: 2919
. Run repair to fix it.

Repair seems to do nothing…
I don’t understand…is a remote file problem or local?

Edit: removing the incriminated file from my local storage doesn’t resolve…so I think is a remote file problem…so there’s a solution to remove this file from remote location and reupload it?

Just give up on Duplicati, seriously. This is not production ready software.

You could do a Command line run with the list-broken-files command to see if your affected file is listed and, if so, then run with the purge-broken-files command to resolve those outstanding issues. Note that these will only work if your local database is in good shape (such as it has NOT been rebuild since the destination errors were reported).

Running list-broken-files say that’s nothing broke…

I resolved restoring a old db backup of some days (I made a db backup every day since last db failuer) and removing (moving to a backup folder in facts) all the files uploaded after this day…
Running a repair fixed the db from myabe dindex and dblock missing from db and now is running…

So you basically “rolled back” your local DB and destination files to before the issue. Interesting solution, I’m glad it worked for you!

Piling on here. I’ve been fighting various issues trying to complete an initial backup of a large (1.2T) media share. As of yesterday evening I was within 100G of completing when it threw an error:

System.IO.InvalidDataException: Found inconsistency in the following files while validating database:
/Volumes/Storage/Media/Movies/BlahBlah.mp4, actual size 2765141701, dbsize 0, blocksetid: 1356
. Run repair to fix it.
at Duplicati.Library.Main.Database.LocalDatabase.VerifyConsistency (System.Data.IDbTransaction transaction, System.Int64 blocksize, System.Int64 hashsize, System.Boolean verifyfilelists) [0x000e9] in <118ad25945a24a3991f7b65e7a45ea1e>:0
at Duplicati.Library.Main.Operation.BackupHandler.Run (System.String[] sources, Duplicati.Library.Utility.IFilter filter) [0x00238] in <118ad25945a24a3991f7b65e7a45ea1e>:0
at Duplicati.Library.Main.Controller+<>c__DisplayClass16_0.b__0 (Duplicati.Library.Main.BackupResults result) [0x0030f] in <118ad25945a24a3991f7b65e7a45ea1e>:0
at Duplicati.Library.Main.Controller.RunAction[T] (T result, System.String[]& paths, Duplicati.Library.Utility.IFilter& filter, System.Action`1[T] method) [0x0014b] in <118ad25945a24a3991f7b65e7a45ea1e>:0
at Duplicati.Library.Main.Controller.Backup (System.String[] inputsources, Duplicati.Library.Utility.IFilter filter) [0x00068] in <118ad25945a24a3991f7b65e7a45ea1e>:0
at Duplicati.Server.Runner.Run (Duplicati.Server.Runner+IRunnerData data, System.Boolean fromQueue) [0x00454] in :0

I have attempted repair and re-run a number of times with no change. Repair reports everything in sync with nothing to do. I tried moving the offending file out of the folder being backed up with no change.

Here’s a link to the bugreport.zip

I’d really like to avoid doing a delete and re-create. The last time I tried that on a similar backup it ran for weeks and didn’t complete and I ended up abandoning the backup set.

Thanks in advance for any help.

Just give up on Duplicati, seriously. This is not production ready software.

This thread is the perfect example of why it’s not ready. A bug is reported, the developer (only one?) asks for data, you provide it, he never responds, you follow up, he says sorry I’ve got other work to do.

Imagine encountering an error when trying to restore your data after a catastrophic loss, is this the kind of support you want to deal with?

Find something else.

I will try to give some actual advice to help you in contrast to the previous post that I flagged as inappropriate.

Can you try a list-broken-files?

Thanks for your reply. I ran the list-broken-files. Result:

No broken filesets found in database, checking for missing remote files
Listing remote folder …
Skipping operation because no files were found to be missing, and no filesets were recorded as broken.
Return code: 0