Protect your precious files and irreplaceable photos with the restic backup program. It’s fast, encrypted, and you can use it right from the Linux command line. Here’s how to set it up.
The value of backups
All hardware has a finite life. Mechanical hard drives (HDDs) and solid-state drives (SSDs) don’t last forever. Accidents also happen. Laptops can be lost, stolen, or fall down stairs.
It used to be said that the value of an effective backup system only becomes apparent when you have lost data. When failures or losses occur, you should have a quick and easy way to get your files and information back. If an organization loses data, the consequences are serious. It can even compromise business continuity. Even in a home environment, data loss can be a painful experience. Backups are the only sensible precaution.
Most importantly, the accidental or deliberate loss of personally identifiable data is considered a breach under certain data protection laws, such as the General Data Protection Regulation (GDPR).
There are a number of considerations to keep in mind when choosing backup software. Where do you want your backups to be kept? On a removable disk, on another machine in your local network (LAN) or in cloud storage? Obviously you need to use a backup program that can write and restore from whatever data storage you want to use.
Backups must be encrypted, especially if they are stored in remote locations or in the cloud. When encrypted, they cannot be read and restored by unauthorized persons.
The program must be fast. You don̵
restic does all this. It is free, open-source, licensed under the 2-Clause BSD License, and in active development. The source code is on GitHub.
Where to back up
In this article, we are going to store our backups on another computer on our network. That’s great because it allows for fast file transfers and is easy to back up and restore. In a realistic scenario, you really need to back up to another remote location. If your live systems and backups are in the same location and there is a disaster in that location – fire, theft or flood – then your goose will be cooked unless you have an external backup.
Unsurprisingly, restic can back up to an external drive that can be deleted from location, and – even better, it can back up directly to cloud storage.
Out of the box restic can make backups of:
- A local directory or a local removable drive.
- A network computer via SSH File Transfer Protocol (SFTP). This of course requires Secure Shell (SSH).
- HTTP REST server.
- AWS S3.
- OpenStack Swift.
- BackBlaze B2.
- Microsoft Azure Blob Storage.
- Google Cloud Storage.
If you need to back up to a data destination not on that list, you can combine the power of rclone with restic and back up to one of the approximately 40 destinations that rclone supports.
For SFTP network backups, SSH must be installed and configured on the backup server. This is the machine where the backups are stored. If you set SSH keys on the backup server and the machine that you will back up, you will not be prompted for the SSH password every time you perform a backup.
One way to automate your backups is to create short scripts or shell functions and use cron to run them at specified times. By using SSH keys, you avoid the problem of entering a password for unattended backups.
RELATED: Create and install SSH keys from the Linux shell
The restic application resides in the repositories of the major Linux distributions, so installing it is a simple one-liner using each distribution’s package manager.
To install restic on Ubuntu, type:
sudo apt install restic
The command to use on Fedora is:
sudo dnf install restic
On Manjaro we use
sudo pacman -Sy restic
Make sure that you have set up SSH on the backup server machine and that you can connect to it remotely from the computer you will be backing up. That is the client machine. In our test network the client is called ‘ubuntu-20-10’ and the server is called ‘backup-box’.
In restic terminology, backups are stored as snapshots in a repository. Each backup takes a new snapshot. We need to make a place for the repository on the server.
We need to create a folder on the backup server to hold the repository in. In the past, services served by a server were located in the “/ srv” directory. So we put our repository there.
Issue this command on the backup server. You can name the repository folder whatever you want. We use the name “restic” for simplicity.
sudo mkdir /srv/restic
We need to make sure that this folder is accessible to the person who will be handling the backups. If it were multiple people, it would make sense to create a user group and give the group access to the directory.
sudo chown dave:dave /srv/restic
Let’s check the settings on the directory:
ls -hl /srv
Now we can go to the client computer and from there create the repository on the server. Replace your user name, backup server name, and repository folder name to match your choices. You can use the IP address of the backup server if desired.
We use the
-r (repository) option to specify the path to the repository we are going to create. The restic
initcommand initializes the repository.
restic -r sftp:email@example.com:/srv/restic init
You will be asked for the password for the user account on the backup server. If you have set up SSH keys between the server and the client, you do not need to perform this step.
You will also be asked for the password of the repository and then you will be asked to confirm it. This password should be used to communicate with the repository in the future. Don’t lose it! You cannot back up or restore the data if you lose the password.
It only takes a moment for the repository to be created and initialized.
Make a backup
Making a backup is very easy. We use the
backup command with restic, tell it what we want to back up and which repository to send the backup to.
restic backup Documents/kernel/ -r sftp:firstname.lastname@example.org:/srv/restic
You must provide the user’s password and the password for the repository. While the backup is in progress, the names of the files being copied are displayed, along with statistics showing how many files will be copied in total, how many have been copied so far, and what percentage of the backup has been completed. The snapshots are encrypted with the advanced encryption standard AES-256.
As this was the first backup to this repository, all files backed up were new. We did say restic was fast, backing up more than 70,000 files in 23 seconds. That’s all the source code for the Linux kernel.
On another test machine, I backed up over 350,000 files in an hour and a half, which amounts to over 170 GiB.
I created a new file on the client in the source folder and made another backup. The command is the same as before.
restic backup Documents/kernel/ -r sftp:email@example.com:/srv/restic
The source directory tree has been scanned for changes, the new file was detected and backed up. That second little backup took three seconds, including scanning the other files for changes.
Let’s take a look at the two snapshots we have in the repository. The rest command for this is
restic -r sftp:firstname.lastname@example.org:/srv/restic snapshots
Each snapshot is hexadecimal identified as a unique ID. The date and time each snapshot was taken are displayed. The name of the computer that was backed up and the path to the data that was backed up is also displayed.
I then created a second new file and made another backup. Again, the command line is the same as before.
As with our previous reload backup, this minor update took three seconds to complete.
By now you are probably tired of entering the repository password. We can address that before we do it
snapshots assignment to view our collection of three snapshots. Open an editor and type in the repository password, then hit “Enter” to start a new line. Save the file as “.rest_pass” in your home directory.
To ensure that no one else can see the password, change the access mode bits of the file with
chmod 600 .rest_pass
This means that only you can access the file.
Now we can pass this to the rest command line using the
-p (password file) option. If you have also set up SSH keys between the client and the server, then you do not need to enter the user account password. You can easily automate your backups with
cron once human interaction is removed from the process.
restic snapshots -r sftp:email@example.com:/srv/restic -p .rest_pass
It no longer asks for the repository password, which is great. We don’t have to memorize it and we cannot mistype it.
Working with snapshots
diff command shows you the differences between any two snapshots. Use the unique IDs of the two snapshots you want to compare. You can see the snapshot IDs when you run the restic
restic diff -r sftp:firstname.lastname@example.org:/srv/restic -p .rest_pass 8f98cd29 8700e4bf
The differences between the snapshots are shown as columns of statistics.
check command performs a verification test against all snapshots in the repository.
restic check -r sftp:email@example.com:/srv/restic -p .rest_pass
To delete a snapshot, tell restic
forget it and to
prune it. You must use the snapshot’s unique ID to determine which snapshot to delete.
restic forget --prune -r sftp:firstname.lastname@example.org:/srv/restic -p .rest_pass e506e089
When it comes time to recover data from your backups, it’s as easy as creating the backup. You must specify which snapshot you want to restore. You can use a snapshot’s unique ID, or you can use the
latest label to use the latest snapshot in the repository.
You must also specify a directory to which the recovered data should be copied using the
restic restore latest --target ~/restored-data -r sftp:email@example.com:/srv/restic -p .rest_pass
Restoring is just as fast as making a backup. When we check in the destination folder, we can see the folder tree and files have been restored for us.
Make backups, sleep peacefully
Data loss is a serious problem. With a robust backup solution you don’t have to worry anymore. Restic allows you to automate your backups to local and cloud repositories and sleep with ease.