Encrypted Backup with Restic: Repo Design and Recovery Drill

Restic is an open-source backup solution that combines data integrity and encryption into a single tool. In this article, I will walk you through every step, from setting up an encrypted repository to scheduling daily backups, followed by a real-world recovery drill. At each step, you will see Ansible automation, terminal outputs, and verification procedures.

Repo Design

Restic stores backups inside a "repo"; this repository can be any filesystem, cloud storage, or a remote server accessible over SSH. When initializing the repository, an encryption key (PASSPHRASE) is specified, and storing this key securely is a critical step.

export RESTIC_REPOSITORY=ssh://user@backup.example.com:/home/user/restic
export RESTIC_PASSWORD_FILE=/etc/restic/passphrase

These environment variables are automatically configured using the setenv module in the Ansible playbook.

Callout:
The encryption key is stored exclusively inside RESTIC_PASSWORD_FILE; it should never be left anywhere as plaintext.

Encryption Strategies

Restic offers two main strategies when managing an encrypted repository:

1. Key Forwarding / Management – You can view existing keys with restic key list and add a new key using restic key add. This allows defining separate passwords for multiple access points.
2. Key Rotation – The restic key rotate command removes the old key and re-encrypts metadata with a new encryption key. This is strongly recommended for long-term security.

# Listing keys
restic key list

# Adding a new key
restic key add --key-file /tmp/newkey

# Key rotation
restic key rotate

Callout:
The key rotation process ensures that old backups remain accessible with the new key; otherwise, older data would stay locked out.

Automated Setup with Ansible

The mafalb.restic Ansible role automates Restic installation and repo configuration. The following playbook installs Restic on an Ubuntu 24.04 host, sets environment variables, and initializes the repository.

- hosts: backup_servers
  become: true
  vars:
    restic_repo: "ssh://backup@example.com:/var/lib/restic"
    restic_passphrase: "{{ lookup('file', '/etc/restic/passphrase') }}"
  roles:
    - mafalb.restic
  tasks:
    - name: Set environment variables
      ansible.builtin.set_fact:
        restic_env:
          RESTIC_REPOSITORY: "{{ restic_repo }}"
          RESTIC_PASSWORD_FILE: "/etc/restic/passphrase"

This role installs the restic package, places the restic binary under /usr/local/bin, and sets up the systemd service.

Callout:
Before running the Ansible playbook, ensure that the /etc/restic/passphrase file is populated with the correct password.

Daily Backup Routine

The backup routine is scheduled to run at 23:00 via cron. Here is an example crontab entry:

0 23 * * * /usr/local/bin/restic backup /etc /home /var/log \
  --exclude-dir=/home/user/Downloads \
  --exclude-file=/etc/restic/exclude.txt \
  >> /var/log/restic/backup.log 2>&1

This command backs up /etc, /home, and /var/log directories, excludes the Downloads folder, and writes logs to the backup.log file.

# Sample terminal output
restic backup /etc /home /var/log
[2026-08-24 23:00:00] Restic 0.16.4
[2026-08-24 23:00:00] Backup finished: 1 file, 0 directories
[2026-08-24 23:00:01] 1.2 GiB written

Callout:
The --exclude-dir and --exclude-file options prevent unnecessary files from being backed up and shorten the overall backup duration.

Disaster Recovery Drill Scenario

The recovery drill simulates an actual disaster scenario. Example scenario: critical configuration files inside the /home/user folder become corrupted. Recovery steps:

1. Finding the latest snapshot:

   restic snapshots | grep '2026-08-23' | head -n 1
   # Sample output:
   # 1234abcd  2026-08-23T23:00:00Z  /home/user

1. Restoring the snapshot to the target folder:

   restic restore 1234abcd --target /tmp/restore_home

1. Checking file integrity:

   diff -rq /home/user /tmp/restore_home

1. Overwriting with the restored state via rsync if necessary:

   rsync -a /tmp/restore_home/ /home/user/

Verification

The restic check command verifies backup integrity:

restic check --verify-full
[2026-08-24 23:05:00] Restic 0.16.4
[2026-08-24 23:05:01] Checking snapshots
[2026-08-24 23:05:02] All checks passed

This step verifies that file hashes match expected values. If an issue is detected, you can roll back to an earlier snapshot using restic restore.

Callout:
A recovery drill guarantees not only that data can be retrieved, but also that its integrity has been preserved.

Edge Cases and Trade-Offs

Callout:
Encryption key management is the most critical component of a backup strategy. Key rotation and secure storage prevent unrecoverable data loss.

Prerequisites and Actionable Steps

Before setting up an encrypted backup environment with Restic, several fundamental prerequisites must be met. First, Ubuntu 24.04 (or an equivalent LTS-based distribution) must have Restic 0.16.4 or newer installed. You can check the version as follows:

restic version
# output:
# restic 0.16.4 compiled with go1.22.0 on linux/amd64

Second, your SSH key must be added to the backup server with fingerprint verification; otherwise, you will encounter a "host key verification failed" error during the ssh connection. Third, the encryption passphrase should be stored within a secret management system (such as HashiCorp Vault) and read exclusively via the RESTIC_PASSWORD_FILE environment variable. Once these three conditions are satisfied, you can create the repository with the following steps:

1. Install the Restic package using the system package manager.
2. Test the SSH connection (ssh -i /root/.ssh/id_rsa backup@example.com true).
3. Initialize the repo and take the first snapshot.

# 1. Restic installation
apt-get update && apt-get install -y restic

# 2. Initializing repo
export RESTIC_REPOSITORY="ssh://backup@example.com:/var/lib/restic"
export RESTIC_PASSWORD_FILE="/etc/restic/passphrase"
restic init
# output:
# created restic repository 2c6e2f1c at ssh://backup@example.com:/var/lib/restic

Preferring a systemd-timer over cron for scheduled backups eliminates timezone and environment variable issues. The following restic-backup.service and restic-backup.timer files are configured to back up /etc, /home, and /var/log directories every day at 02:00:

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic backup service
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/env
ExecStart=/usr/local/bin/restic backup /etc /home /var/log \
  --exclude-dir=/home/*/Downloads \
  --exclude-file=/etc/restic/exclude.txt \
  --tag daily

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run Restic backup daily at 02:00

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

[Install]
WantedBy=timers.target

This setup enables the service and timer, starting the automated backup cycle:

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

These steps form the core of the "Prerequisites and Actionable Steps" workflow; ensuring each step succeeds guarantees a solid foundation for subsequent verification and recovery phases.

Verification, Error Handling, and Rollback

Periodically verifying backup integrity is critical for catching potential data corruptions early. The most common verification command is restic check --verify-full; this recalculates the hash values of all snapshots and compares them against the stored repository blocks. In an actual incident, a backup failed to complete due to an overnight network outage, resulting in an error like this:

# Command at the time of error
restic check --verify-full
# output:
# [2026-08-24 03:05:01] Checking snapshots
# [2026-08-24 03:05:02] error: data corruption detected in snapshot 7f3a1c2d
# [2026-08-24 03:05:02] aborting check due to errors

This error also surfaces in the restic snapshots output, marking the corrupted snapshot ID as 7f3a1c2d. The error handling procedure involves the following steps:

1. Isolate the corrupted snapshot – Remove the target snapshot using restic forget, then clean up repository references with restic prune.
2. Restore from the latest healthy snapshot – Run restic restore <good-id> --target /tmp/restore.
3. Application-level synchronization – Transfer the restored files back to their original location using rsync.

# 1. Forget corrupted snapshot
restic forget 7f3a1c2d --prune

# 2. Latest healthy snapshot ID (e.g., a1b2c3d4)
restic restore a1b2c3d4 --target /tmp/restore_home

# 3. Copy files back to original
rsync -a /tmp/restore_home/ /home/user/

Once completed, the rollback succeeds and the system returns to its prior consistent state. For monitoring purposes, generating a JSON-formatted alert payload whenever restic backup runs allows forwarding metrics to a centralized log aggregator (such as Loki). Below is a sample alert payload:

{
  "backup_id": "2026-08-23T02:00:00Z",
  "status": "failed",
  "error": "data corruption detected in snapshot 7f3a1c2d",
  "host": "backup01.example.com"
}

This payload can be routed via Prometheus Alertmanager directly to a Slack or Teams channel, enabling operators to intervene immediately. Verification, error handling, and rollback steps are systematically defined under this workflow.

Trade-off Gaps and Optimization Opportunities

When designing an encrypted backup architecture, several trade-offs emerge between performance, cost, and security. The table below summarizes the most common trade-offs and recommended optimization strategies:

Testing one of these optimizations in a real environment, recording the measurements, and factoring them into decision-making is essential. The Mermaid diagram below shows a typical Restic backup flow and its decision points:

In this diagram, selecting the "Block Size" directly impacts network transfer and CPU load, so an optimal value should be determined based on available bandwidth and compute capacity. Bridging trade-off gaps boosts system performance while sustaining the required security level, ensuring long-term sustainability for your backup strategy.

Conclusion

Restic brings encryption, integrity verification, and version control together in a single tool. Automating it with Ansible eliminates configuration errors. Daily scheduled backups and routine recovery drills minimize data loss risks. Storing encryption keys securely and rotating them periodically ensures long-term protection. By applying the steps in this guide, you can reliably back up your organization's critical data and restore it quickly during any disaster.

Official Sources

• Ansible Galaxy - mafalb.restic
• Releases · restic/restic · GitHub
• GitHub | restic/restic: Fast, Secure, Efficient Backup Program · GitHub