How to Use Restic: The Beginner's Guide (First Repository, First Snapshot, the Escrow Rule, and the Test-Restore Habit)

CodexFuse Team · 2026-10-31T09:35:00.000Z · 4 min read min read

A complete beginner's guide to Restic: encrypted snapshots, the password-escrow rule, your first repository, retention with forget --prune, automation, and the test-restore habit.

How to Use Restic: The Beginner's Guide

Learning how to use Restic is the step that turns "I have backups" into "I can actually get my data back." Restic is a free, open-source backup program that encrypts everything before it leaves your machine, stores every backup as a snapshot you can browse and restore individually, and sends those snapshots to almost any storage you already own — a local disk, an SFTP server, or any S3-compatible object storage. This restic tutorial runs the full beginner arc in one place: installing Restic, writing down your repository password before you run a single command (the rule that decides whether your backups survive), creating your first repository, taking your first snapshot, setting a retention policy, automating the whole thing on a schedule, and — the step most tutorials skip — proving the backup works by restoring from it.

If you have been copying files with rsync, read our rsync beginner guide first to understand the sync lane — mirroring today's files somewhere else. Restic is the backup lane: encrypted, versioned snapshots with history. Different job, different tool, and you will want both.

What Is Restic, and Why Is It Not Just Another File Copy?

Restic is a backup program that stores encrypted, deduplicated snapshots of your files in a repository, instead of copying files from A to B. A file copy mirrors the present moment; a Restic repository preserves every past moment you choose to keep, and every snapshot is encrypted with a key derived from your password before it touches the storage. If you delete a file today, a copy made today loses it too — a Restic snapshot from last week still has it.

Three design choices make Restic the tool it is. First, encryption is the default, not an afterthought: every repository is encrypted, so it is safe to push your backups into cloud storage you do not fully control. Second, it deduplicates across snapshots: unchanged data is stored once, so daily backups of a server cost barely more storage than a single full copy. Third, the whole program is one static binary — there is no daemon to babysit and no database server to corrupt. Learn three words and you understand the system: the repository is where backups live, a snapshot is one backup taken at one moment in time, and a backend is the storage the repository sits on — local disk, SFTP, S3, or a REST server.

How Do You Use Restic for the First Time?

Here is the complete Restic for beginners first-use arc in seven steps. Each of the sections below teaches one of these steps in detail — run them in this order.

  1. Decide where the repository lives — local disk for practice, SFTP or S3-compatible storage for real off-site backups.
  2. Generate the repository password and store it in two places — a password manager and a sealed offline copy. Do this before any command; a lost password means an unrecoverable repository.
  3. Install Restic — one package-manager command, or the official static binary.
  4. Initialize the repository — restic init, which creates the encrypted repository at the location you chose.
  5. Take your first backup — restic backup on the directories that matter, with an exclude file for caches.
  6. Set a retention policy — restic forget --prune with keep rules, so old snapshots are removed on a schedule instead of accumulating forever.
  7. Restore something on purpose — restic restore latest --target /tmp/restore-test. A backup only exists once you have proven it can be restored.

How Do You Install Restic on Your System?

Restic installs with one command on every platform a beginner is likely to use. On Debian or Ubuntu it is sudo apt install -y restic; on Fedora or RHEL derivatives it is sudo dnf install -y restic (EPEL on RHEL); on macOS it is brew install restic; on Windows it is winget install --exact --id restic.restic --scope Machine or scoop install restic. If your distro's package lags behind, grab the official static binary from the restic release page instead — it needs no installation, and once installed it can update itself in place with restic self-update. Confirm with restic version: as of this writing the current stable line is v0.19.1, released July 2026.

Why Can Nobody Recover Your Restic Repository Password?

Nobody can recover your Restic repository password — not the Restic developers, not your hosting provider, and not anyone who holds a copy of the repository. Everything in the repository is encrypted with keys derived from your passphrase, so without it the data is unreadable, full stop. The official documentation states it plainly: losing your password means your data is irrecoverably lost. That is the price of encryption that the storage host cannot defeat.

Treat the password as the single most important object in the backup system. Generate a long random passphrase with your password manager, and keep a sealed offline copy — printed and stored somewhere safe — as escrow. Then teach Restic where the password lives without typing it into every command: store it in a file only root can read, for example umask 077; echo "your-long-passphrase" > /root/.restic-pass, and point Restic at it with the RESTIC_PASSWORD_FILE environment variable. Never commit the password file to version control, and never paste it into chat logs or support tickets. Do this step first, before restic init — a repository created without the password safely stored is a repository you are one forgotten string away from losing.

Where Should Your Restic Repository Live?

The right backend depends on what failure you are afraid of. If the server itself dies, a repository on the same disk dies with it — so a backup that never leaves the machine is only protection against your own mistakes, not hardware loss. Use this decision table to pick:

BackendBest forOff-site?What it needs
Local disk / USB driveLearning the workflow; second copy of critical filesNoNothing — just a directory
SFTP serverBacking up one server to another server you controlYesSSH key authentication set up beforehand
S3-compatible storage (MinIO, Backblaze B2, Wasabi)Cheap, durable off-site backups for anythingYesBucket name + access key + secret key
restic REST serverAppend-only setups where clients should never deleteYesA REST server instance you run

For a first real backup, S3-compatible storage is the easiest off-site answer: you get durability and versioning on the storage side while Restic supplies the encryption and snapshot history. A common beginner pattern is a local repository for fast restores plus an S3 repository for disaster recovery — the two jobs are separate and Restic handles both with the same commands.

How Do You Create Your First Restic Repository?

You create a repository with restic init, after telling Restic where the repository lives and where the password file is. Set the two environment variables once per session — or better, in the script that will run your backups — and the rest of the commands stay short:

export RESTIC_REPOSITORY=/srv/restic-repo
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init

Restic asks you to enter the password twice and then creates the repository, printing a short repository ID. For remote storage, the repository location becomes a URL: restic -r sftp:user@host:/srv/restic-repo init for SFTP, or restic -r s3:https://server:port/bucket_name init for S3-compatible storage with your access keys exported. Repositories created today use repository format version 2, which supports compression — one less thing to configure. Run restic check after init to confirm the repository is healthy before you trust it with data.

How Do You Take Your First Restic Backup?

You take a backup with restic backup followed by the paths that matter. With the environment variables from the previous section set, the first real backup looks like this:

restic backup /etc /srv/app --exclude-caches --exclude-file=/root/restic-excludes.txt

Restic walks the paths, splits the data into chunks, encrypts each chunk, stores only the chunks it has never seen before, and records the whole run as one snapshot. The --exclude-caches flag skips directories marked as caches (browser caches, package caches), and the exclude file lists paths you never want backed up — logs, temp files, the repository itself if it sits on the same machine. Run restic snapshots afterwards to see your first snapshot listed with its time, hostname, and paths.

One rule is load-bearing for servers: file-level backups of live databases are not consistent. Dump the database first — pg_dump for Postgres, mysqldump for MySQL — and back up the dump file. A snapshot of a database's data files mid-write can restore into a corrupted state, and no backup tool fixes that for you.

How Do You Point Restic at S3-Compatible Storage?

This Restic S3 pattern is identical for AWS S3, Backblaze B2, Wasabi, or a MinIO server you run yourself — only the endpoint changes:

export AWS_ACCESS_KEY_ID="your-access-key"
export AWS_SECRET_ACCESS_KEY="your-secret-key"
export RESTIC_REPOSITORY="s3:https://s3.us-east-1.amazonaws.com/my-backup-bucket"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic init
restic backup /etc /srv/app

For a non-Amazon endpoint such as MinIO, the URL becomes s3:https://minio.example.com:9000/my-backup-bucket; if the bucket does not exist yet, Restic creates it. If you run your own object storage, our MinIO beginner guide walks through setting up the server that this backup targets. Note that Restic expects path-style URLs for Amazon endpoints — virtual-hosted-style bucket hostnames are not supported and must be converted.

How Do You Back Up Over SFTP With Restic?

You back up over SFTP by using an sftp: repository URL, after setting up SSH key authentication to the target server. The init looks like the official docs' example: restic -r sftp:user@host:/srv/restic-repo init, and every later command uses the same -r value. Passwordless key-based login is not optional here — it is what makes unattended, scheduled backups possible, since an automated run cannot answer an SSH password prompt.

Tag your snapshots so the SFTP side stays readable: restic backup --tag daily /etc /srv/app lets you filter later with restic snapshots --tag daily. Once the Restic SFTP repository is initialized, every later command — backup, snapshots, forget, restore — uses the same -r value, so keep it in a script or an environment variable. Run forget --prune from the same side that owns the automation so retention actually executes, and add ServerAliveInterval 60 and ServerAliveCountMax 240 to the client's SSH config — SFTP servers close idle connections, and Restic can look idle while it is busy processing unchanged data.

How Do Retention Policies Work in Restic?

Retention in Restic is two commands used together — the Restic forget prune combination: restic forget decides which snapshots to keep, and --prune actually deletes the data that no snapshot references. Forgetting without pruning marks snapshots as removed but never frees the space — always pair them. A sensible starter policy for a server keeps a week of dailies, a month of weeklies, and half a year of monthlies:

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

Forget groups snapshots by host and path by default, and the keep flags compose: --keep-last 10, --keep-hourly, and --keep-yearly are all available for finer control. Run restic check on a schedule too — it verifies the repository's structure and that every referenced chunk exists, catching storage-side corruption before you need the data. Repositories grow only by the changed chunks between runs, so this policy gives you months of history for roughly the cost of one full backup plus the daily changes.

How Do You Automate Restic Backups on a Server?

You automate Restic with a systemd timer on modern servers, because timers give you logging, failure notifications, and retry behavior that cron does not. The timer runs a small script that exports the four variables — RESTIC_REPOSITORY, RESTIC_PASSWORD_FILE, and the backup command with its tags — then runs restic backup followed by restic forget --prune and restic check. If the box you are backing up is a virtual private server, our what is VPS hosting guide explains the server this automation lives on.

On systems without systemd, cron plus flock is the fallback: flock -n /tmp/restic.lock restic backup ... prevents a second run from starting while the first is still going, which matters because overlapping Restic runs on the same repository can contend on locks. Either way, direct Restic's output to a log file and alert on non-zero exits — a backup job that fails silently for three months is the same as no backup job. If a run is ever interrupted mid-write, restic unlock clears the stale lock before the next run.

How Do You Restore Files From a Restic Snapshot?

You restore with restic restore, naming the snapshot and the target directory — Restic never overwrites your live files in place. List what you have with restic snapshots, then restore the newest snapshot, or one specific snapshot ID, into a scratch directory:

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

Now make the test restore a habit, not a one-time exercise. Every sysadmin has a backup script; almost none has a restore story. Once a month, restore a real directory into /tmp, open a few files, and confirm they are intact — then delete the test directory. If the restore ever fails, you have found out on a quiet afternoon instead of during an outage. The official docs' warning is worth repeating here: the restore is the only proof the backup exists.

Restic vs rsync: Which One Do You Actually Need?

You need both, for different jobs — and this is the most common confusion beginners bring to Restic. The comparison:

Resticrsync
What it doesEncrypted, versioned snapshots with historyFast file synchronization, mirrors the present
EncryptionAlways on, by designNone (relies on the transport, e.g. SSH)
HistoryEvery snapshot kept per your retention policyOnly the latest state exists
Deleted filesRecoverable from older snapshotsGone from the mirror (unless you add --backup)
Storage costNear one full copy plus changesExactly one copy
Best forDisaster recovery, ransomware, "what did this look like in March"Deployments, mirrors, moving files between servers fast

Use rsync to move files and keep machines in sync; use Restic when losing data would hurt. If you want a graphical interface over a similar encrypted-backup engine instead of the command line, our Kopia beginner guide covers the other major tool in this space — the two are the encrypted-backup siblings, and the comparison above is the same lens you would use to choose between them.

What Are the Beginner Mistakes That Cost People Their Backups?

MistakeWhat happensThe fix
Losing the repository passwordThe entire repository becomes unreadable — permanentlyPassword manager + sealed offline escrow copy, set up before init
Running forget without --pruneStorage keeps growing; old data is never actually deletedAlways pair them: forget --prune
Backing up a live database's data filesRestored database may be corruptedDump first (pg_dump / mysqldump), back up the dump
Restoring directly over productionA bad restore destroys the working systemRestore to /tmp first, verify, then copy into place
SFTP automation with password authScheduled backups hang forever waiting for inputSSH key authentication before automating
Never running checkSilent corruption discovered only during a real emergencyMonthly restic check from the same automation

Sources

The facts in this guide were verified against primary sources on October 31, 2026: the official Restic documentation (installation page and "Preparing a new repository" chapter, docs for restic 0.19.1) for install commands, restic init syntax, the password-loss warning, SFTP and S3/S3-compatible repository setup, and the RESTIC_REPOSITORY / RESTIC_PASSWORD_FILE environment variables; the restic/restic GitHub releases page for the current version (v0.19.1, released July 5, 2026); thebackroomtech.com's Restic-on-S3 playbook for the full 11-step install-to-test-restore arc; tuxwraith.com's Restic playbook for the deduplication framing and the "your backup plan is a lie until you've done a restore" restore drill; arphost.com's server-to-server guide for the SFTP arc and the escrow rule; estoreab.com's enterprise guide for the Restic-vs-rsync decision table and the cron-plus-flock pattern; and linuxprofessional.ie's backups-and-recovery guide for the forget --prune retention example and the restore latest --target test-restore pattern.

Frequently Asked Questions

Is my Restic backup really safe on someone else's cloud storage?

Yes. Restic encrypts every chunk with AES-256 and authenticates it before anything leaves your machine, using keys derived from your repository password. The storage provider sees only opaque encrypted blobs — it cannot read your files, and it cannot help you if you lose the password. That is exactly why the password-escrow rule in this guide comes before everything else.

How much disk space do Restic backups actually use?

Roughly one full backup plus the changes between runs. Restic splits files into content-defined chunks and stores each unique chunk once, so a daily backup of a server where little changes costs barely more than the first full copy. Retention policy then decides how far back your history reaches — the --keep-daily 7 --keep-weekly 4 --keep-monthly 6 policy in this guide keeps about six months of history for that incremental cost.

Can I back up a running database with Restic?

Not directly. A file-level snapshot of a database's data files while it is running can restore into an inconsistent or corrupted state. The reliable pattern is to dump the database first — pg_dump for Postgres, mysqldump for MySQL — and point Restic at the dump file. Schedule the dump immediately before the Restic backup in the same automation script.

What happens if a Restic backup is interrupted?

An interrupted run can leave a lock file in the repository, which makes the next run refuse to start. Clear it with restic unlock and run the backup again — Restic resumes efficiently because already-stored chunks are deduplicated and skipped. Partial data from the interrupted run is harmless; it is cleaned up by the next prune.

Does Restic work on Windows and macOS?

Yes — Restic is a single cross-platform binary. On Windows install it with winget install --exact --id restic.restic --scope Machine or scoop install restic; on macOS with brew install restic. The commands in this guide are identical across platforms; only the install step and the paths you back up change.

Featured on Twelve Tools Launch Llama Tools Launch your MCP