NeuroDynamic.Tech
Sign inJoin

Backups that actually restore: restic from zero

An encrypted backup of a folder, stored in a second location, that you have personally restored from. That last part is the whole point.

The founder · 15 min read ·

BASIC

Tested for real: I ran every command in this guide top-to-bottom on a fresh Ubuntu 24.04 virtual machine (4 CPUs, 8 GB RAM) on 13 August 2026. Versions at test time: Ubuntu 24.04.4 LTS, restic 0.16.4 (from Ubuntu's own archive).

Found a problem? Tell me via the contact page.

What you'll end up with

An encrypted backup of a folder, stored on a second location, that you have personally restored from. That last part is the whole point. A backup you have never restored is a hope, not a backup.

Here is the finished state from my test run — a deleted file, brought back, proven byte-for-byte identical:

$ diff -r ~/my-files /tmp/restore-test/home/tester/my-files
Only in /tmp/restore-test/home/tester/my-files: notes.txt

$ cp /tmp/restore-test/home/tester/my-files/notes.txt ~/my-files/
$ diff -r ~/my-files /tmp/restore-test/home/tester/my-files

That silent second diff is the proof. The folders match again.

Who this is for

BASIC. One path, copy-paste-safe, nothing to edit mid-line. If you have a folder you would be upset to lose, this guide is for you.

Time and cost

The commands took me under 3 minutes on the test machine, measured — restic is fast on small folders. Budget 45 minutes to read and understand as you go. Cost: nothing. restic is free and the backups in this guide stay on your own machine.

Your first backup of a big folder will take longer than mine. Backups after the first are quick — restic only stores what changed.

Words you'll meet

  • Repository — the folder where restic keeps your backups, in its own packed, encrypted format. You never edit it by hand. (basics)
  • Snapshot — one backup moment. "The folder as it was at 16:34 on Tuesday." Restic stores many snapshots in one repository. (basics)
  • Encrypted — scrambled so only someone with the password can read it. Restic encrypts everything, always — it cannot be turned off. (basics)
  • Deduplication — restic stores each piece of data once, even if it appears in many snapshots. Ten backups of an unchanged folder cost barely more than one. (basics)
  • Prune — restic's word for actually deleting data that no snapshot needs any more, to free space. (basics)
  • sudo — "do this as the administrator". Ubuntu asks for your password when you use it. (basics)

Placeholders

Anywhere you see CAPS-WITH-DASHES, such as YOUR-USERNAME-HERE, swap in your own value. Where a command uses $USER instead, the shell fills in your username automatically — type it exactly as written.

Before you start

  • An Ubuntu machine (I tested 24.04) with a user that can use sudo.
  • If the machine is brand new, do First hour with a new Ubuntu server first.
  • Somewhere for backups to live. Best: a second disk or USB drive. No second disk today? Read the honest note in Step 3 — the guide still works.

The steps

Step 1 — install restic

Restic is in Ubuntu's own software archive, so one command installs it — no third-party repository, no downloaded script.

sudo apt-get install -y restic

A passing run includes:

The following NEW packages will be installed:
  restic
[...snipped...]
Setting up restic (0.16.4-2ubuntu0.24.04.3) ...

An honest version note. Ubuntu's archive ships restic 0.16.4; the newest official build was 0.19.1 at the time of testing. I use the archive version here on purpose. It is one trusted install path, it gets security fixes through normal Ubuntu updates, and everything in this guide works with it. When you outgrow it, the official binary is a drop-in swap.

Check it worked. Ask restic for its version:

restic version

You should see something like:

restic 0.16.4 compiled with go1.22.2 on linux/amd64

Your version may be newer — that's fine.

Step 2 — make a folder worth protecting

You almost certainly have a real folder to back up. For this guide I made a small practice one, so your output matches mine exactly. Swap in your real folder once the drill makes sense.

Make the folder and two text files:

mkdir -p ~/my-files
printf 'Shopping list\n- oats\n- golden syrup\n- butter\n' > ~/my-files/notes.txt
printf '# Flapjack recipe\n\n150g butter, 100g syrup, 250g oats. 180C for 20 minutes.\n' > ~/my-files/recipe-flapjacks.md

Now a 2 MB file of random bytes, standing in for a photo:

head -c 2M /dev/urandom > ~/my-files/holiday-photo-001.jpg

Check it worked. List the folder:

ls -lh ~/my-files

Your output will vary, but look for:

total 2.1M
-rw-rw-r-- 1 tester tester 2.0M Aug 13 16:34 holiday-photo-001.jpg
-rw-rw-r-- 1 tester tester   95 Aug 13 16:34 notes.txt
-rw-rw-r-- 1 tester tester   76 Aug 13 16:34 recipe-flapjacks.md

Three files, about 2 MB — that is our precious data for today.

Step 3 — choose where backups live

A backup on the same disk as the original dies with that disk. The right home for this folder is a second disk or a USB drive, mounted at a path like /mnt/backup-drive.

An honest note. On my test machine there is no second disk, so /mnt/backup-drive below is a plain folder on the same disk — a stand-in. Every command works identically either way. If you have a real second drive, mount it at /mnt/backup-drive and you are doing it properly. If not, follow along anyway and know this one weakness. The next guide adds an off-site copy, which reduces that risk for real.

Make the folder:

sudo mkdir -p /mnt/backup-drive

Hand it to your own user, so backups do not need sudo every time. $USER fills in your username automatically — nothing to edit:

sudo chown $USER:$USER /mnt/backup-drive

Check it worked. Look at the folder's owner:

ls -ld /mnt/backup-drive

The important line is:

drwxr-xr-x 2 tester tester 4096 Aug 13 16:34 /mnt/backup-drive

The two names in the middle should be your username, not root.

Step 4 — create the password file

Restic encrypts every backup with a password. Here is the uncomfortable truth, straight from restic's own output: lose the password and the backups are gone. Nobody can recover them — not you, not restic's authors, nobody. That is the price of real encryption.

So we do two things. We generate a strong password into a file (so commands can read it without you typing it), and then you copy that password somewhere safe off this machine.

Make a folder for it:

mkdir -p ~/.config/restic

Generate a random password into a file:

openssl rand -base64 24 > ~/.config/restic/password

Lock the file down so only your user can read it:

chmod 600 ~/.config/restic/password

Now print it, once, and store a copy somewhere that survives this machine dying. Your password manager is ideal; a piece of paper in a drawer is honestly fine too:

cat ~/.config/restic/password

You should see something like:

yYG6refhcBfbA3qkdi4X0OCGvnNVDRsX

Yours will differ — it is random. Do not skip the copy. The scenario this guide protects you from is this machine dying; a password stored only on this machine dies with it.

Check it worked. Confirm the permissions:

ls -l ~/.config/restic/password

The important line is:

-rw------- 1 tester tester 33 Aug 13 16:34 /home/tester/.config/restic/password

The -rw------- at the start means only you can read it.

Step 5 — create the repository

One command sets up the repository — restic's encrypted home for all your snapshots. The -r flag says where; --password-file says how to unlock it. Every restic command in this guide uses this same pair of flags.

restic -r /mnt/backup-drive/restic-repo --password-file ~/.config/restic/password init

A passing run includes:

created restic repository e9a5b6feb3 at /mnt/backup-drive/restic-repo

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Restic repeating my warning from Step 4, in writing. Take it at its word.

Check it worked. The line created restic repository appeared. Your repository ID (mine was e9a5b6feb3) will differ.

Step 6 — make your first backup

One command backs up the folder into the repository.

restic -r /mnt/backup-drive/restic-repo --password-file ~/.config/restic/password backup ~/my-files

Your output will vary, but look for:

no parent snapshot found, will read all files

Files:           3 new,     0 changed,     0 unmodified
Dirs:            3 new,     0 changed,     0 unmodified
Added to the repository: 2.002 MiB (2.002 MiB stored)

processed 3 files, 2.000 MiB in 0:00
snapshot b94b4df6 saved

Check it worked. The last line says snapshot ... saved. The ID (mine was b94b4df6) is that snapshot's name. Yours will differ, and that is fine everywhere in this guide — we use the word latest instead of IDs.

Step 7 — see your snapshots

Ask the repository what it holds:

restic -r /mnt/backup-drive/restic-repo --password-file ~/.config/restic/password snapshots

Your output will vary, but look for:

ID        Time                 Host            Tags        Paths
--------------------------------------------------------------------------------
b94b4df6  2026-08-13 16:34:38  ubuntu-testbed              /home/tester/my-files
--------------------------------------------------------------------------------
1 snapshots

Check it worked. The table shows 1 snapshot with today's date and your folder's path.

Step 8 — the drill: delete a file and get it back

Now the part most backup guides skip. We break something on purpose, while it is cheap, so the first time you restore is not the day it matters.

Delete a file:

rm ~/my-files/notes.txt

Confirm it is really gone:

ls ~/my-files

You should see something like:

holiday-photo-001.jpg
recipe-flapjacks.md

No notes.txt. Now restore the newest snapshot into a scratch folder. Restoring to a separate folder first is a habit worth keeping — you inspect before you overwrite anything:

restic -r /mnt/backup-drive/restic-repo --password-file ~/.config/restic/password restore latest --target /tmp/restore-test

You should see something like:

restoring <Snapshot b94b4df6 of [/home/tester/my-files] at 2026-08-13 16:34:38 [...snipped...]> to /tmp/restore-test
Summary: Restored 6 files/dirs (2.000 MiB) in 0:00

Restic rebuilds the full path inside the target, so the files landed in /tmp/restore-test/home/YOUR-USERNAME-HERE/my-files. The commands below use $USER so the path fills itself in.

Compare the live folder with the restored one:

diff -r ~/my-files /tmp/restore-test/home/$USER/my-files

The important line is:

Only in /tmp/restore-test/home/tester/my-files: notes.txt

Read that line slowly — it is the good news. The backup has the file your live folder is missing. Copy it home:

cp /tmp/restore-test/home/$USER/my-files/notes.txt ~/my-files/

Check it worked. Run the same diff again:

diff -r ~/my-files /tmp/restore-test/home/$USER/my-files

You should see something like:


Silence is the pass mark — the folders are identical again. In my test I also compared checksums before deletion and after restore: byte-for-byte identical. You have now done the thing most people never do: restored from your own backup.

Step 9 — let restic check its own health

Restic can audit its repository for damage. Run this occasionally — a corrupted repository you find today is an inconvenience; one you find during a disaster is much worse.

restic -r /mnt/backup-drive/restic-repo --password-file ~/.config/restic/password check

A passing run includes:

create exclusive lock for repository
load indexes
check all packs
check snapshots, trees and blobs
[0:00] 100.00%  1 / 1 snapshots

no errors were found

Check it worked. The last line is no errors were found.

Step 10 — a second backup

Change a file, back up again, and watch deduplication earn its keep:

printf '\nTested: works in the air fryer too, 12 minutes.\n' >> ~/my-files/recipe-flapjacks.md
restic -r /mnt/backup-drive/restic-repo --password-file ~/.config/restic/password backup ~/my-files

Your output will vary, but look for:

using parent snapshot b94b4df6

Files:           0 new,     2 changed,     1 unmodified
Dirs:            0 new,     3 changed,     0 unmodified
Added to the repository: 2.237 KiB (1.517 KiB stored)

processed 3 files, 2.000 MiB in 0:00
snapshot 95cb8fa0 saved

Check it worked. Look at Added to the repository: 2.237 KiB. The folder is 2 MB, but restic stored two kilobytes — only the change. This is why keeping many snapshots is affordable.

Step 11 — tidy up with a retention rule

Old snapshots do eventually pile up. forget picks which to drop by a rule, and --prune deletes the data nothing needs any more. Here is the smallest useful rule — keep only the newest:

restic -r /mnt/backup-drive/restic-repo --password-file ~/.config/restic/password forget --keep-last 1 --prune

A passing run includes:

Applying Policy: keep 1 latest snapshots
keep 1 snapshots:
[...snipped: table showing snapshot 95cb8fa0 kept...]
remove 1 snapshots:
[...snipped: table showing snapshot b94b4df6 removed...]
1 snapshots have been removed, running prune
[...snipped...]
done

Check it worked. List snapshots one more time:

restic -r /mnt/backup-drive/restic-repo --password-file ~/.config/restic/password snapshots

Your output will vary, but look for:

ID        Time                 Host            Tags        Paths
--------------------------------------------------------------------------------
95cb8fa0  2026-08-13 16:35:12  ubuntu-testbed              /home/tester/my-files
--------------------------------------------------------------------------------
1 snapshots

One snapshot remains — the newest. --keep-last 1 is deliberately brutal for the demo; the next guide sets a proper keep-some-days, keep-some-weeks policy.

Something went wrong?

My recorded run came back clean, so I have no captured failures to show you. Two situations follow directly from the design:

  • You see Fatal: wrong password or no key found → it means the password restic read does not match the repository's → check --password-file points at the same file you used for init, and that the file was not edited or regenerated since.
  • You lost the password file and have no copy → it means those backups are permanently unreadable — this is real, not fixable → start again at Step 4, make a new repository, and this time store the copy off the machine.

Undo all of this

Tested for real, in this order. It removes the repository, the password file, the practice folder and restic itself.

Delete the repository:

rm -rf /mnt/backup-drive/restic-repo

Remove the backup folder (skip this if it is a real mounted drive):

sudo rmdir /mnt/backup-drive

Remove the password file, the practice folder and the restore scratch folder:

rm -r ~/.config/restic ~/my-files /tmp/restore-test

Remove restic:

sudo apt-get remove --purge -y restic

A passing run includes:

The following packages will be REMOVED:
  restic*
After this operation, 22.1 MB disk space will be freed.
Removing restic (0.16.4-2ubuntu0.24.04.3) ...

Restic pulled in a few small documentation packages; sweep those too:

sudo apt-get autoremove --purge -y

You should see something like:

0 upgraded, 0 newly installed, 7 to remove and 26 not upgraded.
Removing sphinx-rtd-theme-common (2.0.0+dfsg-1) ...
[...snipped...]

Check it worked. Ask for restic one last time:

restic version

The important line is:

restic: command not found

That error is the pass mark. When I tested this undo it took 11 seconds and the machine was back to its starting state.

Where to go next

  • Backups while you sleep: systemd timers and retention (the GOING FURTHER follow-on — it starts exactly where this guide ends), and its companion The off-site copy, and proving your backups still restore.
  • Official docs: restic.readthedocs.io — the reference for every command used here.

Last tested: 13 August 2026 on Ubuntu 24.04.4 LTS. Versions: restic 0.16.4 (Ubuntu archive; upstream official binary was 0.19.1 at test time).


Tried it? Improved it?

Tell the forum what worked and what didn’t: real experience beats recommendations, and the best answers get folded back into this guide with credit.

Related guides