Every sysadmin has a backup script. Almost none of them has a restore story. Here's how to fix that in one sitting with Restic.

Somewhere in your home directory — or on a VPS you pay for every month — sits a cron job called backup.sh. It has been running for months. Nobody has looked at its output. Nobody knows if the archive it produces can actually be opened.

That script is not a backup plan. It is a superstition.

A backup only exists when you have proven it can be restored. Everything else is a ritual performed against misfortune. So this article does the thing most backup tutorials skip: we will set up a real, encrypted, off-site-capable backup with Restic — and then immediately break something and restore it, on purpose.

Why Restic, of all the backup tools

The Linux world is not short on backup tools: rsync scripts, Borg, duplicity, the tar-and-pray classics. Restic earns its place for three practical reasons. First, encryption is the default, not an afterthought — every repository is encrypted with a key derived from your passphrase, so it is safe to push into cloud storage you don't fully control. Second, it deduplicates across snapshots, so daily backups of a 40 GB server cost barely more than one full copy. Third, one static binary does everything; there is no daemon to babysit and no database server to corrupt.

Install it from your package manager — pacman -S restic, apt install restic, dnf install restic — or grab the static binary from the official releases page.

Init, then your first snapshot

Point Restic at a repository. For local practice, a USB drive or a directory works. For real backups, use S3-compatible storage, Backblaze B2, or an SSH/SFTP server:

export RESTIC_PASSWORD="a-long-passphrase-you-actually-wrote-down"
export RESTIC_REPOSITORY="s3:s3.amazonaws.com/my-bucket/restic-backups"
restic init

Then take your first snapshot of the things that matter — home directories, /etc, your app data — excluding the noise:

restic backup ~ --exclude=".cache" --exclude="node_modules"

That command alone is already better than most setups in the wild: encrypted, deduplicated, incremental from the second run onward.

Automate it with a systemd timer

A backup that depends on you remembering is a backup that will not happen. Add a simple systemd timer (or a cron entry if that is your religion) that runs nightly and keeps a log:

restic backup ~ --exclude=".cache" 2>>/var/log/restic-backup.log

Set up retention with a forget policy so old snapshots don't eat your storage:

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

This keeps a rolling window: seven daily, four weekly, six monthly snapshots. Adjust the numbers to how much history you can afford.

The restore drill — the actual point

Here is where the article earns its title. Create a scratch directory and restore a file from yesterday's snapshot:

mkdir -p /tmp/restore-test
restic restore latest --target /tmp/restore-test
diff -r /tmp/restore-test/home/you/documents ~/documents

If the diff comes back clean, congratulations: you now have something most backup scripts never achieve — proof. Run this drill monthly, ideally on a different machine. The day you need a restore for real is the worst possible time to discover your repository is corrupted, your passphrase is lost, or your storage credentials expired six months ago.

Store the passphrase in your password manager — KeePassXC, Aegis, whatever you trust — not in a sticky note, not in the same machine you are backing up.

The takeaway

Backups are not a storage problem. They are a confidence problem, and confidence comes only from rehearsals. Twenty-five minutes of setup, one restore drill, and you will sleep better than every sysadmin whose cron job has been "running fine" for two years untouched.

Sources: Restic official documentation · Restic on GitHub · systemd.timer documentation