Complete Resti tutorial for Linux for secure backups

If you use Linux daily, sooner or later you're going to need a backup system that is Reliable, fast and easy to restoreRestic has earned that reputation: it's easy to use, encrypts everything it stores, and works equally well on a home laptop as on a cloud server.

In the following lines you will see how to set up a backup system with Restic on Linux that allows you to make copies encrypted, automatic and verifiedThis can be on a local disk, another server via SSH, or compatible cloud services (S3, Backblaze B2, Azure, etc.). The idea is that, once everything is set up, you only need to remember to occasionally check that you can restore your data.

What is Resti and why is it worthwhile in Linux?

Resty is an open-source backup program that focuses on being fast, safe and efficientIt's written in Go and distributed as a single binary, so you don't need to deploy servers or set up complicated architectures: you run it wherever you store data or wherever you want to keep backups, and that's it.

One of its greatest strengths is that it is multi platformYou can use Restic on Linux, BSD, macOS, Windows and even on architectures like ARM (for example, on a Raspberry Pi). This means that with the same tool you can unify the backups of all your devices.

Resty is based on two key concepts: the repositories and snapshotsThe repository is where the information is stored (locally, remotely, or in the cloud), and snapshots represent the state of the data at a specific point in time. Every time you launch a backupResty creates a new snapshot with only the changes compared to the previous ones.

To protect the information, Restic encrypts all repository data with AES-256 and Poly1305-AES authenticationNo file is stored in plain text: even if someone accessed the repository, without the password they could not read anything at all.

Another strength is deduplication. When you run a copy again, Restic detects existing blocks It only uploads or saves what has actually changed. The result: less backup time and much less space used, even if you run full backups frequently.

Practical advantages of Restic for your backups

Beyond the technical aspects, Restic's ease of use is a real plus in everyday life. Being a command-line tool, it's perfect for... Automate backups on servers without a graphical environment or integrate it with scripts, cron, systemd timers, etc.

You can store the copies almost anywhere: a local directory, a disk USBan SSH/SFTP server or S3-type clouds such as Amazon S3, MinIO, Backblaze B2, Wasabi, Google Cloud Storage, OpenStack Swift, or Azure Blob Storage. You can even use rclone to add even more backends.

Another very useful advantage is that you can browse through the contents of a snapshot without fully restoring it.Through commands such as restic mount or file listings, it's easy to locate a specific file and recover it without having to restore the entire backup.

The restoration process is quite straightforward: with a single command you can recover a directory, a file, or an entire copy in the path of your choice. And if you want, you can mount the repository in read-only mode to explore the data as if it were just another file system.

Finally, Resty includes commands for Verify the integrity of the copies, purge old data, and apply retention policies (by number of copies, by age, by tags, etc.), something essential when the repository starts to grow.

Installing Restic on Linux (and keeping it updated)

The easiest way to install Restic on most Linux distributions is to pull the package manager of your system. On Debian, Ubuntu and derivatives you can use:

sudo apt install restic

In other distributions, the usual commands would be similar to these, which serve as a quick reference to see how it works in different environments GNU / Linux:

• sudo dnf install restic on Fedora, RHEL, CentOS, Rocky or AlmaLinux
• sudo pacman -S restic on Arch Linux
• sudo zypper install restic in openSUSE
• sudo apk add restic in Alpine
• sudo emerge -a sys-apps/restic in Gentoo

You can also install Resti from source code or use containers. For example, in Docker, you simply need to download the official image with a simple command. docker-pull:

docker pull restic/restic

If you prefer to compile it, you first need to have Go installed, then clone the repository and run the script of construction. This allows you even generate binaries for other platforms (Windows, FreeBSD, Linux ARM, etc.):

git clone https://github.com/restic/restic
cd restic
go run build.go

Compiling for other systems is as simple as specifying the target system in the command, which is very practical when you have heterogeneous environments and want to use the same backup engine in all.

If you installed Restic from your distribution's repositories, you may not have the latest stable version. The program itself offers a command to auto-update the binary from GitHub, keeping everything up to date without disrupting your workflow:

sudo restic self-update

This command downloads the latest version, verifies the GPG signature, and replaces the old binary, so in a matter of seconds you have Restic updated to the latest version in your system.

Create and protect the backup repository

Before making the first copy, you need to create the repository where the data will be stored. In a typical scenario, you might have a VPS server or remote computer which will act as a copy server.

For example, on the server that will store the backups, you can create a dedicated directory, something as simple as:

mkdir /home/ubuntu/rpi4_bk

Once you have the path, initialize the repository with the command init and the -r option to indicate where the data will be stored:

restic -r /home/ubuntu/rpi4_bk init

The program will ask you for a password for the repository. It is vital that this key is sturdy and store it very wellBecause without it, the repository's contents are unrecoverable. Every operation that involves reading or modifying data (making backups, restoring, listing snapshots, checking integrity, etc.) will require this password or a password file.

If instead of a local directory you use a storage For remote access, the procedure is similar, but the repository path points, for example, to an SFTP backend or an S3 URL. The important thing to understand is that the repository is the encrypted container where all your backup snapshots.

Setting up a dedicated user and permissions in Linux

On Linux machines where you want to make a copy of the entire system, a recurring problem arises: with a normal user you cannot read files owned by root nor restricted areas. The most direct solution would be to run Resti as root, but you can opt for a more refined approach.

A very interesting pattern involves creating a user without administrative privileges, for example called resticand adjust the permissions so that the user can read all the necessary data without being root:

sudo useradd -m restic
sudo passwd restic

Next, the ownership and permissions of the Resti binary are changed so that only root and the restic user can execute it, reinforcing the tool's security on the system:

sudo chown root:restic /usr/bin/restic
sudo chmod 750 /usr/bin/restic

The key step is to apply a special capability to the binary with setcapso that it can read the entire system regardless of file permissions. The capability is used cap_dac_read_search=+epwhich allows Resti to traverse directories and read them as if it were root, but without needing to run as root:

sudo setcap cap_dac_read_search=+ep /usr/bin/restic

With this configuration, when you run backups using the restic user you will be able to back up absolutely all files of the system, respecting a separation of privileges that is more secure than always running as root.

Remote access to the backup server via SSH

If your backups are going to a remote server via SFTP/SSH, the user running Restic on the client (for example, the user restic of a Raspberry Pi) should be able to connect without entering a password each time.

For that, a folder is created. .ssh in your home directory and within it a subdirectory where you will store the private key used to authenticate with the backup server. This entire process can be done with simple commands: create directories, generate or copy the key, and adjust permissions so that only the restic user can read it.

The private key is stored in a file, for example ubuntu_server, to which permissions 0400 and ownership of the user restic are assigned. This ensures that the key is protected and only accessible to the user who needs it:

chown restic:restic ubuntu_server
chmod 0400 ubuntu_server

To simplify the use of the key, the file is configured ~/.ssh/config from the restic user indicating a host alias (for example vps2), the server IP or name, the SSH port, the remote username, and the path to the private key. This way, when Restic uses the SFTP backend with sftp:vps2:/pathIt will automatically use that configuration.

Once this is done, the restic user on the client machine can connect to the copy server without a password, allowing them to Automatic backups function without intervention human

Define what is included and what is excluded in the copies

To have fine control over what's included in the backup, it's common to use two text files: one with what you want to include and another with what you want to exclude. Resty supports this through its options. –files-from y –exclude-file.

For example, in the home directory of the user restic you can create a folder ~/restic and inside a file files_to_backup.txt where directories are listed as /home/pi and other important routes:

/home/pi
/media/nextcloud/twitter
/media/nextcloud/podcast
/media/nextcloud/services/jellyfin/

In parallel, a files_to_exclude.txt This section details paths that you don't want to back up (e.g., a very large video directory) or patterns such as all files with a certain extension. Thanks to this, you can fine-tune the size and relevance of your copies:

/home/pi/videos
*.txt

By combining both files, you ensure that the copy includes everything you're interested in (like the complete home directory and some folders from a service like Nextcloud or Jellyfin) and excludes what doesn't contribute much or can be easily regenerated.

Perform a manual backup with Restic

Once you have a repository, a dedicated user, an SSH connection, and include/exclude lists, you're ready to run your first manual backup. This is great for Verify that everything is working correctly before automating. nothing.

A typical command, if the repository is on an accessible SFTP server like vps2 and the destination route is /home/ubuntu/rpi4_bk/It would be something like:

sudo -u restic restic -r sftp:vps2:/home/ubuntu/rpi4_bk/ backup \
--tag raspberry --tag docker \
-v --exclude-file=/home/restic/restic/files_to_exclude.txt \
--files-from=/home/restic/restic/files_to_backup.txt

It's used sudo -u restic To run the command as the restic user, the SFTP backend is specified, labels are added to the copy (for example, to distinguish backups from different machines or services), and the files to include and exclude are specified.

During execution, you'll see Resty scan the directories, calculate the size, upload the new blocks, and finally create a snapshot with its unique identifier. Once finished, the repository on the backup server will contain a complete snapshot of the state of your data at that moment.

Check that the copy is correct

There's no point in making backups if you can't restore them, so learning how to verify what's been saved is a must. Resty offers several commands for this, both from the copy server as well as from the client's perspective.

To list the snapshots stored in a local repository, you can use something like:

restic -r /home/ubuntu/rpi4_bk/ snapshots

The list shows the ID of each snapshot, the date, the host that created it, the included tags, and the paths. With that information, you know which versions of your data are available and when they were generated.

If instead of accessing the local repository you want to do so from the client that created the copies via SFTP, the command is almost identical but changing the repository path to the remote URL:

sudo restic -r sftp:vps2:/home/ubuntu/rpi4_bk/ snapshots

To verify the integrity of the repository, the following command is used: checkThis tool iterates through indexes, packages, and data trees, verifying that everything is consistent. It's a very powerful way to ensure there's no corruption or problems in your backups.

restic -r /home/ubuntu/rpi4_bk/ check

It's advisable to run this check periodically, especially if you use external drives, network storage, or services where outages might occur, as it gives you peace of mind regarding the actual health of your backups.

Delete snapshots and retention policies

With ThereThe number of saved snapshots can grow considerably, and it's advisable to have an organized way to delete old copies. free up space and keep the repository under control.

The most basic form consists of delete specific snapshots using its ID. First we list the copies with the snapshots command and then we can delete a specific one with forget:

restic -r /home/ubuntu/rpi4_bk/ forget 3161b4f6

This command takes the index snapshot, but the shared data They may remain on the disk if they are part of other snapshots. To permanently clean up what is no longer needed, run plums about the repository:

restic -r /home/ubuntu/rpi4_bk/ prune

If you want to do it all at once from the client to an SFTP backend, you can combine both steps in a single command, asking Resti to forget a specific snapshot and then clean up the associated data.

Even more interesting is using the built-in retention policies. For example, if you want to keep only the last six copies per host, you can use:

restic forget -r /home/ubuntu/rpi4_bk/ --group-by host --keep-last 6 --prune

With this, Restic will maintain the six most recent snapshots for each machine and will delete the oldest ones, automatically adjusting the repository space. There are also options to retain copies by age (days, weeks, months) or by tags, giving you a lot of flexibility to design your backup policy.

Automate backups with scripts and cron

Once you've verified that the manual backup works correctly, the next logical step is to automate the process. The usual approach is to use a small script that does all the work and schedule it accordingly. cron or an equivalent service.

The first detail to resolve is the repository passwordTo avoid typing it each time it runs, a file is usually created, for example pass en /home/restic/restic, which contains the key. It is given strict permissions so that only the restic user (and root) can read it:

echo "mi_password" > /home/restic/restic/pass
chmod 0400 /home/restic/restic/pass

You can also have an output file, like raspberry.txtwhere all the information generated by the script is redirected. This way you can easily check if the process went well or if any errors have occurred.

The automation script can be called run_backup.sh and contain several sections: write the backup date, run the copy command, apply the retention policy and, optionally, perform an integrity check at the end.

#!/bin/bash
echo -e "Backup $HOSTNAME realizado el $(date +'%d/%m/%Y a las %R')" > /home/restic/restic/raspberry.txt 2>&1
sudo -u restic restic -r sftp:vps2:/home/ubuntu/rpi4_bk/ backup \
--password-file="/home/restic/restic/pass" \
--tag raspberry --tag docker \
-v --exclude-file=/home/restic/restic/files_to_exclude.txt \
--files-from=/home/restic/restic/files_to_backup.txt >> /home/restic/restic/raspberry.txt 2>&1
sudo -u restic restic -r sftp:vps2:/home/ubuntu/rpi4_bk/ forget \
--password-file="/home/restic/restic/pass" \
--group-by host --keep-last 6 --prune >> /home/restic/restic/raspberry.txt 2>&1
sudo -u restic restic -r sftp:vps2:/home/ubuntu/rpi4_bk/ check \
--password-file="/home/restic/restic/pass" >> /home/restic/restic/raspberry.txt 2>&1

Once you've created the script, don't forget to give it execute permissions. From that point on, any authorized user (for example, your regular user account using sudo) will be able to run it. To launch the automatic backup, simply call the script..

Schedule execution with cron on Linux and Android

To make copies automatically, the usual practice is to add a entry in crontab of the user you want to trigger the process. For example, if you want the user pi Run the script every Saturday at 1:05 AM; simply edit your crontab:

crontab -e

And add a line like this:

5 1 * * 6 bash /home/restic/restic/run_backup.sh

Cron will automatically run the script at the specified time without any further intervention. This way you will have regular and consistent copies without having to do it manually every time.

In Android environments, something similar can be achieved using Termux and the termux-services package, which provides cron support through cronyThe workflow would be to install Termux, add termux-services, enable the services, and configure a cron job that calls a Restic-based backup script, just as you would on a desktop Linux system, but adapting paths and variables.

Restyc on Android and S3-type storage with MinIO

Restic isn't limited to the PC or server world. You can also use it to protect your data on Android deviceswhich are ultimately just computers that handle personal and work information.

One option is to use a specific project called Restic Android, which uses termux/proot to run the Restic Linux binary within Android. This app allows you to manage S3, B2, or REST repositories, configure backup folders, schedule backup times, and define cleanup policies, although the project is still under development. early stage of development and not without flaws.

Another, more flexible option is to use Restic directly within Termux. This keeps your backup configuration in your dotfiles, sharing scripts between your desktop computer and the Android device with minor variations. It's very convenient if you already work with templates (for example, Jinja files) and tools like jinrender to generate scripts with the corresponding variables for each device.

In both cases, remote storage can be based on S3-compatible services. This is where MinIO comes in, an object server that replicates the S3 API and that you can self-host on your own server or even on your PCThis way you get all the advantages of the S3 model without paying for an external service or depending on third parties.

This obviously involves installing, configuring, and maintaining MinIO, but in many cases the cost is offset by the flexibility and complete control over your data. Combined with Restic, you have a system of encrypted and deduplicated copies in an object-based backend. that you control 100%, both for Linux and Android.

Basic operations: snapshots, restoration, and cleanup

In daily use of Resti, in addition to making and scheduling backups, there are three operations that should be very clear: List snapshots, restore data, and delete old copies.

To see which copies you have stored, the snapshots command already mentioned shows you the full inventory.

If at any point you want to compare two snapshots to see what changed between them, you can use restic diff Passing the IDs that interest you, which greatly helps in understanding the evolution of your data.

The restoration is done with the command restore, indicating the snapshot ID (or the keyword latest (if you want the most recent one) and the destination path. Restic doesn't restore to the original location by default, so you must specify a target directory where the content will be displayed:

restic restore latest -r /path/to/backup-repository --target /tmp/restore

If you only want to retrieve a specific directory, you can use additional options such as --include o --path to limit which part of the snapshot is restored, saving time and space when searching a small set of files.

Regarding cleaning, apart from the commands forget y pruneRestic allows you to define more elaborate rules such as "keep the last N copies, keep those from the last X days, weeks, or months, or don't delete those with certain tags." This gives you enough tools to design. fairly sophisticated retention strategies without complicating your life.

With Restic you can set up a backup system on Linux (and other systems, including Android) that is fast, secure, and easy to manage: you install the binary, create a encrypted repositoryYou define what gets copied and what doesn't, automate the process with a script and cron job, apply retention policies, and periodically verify data integrity. All of this leverages local backends, SSH, or cloud services like S3, with deduplication, strong encryption, and a simple restore workflow that lets you sleep much more soundly knowing your important data is well protected.