Backups using Restic
Restic is a free and open-source tool to create encrypted backups. As storage for Restic, you can use Glesys object storage.
We all know how important backup is, yet a secure and reliable backup solution is often missing. Some may have external hard drives or a small home NAS, but what good does that do in the event of theft or fire?
Enter Restic, a modern backup tool that lets us create encrypted backups. The program is entirely free and open‑source, and it also uses a technique called deduplication, which means that only unique data is stored in the backup. This helps keep backup sizes low. Since version 0.14.0, Restic also supports compression. Additionally, you get a complete history of the repository. Each new backup becomes a new snapshot. That means you can restore your data as it looked three months ago—or even as far back as two years ago.
Here, we'll use Glesys Object Storage to store the Restic backup data. This gives you a backup that is stored off‑site.
Install Restic in Linux and macOS
The installation procedure is the same for Linux and macOS.
Start by downloading the correct release of Restic from GitHub. The latest version is listed at the top. Under the Assets heading, choose the release that matches your computer and operating system. For example, if you have an Intel‑based Mac, select the file whose name ends with darwin_amd64.bz2. If you have an M1‑ or M2‑based Mac, select darwin_arm64.bz2. For most Linux distributions running on a typical PC, choose the file whose name ends with linux_amd64.bz2. Download the file to the Downloads directory on the computer via the browser.
Next, you need to unpack the file and place it in the proper directory on the computer. You do this with the following commands. In the example below, we have downloaded version 0.15.2 of Restic for Linux for standard PCs.
cd ~/Downloads
bunzip2 restic_0.15.2_linux_amd64.bz2
sudo mkdir -p /usr/local/bin
sudo mv restic_0.15.2_linux_amd64 /usr/local/bin/restic
sudo chmod +x /usr/local/bin/resticVerify that the restic command is working.
restic versionThis should output something like the text below.
restic 0.15.2 compiled with go1.20.3 on linux/amd64Create an object storage instance
See the section on Create an instance for instructions on how to create an object storage instance. Make a note of the access key, the secret key, the endpoint address, and the name of the initial bucket.
Initialize a Restic repository
Now it’s time to create and initialize a Restic repository. This step creates a directory structure, along with encryption keys and other necessary files in the bucket.
When working with Restic repositories, it’s easiest to set all settings as environment variables. That way, you don’t have to type them repeatedly. Environment variables also make it simpler later on when you automate the backups. Here, start by disabling shell history so that your key doesn’t appear in the history file of your shell.
RESTIC_REPOSITORY is where the backup will be stored. It starts with s3 because Glesys object storage is S3‑compatible. Then comes the address https://objects.dc-fbg1.glesys.net/ (dc-fbg1 is the Falkenberg data centre). This is the address that was shown when you created your object storage instance. After the final slash, the name of your initial bucket is appended, which in this case is cool-recipe.
AWS_ACCESS_KEY_ID is the key that was displayed under Access Key when you created the storage instance.
AWS_SECRET_ACCESS_KEY is the secret key that was shown when you created the storage instance.
RESTIC_PASSWORD is the encryption password for the Restic repository. This is a password you choose yourself. It’s crucial to remember this password; without it, you will never be able to access the backup again. It’s also important to choose a long password with many different characters.
Now that all the values are ready, you can initialise the repository with the command restic init.
The command will output something similar to the example below.
Making backups and working with repositories
You have now prepared everything needed to start backing up your files. In this example, we will back up the Documents directory in the user’s home directory.
This will output something like below:
The backup is now complete. You can also see that compression and deduplication worked: the files in the backup occupy 12.8 MiB, even though the files on disk total 37.3 MiB.
You can verify that everything looks correct before proceeding. First, list all snapshots contained in your Restic repository:
This will output a list of the current snapshots in the repository:
Each snapshot is labeled with the computer the backup originates from (here red‑dwarf.nixnet.test) and the directory that was backed up.
You can also list the files that a particular snapshot contains. To do this, use the snapshot’s ID number, which in this case is bbad22da (you can see it under the ID column in the output from the command above).
If you modify a file, for example lorem‑ipsum1.txt, and then create a new backup, only that file—and only the changes—will be transferred to save storage space. The previous snapshot will be used for the files that haven’t changed.
Here you see that one file has been changed and ten remain unchanged. This snapshot occupies only three KiB.
You now have two snapshots in the repository:
If you list the files for the new snapshot, you will see all the files, including those that haven’t changed.
Restore files from a backup
It's time to test restoring the Documents directory to a temporary location. Restore the files from the latest snapshot, which in this example is 5f80356f as seen in the previous section. The backup will be restored to the directory /tmp/restic‑lab.
The home/jake/Documents directory has now been restored under /tmp/restic‑lab/. List the files to make sure everything looks correct:
The new line we added to lorem‑ipsum1.txt is also present.
Restore individual files
It is also possible to restore individual files from a snapshot. This is done using the --include flag. Here, let's restore the file lorem‑ipsum1.txt from the first snapshot—before we added the new line—to the directory /tmp/new‑restic‑lab, which results in the file being placed at /tmp/new‑restic‑lab/home/jake/Documents/lorem‑ipsum1.txt.
Automate the backup
Restic is designed to be easy to script and automate, which is evident. Here, we’ll create a simple Bash script to back up the documents directory we’ve been working with earlier. Then we’ll add the script to the user’s crontab so the directory is backed up automatically every day.
Create a file named document-backup.sh in your home directory with the following contents. Adjust the variables and paths to match your own setup. The variables are the same ones we used previously.
Then, change the file’s permissions so that it becomes executable. Also, adjust the permissions so that only your own user can read and write the file, protecting the keys and password.
Let's run the script to verify it's working.
It should output something like this if it's working.
Everything worked, and no files have changed since the previous snapshot. Now, add the script to the user’s crontab:
Now a text editor opens, most likely nano or vi. Add the following line, adjusting the path to match your user’s home directory. Then exit the editor and save the file.
Now the Documents directory will be backed up automatically every evening at 21:05.
Add a log file
If your computer or server has email enabled, you will also receive an email containing all the output from the cron job execution. This way, you can verify that everything worked as intended. If you instead want to log the latest run to a file, you can modify the crontab line so that it looks like this:
After 21:05, you can view the output from the most recent run in the file restic-run.log.
Real-world deduplication
Depending on the type of data you back up, Restic’s deduplication can be highly effective. I recently backed up the disks of four virtual machines. All of the VMs were running Debian 11. Together, those four disks occupied 122 GiB on the local drive. The backup in Restic, however, took only 17.7 GiB. Because all the VMs were so similar, there was a lot of redundant data that deduplication could ignore.
Last updated
Was this helpful?