Restic back-ups instellen op Ubuntu 24.04

Waarom een back-up op dezelfde server geen back-up is

Restic is een gratis, open-source back-uptool die versleutelde, ontdubbelde snapshots van uw bestanden naar een repository elders verstuurt: een tweede VPS, een machine thuis of S3-compatibele objectopslag. Deze handleiding beschrijft de installatie op Ubuntu 24.04, van de installatie tot een repository via SFTP, een eerste back-up, een dagelijkse systemd-timer, een retentiebeleid en de hersteloefening die aantoont dat het geheel werkt. De bestemming moet een andere machine zijn, omdat een kopie die op dezelfde server staat, verloren gaat als de server uitvalt.

Een backup/-map op de machine waarvan een back-up wordt gemaakt, beschermt u slechts tegen één ding: het per ongeluk verwijderen van een bestand. Het overleeft geen defecte schijf, omdat de kopie zich op diezelfde schijf bevond. Het overleeft geen aanvaller met root-toegang, omdat deze de kopieën als eerste verwijdert. Het overleeft evenmin een accountfout waarbij de VPS zelf wordt verwijderd. Het minst efficiënte datacenter ter wereld maakt grappen over een tarball genaamd backup_final_v2_REAL die op dezelfde schijfarray staat als de data, en die grap is treffend omdat zovelen van ons precies dat hebben gedaan. Buiten de machine is de regel, en restic is de minst pijnlijke manier om die regel na te leven.

Restic in vier concepten

Repository. De locatie waar restic naar schrijft. Dit is een map in het eigen formaat van restic, gevuld met versleutelde blobs, die uitsluitend door restic gelezen kan worden. Bewerk deze nooit handmatig; u communiceert ermee via restic-commando's en het -r-adres.

Snapshot. Een momentopname van de bestanden waarvan u een back-up heeft gemaakt. Elke back-up-run creëert een snapshot, elke snapshot kan afzonderlijk worden hersteld en elke snapshot gedraagt zich als een volledige kopie van uw gegevens op dat specifieke moment.

Deduplicatie. Restic splitst bestanden in inhoudsgebaseerde blokken en uploadt alleen de blokken die de repository nog niet bevat. De eerste back-up uploadt alles; elke daaropvolgende run uploadt in grote lijnen alleen wat er is gewijzigd. Een dagelijkse snapshot van 20 GB waarbij 50 MB is gewijzigd, kost ongeveer 50 MB, wat de reden is dat het bewaren van tientallen snapshots goedkoop is.

Standaardversleuteling. Een restic-repository is altijd versleuteld (AES-256) en voor elk commando is het repository-wachtwoord vereist. De back-up-host of de opslagprovider ziet alleen versleutelde blobs. Het strikte gevolg: verliest u het wachtwoord, dan zijn de gegevens permanent en volgens ontwerp verloren. 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 benadrukt.

Restic installeren op Ubuntu 24.04

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

Op Ubuntu 24.04 installeert dit restic 0.16.4, terwijl de huidige upstream-versie 0.19.1 is. Dit verschil bestaat omdat een LTS-release (long term support) pakketversies bevriest. Dit is hier niet van belang: 0.16.4 ondersteunt alle functies in deze handleiding. Als u de nieuwste versie wilt gebruiken vanwege de prestatieverbeteringen, download dan het officiële single-binary bestand van de GitHub-releasespagina van het restic-project, pak het uit met bunzip2 en installeer het in /usr/local/bin/restic; een installatie van restic stelt verder niets voor.

De repository aanmaken op een andere server via SFTP

U heeft een doelmachine nodig: een tweede kleine VPS is hiervoor de standaardoplossing, en elke machine met een SSH-server en beschikbare schijfruimte volstaat. Restic ondersteunt SFTP (bestandsoverdracht via SSH), waardoor er op de back-uphost niets geïnstalleerd hoeft te worden. In deze handleiding is de back-uphost 10.0.0.12 met een gebruiker genaamd restic. Gebruik niet de naam backup voor deze gebruiker: Ubuntu en Debian leveren bij elke installatie een gereserveerd systeemaccount genaamd backup (uid 34, geen login-shell), waardoor adduser backup mislukt en ssh backup@... in nologin terechtkomt.

De nachtelijke taak wordt uitgevoerd als root op de server waarvan een back-up wordt gemaakt, dus root heeft toegang via een sleutel tot de back-uphost nodig. Maak een specifieke sleutel aan zonder wachtwoordzin, omdat er om 03:00 uur 's nachts geen mens aanwezig is om deze in te voeren, en kopieer deze naar de host:

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 niet bekend bent met sleutels, legt basisprincipes van SSH-sleutelbeheer het model, de rechten en het intrekken van een sleutel later uit.

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

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

Kopieer dit wachtwoord nu naar uw wachtwoordbeheerder voordat u verdergaat. Als deze VPS uitvalt, zorgt de repository in combinatie met dit wachtwoord voor volledig herstel; de repository zonder dit wachtwoord is waardeloos.

Initialiseer de 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

Het alternatieve doel is S3-compatibele objectopslag, wat de juiste keuze is wanneer u geen tweede machine wilt beheren. Elke S3-compatibele bucket werkt op dezelfde manier; alleen het adres en twee variabelen voor inloggegevens 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 doelen. De rest van deze handleiding toont het SFTP-adres; vervang dit door uw eigen adres.

De eerste back-up, met uitsluitingen

Maak een back-up van de gegevens die u niet opnieuw kunt installeren, niet van het volledige bestandssysteem. Het besturingssysteem komt terug na een herinstallatie; uw configuratie en uw gegevens niet. Voor een standaard VPS betekent dit /etc, /home, en de locaties waar uw applicaties hun status bijhouden, 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 en het is binnen enkele seconden klaar, waarbij wordt gerapporteerd dat er 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. Die ID's gebruikt u om gegevens te herstellen.

Nachtelijke taken met een systemd timer

Het telkens opnieuw typen van het repository-adres bij elk commando wordt snel vervelend, en een back-up die u handmatig uitvoert, stopt binnen een maand. Beide problemen worden opgelost met één script en één timer. Het script stelt de twee omgevingsvariabelen in die restic uitleest, RESTIC_REPOSITORY en RESTIC_PASSWORD_FILE, waardoor elk commando daarin kort blijft:

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 toegelicht. Nu het schema: een oneshot service die het script uitvoert, en een timer die deze elke nacht om 03:00 uur activeert. Een timer geniet hier de voorkeur boven een cron-regel omdat de uitvoering wordt gelogd naar de journal, en Persistent=true een gemiste back-up uitvoert zodra de server weer online is na een periode van downtime.

# /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

Schakel de timer in, voer de service daarna eenmaal handmatig uit en controleer of deze werkt:

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 uitvoering plaatsvindt. U kunt het paar unit-bestanden ook genereren in plaats van ze handmatig te typen:

Het volledige patroon achter deze twee bestanden, inclusief de kalendersyntaxis en de hardening-richtlijnen die een service kan bevatten, vindt u in een programma uitvoeren als een systemd service op een VPS.

Een back-up is slechts een gerucht totdat u deze herstelt

Beschouw deze zin als een gebod. Een back-uptaak die elke nacht succesvol wordt voltooid, bewijst alleen dat de taak is uitgevoerd; het bewijst niet dat uw gegevens terugkomen. Twee controles dichten dit gat.

Ten eerste restic check, dat het script al elke nacht uitvoert. Dit verifieert de structuur van de repository en de index, zodat stille corruptie op de back-uphost de volgende nacht wordt opgemerkt in plaats van op de dag van herstel. Voer eenmaal per maand de uitgebreidere versie uit, die een willekeurig tiende deel van de werkelijke gegevens 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 elke keer willekeurig is, werken maandelijkse runs zich door de gehele repository heen zonder dat u ooit voor een volledige download hoeft te betalen.

Ten tweede, de hersteloefening. Gebruik nog steeds de root-shell van hierboven, herstel één echte map van 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

diff dat niets afdrukt, betekent dat elke byte identiek is teruggekomen; dit is het enige bewijs dat telt. Verwijder daarna /srv/restore-drill. Voer deze oefening maandelijks uit en doe één of twee keer per jaar de volledige versie: herstel de volledige laatste snapshot naar een tijdelijke VPS en controleer of uw applicatie daadwerkelijk vanaf dat punt opstart. De dag dat u dit onder druk nodig heeft, wilt u dat het een routine is die u al vaker heeft uitgevoerd.

Retentie: forget en prune

Zonder beleid stapelen snapshots zich voor eeuwig op en groeit de repository alleen maar. De forget-regel in 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 op zichzelf alleen de snapshot-records; de datablokken blijven in de repository totdat ze worden verwijderd. Dat is wat --prune doet: het zoekt naar blokken waarnaar geen enkele snapshot meer verwijst en verwijdert deze. Pas op dat moment komt de schijfruimte daadwerkelijk vrij. Prune voert intensief werk uit op de repository; daarom voeren sommige gebruikers forget dagelijks uit en --prune wekelijks. Bij de omvang van een gemiddelde VPS is dagelijks prima.

Databases: eerst een dump maken, daarna pas back-uppen

Restic kopieert bestanden terwijl het deze leest, terwijl een database continu naar zijn bestanden schrijft. Een live databasebestand dat tijdens het schrijven wordt vastgelegd, herstelt als een corrupte database, omdat de kopie pagina's van voor en na een schrijfactie mengt. De oplossing is standaard: laat de database-engine een consistente export naar een bestand genereren en laat restic vervolgens dat bestand back-uppen.

Voeg voor PostgreSQL een dump-regel toe aan het begin van restic-backup.sh, vóór het restic backup-commando, en neem de dump-directory op in de back-uppaden:

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 patroon, schakelt de Nextcloud back-upsectie de onderhoudsmodus in, maakt een dump van Postgres en kopieert de bestanden als één consistente set; precies de set die restic elke nacht van de server moet halen. Voor SQLite geldt hetzelfde principe met een minder zwaar middel: de Vaultwarden-handleiding stopt de container voor enkele seconden om een koude kopie van db.sqlite3 te maken, en dat archief is wat restic vervolgens van de server verplaatst.

FAQ

Zijn restic-back-ups versleuteld?

Ja, altijd. Elke restic-repository is versleuteld met AES-256; er bestaat geen onversleutelde modus en voor elk commando is het repository-wachtwoord vereist. De machine of provider die de repository opslaat, bevat alleen versleutelde blobs, waardoor een gecompromitteerde back-uphost uw bestanden niet blootstelt. De afweging is absoluut: zonder het wachtwoord kan niemand de data herstellen, dus bewaar een kopie op een locatie buiten de server.

Maakt restic incrementele back-ups?

Elke restic-snapshot gedraagt zich als een volledige back-up, terwijl het de opslagkosten van een incrementele back-up heeft. Restic splitst bestanden in chunks en uploadt alleen chunks die nog niet in de repository staan, waardoor een dagelijkse run ongeveer de wijzigingen van die dag overzet. In tegenstelling tot traditionele incrementele schema's is er geen keten die opnieuw moet worden opgebouwd: elke snapshot kan direct worden hersteld en het verwijderen van een oude snapshot maakt een nieuwere nooit onbruikbaar.

Hoe herstel ik bestanden uit een restic-back-up?

Voer restic snapshots uit om het snapshot-ID te vinden en gebruik vervolgens restic restore <id> --target /some/empty/dir om het te herstellen. Voeg --include /path toe om slechts een deel te herstellen. latest werkt in plaats van een ID. Restic reconstrueert de oorspronkelijke mappenstructuur onder de doelmap, dus het herstellen van /etc/ssh komt terecht in /some/empty/dir/etc/ssh. Oefen dit voordat u het nodig heeft, want een ongeteste back-up is slechts een gerucht.

Hoe vaak moet ik restic-back-ups uitvoeren?

Dagelijks is het verstandige minimum voor een server, en dankzij deduplicatie is dit goedkoop: elke run uploadt alleen de chunks die sinds de vorige keer zijn gewijzigd. Data die snel verandert, of waarvan het verlies van zelfs maar één dag pijnlijk zou zijn, kan elke paar uur worden verwerkt met hetzelfde timerpatroon. Frequentie is het makkelijke deel; voer ook regelmatig restic check uit en doe maandelijks een hersteloefening, want een schema zonder verificatie biedt slechts schijnveiligheid.

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

De back-ups zijn onherstelbaar. De versleuteling van restic heeft geen achterdeur en geen resetmogelijkheid, dus het wachtwoord is net zo belangrijk als de back-ups zelf. Bewaar een kopie in uw wachtwoordmanager en op een andere duurzame plek die niet de server is waarvan een back-up wordt gemaakt. Zolang u nog toegang heeft, kan restic key add een tweede wachtwoord voor dezelfde repository registreren, wat u een reservewachtwoord geeft.