VPS guide

How to Back Up a Linux Server with Restic

By Gander Web · Published 16 October 2026 · 3 min read

Unmanaged VPS plans don't include backups, and a copy kept on the same server is lost along with it. Restic encrypts everything before it leaves the server, only uploads data that has changed since the last run, and can store backups on another server over SFTP or in S3-compatible storage such as Backblaze B2 or Cloudflare R2.

Install restic

sudo apt install restic
restic version

On AlmaLinux and Rocky, restic is in EPEL: run sudo dnf install epel-release, then sudo dnf install restic.

Choose where backups go

• Another server over SFTP: any Linux machine you can reach over SSH with a key, such as a second VPS or a NAS. The repository address looks like sftp:[email protected]:/srv/restic/web1. Backups run as root, so create a key for root with sudo ssh-keygen -t ed25519 and add it to the backup server, as in our SSH keys guide.
• S3-compatible storage: Backblaze B2, Cloudflare R2, Wasabi or Amazon S3. The address is s3:https:// followed by your provider's endpoint and bucket name, with the access keys in two environment variables.

Either way, keep backups somewhere other than the server they protect.

Store the settings

Put the repository details in a file only root can read:

sudo nano /root/restic.env

export RESTIC_REPOSITORY="sftp:[email protected]:/srv/restic/web1"
export RESTIC_PASSWORD_FILE="/root/.restic-password"

# for S3-compatible storage, use these instead of the first line:
# export RESTIC_REPOSITORY="s3:https://YOUR-ENDPOINT/your-bucket/web1"
# export AWS_ACCESS_KEY_ID="your-key-id"
# export AWS_SECRET_ACCESS_KEY="your-secret-key"

Generate a random repository password and lock both files down:

sudo sh -c 'openssl rand -base64 32 > /root/.restic-password'
sudo chmod 600 /root/restic.env /root/.restic-password

Create the repository

sudo -i
source /root/restic.env
restic init

The remaining commands assume you're root with restic.env loaded, as above.

Back up files and databases

Dump databases to a file first, so the backup gets a consistent copy rather than database files caught mid-write:

mkdir -p /var/backups/db
mysqldump --single-transaction --all-databases > /var/backups/db/all.sql
restic backup /etc /home /var/www /var/backups/db --exclude-caches

The first run uploads everything; later runs only send what's changed. Add any other folders your apps keep data in, such as the folders mounted into Docker containers. If MySQL's root account has a password on your server, put it in /root/.my.cnf so mysqldump can run without asking.

Keep a sensible history

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

This keeps one snapshot for each of the last 7 days, 4 weeks and 6 months, and deletes data no snapshot needs any more. Run restic check now and then to test the repository's integrity.

Run it every night

Put the steps in a script:

sudo nano /usr/local/bin/backup.sh

#!/bin/sh
set -eu
. /root/restic.env
mkdir -p /var/backups/db
mysqldump --single-transaction --all-databases > /var/backups/db/all.sql
restic backup /etc /home /var/www /var/backups/db --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Make it executable and add it to root's crontab:

sudo chmod 700 /usr/local/bin/backup.sh
sudo crontab -e

30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

That runs at 02:30 every night. Check /var/log/backup.log the next morning.

Restore files

restic snapshots
restic restore latest --target /tmp/restore --include /var/www/example.co.uk

Restoring into /tmp/restore lets you check the files before copying them back. To restore databases, load the dump with mysql < /tmp/restore/var/backups/db/all.sql, which replaces the databases it contains. Test a restore every few months, so you know the backups work and how long a restore takes.

Questions

Related guides

Sources

1. Installing restic (restic docs)
2. Preparing a new repository (restic docs)
3. Removing backup snapshots (restic docs)

Commands are for Ubuntu 24.04, Debian 12 and AlmaLinux 9, as of 16 October 2026. If something here no longer matches what you see, tell us and we'll update it.