A while ago I posted about how I back-up my personal servers to Backblaze B2. That approach involved adding all of the files and directories into a single compressed archive and sending this up to an encrypted bucket on B2.
Whilst this does achieve my back-up goals (and I use Telegram to notify me each time it completes), it felt inelegant. Every time the back-up executed, the entirety of the back-up file - several gigabytes - would be built and transferred.
In this post I will talk about my new approach, which uses a tool called Restic.
Restic, repositories, and Backblaze B2
A single repository can contain multiple “snapshots” representing various back-ups. Each snapshot is timestamped and can be filtered by the path of the back-up and the host that the back-up came from.
One of the most useful features of Restic is that each snapshot only stores the representation of what changed since the last snapshot. This means that although the first back-up might take a little while, subsequent snapshots are much quicker.
Repositories can be local (i.e. on a filesystem accessible by the host), or remote. Restic supports a number of remote repository types - from SFTP and RESTful interfaces through to S3-compatible backends and storage services operated by cloud providers.
Restic also supports Backblaze B2 out of the box, which is the repository type that I use.
In the rest of this post I will run through how this can be set-up and automated.
Preparing a Restic repository on B2
First, we need to install Restic. There are instructions for installation on a range of systems on the Restic website.
Next, in the Backblaze B2 console, create a new bucket. The bucket will need a unique name. Whilst there, create a new “App Key”, with read/write access to the bucket. Make a note of the
applicationKey once created.
You can close the B2 console. You now need a file that can be
sourced to tell Restic how to access your repository. Create a new file (e.g. in the home directory of the host you want to back-up), called
resticenv, with these contents:
export B2_ACCOUNT_ID="<KEY_ID>" export B2_ACCOUNT_KEY="<APPLICATION_KEY>" export RESTIC_REPOSITORY="b2:<BUCKET_NAME>" export RESTIC_PASSWORD="<PASSWORD>"
You’ll need to replace some of the parts of the file as described below:
keyIDof the B2 key you created earlier
applicationKeyof the B2 key you created earlier
<BUCKET_NAME>: the name of the B2 bucket you created earlier
<PASSWORD>: a strong and private password
Each Restic repository is secured with a password. This is used to encrypt the repository, so if this is lost then so is the associated data. I use my password manager to generate a strong password. It goes without saying that this
resticenv file should be kept very safe.
Finally, we need to initialise the repository. To do so, first
source the environment file, and then use the
$ source ~/resticenv $ restic init
You’re now ready to create back-ups.
Creating a new back-up
Creating a new back-up is as easy as running the following (as long as your shell still has the
sourced environment as described above):
$ restic backup /path/to/directory
If the target directory is particularly large then the first back-up may take a while. However, subsequent back-ups will be much quicker.
Once done, you can run the following to view a list of all the snapshots held by the repository. You’ll see your recently-created back-up listed:
$ restic snapshots ID Time Host Tags Paths ----------------------------------------------------------------------- 6b25863c 2021-11-27 08:39:44 myhost /path/to/directory ----------------------------------------------------------------------- 1 snapshot
The next time you run
restic backup again, you’ll notice new snapshots are created.
Luckily it’s straight forward to “forget” old snapshots. The command below tells Restic to hold onto the last 24 hours’ worth of hourly snapshots and the last 7 days’ worth of daily snapshots:
$ restic forget --prune --keep-hourly 24 --keep-daily 7
Back-ups are useless unless you can later recover them! Rustic makes this easy. You just need the
ID of the back-up you want to recover (as provided by the
restic snapshots command from earlier):
$ restic restore 6b25863c --target ~/restored
~/restored directory should now contain the files included in the back-up at that snapshot’s point in time.
Finally we can cover a way to automate back-ups. For this we can simply use
cron. To begin, install a suitable cron service (if your system doesn’t come with one). I use cronie.
Once ready, add an entry to your user’s crontab by running
crontab -e and adding the following line:
15 * * * * . /home/<USER>/resticenv; /usr/bin/restic backup -q /path/to/directory
The above job will run at quarter-past the hour for every hour the system is running. Note that cron requires that we include full paths to files. The
-q flag suppresses output. You’ll need to change parts of the line to suit your needs (run
which restic to see where Restic is installed on your system).
I have much more confidence in a tool like Restic to handle my back-ups than a home-grown solution. It’s great to have the peace of mind!