Set Up Automatic Incremental Backups on Linux with Restic and S3-Compatible Storage

on

Why Restic Is a Smart Backup Tool in 2026

Backups are one of those tasks everyone agrees are important—right up until storage fills up, scripts break, or restore day arrives and nothing works. If you need a modern backup solution for Linux servers, laptops, or small business systems, restic is a strong choice. It is fast, encrypted by default, supports incremental snapshots, and works well with local disks, SSH targets, and S3-compatible object storage (such as MinIO, Backblaze B2 S3, Wasabi, or many private clouds).

This tutorial shows how to configure automatic incremental backups with restic to an S3-compatible bucket, keep backups clean with retention policies, and validate that restores actually work. The goal is a setup you can run unattended with systemd timers.

Prerequisites

Before you start, you’ll need a Linux system with root or sudo access, network connectivity to your S3 endpoint, and an S3 bucket created for backups. You should also have an access key and secret key for a user that can read and write that bucket. For best results, create a dedicated bucket and dedicated credentials only for backups.

Step 1: Install Restic

On Ubuntu/Debian, install from the package repository:

sudo apt update && sudo apt install -y restic

On RHEL/AlmaLinux/Rocky, restic may be available via EPEL, or you can install from an official release binary. If you install a binary, place it in /usr/local/bin/restic and ensure it’s executable.

Step 2: Prepare Environment Variables for S3

Restic reads S3 settings from environment variables. Create a root-only file to store them:

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

Add values like the following (adjust to your provider). The AWS_ENDPOINT_URL line is especially important for S3-compatible services:

export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"
export AWS_DEFAULT_REGION="us-east-1"
export AWS_ENDPOINT_URL="https://s3.your-provider.example"

Lock down permissions so only root can read it:

sudo chmod 600 /etc/restic/env

Step 3: Create and Initialize the Restic Repository

Decide where your repository will live. For S3, the syntax is s3:https://endpoint/bucketname or sometimes s3:bucketname depending on provider. A safe, explicit pattern for S3-compatible endpoints is:

export RESTIC_REPOSITORY="s3:https://s3.your-provider.example/my-linux-backups"

Set a strong repository password (store it securely). For unattended jobs, put it in a root-only file:

sudo nano /etc/restic/password

Add one line containing the password, then:

sudo chmod 600 /etc/restic/password

Initialize the repository:

sudo bash -c 'source /etc/restic/env && export RESTIC_PASSWORD_FILE=/etc/restic/password && export RESTIC_REPOSITORY="s3:https://s3.your-provider.example/my-linux-backups" && restic init'

Step 4: Run Your First Incremental Backup

Restic snapshots are incremental by design: after the first run, subsequent runs only transfer changed data. Start with a realistic set of folders. For a server, you might back up /etc, /home, and application data such as /srv. Avoid transient paths like /proc and /sys.

Example backup command:

sudo bash -c 'source /etc/restic/env && export RESTIC_PASSWORD_FILE=/etc/restic/password && export RESTIC_REPOSITORY="s3:https://s3.your-provider.example/my-linux-backups" && restic backup /etc /home /srv --exclude /home/*/.cache --exclude /srv/tmp'

List snapshots to confirm it worked:

sudo bash -c 'source /etc/restic/env && export RESTIC_PASSWORD_FILE=/etc/restic/password && export RESTIC_REPOSITORY="s3:https://s3.your-provider.example/my-linux-backups" && restic snapshots'

Step 5: Add Retention Rules (Forget + Prune)

Without retention, backups grow forever. A common policy is “keep daily backups for a week, weekly backups for a month, and monthly backups for a year.” Apply it like this:

sudo bash -c 'source /etc/restic/env && export RESTIC_PASSWORD_FILE=/etc/restic/password && export RESTIC_REPOSITORY="s3:https://s3.your-provider.example/my-linux-backups" && restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune'

The --prune option actually removes unreferenced data, keeping storage costs under control.

Step 6: Automate Backups with a Systemd Service and Timer

Create a simple backup script so the systemd unit stays clean:

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

Paste (adjust paths and repository):

#!/bin/bash
set -euo pipefail
source /etc/restic/env
export RESTIC_PASSWORD_FILE=/etc/restic/password
export RESTIC_REPOSITORY="s3:https://s3.your-provider.example/my-linux-backups"
restic backup /etc /home /srv --exclude /home/*/.cache --exclude /srv/tmp
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check

Make it executable:

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

Now create the systemd service:

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

Service content:

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

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

Create the timer (daily at 02:15):

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

Timer content:

[Unit]
Description=Run Restic Backup Daily

[Timer]
OnCalendar=*-*-* 02:15:00
Persistent=true

[Install]
WantedBy=timers.target

Enable it:

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

Check status and recent runs:

systemctl status restic-backup.timer
journalctl -u restic-backup.service --since "2 days ago"

Step 7: Test a Restore (The Part Most People Skip)

A backup you never test is just a theory. Create a restore directory and restore a single file or folder to verify permissions and content:

sudo mkdir -p /restore-test
sudo bash -c 'source /etc/restic/env && export RESTIC_PASSWORD_FILE=/etc/restic/password && export RESTIC_REPOSITORY="s3:https://s3.your-provider.example/my-linux-backups" && restic restore latest --target /restore-test --include /etc/ssh'

Confirm the restored files exist under /restore-test. If you can restore cleanly, you can trust the automation far more.

Final Notes for a Reliable Backup Routine

For production systems, keep the repository password in a secure vault when possible, restrict bucket permissions, and consider enabling object-lock or versioning if your provider supports it. Restic’s encryption and incremental design make it efficient, but the real win is consistency: automated snapshots, retention rules, and periodic restore tests turn backups into a predictable safety net instead of a last-minute panic.

Comments

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

Install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Overview Running a local large language model (LLM) is easier than ever thanks to Ollama and Open WebUI. Ollama handles model downloads and inference, while Open WebUI gives you a clean, chat-style interface in your browser. In this tutorial, you'll install both on Ubuntu 24.04 (works on 22.04 too), enable NVIDIA GPU acceleration, and deploy them with Docker Compose. The result is a fast, private AI stack you control. What You'll Need - Ubuntu 24.04 or 22.04 (fresh or existing server/desktop). - An NVIDIA GPU with recent drivers (Turing/RTX or newer recommended). - Root or sudo access. - Open ports 3000 (Open WebUI) and 11434 (Ollama) on your firewall if you access remotely. Step 1: Install NVIDIA Drivers and Verify CUDA First, update your system and install the recommended NVIDIA driver. On Ubuntu Desktop you can use Additional Drivers, but the CLI route is reliable: sudo apt update && sudo apt -y upgrade sudo ubuntu-drivers autoinstall sudo reboot After reboo...

Install a Local AI Chatbot on Ubuntu 24.04 with Ollama and Open WebUI (Step-by-Step)

Running a fast, private AI chatbot on your own computer or server is easier than ever. In this guide, you will install Ollama (a lightweight local LLM runtime) and Open WebUI (a modern web interface) on Ubuntu 24.04 . You will be able to chat with models like Llama 3 or Mistral without sending data to the cloud, and with optional GPU acceleration if you have an NVIDIA card. What you will need : an Ubuntu 22.04/24.04 machine (VM, bare metal, or WSL), at least 8 GB RAM (16 GB recommended for larger models), 15–30 GB free disk space for models, Internet access, and optional NVIDIA GPU drivers for acceleration. Why Ollama + Open WebUI? Ollama manages local large language models (LLMs) with simple commands and sensible defaults. Open WebUI gives you a clean, chat-style interface with features like prompt history, file uploads (for some models), and model switching. Together, they are a simple, reliable stack for a self-hosted AI experience. 1) Update Ubuntu and install basics First, ...

Install Ollama + Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Overview This guide shows you how to install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU acceleration. You will get a fast local AI stack that can run modern large language models (LLMs) like Llama 3 on your own hardware, secured and accessible in a web browser. We will cover GPU driver setup, Docker with the NVIDIA Container Toolkit, Ollama installation, Open WebUI deployment, basic security, and troubleshooting. Prerequisites - A machine running Ubuntu 24.04 (fresh or updated). - An NVIDIA GPU with at least 8 GB VRAM recommended for 8B models (more is better). - Internet access and sudo privileges. Step 1: Install the NVIDIA GPU Driver Install the recommended proprietary driver so CUDA becomes available to both Ollama and containers. sudo apt update && sudo apt install -y ubuntu-drivers-common sudo ubuntu-drivers autoinstall sudo reboot After reboot, verify the GPU is recognized: nvidia-smi You should see a driver version and your GPU model. If not, check...

Trending Now

Homogeneous Nucleation on Mars: A Textbook Process Finally Observed in Nature

on
By the end of this piece, you will understand what the Arsia Mons Elongated Cloud is, why it resisted explanation for several years after its first observation, and what the newly published model reveals about a physical process that has never been directly confirmed on any planet's atmosphere. The cloud that broke the model Every morning during Martian spring and summer, a thin, extremely long cloud forms near the Arsia Mons volcano and gradually elongates until it stretches to more than 1,000 miles before dissipating. The cycle then repeats for several months. The formation was first recorded by a probe in 2018, and from that point onward it became a persistent puzzle for atmospheric scientists working with Mars data. The cloud's geometry, its timing, and its seasonal recurrence all pointed to a real and reproducible physical process, yet no existing model could reproduce it. For a technical audience familiar with simulation work, the situation is analogous to a product...