Backing up your server properly

A backup that has never been restored is not a backup. It is an intention, in a folder.

This guide sets up something that holds: three copies, two media, one off-site — and above all a restore you have actually tried, because that is the only moment you find out the encryption wanted a key you never wrote down.

What to back up, and what not to

Not everything is worth the same. Three categories:

Irreplaceable. Your photos, your documents, your password manager's database. What exists nowhere else and no purchase brings back. This is what goes off-site.

Painful to rebuild. Your docker-compose.yml files, your configuration, your certificates. Tiny, and would cost you a weekend. Back it up too: it weighs nothing.

Re-downloadable. Films, series, Docker images. Paying every month to store elsewhere what one command brings back is the most common way to blow up a backup bill.

This distinction is not cosmetic: it decides whether you pay for 250 GB or for 8 TB.

The 3-2-1 rule

• 3 copies of your data;
• on 2 different media;
• 1 of them off-site.

On a server at home that means:

1. the original, on the server;
2. a copy on a different disk — a parity array does not count, it protects against a dead drive, not against rm -rf, ransomware or a burst pipe;
3. a copy outside the building.

The third is the one everyone postpones. It is the only one that survives a burglary or a fire.

This guide uses restic

End-to-end encrypted, deduplicated, incremental. A file that does not change is stored once, however often you back up.

Encrypted before it leaves, so the provider cannot read your files. Which has a flip side worth knowing up front: lose the key and the data is gone. Nobody can send it back to you.

sudo apt install restic

Step 1 — The local copy

The second copy first, on another disk in the machine:

sudo mkdir -p /mnt/backup/restic
sudo restic init --repo /mnt/backup/restic

It asks for a password. That is the encryption key. Write it down somewhere other than this server — in your password manager, on paper, at someone else's house. A key that only lives on the machine it protects protects nothing.

Stop the services before copying their data:

cd /srv/docker && docker compose stop
sudo restic --repo /mnt/backup/restic backup /srv/docker /var/lib/docker/volumes
docker compose start

Stopping is not optional as soon as a database is involved. Copying the files of a PostgreSQL that is mid-write gives you a backup that looks complete and does not restore — and you only learn that on the day you need it.

Step 2 — The off-site copy

This is where a storage plan comes in. This guide uses Infomaniak's Swiss Backup: data held in Switzerland, priced by space, and restic-compatible with nothing in between.

Create a space there, then a Swift user in its interface. You get an identifier shaped like SBI-XXXX and a password.

A ~/.restic-swissbackup file, readable only by you:

export OS_AUTH_URL=https://swift02-api.cloud.infomaniak.ch/identity/v3
export OS_REGION_NAME=RegionOne
export OS_USER_DOMAIN_NAME=default
export OS_PROJECT_DOMAIN_NAME=default
export OS_USERNAME=SBI-XXXX
export OS_PROJECT_NAME=sb_project_SBI-XXXX
export OS_PASSWORD=your_swift_password
export RESTIC_REPOSITORY=swift:sb_project_SBI-XXXX:/server
export RESTIC_PASSWORD_FILE=/root/.restic-key

chmod 600 ~/.restic-swissbackup

It really is Swift, OpenStack's protocol — not S3. Writing s3: gives an authentication error you will spend an hour mistaking for a wrong password.

Then:

source ~/.restic-swissbackup
restic init
restic backup /srv/docker /var/lib/docker/volumes

The credentials must be reloaded (source) before every operation — backup, listing or restore.

Step 3 — Restore, before you need to

The step everyone skips. Do it now, while nothing is on fire.

source ~/.restic-swissbackup
restic snapshots
restic restore <snapshot-id> --target /tmp/restore-test

Then actually open a restored file. Not the listing: the file.

Three things surface at this point, and otherwise only once it is too late: the key was written down nowhere, the folder you backed up was not the one you thought, and a full restore takes six hours — which changes your answer to "when will it be back up?".

Step 4 — Automate, and prune

A backup you have to remember to run does not get run.

Write a script first, /usr/local/bin/backup — not a sprawling cron line: you never re-read one, you never test one, and a typo in the middle shows up nowhere.

#!/bin/bash
set -euo pipefail

source /root/.restic-swissbackup

restic backup /srv/docker /var/lib/docker/volumes

# Retention: seven days, four weeks, twelve months. Without it the
# repository grows forever, and the bill with it.
restic forget --prune \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12

set -euo pipefail matters: without it, a script whose backup failed carries on to the prune and deletes old versions without having written a new one.

sudo chmod 700 /usr/local/bin/backup
sudo /usr/local/bin/backup

Run it once by hand. A scheduled script that has never run in front of you will fail at night, with nobody watching.

Then /etc/cron.d/restic:

0 3 * * * root /usr/local/bin/backup

That retention is also what saves you from ransomware: the versions from before the encryption are still there. This is why "a synced copy" is not a backup — a sync faithfully replicates the disaster.

Step 5 — Watch it

A silent backup that has been failing for three months is worse than no backup: it made you drop your guard.

Check now and then that the latest one is from yesterday:

source ~/.restic-swissbackup && restic snapshots --latest 1

And once a quarter, check the repository's integrity:

restic check --read-data-subset=5%

What it costs

Swiss Backup is billed on reserved space, excluding VAT, and its prices are converted from Swiss francs. Each backed-up device is counted separately.

The setup in this guide — irreplaceable data only, no re-downloadable media — usually fits in the smallest tier. That is the whole point of sorting first.

The builder prices this line into your monthly cost, next to electricity.

Next

• Updating your containers without breaking anything
• Setting up a reverse proxy