How to restore from restic
full snapshots, single files, and more

Step 1: List your snapshots

source /etc/restic/env

# List all snapshots
restic snapshots

# List snapshots for a specific host
restic snapshots --host web01

# List snapshots with a specific tag
restic snapshots --tag production

Restore a full snapshot

# Restore the most recent snapshot
restic restore latest --target /tmp/full-restore

# Restore a specific snapshot by ID
restic restore a1b2c3d4 --target /tmp/restore-20260101

# Restore to original location (be careful - overwrites existing files)
restic restore latest --target /

Restore a specific file or directory

# Restore a single file
restic restore latest \
  --target /tmp/restore \
  --include /etc/nginx/nginx.conf

# Restore an entire directory
restic restore latest \
  --target /tmp/restore \
  --include /var/www/mysite

# Restore multiple paths
restic restore latest \
  --target /tmp/restore \
  --include /etc \
  --include /var/www

The restored files preserve their original path structure under the target directory. So restoring /etc/nginx/nginx.conf to /tmp/restore gives you /tmp/restore/etc/nginx/nginx.conf.

Mount and browse without restoring

Install FUSE support, then mount the repository to browse snapshots interactively.

apt install -y fuse
mkdir -p /mnt/restic

# Mount the repository
restic mount /mnt/restic &

# Browse snapshots
ls /mnt/restic/snapshots/
ls /mnt/restic/snapshots/latest/etc/

# Copy a specific file
cp /mnt/restic/snapshots/latest/var/www/index.html /tmp/

# Unmount
umount /mnt/restic

Verify backup integrity before you need it

# Quick check (metadata only, fast)
restic check

# Full check (reads all data, slow but thorough)
restic check --read-data

# Check a random 10% sample (good balance)
restic check --read-data-subset=10%

Run restic check monthly and restic check --read-data-subset=10% quarterly. This catches corruption before you need to restore.

Restore after complete system loss

If you need to rebuild a machine from scratch: boot into a live environment, install restic, configure your credentials, and restore to the target filesystem. The key requirement is that you have your RESTIC_REPOSITORY and RESTIC_PASSWORD stored somewhere independent - a password manager, printed and locked away, or both.

Restore performance and what affects it

Restic restore speed is bounded by two things: how fast your network connection can download from the SFTP server, and how efficiently restic can reconstruct chunks. The first run after a long gap downloads everything. Incremental daily backups mean most restores only need to download the changed chunks from recent snapshots.

For large restores, restic downloads packs in parallel. You can influence concurrency with --option sftp.connections=8 for SFTP backends. Most users won't need to tune this - the defaults are sensible for a standard server connection.

Restoring specific file types - practical examples

• Nginx config:restic restore latest --target /tmp/r --include /etc/nginx - then diff against current and apply changes selectively
• PostgreSQL dump:restic restore latest --target /tmp/r --include /var/backups/postgres - then psql -f /tmp/r/var/backups/postgres/dump.sql
• SSH keys:restic restore latest --target /tmp/r --include /root/.ssh - then copy to destination with correct permissions
• Docker volume:restic restore latest --target /tmp/r --include /var/lib/docker/volumes/myapp_data - then copy back to volume path

The test restore habit

The only way to know your backup works is to restore from it on a regular schedule, not when you actually need it. Set a calendar reminder: once a month, restore a single file from your most recent snapshot. Once a quarter, do a full restore to a temporary location and verify the contents look correct.

ServerCrate charges no egress fees, so testing restores costs nothing extra. There is no financial reason not to test regularly. The time cost is under ten minutes once you have done it once. Make it a habit before you need it.