I installed Duplicati on Windows fine and now I am trying to setup Duplicati in pure CLI mode (no desktop) on web servers to backup to Backblaze B2 Cloud.
I ran “systemctl enable duplicati” and “systemctl start duplicati”
It says it is up
"systemctl status duplicati
duplicati.service - Duplicati web-server
Loaded: loaded (/etc/systemd/system/duplicati.service; enabled; vendor preset:
Active: active (running) since Fri 2019-06-07 21:06:53 AEST; 57s ago
Main PID: 17247 (mono)
Tasks: 14 (limit: 4915)
CGroup: /system.slice/duplicati.service
|-17247 DuplicatiServer /usr/lib/duplicati/Duplicati.Server.exe
`-17251 /usr/bin/mono-sgen /usr/lib/duplicati/Duplicati.Server.exe
"
Duplicati is ready
“which duplicati-cli
/usr/bin/duplicati-cli”
Q1) I am a bit confused as to how to schedule a backup to an existing B2 bucket daily with a smart backup retention? So many guides but which one to use?
The CLI and Web-UI are not the same, and operate independently.
If you use the CLI, you need to use cron or something similar to run the backups periodically. You can use duplicati-cli help to get started. You do not need the server running for this.
For the web-UI we do not currently have any tools for manipulating the backups other than the main WebUI itself. You need to somehow forward/tunnel access to the server, and then access the WebUI from a local browser.
I guess systemctl disable duplicati would do the trick?
For setting it up with the commandline, there is documentation here:
That would be the retention-policy:
If you have already set it up to your liking with the GUI, you can export the job and choose “As commandline” to get the exact string you would need to put into the cron job.
I think smart retention is a just a --retention-policy of 1W:1D,4W:1W,12M:1M to avoid doing a custom one.
It would be possible to see whether the above is correct by doing the suggested Export as Command-line.
The GUI description talk of “at least one remaining backup” is likely just –allow-full-removal=false (default).
Nice post. There doesn’t seem to be anything yet in the How-To category, but maybe you could fix that.
Two things caught my eye.
Backblaze B2 confuses lots of people ever since application keys got introduced. I think the rule is to pair Key ID with Application Key, or pair Account ID with Master Application Key, but post suggests the pairing:
* Enter your Backblaze Account ID ( *e.g* . ##########################)
* Enter the Buckey ApplicationKey ( *e.g* . ###############################)
doesn’t reflect what happens, which is actually closer to incremental-forever, except with back-references instead of a (potentially breakable) chain of additional increments. Every file, old or new, is a set of blocks, and existing blocks can be used again in new files if the content is the same. That’s the deduplication part.
Taking a new “full” backup actually uploads only the changed blocks, and everything else just points to old. This makes what seems to be a full backup, with the backup overhead of an incremental. The inefficiency of having to rebuild restore files from potentially various bundles of blocks can slow down restores though.