LifeBytes Journal

Modern backups are not just about copying files to an external disk. If you manage a Linux server, a development workstation, or even a home lab, you need backups that are incremental, encrypted, and easy to restore. In this tutorial, you’ll configure restic (a fast, deduplicating backup tool) to send backups to S3-compatible object storage such as MinIO, Backblaze B2 (S3 API), Wasabi, or an on-prem S3 gateway. The result is a secure backup setup that scales well and can be automated with systemd.

Why restic + S3 is a strong backup combo

Restic is popular because it encrypts data before it leaves your machine, stores only changed blocks (deduplication), and keeps snapshots you can browse and restore from. Pairing it with S3-compatible storage makes your backups resilient: object storage is designed for durability, and you can back up over the network without mounting remote filesystems.

Prerequisites

You’ll need a Linux machine (Debian/Ubuntu/Fedora/AlmaLinux all work), an S3 endpoint (cloud or self-hosted), and credentials (access key and secret key). Make sure the target bucket exists or that your provider allows creating it via API. Also decide what to back up: typical choices are /etc, application configs, and data directories like /srv or /var/lib (be careful with databases; see notes below).

Step 1: Install restic

On Ubuntu/Debian:

sudo apt update && sudo apt install -y restic

On Fedora:

sudo dnf install -y restic

Verify:

restic version

Step 2: Export S3 credentials securely

Restic uses environment variables for S3 credentials. For a quick test in your current shell:

export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"

export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"

If you’re using a non-AWS endpoint (MinIO, Wasabi, etc.), also set a custom endpoint URL:

export AWS_DEFAULT_REGION="us-east-1"

export RESTIC_REPOSITORY="s3:https://s3.example.com/my-restic-bucket"

For AWS S3, your repository might look like:

export RESTIC_REPOSITORY="s3:s3.amazonaws.com/my-restic-bucket"

Step 3: Initialize the backup repository

Initialize once per repository. Restic will prompt for a repository password (this is used for encryption):

restic init

Store this password carefully. If you lose it, you cannot decrypt your backups.

Step 4: Run your first incremental backup

Start with a small but meaningful set of paths. Example:

restic backup /etc /home --exclude /home/*/.cache

Run the same command again later and you’ll get an incremental snapshot: restic will upload only what changed. To see what was saved:

restic snapshots

To verify repository integrity (recommended after initial setup):

restic check

Step 5: Create a smart retention policy (forget + prune)

Backups are only useful if they don’t grow forever. Restic can enforce retention rules and remove unneeded data. A common policy is: keep daily backups for 7 days, weekly for 4 weeks, and monthly for 12 months:

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

The --prune flag actually removes unreferenced data, reclaiming space in the S3 bucket.

Step 6: Automate backups with systemd (service + timer)

For reliable automation, use a systemd timer instead of cron. Create an environment file that root can read, for example:

sudo nano /etc/restic.env

Add:

AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY

AWS_SECRET_ACCESS_KEY=YOUR_SECRET_KEY

AWS_DEFAULT_REGION=us-east-1

RESTIC_REPOSITORY=s3:https://s3.example.com/my-restic-bucket

RESTIC_PASSWORD=YOUR_STRONG_REPO_PASSWORD

Now create the service unit:

sudo nano /etc/systemd/system/restic-backup.service

Example content:

[Unit]
Description=Restic Backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic.env
ExecStart=/usr/bin/restic backup /etc /home --exclude /home/*/.cache
ExecStartPost=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

[Install]
WantedBy=multi-user.target

Create the timer:

sudo nano /etc/systemd/system/restic-backup.timer

Example content:

[Unit]
Description=Run Restic Backup Daily

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Enable and start:

sudo systemctl daemon-reload

sudo systemctl enable --now restic-backup.timer

Check status and logs:

systemctl list-timers | grep restic

journalctl -u restic-backup.service -e

Step 7: Test a restore (don’t skip this)

A backup you haven’t restored from is just a hope. List snapshots, pick one, then restore to a temporary directory:

restic snapshots

restic restore latest --target /tmp/restic-restore-test

To restore a single file or folder, you can use restic dump or browse snapshots with restic ls to find the path.

Practical notes for servers and databases

If you back up database files directly (like PostgreSQL under /var/lib/postgresql), you risk capturing inconsistent data. Prefer application-aware backups: use pg_dump for PostgreSQL, mysqldump for MySQL/MariaDB, or filesystem snapshots (LVM/ZFS) followed by restic. Also exclude large volatile paths such as caches, build folders, and container image layers unless you truly need them.

Conclusion

With restic and S3-compatible storage, you get fast incremental backups, strong encryption, simple retention rules, and clean automation through systemd timers. Once you’ve tested restores and verified the schedule, you’ll have a backup system that behaves like a reliable utility: quiet when it works, loud when it fails, and easy to trust when disaster strikes.

Why Restic + S3 Is a Smart Backup Combo

If you want a modern Linux backup solution that is fast, encrypted by default, and easy to automate, restic is one of the best tools available today. It creates deduplicated, incremental snapshots, so repeated backups are much smaller than full copies. Pairing restic with an S3-compatible object storage (such as MinIO, Backblaze B2 S3, Wasabi, or a private S3 gateway) gives you reliable offsite storage without managing a traditional backup server.

In this tutorial, you will set up restic on Linux, connect it to an S3-compatible destination using environment variables, run your first backup, verify it, and schedule it with systemd. The steps are designed to be practical for a workstation or a small server.

Prerequisites

You will need: a Linux machine (Ubuntu/Debian/RHEL-based are fine), access keys for an S3-compatible bucket, outbound internet access (or network access to your S3 endpoint), and a user account with permission to read the folders you plan to back up. Choose a directory to store your restic password securely (or use a password manager and a root-only file).

Step 1: Install Restic (and Rclone if Needed)

On Ubuntu/Debian, install restic with:

sudo apt update && sudo apt install -y restic

On RHEL/CentOS/Fedora, you can use your distribution repositories or install a package from your vendor. If you prefer a consistent version everywhere, you can also download the official restic release binary from the project site and place it in /usr/local/bin.

Restic can speak to S3 directly, so rclone is optional. However, rclone is useful if you want a single configuration tool for many cloud backends or if your environment already relies on it. If you want it:

sudo apt install -y rclone

Step 2: Create Your Bucket and Gather S3 Settings

Create a bucket in your S3-compatible storage, for example my-linux-backups. Collect these values: Access Key, Secret Key, Bucket name, Region (if required), and the S3 endpoint URL. For AWS S3, the endpoint is usually implicit; for MinIO or other providers, you will typically use something like https://s3.example.com.

Step 3: Set Restic Environment Variables

Restic reads credentials from environment variables. Create a root-only file to store them. This approach avoids leaving secrets in shell history and makes automation easier.

Create /etc/restic/env:

sudo mkdir -p /etc/restic
sudo nano /etc/restic/env

Add the following (adjust values to your provider):

export RESTIC_REPOSITORY="s3:https://s3.example.com/my-linux-backups"
export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"
export AWS_DEFAULT_REGION="us-east-1"

Now create a password file for the repository encryption key:

sudo nano /etc/restic/password

Put a long passphrase on a single line, then lock down permissions:

sudo chmod 600 /etc/restic/env /etc/restic/password

Step 4: Initialize the Restic Repository

Load the environment variables and initialize the repo:

source /etc/restic/env
sudo RESTIC_PASSWORD_FILE=/etc/restic/password restic init

If everything is correct, restic will create the repository structure in the bucket and confirm initialization. If you see endpoint or TLS errors, double-check the endpoint URL and whether your provider requires a specific region.

Step 5: Run Your First Backup (Incremental by Default)

Choose what to back up. A common starting point is /home plus important configuration under /etc. You should exclude cache folders and other noise to keep snapshots clean.

Create an exclude file:

sudo nano /etc/restic/excludes

Example excludes:

*/.cache
*/Downloads
/var/tmp
/tmp

Run the backup:

source /etc/restic/env
sudo RESTIC_PASSWORD_FILE=/etc/restic/password restic backup /home /etc --exclude-file=/etc/restic/excludes

The next time you run the same command, restic will automatically create an incremental snapshot and upload only new or changed data blocks. This is where deduplication saves both time and storage.

Step 6: Verify and Test a Restore

A backup you never tested is not a strategy. List snapshots:

source /etc/restic/env
sudo RESTIC_PASSWORD_FILE=/etc/restic/password restic snapshots

Check repository consistency (run occasionally, not every hour):

sudo RESTIC_PASSWORD_FILE=/etc/restic/password restic check

To restore a single file safely, restore into a temporary directory first:

sudo mkdir -p /restore-test
sudo RESTIC_PASSWORD_FILE=/etc/restic/password restic restore latest --target /restore-test --include /etc/hosts

Confirm the file is correct, then copy it to the desired location if needed.

Step 7: Set a Retention Policy (Forget + Prune)

Backups grow over time unless you define retention. A practical policy keeps daily snapshots for a week, weekly for a month, and monthly for a year:

source /etc/restic/env
sudo RESTIC_PASSWORD_FILE=/etc/restic/password restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

The --prune step removes unneeded data blocks so your S3 storage usage stays under control.

Step 8: Automate Backups with systemd

Create a simple script so the job is repeatable. Create /usr/local/sbin/restic-backup.sh:

sudo nano /usr/local/sbin/restic-backup.sh

Add:

#!/bin/sh
set -eu
. /etc/restic/env
export RESTIC_PASSWORD_FILE=/etc/restic/password
restic backup /home /etc --exclude-file=/etc/restic/excludes
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

Make it executable:

sudo chmod 750 /usr/local/sbin/restic-backup.sh

Now create a systemd service /etc/systemd/system/restic-backup.service:

[Unit]
Description=Restic Backup

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-backup.sh

And a timer /etc/systemd/system/restic-backup.timer to run daily:

[Unit]
Description=Daily Restic Backup

[Timer]
OnCalendar=daily
Persistent=true

[Install]
WantedBy=timers.target

Enable the timer:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

You can confirm runs with:

systemctl list-timers --all | grep restic

Final Tips for Reliable Offsite Backups

Keep your restic password file protected, and consider storing a sealed copy in a secure vault so you are not locked out during an emergency. If you are backing up a server with databases, add application-aware steps (such as dumping PostgreSQL or MySQL) before running restic. Most importantly, schedule a recurring restore test so you know the entire chain works—from Linux to S3 and back.