Mar 15, 2021
CODEX
Restic Backup III — How to setup
TL;DR
This blog post is the third of four posts about restic, a simple, beautiful, and extremely versatile file backup solution. In this post, I will guide you through a very basic setup of restic backup including a self-hosted Minio S3 server.
The restic blog post series
Restic Backup I — Simple and beautiful backups
Restic Backup II — In action
Restic Backup III — How to setup (this post)
Restic Backup IV — Real-life examples
The setup
My aim is to show how restic can be used in a practical example. For simplicity I did set up everything on a Raspberry Pi, meaning the backup repository remains on the same server. If the backup is only meant to restore accidentally deleted files that is totally fine. If it is meant to be safe even in case of a hardware failure it would be wise to put the backup repository on a different server or even cloud-hosted S3 storage. For further questions on how to plan such a repo feel free to reach out via LinkedIn (link below).
My setup does look more or less like the graphic above. Everything runs on a Raspberry Pi 4 with 64-bit Raspberry Pi OS (Debian Buster). I installed docker and docker-compose using the following commands:
I have a Minio S3 server in place that has one static Docker volume for its data to host the backup repository. Further, I have a resticker container that has local host directories mounted as read-only docker volumes and does the backup via Minio’s S3 API. If you want to back up all the Docker volumes of other containers running on your server, you can add the “/var/lib/docker/volumes” directory via a volume to the resticker container. Just be aware to put your Minio data somewhere else, otherwise, you will back up your backup repo recursively and you will soon run out of storage. Also, when backing up databases, it is always a good idea to do a DB dump before backing up.
My file structure for this setup looks like this:
Minio S3 server
I did set up my Minio S3 server using docker-compose. My docker-compose.yml does look like this:
Be aware to put a safe MINIO_ACCESS_KEY/MINIO_SECRET_KEY pair, since these are the credentials that we will use to back up onto the repository. If you want to put a little more effort into the configuration you can set up a dedicated backup user instead of using the administration account of the server. To do so you can have a look at the example from my other blog post on setting up an S3 nix cache. For simplicity, we will just use the admin account in this example.
Resticker — restic on docker
For resticker I also created a docker-compose.yml that looks like this:
There are some important parameters that I will quickly go through:
hostname
This hostname will be visible in your snapshots list, so it’s a good idea to set it to something reasonable, otherwise, there will be cryptical-looking numbers that change every-time the resticker container is recreated.
BACKUP_CRON
With this cron expression, we tell resticker when to backup. If you are having trouble configuring the string the right way, maybe crontab.guru might help. In our case, the backup runs every 30 minutes.
TZ
To ensure your container has the right time zone you should set it using the TZ environment variable.
RESTIC_REPOSITORY
Is the “path” to your repository. In this case, we use S3 compliance storage, other repository types can be configured according to the restic manual.
AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY
These are the S3 credentials that you configured in the Minio docker-compose.yml file.
RESTIC_PASSWORD
This is the password that is used to encrypt our backup repository. Without this password, your backup repository cannot be read even if you have access to the S3.
RESTIC_BACKUP_SOURCES
This is the directory that is going to be backed up by resticker. This is also the place we mount all the local directories we want in our backup.
RESTIC_BACKUP_ARGS
Here we can add further backup arguments such as tags.
RESTIC_FORGET_ARGS
These are the forget arguments we use for policy-based backup retention. Stick to the restic manual for proper configuration.
More information on how to configure resticker can be found on its github project or just feel free to reach out.
Once we start the resticker container it will continuously be backing up our data.
Accessing the backup repository
To gain access to the data we need a server with restic is installed. We can install it directly to our raspberry pi by using:
Then we need our restic.sh executable to export the needed environment variables:
Once exported using …
… we can start using restic from the command line as described in the second blog post of this restic blog post series.
Last Words
I hope the example above helps to understand how restic can be set up on a Linux server without any deeper knowledge and shows how straightforward the setup process is. Let me know if there is anything unclear. In my next post of these four posts series, I will show what else restic can do in real-life examples. If you liked this blog post, make sure to follow me and support my writing. Thanks for reading!
About the author
Remo Höppli is Co-Founder and Software Engineer at Earlybyte.
Earlybyte is an IT consultancy firm specialized in developing new digital solutions for companies around the world from digitalization to IoT solutions, close to the client and its business embracing agility.
Follow me on Twitter to get informed on new blog posts.
