Having a backup solution is one thing. Having a backup solution that runs in a timely manner is another thing entirely. Question: If your computer were to suddenly catch fire, taking with it all those irreplaceable family photos, cute cat videos, and other forms of precious, precious data; could you count on a backup restoring those?
If your answer to that question was no, worry no more! This week we will be talking about upping your backup game with automation through systemd.
Don’t Do It Yourself, Automate!
In the days of yore, we used cron to do automation (some still do). For those of us using more recent distros, we have systemd available to us. Systemd is short for system daemon and is the backbone for Linux process and service management. To the delight of some and the lament of others, it provides everything and the kitchen sink, from system logging to network management. Systemd, just like cron, provides the ability to schedule services.
Scheduling Peace of Mind
Systemd provides scheduling through something called timers. Do you feel paranoid when you think about random electric discharges or extraterrestrial radiation causing your hard drives to crash and burn without warning? Or, are you one who prefers to live a little more dangerously and schedule your backups on a per month (or maybe even year) basis? Regardless, systemd timers have you covered. There are two types of timers in systemd: realtime and monotonic. As we are interested in tracking our backup on a specific date time (i.e. calendar date), we are going to focus on a realtime timer.
Anatomy of a Timer Service
Note: Creating systemd services requires root privileges. It is recommended to edit all unit files using `sudo`.
There are two parts to a systemd timer: the `.service` and `.timer` configuration files. Systemd services can be as complex or simple as you want. Today, however, we aren’t here to discuss the infinite recesses of systemd, just the important parts for our backup. We are interested in two things: backing up, and making sure that the backup runs in a timely manner.
Last week we ran a command for initiating a borg backup:
This is the basis for our backup and will provide us with the main execution for our systemd service.
Before creating the systemd service, create a script under “/home/$USER/Scripts/borg-backup.sh” and add the following contents:
#!/bin/bash
export BACKUP_LOCATION=”” #insert location to backup repository
export BACKUP_NAME=”” #insert the name of the backup
export PATH_TO_BACKUP=”” #insert location to backup from
export BORG_PASSPHRASE=”” # insert borg passphrase (if backup is encrypted) and borg will pick it up
# Route the normal process logging to journalctl
2>&1
borg create -v --stats “$BACKUP_LOCATION"::$BACKUP_NAME $PATH_TO_BACKUP
# If there is an error backing up, reset password envvar and exit
if [ "$?" = "1" ] ; then
export BORG_PASSPHRASE=""
exit 1
fi
exit 0
A `.service` is a configuration unit that looks like the following:
[Unit]
Description=Automated Borg Backup
[Service]
# nothing fancy here - just a simple service trying to make its way in the universe
Type=simple
# define what occurs before the main process.
# in our case we are breaking the lock on the repo
# so we can start another backup.
# In the example the $REPOSITORY is
# Raft/Backup/Linux/Documents
ExecStartPre=/usr/bin/borg break-lock $REPOSITORY
# Do the thing - get it going - $USER should be your user (Example: $USER=christian)
ExecStart=/home/$USER/Scripts/borg-backup.sh
# This needs to execute as some user and group you login with (Example: $USER=christian, $GROUP=christian)
# Otherwise it will use root and ownership of your backup will be incorrect
User=$USER
Group=$GROUP
Open your favorite text editor and save the contents of this file to “/etc/systemd/system/borg-backup.service”.
A `.timer` is a configuration for how often the same-named service should be run and looks like the following:
[Unit]
Description=Automated Borg Backup Timer
[Timer]
WakeSystem=false
# Lets run this every day at 9 AM
# If specific times need to be used, you can specify the OnCalendar clause more than once
# A useful reference for timers can be found here.
OnCalendar=*-*-* 9:00:00
RandomizedDelaySec=10min
Unit=borg-backup # the unit we want this timer to run
[Install]
WantedBy=timers.target
Open your favorite text editor and save to “/etc/systemd/system/borg-backup.timer”.
Enabling and Firing Off a Backup (this time automated)
To enable your backup, run the following:
Since our timer has yet to be run, you will need to run this command to list it:
To start the timer so that it may trigger at the correct time, run:
You can check the status of the timer like this:
The “trigger” line indicates when the backup will run next.
Manually triggering a backup
You can manually trigger a backup (in case you need to troubleshoot it or are paranoid the configuration is wrong) like this:
View the status of your triggered run like this:
If for some reason there is an error, modify the “borg-backup.service” file and run the following to make sure the service is up-to-date:
Checking a Backup
If you want to check on the status of a trigger backup, run the following:
The outputs are:
Nov 07 11:45:05 robo-beaver systemd[1]: Starting Automated Borg Backup...
Nov 07 11:45:05 robo-beaver systemd[1]: Started Automated Borg Backup.
Nov 07 11:49:39 robo-beaver borg-backup.sh[25787]: /home/christian/.config/Bitwarden: scandir: [Errno 13] Permission denied: '/home/christian/.config/Bitwarden'
(Note: the last line isn’t an error, it's just a directory that borg shouldn’t be accessing - oops!)
Conclusion
Systemd is an awesome tool for automating tasks, especially backups, with minimal configuration. Having an automated backup strategy gives you peace of mind when it comes to making sure your documents, music, and precious digital memories are safe.
About Automox
Facing growing threats and a rapidly expanding attack surface, understaffed and alert-fatigued organizations need more efficient ways to eliminate their exposure to vulnerabilities. Automox is a modern cyber hygiene platform that closes the aperture of attack by more than 80% with just half the effort of traditional solutions.
Cloud-native and globally available, Automox enforces OS & third-party patch management, security configurations, and custom scripting across Windows, Mac, and Linux from a single intuitive console. IT and SecOps can quickly gain control and share visibility of on-prem, remote and virtual endpoints without the need to deploy costly infrastructure.
Experience modern, cloud-native patch management today with a 15-day free trial of Automox and start recapturing more than half the time you're currently spending on managing your attack surface. Automox dramatically reduces corporate risk while raising operational efficiency to deliver best-in-class security outcomes, faster and with fewer resources.
