Praktische handleiding / Back-up en herstel

Een VPS-back-up herstellen en de bestanden controleren

Een VPS-back-up herstellen is pas overtuigend als de kopie buiten de VPS bereikbaar is en de verwachte bestanden terugkomen. Deze oefening archiveert een statische pagina en één Nginx-configuratie en controleert de herstelde bytes zonder een werkende website aan te raken.

VPSuntu · Bijgewerkt: 27 september 2026 · circa 4 minuten lezen

In deze handleiding

Baken de oefening af

Gebruik Bash, GNU tar, sha256sum en OpenSSH op Ubuntu of een Linux/WSL-client. Houd één serverterminal en één terminal op een aparte computer open: variabelen blijven in die sessies beschikbaar. Stop na elke commandofout.

Begin met twee tijdelijke oefenbestanden in je home. Activeer geen Nginx-configuratie en pak nooit als root uit. De optionele echte bestanden komen uit de HTTPS-handleiding. Voor een grotere site heb je ook assets, redirects, includes, DNS en andere afhankelijkheden nodig; dit is geen volledige machineback-up.

Maak twee oefenbestanden

Maak op de server een privé-oefenmap. De configuratie is alleen een tekstbestand om te archiveren.

umask 077
backup_lab=$(mktemp -d "$HOME/ubuntu-vps-backup.XXXXXX")
mkdir -p "$backup_lab/payload/site" "$backup_lab/payload/nginx" "$backup_lab/export"
printf '%s\n' '<!doctype html><html lang="nl"><title>Hersteloefening</title><h1>Herstelde statische pagina</h1></html>' > "$backup_lab/payload/site/index.html"
printf '%s\n' 'server {' '    listen 8080;' '    server_name example.test;' '    root /var/www/first-site;' '}' > "$backup_lab/payload/nginx/first-site.conf"
printf 'Oefenmap: %s\n' "$backup_lab"

Optioneel: vervang alleen deze tijdelijke kopieën door de twee echte tutorialbestanden. Beide bronnen moeten leesbaar zijn voor je account. Controleer de configuratie op geheimen en pauzeer publicaties zodat de bestanden dezelfde release beschrijven. Sla dit blok over voor de gewone oefening.

install -m 600 /var/www/first-site/index.html "$backup_lab/payload/site/index.html"
install -m 600 /etc/nginx/sites-available/first-site "$backup_lab/payload/nginx/first-site.conf"

Deze opdrachten wijzigen de live bron niet en kopiëren geen certificaatprivésleutels of volledige systeemmappen. Voeg andere benodigde bestanden bewust toe aan inventaris én manifest.

Archiveer en controleer op twee niveaus

Laat de payload ongewijzigd tijdens de volgende serveropdrachten: bestandchecksums, archief met relatieve paden en archiefchecksum.

(
    cd "$backup_lab/payload" &&
    sha256sum site/index.html nginx/first-site.conf > SHA256SUMS
)
tar -czf "$backup_lab/export/static-site.tar.gz" -C "$backup_lab/payload" site nginx SHA256SUMS
(
    cd "$backup_lab/export" &&
    sha256sum static-site.tar.gz > static-site.tar.gz.sha256
)
tar -tzf "$backup_lab/export/static-site.tar.gz"
printf 'Exportmap op de server: %s\n' "$backup_lab/export"

De lijst hoort site/, nginx/, beide bestanden en SHA256SUMS te bevatten. De buitenste checksum controleert de overdracht; het manifest controleert uitgepakte bestanden. Geen van beide bewijst authenticiteit als iemand zowel gegevens als verwachte checksum kan vervangen.

Kopieer naar een andere computer

Stel op de client remote_backup in op het exacte exportpad van de server. Vervang adres, gebruiker en sleutel door werkende SSH-gegevens. 203.0.113.10 is een voorbeeld en REPLACE is niet de door mktemp gemaakte suffix.

umask 077
recovery_dir=$(mktemp -d "$HOME/ubuntu-vps-restore.XXXXXX")
remote_backup=/home/deploy/ubuntu-vps-backup.REPLACE/export
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz" "$recovery_dir/"
scp -i ~/.ssh/ubuntu_vps "deploy@203.0.113.10:$remote_backup/static-site.tar.gz.sha256" "$recovery_dir/"

Controleer bij een nieuwe host de vingerafdruk via een vertrouwd kanaal. Gebruik bij verbindingsfouten de SSH-diagnose; omzeil de hostsleutelcontrole niet.

SCP beschermt de overdracht. tar.gz is gecomprimeerd, niet versleuteld. Bescherm doelaccount en opslag en gebruik waar nodig versleuteling in rust. Een tweede map op dezelfde VPS is geen externe back-up.

Herstel naar een nieuwe lege map

Controleer op de client het archief vóór uitpakken. Ga alleen door bij OK; onderzoek een mismatch of kopieer opnieuw. Pas de verwachte checksum niet aan om de fout te verbergen.

(
    cd "$recovery_dir" &&
    sha256sum -c static-site.tar.gz.sha256
)
tar -tzf "$recovery_dir/static-site.tar.gz"

Pak dit vertrouwde archief uit in een nieuwe map. keep-old-files weigert overschrijven; no-same-owner neemt de opgeslagen eigenaar niet over. Gebruik geen sudo en verander het doel niet naar /.

restore_dir=$(mktemp -d "$recovery_dir/restored.XXXXXX")
tar -xzf "$recovery_dir/static-site.tar.gz" -C "$restore_dir" --keep-old-files --no-same-owner
(
    cd "$restore_dir" &&
    sha256sum -c SHA256SUMS
)
cat "$restore_dir/site/index.html"

Verwacht tweemaal OK en de herstelde paginakop. Dit controleert inhoud, niet productie-eigendom, ACL’s, bereikbaarheid of iedere afhankelijkheid.

Scheid bestanden van een werkende dienst

De teruggezette Nginx-configuratie blijft inactieve tekst. Controleer paden, includes, modules, rechten en certificaten op een aparte vervangende server. Valideer daar de samengestelde configuratie vóór herladen en test HTTP/HTTPS extern. Een test van de ongewijzigde live server bewijst deze kopie niet.

TLS-privésleutels zijn bewust uitgesloten. Plan heruitgifte of een afzonderlijk beschermde certificaatback-up. Kopieer geen actieve databasebestanden met dit recept; gebruik de consistente back-up- en herstelmethode van die database.

Snapshots kunnen helpen, maar controleer bewaartermijn, storingsdomein en herstelprocedure. Hun bestaan bewijst geen herstel van de geëxporteerde site op een andere host.

Leg hersteldoelen en uitkomst vast

RPO beschrijft aanvaardbaar gegevensverlies in tijd; RTO de gewenste hersteltijd van de dienst. Voor een kleine statische site zijn 24 uur RPO en 60 minuten RTO denkbare bedrijfsdoelen, geen gemeten resultaat. Dagelijkse back-ups helpen alleen als ze slagen en herstelbaar blijven.

Schuif de tabel opzij om alle kolommen te bekijken.

RegistratieWat dit aantoont
Back-uptijd en release-IDWelke versie terugkomt
Externe locatie en retentieWaar de kopie blijft en hoelang
Archief- en bestandchecksumsOf de gekozen bytes hersteld zijn
Begin- en eindtijdDuur van de beschreven herstelstappen
Ontbrekende rechten of afhankelijkhedenWat nog nodig is voor de dienst
Externe HTTPS-test op de vervangerOf de website daadwerkelijk terug is

Meet het hele vervangingsproces, inclusief toegang, VM, configuratie, certificaten en zo nodig DNS. Snel lokaal uitpakken is geen storingsbenchmark. Bewaar meerdere geschikte herstelpunten en controleer mislukte taken. Neem herstelondersteuning mee bij de hostingkeuze.

De GNU-commando’s voor de bestandsoefening zijn lokaal getest in Git Bash op Windows. Dat was geen test van een Ubuntu-server, externe SSH-overdracht, certificaatherstel of Nginx-activatie.

Veelgestelde vragen

Moet ik de originele website verwijderen om herstel te testen?

Nee. Herstel in een aparte lege map en test de volledige dienst in een vervangende omgeving.

Bewijst een geslaagde checksum een volledige back-up?

Alleen de bestanden in het manifest zijn gecontroleerd. Ontbrekende assets, databases en DNS-instellingen worden er niet door ontdekt.

Is een snapshot genoeg?

Controleer locatie, bewaartermijn en daadwerkelijk herstel. Een onafhankelijke kopie test een ander herstelpad.

Een logische volgende stap

Alle handleidingen →
Je volgende stap

Kies ruimte voor je project.

Controleer de beschikbare configuraties en actuele voorwaarden.

Bekijk de serversAffiliatelink · Bestellen doe je bij de provider.