Sorry if this is a dumb question, I’m not too knowledgeable in databases
I’ve recently switched my Duplicati installation to run it as a service, and it looks like everything is running as it should. My main database is therefore now located at c:\Windows\System32\config\systemprofile\AppData\Local\Duplicati
The database file is about 800 MB for around 380 GB of backed up data.
What I find strange is that the timestamp of the 800 MB sqlite file doesn’t change after running a couple of backups. Granted, not much changed between those backups, but at least a few files/MBs did change. Shouldn’t the database sqlite file have changed slightly and have a new “modified at” date and time?
Yes, you should probably be seeing timestamp changes on the job-specific sqlite file. You probably will NOT see changes on the “Duplicati-server.sqlite” file.
Hi @JonMikelV, thanks for your reply and the welcome
I’m talking about the job-specific sqlite file. The one with a name made up of random characters (well, I think they are random characters)
A scheduled backup ran about an hour ago; new dlist, dindex and dblock files were created on the backend, but the job-specific sqlite file didn’t change. It still has the same size and timestamp
I’m afraid I may have made a mistake when I converted Duplicati to a service, while migrating/moving the database files.
But I don’t understand why the backups keep working without modifying the database file.
Hi @Wim_Jansen
Yes, that’s what I thought at first. There had to be another database somewhere. But I ran a search looking for sqlite files that had been modified in the last few days and couldn’t find another one
So I decided to repair or, if necessary, rebuild the database, and that’s when I found the solution. When trying to rebuild the database, Duplicati complained about not having access to the path (c:\Windows\System32\config\systemprofile\AppData\Local\Duplicati) Which is very strange, since it should be running as SYSTEM, and I checked that both SYSTEM and the user I was logged in as both had read and write permissions to that path
The solution ended up being more complex than what I thought. I went back to reading the tutorial for migrating Duplicati to a service:
In that topic, the database location is discussed and there seems to be several alternatives about its location. In the last post of the thread, Ken makes this suggestion:
So I did exactly that, created the environmental variable for Duplicati and moved both sqlite files (Duplicati-server.sqlite and the job-specific sqlite file) to that folder so that Duplicati could find them. After that, I expected Duplicati to use that path for all its data, but it wasn’t that simple.
The settings (Duplicati-server.sqlite) were imported correctly, but the job database was not. So I decided to recreate it.
To my surprise, Duplicati started to recreate the database in C:\Users\(username)\AppData\Local\Duplicati
So I ended up with one sqlite file in C:\ProgramData\Duplicati and another one in C:\Users\(username)\AppData\Local\Duplicati
I don’t know if this is the expected behaviour, or maybe if I made a mistake in all this process.
It’s not ideal, but at least it works now. The database size and timestamp changes when backups are run. So I’m going to leave it like that
Hopefully this explanation helps someone else in case they run into the same problem
