Yes, @ts678 it looks like you might be onto something with the dbconfig.json file. On the system I’m restoring to, it has an unexpected Databasebath
[
{
"Type": "ssh",
"Server": "jupiter",
"Path": "datadisk/duplicati-backups/saturn/containers",
"Prefix": "duplicati",
"Username": "ubuntu",
"Port": -1,
"Databasepath": "/config/OD12 Restore from Saturn to local mirror.sqlite",
"ParameterFile": null
}
]
This is actually the content of the –backup-name parameter on one of my restore commands (not the one that I’m testing). There is no database of this name so I’m wondering whether the restore expects that to pre-exist or whether it creates a temporary database of that name during the restore.
I have run another test which seems to confirm your suspicion:
For my previous restore tests (onto my Ubuntu system), I always used the config file. Now, I used the config file to add the backup “task” to the new system. I was then told to re-create the database which worked without issues. And from there, I could successfully restore any version.
I am glad to now have a way to restore to a different system, but it is kind of dangerous since that new system also easy could be used to accidentally create another backup.
was opened yesterday after being able to repro an issue in CLI restore case. Restore with duplicati-cli fails explains theory and workaround by “Recreate”.
Everyone seems to have trouble with two backups, so most of this fits theory.
This part does not:
I would have thought the last restore doing one out of two versions would fail.
For those using CLI, the other topic and the issue should serve as their guide.
For those using GUI, you probably need to make a dummy job and DB repair.
If you have a config, you can import it, disable schedule. If not, do dummy job.
Once minimal config is there, use Database screen to Repair, then do restore.
And don’t run backup or anything to change Destination. Delete DB if you like.
EDIT 1:
Careful readers of the issue may read that GUI seems less prone to this issue.
Nevertheless, if a GUI user has trouble, the full DB recreate seems worth a try.
Lastly I also get similar problem but when I try to make backup (through GUI). I got following error message: The “operation Backup has failed DatabaseInconsistencyException: Detected 1 volume with missing filesets”. And as ts678 advised I decided to recreate backup db. I started Recreate process yesterday at about 09am and it is still running. I’m a little bit terrified. From time to time I’m checking Duplicati profiling log and I saw, that process works, but last entry was 6h ago:
Jan 8, 2026 2:06 PM: Starting - ExecuteNonQuery: DELETE FROM “Block” WHERE “ID” IN (SELECT “ID” FROM “DeletedBlocks-D9ABF93721419B469560B66E5EE6FFD2”)
ProcessExplorer shows that Duplicati.GUI.TrayIcon.exe stil use about 8% of CPU and stil writes and reads to disk.
Progress bar is at about 80%, but it didn’t move since 6h. How long it can take to finish? How can I check, that the process still do something meaningful?
Since you know about Sysinternals tools, Process Monitor can show what files (if any) Duplicati is using. For a no-install way, Task Manager Performance can start Resource Monitor for a similar view at probably less detail. If it’s working in sqlite files (some temporary files may be less obvious but might have dupl or etilqs) then something is going on, but even better would be if the profiling log advanced, however if it’s still working surprisingly long on that one query, it might be slowed if backup is large. SQLite memory cache can exhaust, then it has to hit drive a lot…
You’d probably see such (nameless) drive hits even in Task Manager Process tab, however if you want better clues as to internal situation, then you need better tool.
Ideally the developer will give a comment about your question and the whole topic.