I am guessing they are in some folder that the user installation was using, and Duplicati is still using, even after migrating to a service install. (Honestly, I thought they lived in the database .squlite file, but that file is not missing, and getting used, so I’m a little stumped.
Before migrating, I exported the job, and then re-imported.
First time I did import metadata. That seemed to keep around the old sizes and versions and last successful backup. But no log-files, new or old.
Second time I imported the job, I did not import metadata. Still, no log-files.
I did use --server-datafolder to relocate the database of the new service installation. Might that affect something?
Your migration procedure moves Duplicati-server.sqlite, then moves job databases. Did you decide to start with a clean Duplicati-server.sqlite instead? I think that’s fine provided the old job databases get reattached, otherwise not only will the old logs be left behind, but Duplicati backup won’t expect the old destination files.
Have the backups been doing everything else OK, such as updating the main screen with Last successful backup, and showing it on Restore files? If all else is OK, lack of logs (which are stored in the DB) is odd…
You could look in the job Database tab, check timestamps on Local database path, or even browse the DB LogData table with DB Browser for SQLite. Your Server (or maybe job?) will need --unencrypted-database because the database on Windows is obfuscated, so the typical SQLite browser won’t be able to open DB.
The job is still running. This is the first backup job after migration. (Well, the 3rd. The 1st I forgot an option, so deleted job and backup files. The 2nd ran for 1.5 days then PC crashed (that’s why I’m doing backups and I was not able to restart it, nor recreate the local database, so I deleted that job and backupfiles.) But now the status bar at the top, and the details under the job (next schedule run, current action, progress bar, current file) all seem to be what I expect.
Those look fine. The Database file under the job drop-down in the GUI is in the dir I expect (that I set with --server-datafolder) and it was just updated a few min ago (job is currently running). One of the backup*.sqlite fils has also been updated recently. No other file in that dir has been updated in the last 24 hours.
Well, thanks for the tip! That table is empty! That is, the LogData table is empty.
How is that possible?
I copied the 808988....782.sqlite file to another folder and opened it with DB Browser for SQLite and it opened fine. I did not start the server nor job with --unencrypted-database at least not intentionally. It’s not a default right? It looks like it’s an option on Duplicati.Server.exe. I can see from Windows services.msc the command line Duplicati.Server.exe was started with and it does not have --unencrypted-database.
So maybe the LogData is being hidden due to encryption?
It’s created at the end of the backup, but it sounds like initial backup has not finished.
If you want to watch live logs, About --> Show log --> Live should show some action.
If you can even open the DB, it’s probably not encrypted. It’s definitely not if you can read other tables.
I’m not sure why you’re able to open it. I expect it on non-Windows, but I thought Windows encrypted. Maybe something changed. I’ve been on --unencrypted-database awhile, so I wouldn’t have noticed…
The exact chronology is still a bit unclear, but Job --> Show log should be empty before a backup end.
If backups have varied methods, great. If not, now might be a good time to start. Some image backups can boot directly, without even having a Windows installation to crash (assuming it’s not from hardware failure). My own practice is to run Macrium Reflect Free Edition to a USB drive before a Windows version update… Being a whole-drive backup, this also covers me somewhat for whatever I didn’t have my file backup save.