Hi, I recently did a reinstallation of duplicati and noticed that I have more databases than backup jobs
Is there a way to housekeep them? Do I still need to keep them even if their backup/source files (those files with duplicati as part of their names) no longer exist?
There is no tool as such, but this could be an excellent job for the Database Tool.
If you use the CLI, look in dbconfig.json for potential databases, otherwise look in the UI under “Database” for each job.
You generally don’t need the databases in there, except for active backups (the Duplicati-server.sqlite file is special). The databases are just an index of the remote storage.
If you accidentally delete one, it can be recreated using the “Repair” command.
If you no longer have the backup data (the .dlist.zip files), then the database has no purpose.
Thanks, I notice that the UI also shows the wrong number of backup versions for some of the backup jobs/filesets. Maybe it is due to my editing of them (e.g. removing unneeded versions or files within the filesets)
Will it be better to start off on a clean slate if I were to delete all databases except Duplicati-server.sqlite and then rebuild each of them?
Run a backup before concluding it’s a permanent problem.
Thanks, will it matter if the files are largely the same but their folder names/structure are not?
Matter to what? It shouldn’t matter to the number of backup versions.
If you move files, blocks in moved files will be found already existing.
This means it gets backreferenced instead of uploading second copy.
Old and new paths will show in job log stats as Deleted and Added.
Reading through the “added” files does take some extra backup time.
One thing you can try in advance is to read “Complete log” in job log.
Most operations show a BackupListCount. Does it look more right?
If you can view destination, you can count number of dlist files too.
Ah point taken. Am I right to say that in the event that I am unsure, I can ignore the number of backup versions shown on the UI and just refer to the BackupListCount in the logs?
The most definitive number (e.g. if you lost system) is the dlist count.
That’s ultimately what’s potentially restorable if system and DB are lost.
I mention that partly because I wonder if you’re making system archive.
Generally I don’t get so much pushback to the idea of running a backup.
BackupListCount on my system looks more complex than I’d thought.
I already mentioned that not all operations show the statistics non-zero.
It turns out that some also give old statistics. Verify files seems OK.
KnownFilesets is giving the same number and matches dlist count.
Another approach is to open Restore. Versions are numbered from 0.
Adding one to the highest (bottom) number should be the version count.
I see, thanks. I am asking all of these cos admittedly it’s been months since I turned on this system and am still trying to recall how the setup was like while also getting used to the newer UI at the same time
In general, the information in the overview page is all from the backup metadata which is stored in the server database and updated after a backup. It is only recorded for the purpose of the overview and is not used for anything but that display.
It can be out-of-sync, but this will not cause anything other than some confusion when looking at it, and it should be corrected after running a backup as @ts678 mentions.
Thanks, I am still doing some other checks on this system (almost done thankfully) hence the delay in reply
Am I right to say that theoretically speaking, I can just create an ultra-small backup job (backing up maybe some small files), run that and therefore “correct” the UI at the same time?
I think backup updates stats only for job run.