Can't find SQL databases when restoring


I installed Duplicati and must say that it looks easy enough. I just don’t understand how I can restore databases? I made a backup and selected the userfiles + SQL databases on the system to be backed up. When the backup is finished I want to test if the restore works ok. So I select Restore from the menu and get a filebrowser where I can select which files I would like to restore. But where are the backed up SQL databases? They are not listed in that window. Am I doing something wrong? Please help.

Best regards,


A post was merged into an existing topic: All configurations lost

I don’t know if that’s the same problem. My configuration has not vanished. I just can’t find the databases that I backed up. The rest is all there.

Hi @topdata, welcome to the forum!

If your SQL databases were in use when Duplicati ran and you were NOT using a --snapshot-policy of something like on or required then my guess is Duplicati couldn’t get access to the in-use database files so couldn’t back them up.

This setting controls the usage of snapshots, which allows Duplicati to backup files that are locked by other programs. If this is set to “off”, Duplicati will not attempt to create a disk snapshot. Setting this to “auto” makes Duplicati attempt to create a snapshot, and fail silently if that was not allowed or supported (note that the OS may still log system warnings). A setting of “on” will also make Duplicati attempt to create a snapshot, but will produce a warning message in the log if it fails. Setting it to “required” will make Duplicati abort the backup if the snapshot creation fails. On windows this uses the Volume Shadow Copy Services (VSS) and requires administrative privileges. On Linux this uses Logical Volume Management (LVM) and requires root privileges.
Default value: “off”

If you check the job lob, you may find that by expanding a “Results” line (just click on the line that looks like Jun 14, 2018 2:52 PM: Result) you may find a Warnings or Messages block that mentions not being able to get access to those files.

I’d suggest maybe making a test backup job of JUST the database files (could even be to a local folder destination so it runs faster) and trying running that, just to have less “stuff” to look at in the logs. :slight_smile: