Why Restic + Object Storage Is a Modern Backup Strategy
Traditional file copy backups are easy to set up, but they are also easy to destroy. If ransomware encrypts your server or a compromised account deletes local snapshots, a “backup” stored on the same machine is usually gone. A more resilient approach is to use encrypted, deduplicated backups pushed to remote object storage (S3-compatible services like MinIO, Wasabi, Backblaze B2 S3, or AWS S3). In this tutorial, you will configure Restic on Linux to back up important folders to an S3 bucket, verify restores, and automate everything with a systemd timer.
What You Need
You will need a Linux server (Ubuntu/Debian/RHEL-based), outbound HTTPS access to your object storage endpoint, and credentials for an S3-compatible bucket. It is strongly recommended to use a dedicated bucket (or dedicated prefix) per server. You should also decide which paths to back up (for example: /etc, /home, application config, and data directories) and which directories to exclude (cache, node_modules, temporary files, and large rebuildable artifacts).
Step 1: Install Restic
On Ubuntu or Debian, install Restic from the package manager:
sudo apt update && sudo apt install -y restic
On RHEL/CentOS/AlmaLinux/Rocky, Restic is commonly available via EPEL:
sudo dnf install -y epel-release && sudo dnf install -y restic
Step 2: Prepare S3 Environment Variables
Restic uses environment variables for S3 authentication. Create a protected file so you do not store secrets in shell history. This example uses an S3-compatible endpoint (change values to match your provider):
sudo install -m 600 -o root -g root /dev/null /etc/restic.env
Edit /etc/restic.env and add:
export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"
export RESTIC_PASSWORD="USE_A_LONG_UNIQUE_PASSPHRASE"
export RESTIC_REPOSITORY="s3:https://s3.example.com/your-bucket/your-hostname"
export AWS_DEFAULT_REGION="us-east-1"
If you are using AWS S3 itself, your repository line may look like:
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/your-bucket/your-hostname"
Step 3: Initialize the Repository
Load the environment file and initialize the repo. The repository will be encrypted using the password you set:
sudo bash -c 'source /etc/restic.env && restic init'
If you see “created restic repository,” you are ready to back up. If you get TLS or endpoint errors, re-check the endpoint URL and whether your provider requires a specific region or hostname style.
Step 4: Run Your First Backup (with Practical Excludes)
Start with a focused set of folders. Backing up everything under / is rarely ideal because it includes virtual filesystems and caches. Create an excludes file:
sudo install -m 644 /dev/null /etc/restic-excludes.txt
Add common excludes (customize as needed):
/proc
/sys
/dev
/run
/tmp
/var/tmp
/var/cache
/var/log/journal
Run a backup of key paths:
sudo bash -c 'source /etc/restic.env && restic backup /etc /home /var/www --exclude-file /etc/restic-excludes.txt --tag daily'
Restic performs deduplication automatically, so future backups are usually fast and storage-efficient.
Step 5: Verify Snapshots and Test a Restore
A backup is only useful if you can restore it. List snapshots:
sudo bash -c 'source /etc/restic.env && restic snapshots'
To test restoring a single file or folder safely, restore into a temporary directory:
sudo mkdir -p /restore-test
sudo bash -c 'source /etc/restic.env && restic restore latest --target /restore-test --include /etc/ssh'
Confirm files are present, then remove the test directory when you are satisfied.
Step 6: Add Maintenance: Forget and Prune
Without retention rules, backups will grow forever. Restic separates “forget” (remove snapshot references) from “prune” (actually remove unneeded data). A common policy keeps daily backups for two weeks, weekly backups for two months, and monthly backups for a year:
sudo bash -c 'source /etc/restic.env && restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune'
Also schedule occasional integrity checks (for example weekly):
sudo bash -c 'source /etc/restic.env && restic check'
Step 7: Automate with systemd (Safer Than Cron)
Systemd timers provide better logging and predictable behavior. Create a script:
sudo install -m 700 /dev/null /usr/local/sbin/restic-backup.sh
Edit /usr/local/sbin/restic-backup.sh:
#!/bin/bash
set -euo pipefail
source /etc/restic.env
restic backup /etc /home /var/www --exclude-file /etc/restic-excludes.txt --tag daily
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune
Create a service unit at /etc/systemd/system/restic-backup.service:
[Unit]
Description=Restic Backup to S3
[Service]
Type=oneshot
ExecStart=/usr/local/sbin/restic-backup.sh
Create a timer at /etc/systemd/system/restic-backup.timer:
[Unit]
Description=Daily Restic Backup Timer
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target
Enable and start the timer:
sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
Check status and logs:
sudo systemctl list-timers | grep restic
sudo journalctl -u restic-backup.service --since today
Final Hardening Tips
For better ransomware resistance, use credentials with the minimum required permissions (write, list, and read for restores), and consider an object storage feature like bucket versioning or object lock if your provider supports it. Keep the Restic password in a secure secrets manager when possible, and document your restore steps so you can recover quickly during an incident. With encrypted offsite backups and regular restore tests, you move from “we have backups” to “we can reliably recover.”
Comments
Post a Comment