All configuration data, logs and settings are stored inside the file
Duplicati-server.sqlite.
To protect the database, Duplicati has support for a field-level encryption password. When activated, any setting that is deemed sensitive will be encrypted before being written to the database. This method ensures that the SQLite database itself is still readable, but the secrets are not readable without the encryption passphrase.
The local database is the per-job one, and can get large. I don’t think it needs any encryption.
Are you talking about this from above? If so, please note the words in front of the suggestion:
If something else, please give context, link, quote, etc. From job exports, you can then do this:
This will get the backup configurations restored. You do lose some history, but it’s pretty good.
Problem is that if you never got job exports, you can’t import, so your configs are in database.
I would prefer that the developer give detailed advice, but I can quote from the release notice:
Added wipe-encryption to database tool
The database tool now supports a wipe-encryption command that can be used to remove all encrypted fields from a server database. With this command it is possible to get an encrypted database back into a state where it can be opened again. After encrypted fields are wiped, the user can then edit backups and settings to replace the lost data.
Theory sounds like your secrets should be in a password saver or somewhere. Get non-secret
configuration parts out of database with a key that no longer works, then manually add secrets.
EDIT 1:
Actually wipe-encryption was described above before it was done, so you can also read that.