I really like the combination of Backblaze B2 and Duplicacy for an off-site backup. It is easy to setup and Duplicacy provides a very reasonable Quick Start guide as well as specific back-end details .
Once you have properly configured the backup source directories (see the documentation above), you can run backups manually from the backups’ source directories:
duplicacy backup -stats
Now you should schedule backup jobs to run from all backup source directories at your preferred schedule. While using a classical crontab is still an option, here is a way to do it using systemd
with more control over the jobs and extra benefits like proper logging. Here I show how to schedule the jobs as an unprivileged user, without using system-wide permissions.
The setup shows how to minimise future work when adding or removing extra directories to the backup schedule. While I prefix this setup as dpcy
, nothing stops you from using a different prefix - just keep it consistent and without other collisions.
First you need a service template file. All backup runs will be derived from this template. Put it at ~/.config/systemd/user/[email protected]
:
[Unit]
Description=Backup %I with duplicacy
Documentation=https://github.com/gilbertchen/duplicacy/wiki/Quick-Start
[Service]
Restart=no
WorkingDirectory=%I
ExecStart=/home/vlad/bin/duplicacy backup -stats
StandardOutput=journal
StandardError=journal
SyslogIdentifier=duplicacy@%i
PIDFile=%t/duplicacy@%i.pid
As the duplicacy
executable path is different on your system you need to adjust the value of ExecStart
in this sevice template.
Next, create the actual scheduling files, timers
in systemd
terms. In my setup all backup jobs will run at the same timeframe on a Sunday, with a 15 min variance.
For example, imagine that you have the following directories which you want to back up with duplicacy
:
/home/archive
/home/family
/home/music
/home/photos
Get the systemd-escape
values of the paths, to avoid surprises:
$ systemd-escape /home/{archive,family,music,photo}
-home-archive -home-family -home-music -home-photo
Then create a same file with varying names, pointing to your directories. Here is the first copy of the file, ~/.config/systemd/user/[email protected]
:
[Unit]
Description=Backup the configured location with duplicacy
[Install]
WantedBy=timers.target
[Timer]
RandomizedDelaySec=900
OnCalendar=Sun, 00:42
Naturally, the [Timer]
parameters may be adjusted per the documentation of systemd.timer
and systemd.time
.
When the timer fires, systemd will expect to be able to run a unit named in a same way as this timer file, except ending with the .service
postfix, so [email protected]
. While looking for such service it will use the [email protected]
template which we created above. The remplate will use the parameter -home-archive
as the escaped value for %i
. The %I
macro in the template file will be substituted with the unescaped value of /home/archive
.
And here are the other timer files created, checked, and systemsd
is told to enable all timers:
$ cd .config/systemd/user/
$ ln [email protected] [email protected]
$ ln [email protected] [email protected]
$ ln [email protected] [email protected]
$ stat -c "%i %n" dpcy@*
43913832 [email protected]
43913832 [email protected]
43913832 [email protected]
43913832 [email protected]
43913874 [email protected]
$ systemctl --user enable dpcy@*.timer
Created symlink /home/vlad/.config/systemd/user/timers.target.wants/[email protected] → /home/vlad/.config/systemd/user/[email protected].
Created symlink /home/vlad/.config/systemd/user/timers.target.wants/[email protected] → /home/vlad/.config/systemd/user/[email protected].
Created symlink /home/vlad/.config/systemd/user/timers.target.wants/[email protected] → /home/vlad/.config/systemd/user/[email protected].
Created symlink /home/vlad/.config/systemd/user/timers.target.wants/[email protected] → /home/vlad/.config/systemd/user/[email protected].
To check the last runs’s status, next planned runs and recent log entries you can use the systemctl command:
$ systemctl --with-dependencies --before --user status dpcy@*.timer
...
Once the jobs have run you should be able to check their log output with joutnalctl, similar to:
$ journalctl --catalog --quiet --user-unit=dpcy@*.service --since="$(date -I --date="last Saturday")"
...
If at some point of time you want to schedule another duplicacy backup, say of /home/business
, then just:
$ systemd-escape /home/business
-home-business
$ cd .config/systemd/user/
$ ln [email protected] [email protected]
$ systemctl --user enable [email protected]
Created symlink /home/vlad/.config/systemd/user/timers.target.wants/[email protected] → /home/vlad/.config/systemd/user/[email protected].
If you happen to edit a template or a timer, or delete one altogether, do not forget to run the reload:
systemctl --user daemon-reload
Finally, do not forget to regularly test and prune your backups. The last point is not subtle - If you happen to change many files often it is very feasible to store more than you comfortably want to pay for in the cloud.
2021-02-14