Hi
I use Duplicati on Windows10 to run backups to a NAS via WebDAV. Everything works fine from the GUI.
And when I export a job to a CLI-Commando the job runs OK from CLI too: I get a lot of output and a “Backup completed successfully!” at the end
.
BUT on the GUI the time of the “last successful backup” stays on the time of the last backup I made from the GUI. Also when I try to restore from the GUI the backup I made from the CLI does not show up. Why?
To my understanding both ways to execute the job should write to the same sqlite-file. can’t I use Duplicati to backup from both GUI and CLI? Thank you!
Either nope or very-nope. The statistics the GUI server provides are in duplicati-server.sqlite.
The job-specific file is random-letters.sqlite, and can be seen in Database screen of the GUI.
The CLI chooses a database path based on target URL unless you pass one using –dbpath,
which you would do automatically on an export. So result is GUI has restore, logs, and more
because those are in the job database, but doesn’t get server stats because those are not…
Did you pass the complete Export As Command-line? If not, you’re now in very-nope case.
Runs from CLI are intentionally independent from each other and GUI, except maybe job DB.
Duplicati.CommandLine.exe operates independently from the GUI. If you normally want to manage your jobs from the GUI but just want the ability to trigger them via command line, try using duplicati-client. This tool can trigger a job to run as if you manually started it in the GUI. As an added bonus the command will be much simpler.
you are right, these info don’t show up. As explained, even if the job name is passed to the command line, only the job database is touched, and not the server database.
It’s not very logical from Duplicati since if command line jobs were completely independent they should not appear in the log. I can understand why the last date is not updated (it’s in the server database), but not the impossibility in the UI to restore from a command line backup. I get the nasty impression that Duplicati is basing its restore on the metadata table, and it seems wrong somehow.
They’re independent until you make them connected by sharing dbpath.
It’s awkward, but you can point the GUI database to yours to do restore.
To any who wonder why they run a backup, get a log, and don’t get a new version to restore from:
Note that a backup only shows up in restore if something changes, causing a new backup version.
If you want every CLI run to make a version GUI restore shows, add –upload-unchanged-backups
--upload-unchanged-backups = false
If no files have changed, Duplicati will not upload a backup set. If the backup data is used to verify that a backup was executed, this option will make Duplicati upload a backupset even if it is empty.
Having said that, CLI backups that actually created backup versions show up for me for GUI restore.
EDIT:
I ran two tiny CLI backups which made logs at time 8:22 and 8:23. The GUI Restore dropdown shows
Source Files change statistics shows why 8:22 wasn’t made by default – no changes:
I changed the source file for the 8:23 backup, and its new version showed in Restore.
yes you are correct. The only problem is with the last backup date in the home page. It’s definitely not updated, so it’s coming from the metadata table that is not touched by command line backups.
I agree that (I think) that’s where last backup is from, unlike the Restore dropdown, logs, and more.
Exactly why things are as they are is often a mystery that only author (or maybe code) can answer.
I haven’t looked much at the Duplicati-server.sqlite table before, but I notice it has similar metadata:
One advantage of keeping this in the server DB is it’s fast for the home screen to look in one table.
If I hadn’t filtered it for BackupID=3, there’d be more rows. Getting it from each job DB will be slow.
Some of this metadata could be inferred from job logs still in job DB (they age out), as job logs do.
When a DB recreate happens, logs are lost, as they aren’t at the destination. Server DB persists…
SQLite prefers a single writer, so simultaneous CLI backups trying to write server DB could be bad.
The CLI doesn’t even know with certainty where server DB is, although it’s typically near its job DB.
For whatever historical or design reasons, the GUI home screen is not as good for CLI as possible.
The job/server split that seems worse is that there is a separate server log, and it confuses people.
For technical reasons there are multiple logs.
is the explanation from the author, and I assume it’s deep in the design. An easy fix would get done.
Thank you for your explainations.
Yes, my backups are connected by sharing dbpath because that is also exported when exporting to CLI-Commando.
and yes, my test backups were empty, so I’ll try to use –upload-unchanged-backups next
That the “last successful backup”-date on the homepage is not updated doesn’t bother me as long as the backups show up when I try to restore. but good to know
