Restic: A Professional Linux Backup Solution to the Cloud (Encryption, Deduplication) – ITFROMZERO

Table of Contents

Why is Restic Superior to Traditional rsync or tar?

After years of managing Linux systems, I’ve realized that relying on manual rsync or tar scripts is a risky move. The old methods often face two major issues: high storage consumption and extreme slowness as data grows. If you’re managing a 500GB server, compressing a tarball every day and pushing it to Google Drive will soon become a bandwidth and cost nightmare.

Restic completely solves this problem thanks to Deduplication technology. Imagine backing up a 10GB database every day. With the old way, after 10 days, you’d consume 100GB. With Restic, if the data only changes by 1%, you’ll only use about 10.1GB for all 10 backups combined. Additionally, all data is AES-256 encrypted on the client side. Even if the Cloud provider is hacked, your data remains meaningless blocks of encryption to the attacker.

3 Core Concepts to Master When Using Restic

To avoid confusion during operation, you need to distinguish between these three components:

Repository: Where backup data is stored. This can be an external hard drive, a server via SSH, or object storage like AWS S3, Backblaze B2, or MinIO.
Snapshot: A version of the data at a specific point in time. Think of this as a “restore point.” Restic allows you to travel back in time to any snapshot extremely quickly.
Password: Restic uses this password to create the data encryption key. Remember: If you lose the password, you lose the data. There’s no “Forgot Password” button here.

Installing Restic in a Flash

Written in Go and packaged as a single executable, Restic is lightweight and stable. You can install it quickly via package managers:

# Ubuntu / Debian
sudo apt update && sudo apt install restic -y

# CentOS / RHEL / AlmaLinux
sudo dnf install restic -y

# Check if installation was successful
restic version

Initializing and Performing the First Backup

Step 1: Create a Local Repository

Before pushing to the Cloud, try it locally to understand the workflow. Create a repo at /srv/my-backup:

restic init --repo /srv/my-backup

The system will ask for a password. Don’t forget to save it in your Bitwarden or 1Password.

Step 2: Run the Backup

Try backing up the /etc configuration folder and /var/www/html web code:

restic -r /srv/my-backup backup /etc /var/www/html

The first time, Restic will scan all data, so it might take a while. From the second time onward, it only pushes the data blocks (chunks) that have actually changed, making it many times faster.

Pushing Data to the Cloud (Backblaze B2 or AWS S3)

Using the Cloud is a smart choice to avoid on-site physical failure risks. I usually prefer Backblaze B2 because it costs around $6/TB/month, which is 4 times cheaper than standard AWS S3.

To avoid entering info every time you type a command, set up Environment Variables:

export B2_ACCOUNT_ID="your_id"
export B2_ACCOUNT_KEY="your_key"
export RESTIC_REPOSITORY="b2:your-bucket-name:backup-folder"
export RESTIC_PASSWORD="your_repo_password"

Now, every Restic command will automatically understand it’s interacting with the Cloud:

# Initialize the repo on the Cloud
restic init

# Backup important data
restic backup /home/user/data

Managing Snapshots and Restoration

Checking the Backup List

Use the following command to see what you have in hand:

restic snapshots

Restic will list a data table with unique IDs (e.g., 76c12f34). You will use this ID to restore.

Restoring Data

When you need to recover data, specify a target folder for Restic to extract it into:

restic restore 76c12f34 --target /tmp/restore-point

Automation and Periodic Cleanup

Don’t let old backup data drain your wallet. Restic has a very smart mechanism for automatically deleting expired backups.

Example: Keep 7 backups for the last 7 days, 4 for the last 4 weeks, and 12 for the last 12 months.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Quick Tip: The forget command only deletes the index; you must include --prune for Restic to actually delete the redundant data blocks and free up space on the Cloud.

Here is a sample script to set up a Cronjob running at 2:00 AM:

#!/bin/bash
source /path/to/env_vars.sh
restic backup /var/www/html --quiet
restic forget --keep-daily 14 --prune --quiet
restic check --quiet # Check for data errors

Final Thoughts from Experience

A classic mistake among Junior admins is trusting backups blindly without ever testing them. Occasionally, run restic check to ensure the data structure isn’t corrupted. Keeping the Repository password separate from the Cloud access keys is also a paramount security rule. Once you’ve mastered Restic, you’ll find data management easier than ever, no matter how serious the system failure.