Error Detected 1 volume with missing filesets: VolumeId = 32, Name = duplicati-20251104T211541Z.dlist.zip.aes, State = Uploaded

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.

@kenkendk To me this looks like a bug!

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.