Hello all. Also interested in understanding how this issue occurs and steps to fix. I am restoring on a separate system (for backup testing purposes) and I ran into this issue. Ran through deleting recent backups, rebuilding the database, compacting and testing without any no success (all from the backed up system).
I am getting this error after upgrading to 2.2.0.1 - 2.2.0.1_stable_2025-11-09 when restoring to another system on the same version. To attempt a fix, I deleted the database and all the files from the backup server and then ran a backup and a restore - it worked, but only once. After another backup the subsequent restore failed after getting the index files, with
The operation Restore has failed => Detected 1 volume with missing filesets: VolumeId = 26, Name = duplicati-20251111T084437Z.dlist.zip.aes, State = Uploaded
ErrorID: DatabaseInconsistency
Detected 1 volume with missing filesets: VolumeId = 26, Name = duplicati-20251111T084437Z.dlist.zip.aes, State = Uploaded
Yes. It’s been working for years before the upgrade. I’m wondering if I need to revisit the restore command - perhaps something has changed there in new version.
Last night the backup had a warning
"2025-11-13 00:23:48 +00 - [Warning-Duplicati.Library.Main.Operation.TestHandler-FaultyIndexFiles]: Found 1 faulty index files, repairing now"
but a re-run worked fine this morning, so it need to look for a pattern. A subsequent attempt to restore failed with the same error.
Extra feedback. In my scenario I deleted all but the most recent backup from the backed up system web ui. Then I rechecked that last backup from the separate machine and the rebuilt database worked. The last backup was made with the new version.
I was wondering what is special in your backup configuration that allowed it to “heal” on the next run in order to implement it on my own backups. Thanx!
That sounds like a possibility (test all). Thanx for the info. In the meantime I was able to replicate that a backup that failed the test started working after I deleted all but the latest backup. It may be localized to some backups - perhaps they didn’t finish properly - as I have other backup jobs that work just fine.
This fails for me with the same error. I have disabled my remote restore for a few days to see if the backup works OK without any ‘interference’ from another system.
Do the dlist files with complaints have about the right size compared to others, assuming you have some old ones. If you do, do the old versions restore OK?
The time on the dlist file name “should” match “Restore” list except dlist is UTC. Complaint seems to be saying there’s a dlist that didn’t make a restore version.
The problem sounds like people are using “Direct restore” to their other system. Alternatively, one could do an actual database recreate, but be careful with that. Restore “should” be OK, but don’t do things like backup that change destination.
is the concern if two systems collide, but usually it causes extra or missing files.
Looking forward to hearing test result.
Doesn’t matter. This question (which still be off-target) is DB on restore system.
Docs or no, it’s a cache only of the DB location, on whatever system you’re on.
Here’s a chunk of the one I was using to try to get your error, but got another…
Doesn’t matter if the problem is database – they’re different.
I was trying to repro a situation where backup got things out of sync. I did so, however the error was different. The restore compared old DB to destination.
I thought maybe looking at your dbpath.json might shed some light on things.
I was just talking DB presense/absence, but if desired the DB can be opened.
DB Browser for SQLite is available directly, or often as Linux sqlitebrowser.
If nobody wants to look at things, I guess we can just wait and hope for help…
It’s unfortunate that there are two similar topics being active at the same time.
Please keep an eye on other one too. My repro attempt was described in that.
Done the same way, with CLI and no explicit database? I still worry about old DB.
Make sure the remote is doing a recreate, like I advised in the other topic already.
It should have to read through all the dlist and dindex files, showing it on terminal.
EDIT 1:
Kind of like the other topic original post showed. It didn’t help there though, but it
would still be best to know what any individual restore by anybody is really doing.
Maybe a better recipe for repro can be put together.
EDIT 2:
I suppose I can ask if the two systems have equal access to the destination files.
This doesn’t seem likely to me to be the crucial difference, but what else is there?
The problem sounds like people are using “Direct restore” to their other system. Alternatively, one could do an actual database recreate, but be careful with that. Restore “should” be OK, but don’t do things like backup that change destination.
Well, being able to restore to a different system is the whole point I run this test. Eg. what if the hardware failed, the restore then also would be in a new, different hardware. It is obvious to me that a backup only should be triggered from one location.
I suppose I can ask if the two systems have equal access to the destination files.
I exported the config file (NAS backup) and did the restore on a different system (Ubuntu) using that config file. So I expect the backup access should be identical.
The remote restore succeeds on first attempt and fails as soon as another backup takes place.
I just did another test using version 2.2.0.0:
I configured a new backup on my NAS1 to NAS2 (backup schema: Smart) and exported the config
Created the first backup
Then I restored it (version 0) on my Ubuntu system → No errors
Then I did a 2nd backup (version 1)
Then I tried to restore it (version 1) on my Ubuntu system → error (missing fileset). Not a single file got restored at all!
Then I tried to restore version 0’ once more on my Ubuntu system → restored without issues!
So indeed restoring onto a different system seems only to work for the first version (I did not check if the same issue applies to the original system, NAS1 in my case).