Backup Job not leaving logs anymore

Hi!

I have three backup jobs setup in duplicati. They were all leaving logs as normal until May 15th. After May 15th one backup job stopped leaving logs (it left one on the 15th). Recently I changed the database bath for this backup that stopped leaving logs. I did this by coping its existing database into a new name. I’m pretty sure I did this in the last couple of days but I honestly can’t remember if I did that before or after the 15th. Could this be the cause of logs not showing up? The backups still appear to be running. I still sometimes get a notification that there was a warning but clicking on the button to show the warning does nothing. I still have the original database file for this backup job.

Thank for any and all help you can provide!

You also need to tell Duplicati the new DB path in Database --> Local database path
Maybe you just didn’t mention that, but even if skipped, logs should go somewhere…

Are you sure that notification was for this backup? Can you just watch a manual run?
Using another tab in About --> Show log --> Live information is a way to view activity.

When done, you should be able to see Last successful backup of backup update.
Of course, you should also be able to see Show log list the new log at backup date…
You should also be able to see that backup date as latest backup on the Restore list.

Sorry I did forget to mention this! I updated the database path in Duplicati by going to the backup job then: Edit > Options (Circle 5) > Advanced Options > dbpath. In the box to set the value for dbpath I typed exactly this without quotes: “/home/tyler/.config/Duplicati/Ubuntu.sqlite”.

I checked again that this was the right path before posted and noticed that ls -l lists Ubuntu.sqlite as having a last modified date of right now (May 21 12:06) which makes sense because Duplicati started running last nights missed backups when I logged in today.

There’s also a new file called “Ubuntu.sqlite-journal” with the same last modified date. Could this be where the logs are going? And if so how do I tell Duplicati to use that to show me the log files?

Lastly after Duplicati finished running “Ubuntu” the last successful backup time was changed to “Today at 12:08 PM”. It produced one warning (that I missed while looking at About > Show log > Live) but I took the opportunity to take a screenshot of the log view with the warning message still at the bottom.

Edit: I just realized the way you said to change the database is different from the way I did it. I checked where you said and sure enough the old database file is still listed. I would just change it but I’m worried about accidentally breaking something. Should it be okay to just change the path and hit “Move existing database” or is a more complicated fix required?

Edit 2: I should mention that another backup job backups ~/.config/Duplicati. So even if something horrible happens there still should be backups of the databases.

Thanks!

2.1. Rollback Journals explains this SQLite internal temporary file, and I can’t add much.
There’s no design plan for Duplicati to write logs to it. They “should” wind up in main DB.
Maybe something went wrong, but then I’d expect the DB to be broken in a lot of ways…

If you start like you did, by making a copy, you probably want to change the path and Save.
I do this a lot with moved-in databases. It looks like Move will move your existing database,
which possibly fits some situations, but I’m not sure it’s the best solution for where it is now.

I was able to reproduce the which-DB-is-which confusion you got into by adding --dbpath.
New backup start time was in Restore list. DB that got its timestamp updated was that one.
Home screen showed completion time correctly. Show log and Database went with old DB.

To straighten things out, I put the new-timestamp DB in Database screen, Save, approved

image
image

and the log file for the new backup appeared. To finish cleanup, I deleted the --dbpath option.

This confusion is interesting, and not ideal. It’s not integrated as well as perhaps it should be.

Possibly cause of split at the Duplicati-server.sqlite configuration DB level is that the Backup table has DBPath value which seems to match the Database screen value, but options including --dbpath are in Option table and so follow what you give as user-supplied option. Different code used different ones?

Thank you so much! That did it. I’m glad there was no permanent damage (at least none found yet.). Do you know if the dbpath option is depreciated and/or only for specific situations?

It’s essential on the command line (by Export As Command-line) when trying to work with an existing job known to the server, otherwise Duplicati tries helpfully-but-invisibly to create a new database for the CLI. Safer (or at least clearer) on CLI is to say explicitly via --dbpath where you want the database to be kept.

–dbpath in the web UI on Database screen doesn’t appear in Advanced options, and I guess by this test it’s deprecated to add it in conflict with the Database screen, but I don’t know if design forces that, or it’s a bug Feel free to file a GitHub Issue to more formalize the steps to reproduce. Perhaps somebody can research it further although there are a whole lot of open issues, so possibly this wouldn’t be worked on.

Having a clear title on the issue will also make it more findable if somebody else runs into such an issue. Further characterization on which things follow which setting might also help a developer sort this out… At the very least, please link back here for characterization so far, but there might be more to be known.