I just finished some maintenance on my Duplicati backups, and there are files in the configuration directory that I think can be deleted, but wanted to confirm before doing so.
Files of the form “backup Duplicati-server 20250104080844.sqlite”
Files similar to “KVGFABCQYB.backup”
Files similar to “68886569817477797571.backup”
Files similar to “backup JETXUNWVVW 20220523020000.sqlite”
Files similar to “Duplicati-server20241105-091023.bak”
Any file that is “*.sqlite” that is not Duplicati-server.sqlite, and is not associated with any current backups
I’m not sure which is which in the different backup namings (some even get translated), however any random-letters.sqlite would be a job database, and they get stale real fast.
Basically, as soon as you run the owning backup successfully, backup DB is out of date.
These databases can also get large for large backups, so are more worth deleting soon.
The Duplicati-server.sqlite databases are for the server, and tend to be pretty small. One maybe not great reason to keep is if something happens to the main database, info from previous one can (maybe painfully) be extracted if you didn’t save a configuration Export which is a better way to do it. Aside from a bit of space waste, keeping Linux server DBs around can reveal secrets that you should encrypt in 2.1, but 2.0 may store unencrypted. Windows in 2.0 encrypted the whole database. 2.1 moves to specific fields for both OSs.
The random-digits databases may be job database from a brief time when that was done inadvertently because (something like) letters were kept as their decimal character value.
You could sanity-check file modification dates, assuming you run everything occasionally. Certainly one could save databases in non-standard places, if one set things up that way.
Another way to get things split is to move Duplicati-server.sqlite, e.g. in service migration.
Moving the server database doesn’t change the paths inside it which show job databases. Path in GUI would show this if one looked, but it’s unusual to have databases spread out.
CLI backups can also cause job databases to be created which the GUI won’t be tracking.
Possibly none of this is relevant, but since you were seeking to confirm, there’s some info.
Honestly, it is a bit messy, but let me try to break it down:
The GUI database is Duplicati-server.sqlite.
Files of the format <10 uppercase letters>.sqlite are job databases (aka local database).
When upgrading and changing the database schema, a file with the same name as the original file, but with a prefix and a timestamp. The prefix is localized (for some reason), but results in a filename such as backup Duplicati-server 20250104080844.sqlite.
The RC4 decrypter will create a file with a timestamp prefixed and a .bak extension, resulting in a filename such as: Duplicati-server20241105-091023.bak.
The new database downgrader will create use the .bak format but also inserts a -, giving something like Duplicati-server-20241105091023.bak.
The file 68886569817477797571.backup I don’t know about. Is it possible this was created manually?
If you use the CLI there should also be a file called dbconfig.json in the folder.
Additionally, the files installationid.txt and machineid.txt are also in the folder.
You can look in dbconfig.json and Duplicati-server.sqlite to see which of the job databases are used, in case there are leftovers from deleted jobs.
I think you are right, there was a version where something was messed up with generating the filenames, making digit-based names instead. Cannot remember the details, but it sounds plausible that it was instead emitting the ASCII values of the characters.
I always figured something triggered creating the backup files, but had never put any thought into what it might be. A database upgrade makes perfect sense.
And the ancient bug with filenames would certainly be in play - I’ve been using Duplicati on the Windows system in question ever since Crashplan abandoned the home user.
Thank you very much! I feel very comfortable proceeding with the clean-up.