Restic backups maken voor uw VPS

Waarom een backup op dezelfde server geen backup is

Restic is een gratis, open source backup-tool die versleutelde, gededupliceerde snapshots van uw bestanden naar een externe repository stuurt: een tweede VPS, een machine thuis, of S3-compatibele object storage. Deze handleiding behandelt de installatie op Ubuntu 24.04, van de installatie tot een repository via SFTP, een eerste backup, een nachtelijke systemd timer, een retention policy, en de restore-procedure om te bewijzen dat alles werkt. De bestemming moet een andere machine zijn, omdat een kopie op dezelfde server verloren gaat als de server uitvalt.

Een backup/ directory op de machine die wordt gebackupt, beschermt u slechts tegen één ding: het per ongeluk verwijderen van een bestand. Het overleeft een defecte schijf niet, omdat de kopie op die schijf stond. Het overleeft een aanvaller met root-rechten niet, omdat zij eerst de kopieën verwijderen. Het overleeft een fout bij het accountbeheer niet waarbij de VPS zelf wordt verwijderd. Het minst efficiënte datacenter ter wereld grapt over een tarball genaamd backup_final_v2_REAL die op dezelfde array staat als de data, en de grap is herkenbaar omdat velen van ons precies dat hebben gedaan. De regel is: buiten de machine. Restic is de eenvoudigste manier om deze regel te volgen.

Restic in vier concepten

Repository. De locatie waar restic naar schrijft. Het is een directory in het eigen formaat van restic, gevuld met versleutelde blobs, en alleen restic kan dit lezen. U mag dit nooit handmatig bewerken; u communiceert hiermee via restic commands en het -r adres.

Snapshot. Een momentopname van de bestanden die u heeft gebackupt. Elke backup-run maakt een snapshot aan. Elke snapshot kan afzonderlijk worden hersteld en gedraagt zich als een volledige kopie van uw data op dat specifieke moment.

Deduplication. Restic splitst bestanden in content-defined chunks en uploadt alleen de chunks die de repository nog niet heeft gezien. De eerste backup uploadt alles; elke run daarna uploadt ongeveer alleen hetgeen is gewijzigd. Een nachtelijke snapshot van 20 GB waarbij 50 MB is gewijzigd, kost ongeveer 50 MB. Daarom is het opslaan van tientallen snapshots goedkoop.

Encryption by default. Een restic repository is altijd versleuteld (AES-256) en elke command vereist het wachtwoord van de repository. De backup host of de storage provider ziet uitsluitend versleutelde blobs. Het directe gevolg: als u het wachtwoord verliest, is de data definitief verloren door het ontwerp van het systeem. Bewaar een kopie van het wachtwoord op een locatie die niet deze server is. Dit is zo belangrijk dat het hieronder nog twee keer wordt vermeld.

Installeer restic op Ubuntu 24.04

sudo apt update && sudo apt install -y restic
restic version

Op Ubuntu 24.04 wordt restic 0.16.4 geïnstalleerd, terwijl de huidige upstream-versie 0.19.1 is. Dit verschil komt doordat een LTS (long term support) release pakketversies bevriest. Dit is niet relevant voor deze handleiding: versie 0.16.4 ondersteunt alle functies in deze gids. Als u de nieuwste versie wilt vanwege de snelheidswinst, download dan de officiële single-binary build van de GitHub-releasespagina van het restic-project. Pak het bestand uit met bunzip2 en installeer het in /usr/local/bin/restic; een restic-installatie vereist verder geen extra stappen.

Maak het repository aan op een andere server via SFTP

U heeft een doelmachine nodig: een tweede kleine VPS is de gebruikelijke keuze. Elke machine met een SSH-server en vrije schijfruimte volstaat. Restic gebruikt SFTP (file transfer over SSH), dus op de backup-host hoeft er niets geïnstalleerd te worden. In deze handleiding is de backup-host 10.0.0.12 met een gebruiker genaamd restic. Geef deze gebruiker geen naam als backup: Ubuntu en Debian leveren bij elke installatie een gereserveerd systeemaccount genaamd backup (uid 34, geen login shell). Hierdoor mislukt adduser backup en komt ssh backup@... terecht in nologin.

De nachtelijke taak wordt uitgevoerd als root op de te backuppen server. Daarom heeft root sleutel-login (key login) nodig op de backup-host. Maak een speciale sleutel aan zonder wachtwoord, omdat er om 3 uur 's nachts geen persoon aanwezig is om een wachtwoord in te voeren. Kopieer de sleutel vervolgens:

sudo ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "web1-restic"
sudo ssh-copy-id -i /root/.ssh/id_ed25519.pub restic@10.0.0.12
sudo ssh restic@10.0.0.12 true && echo key login works

Als u nog geen ervaring heeft met sleutels, legt SSH key management basics het model, de permissies en het intrekken van een sleutel uit.

Vervolgens het wachtwoord voor het repository. Genereer een sterk wachtwoord in een bestand dat alleen voor root toegankelijk is:

openssl rand -base64 32 | sudo tee /root/.restic-password
sudo chmod 600 /root/.restic-password

Kopieer dit wachtwoord naar uw wachtwoordbeheer voordat u verdergaat. Als deze VPS uitvalt, herstelt het repository samen met dit wachtwoord alles. Zonder het wachtwoord kan het repository niets herstellen.

Initialiseer het repository:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password init

created restic repository 9f3c2a1b0d at sftp:restic@10.0.0.12:/srv/restic/web1

Een alternatieve bestemming is S3-compatibele object storage. Dit is de juiste keuze als u geen tweede machine wilt beheren. Elke S3-compatibele bucket werkt op dezelfde manier; alleen het adres en twee variabelen voor de credentials veranderen:

export AWS_ACCESS_KEY_ID=your-key-id
export AWS_SECRET_ACCESS_KEY=your-secret-key
sudo -E restic -r s3:https://s3.example.com/web1-backups --password-file /root/.restic-password init

Alles na init is identiek voor beide bestemmingen. De rest van deze handleiding toont het SFTP-adres; vervang dit door uw eigen adres.

De eerste backup, met uitsluitingen

Maak een backup van de gegevens die u niet opnieuw kunt installeren, niet van het volledige bestandssysteem. Het besturingssysteem kan worden hersteld via een nieuwe installatie; uw configuratie en uw gegevens niet. Voor een typische VPS betekent dit /etc, /home, en de locaties waar uw applicaties gegevens opslaan, zoals /srv of /var/www. Sluit caches uit, omdat deze groot zijn, dagelijks veranderen en zichzelf opnieuw opbouwen:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password backup /etc /home /srv --exclude '/home/*/.cache'

Files:        4181 new,     0 changed,     0 unmodified
Added to the repository: 731.204 MiB (312.418 MiB stored)
snapshot 5b8a3f2c saved

De eerste uitvoering uploadt alles, dus dit duurt even. Voer hetzelfde commando opnieuw uit; dit duurt slechts enkele seconden. Er wordt gerapporteerd dat enkele bestanden zijn gewijzigd en enkele MiB zijn toegevoegd, omdat deduplicatie alleen nieuwe chunks uploadt. Bekijk wat u heeft:

sudo restic -r sftp:restic@10.0.0.12:/srv/restic/web1 --password-file /root/.restic-password snapshots

Elke snapshot toont een ID, een tijdstip en de paden die deze bevat. Deze ID's gebruikt u voor het herstellen.

Nachtelijke runs met een systemd timer

Het telkens handmatig invoeren van het repository-adres is tijdrovend. Een handmatig uitgevoerd backup-proces wordt vaak binnen een maand vergeten. Beide problemen zijn op te lossen met één script en één timer. Het script stelt de twee omgevingsvariabelen in die restic gebruikt, RESTIC_REPOSITORY en RESTIC_PASSWORD_FILE. Hierdoor blijven alle commando's in het script kort:

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

#!/usr/bin/env bash
set -euo pipefail
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password

restic backup /etc /home /srv --exclude '/home/*/.cache'
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check

sudo chmod 700 /usr/local/bin/restic-backup.sh

De regels forget en check worden in de volgende twee secties uitgelegd. Wat betreft de planning: een oneshot service voert het script uit, en een timer start dit elke nacht om 03:00. Een timer is hier superieur aan een cron-regel omdat de logs naar het journal gaan. Daarnaast voert Persistent=true een gemiste backup uit zodra de server na downtime weer online is.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Nightly restic backup
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/restic-backup.sh

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Run the nightly restic backup

[Timer]
OnCalendar=*-*-* 03:00:00
RandomizedDelaySec=15m
Persistent=true

[Install]
WantedBy=timers.target

Activeer de timer, voer de service daarna handmatig één keer uit en controleer de werking:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
sudo journalctl -u restic-backup.service -f

systemctl list-timers toont wanneer de volgende run plaatsvindt. U kunt ook direct het paar unit-files genereren in plaats van ze handmatig te typen:

Het volledige concept achter deze twee bestanden, inclusief de kalendersyntaxis en de hardening-instructies voor een service, vindt u in het uitvoeren van een programma als systemd service op een VPS.

Een backup is slechts een gerucht totdat u deze heeft hersteld

Beschouw deze zin als een voorschrift. Een backup-job die elke nacht succesvol wordt uitgevoerd, bewijst alleen dat de job is uitgevoerd; het bewijst niet dat uw data herstelbaar is. Twee controles overbruggen dit gat.

De eerste is restic check, die het script al elke nacht uitvoert. Dit controleert de repository-structuur en de index. Hierdoor wordt stille corruptie op de backup-host de volgende nacht gedetecteerd in plaats van op de dag van herstel. Voer één keer per maand de uitgebreidere versie uit, die een willekeurige tiende van de werkelijke data downloadt en cryptografisch verifieert:

sudo -i
export RESTIC_REPOSITORY='sftp:restic@10.0.0.12:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic check --read-data-subset=10%

Omdat de subset telkens willekeurig is, worden bij maandelijkse runs de volledige repository doorlopen zonder dat een volledige download nodig is.

De tweede is de hersteltest. Voer vanuit de root shell van de bovenstaande stappen een herstel uit van één echte directory vanuit de laatste snapshot naar een tijdelijke locatie, en vergelijk deze met de live bestanden:

restic restore latest --target /srv/restore-drill --include /etc/ssh
diff -r /etc/ssh /srv/restore-drill/etc/ssh

Als diff niets printt, zijn alle bytes identiek hersteld. Dit is het enige relevante bewijs. Verwijder /srv/restore-drill daarna. Voer deze test maandelijks uit. Voer één of twee keer per jaar de volledige versie uit: herstel de volledige laatste snapshot naar een tijdelijke VPS en controleer of uw applicatie daadwerkelijk start vanuit deze backup. Op de dag dat u dit onder druk moet uitvoeren, moet het een routine zijn die u al eerder heeft uitgevoerd.

Retention: forget plus prune

Zonder beleid worden snapshots oneindig opgeslagen en blijft het repository groeien. De forget regel van het script past elke nacht een beleid toe: --keep-daily 7 bewaart één snapshot per dag voor de laatste zeven dagen, --keep-weekly 4 één per week voor vier weken, en --keep-monthly 6 één per maand voor zes maanden. Alles wat niet door een regel wordt beschermd, wordt vergeten.

forget verwijdert alleen de snapshot-records; de data chunks blijven in het repository staan totdat iets ze verwijdert. Dat is wat --prune doet: het zoekt naar chunks zonder resterende snapshot-referenties en verwijdert deze, waardoor er daadwerkelijk schijfruimte vrijkomt. Prune voert de werkelijke repository-acties uit. Bij een groot repository voeren sommige gebruikers forget wekelijks uit en --prune wekelijks; bij typische VPS-formaten is dagelijks uitvoeren voldoende.

Databases: eerst een dump maken, dan de dump backuppen

Restic kopieert bestanden terwijl deze worden ingelezen. Een database schrijft continu naar haar bestanden. Een live databasebestand dat tijdens het schrijven wordt vastgelegd, herstelt als een beschadigde database. Dit komt doordat de kopie pagina's mengt van vóór en na een schrijfactie. De oplossing is standaard: laat de database-engine een consistente export naar een bestand maken, en laat restic dat bestand vervolgens backuppen.

Voeg voor PostgreSQL een dump-regel toe bovenaan restic-backup.sh, vóór het restic backup commando, en voeg de dump-directory toe aan de backup-paden:

mkdir -p /var/backups/db
sudo -u postgres pg_dump myapp | gzip > /var/backups/db/myapp.sql.gz

mysqldump vervult dezelfde rol voor MariaDB en MySQL. Voor een uitgewerkt voorbeeld van dit volledige proces, schakelt de Nextcloud backup sectie de onderhoudsmodus in, maakt een dump van Postgres, en kopieert de bestanden als één consistente set. Dit is exact de set die restic elke nacht van de server moet meenemen. SQLite werkt volgens hetzelfde principe, maar dan eenvoudiger: de Vaultwarden handleiding stopt de container enkele seconden om een cold copy van db.sqlite3 te maken, en dat archief is wat restic naar de server verplaatst.

FAQ

Zijn restic-backups versleuteld?

Ja, altijd. Elk restic-repository is versleuteld met AES-256. Er is geen onversleutelde modus en elk commando vereist het wachtwoord van het repository. De machine of provider die het repository opslaat, bevat uitsluitend versleutelde blobs. Een gecompromitteerde backup-host legt uw bestanden dus niet bloot. De consequentie is absoluut: zonder het wachtwoord kan niemand de data herstellen. Bewaar daarom een kopie op een veilige locatie buiten de server.

Doet restic aan incrementele backups?

Elke restic-snapshot werkt als een volledige backup, maar verbruikt slechts incrementele opslag. Restic splitst bestanden in chunks en uploadt alleen de chunks die het repository nog niet heeft opgeslagen. Een dagelijkse uitvoering verplaatst daarom ongeveer alleen de wijzigingen van die dag. In tegenstelling tot traditionele incrementele schema's is er geen keten die herhaald moet worden: elke snapshot herstelt direct en het verwijderen van een oude snapshot beschadigt nooit een nieuwere snapshot.

Hoe herstel ik bestanden uit een restic-backup?

Gebruik restic snapshots om de snapshot ID te vinden en vervolgens restic restore <id> --target /some/empty/dir om deze te herstellen. Voeg --include /path toe om alleen een deel van de snapshot te herstellen. latest kan worden gebruikt in plaats van een ID. Restic recreëert de originele mappenstructuur in het doelpad, dus het herstellen van /etc/ssh komt terecht in /some/empty/dir/etc/ssh. Oefen dit voordat u het nodig heeft, want een ongeteste backup is slechts een gerucht.

Hoe vaak moet ik restic backup uitvoeren?

Voor een server is een dagelijkse uitvoering de minimale aanbevolen frequentie. Deduplicatie maakt dit efficiënt: elke uitvoering uploadt alleen de chunks die sinds de vorige keer zijn gewijzigd. Voor data die snel verandert, of waarbij verlies van zelfs maar één dag schadelijk is, kan de backup elke paar uur worden uitgevoerd met hetzelfde tijdsinterval. De frequentie is het eenvoudige deel; voer ook regelmatig restic check uit en test maandelijks een herstelprocedure. Een schema zonder verificatie biedt geen zekerheid.

Wat gebeurt er als ik mijn restic-repository wachtwoord verlies?

De backups zijn dan onherstelbaar. De versleuteling van restic heeft geen achterdeur en geen resetoptie. Het wachtwoord is daarom even belangrijk als de backups zelf. Bewaar een kopie in uw wachtwoordbeheerder en op een andere duurzame locatie die niet de gebackupte server is. Zolang u nog toegang heeft, kan restic key add een tweede wachtwoord voor hetzelfde repository registreren als reserve.