I just completed a selective restoration from my backup and few minutes later I decided to restore another file, so I started the restoration [from a config file] one more time and Duplicati shows me “Building partial temporary database …“ again. Is it possible that I previously configured Duplicati to not keep the local database?
Why are you using config file? Is there no job configured?
For repeating restores, any backup (and more), use a job.
Did you lose a system? There’s no context given for need.
If you just did restore from a config file without a job, that doesn’t save either the config file as a job, or the partial temporary database (temporary is temporary…).
If you are trying to get back to normal operations, import the job from config, then on Database screen, do a Repair. You can then Restore repeatedly from that DB.
If you’re trying to do something else, please say your situation and what you want.
Thanks for the explanation.
The config was exported from another installation and now I just need to restore individual files from time to time. So there is no job now, yes.
Does the other installation have an active job, doing backups and such work? Activity means its destination and local database are constantly changing, so second Duplicati has no choice but to start again using whatever is the latest.
Duplicati is not designed for quick and casual individual file transfers between systems, but other tools exist if current file is the wish, and other system is up.
If you need historical file versions from an active system’s backup, it gets hard, however the same for an inactive other system is a little easier but is still tricky.
No, it’s dormant, inactive, etc.
Then you can (if you wish) install its job, do DB repair once, and only restore, meaning turn off the backup schedule, and don’t do manual backups or harm.
This is the time when one would like a destination to be read-only, but not all destinations can do that. To easily add safety, you can have Options screen “Backup retention” keep all versions, so last legit one will survive new backup.
More can be done to ensure an accidental backup will fail, but it’s not as easy.
1 Like