Back-ups van je VPS: wat wij back-uppen en hoe je het zelf doet

De back-ups van je VPS beheren wij, en in je klantaccount herstel je daaruit de hele schijf. Voor losse bestanden, databases en een kopie buiten onze infrastructuur stel je eigen back-ups in. We laten beide zien.

Automatische back-ups van StormHost#

We maken automatisch back-ups van je VPS. Je vindt ze in je klantaccount: Mijn diensten › je VPS › tabblad Back-ups.

• De lijst toont bij elke back-up Aangemaakt (datum en tijd), Grootte en de Opslag waarop die staat.
• Handmatig een back-up maken vanuit je klantaccount is niet mogelijk. Maak daarom vóór een riskante ingreep (een upgrade van het systeem, een grote configuratiewijziging) een eigen back-up volgens de rest van deze handleiding.
• Verschijnt de melding “Een van de back-upopslagen reageert nu niet, de lijst is mogelijk onvolledig”, dan is een deel van de back-ups tijdelijk niet beschikbaar. Probeer het later opnieuw, of stuur ons een bericht.
• Een lid van een gedeelde dienst ziet de back-ups alleen met de machtiging Back-ups en herstel.

De hele VPS herstellen#

1. Zoek op het tabblad Back-ups de back-up op aan de hand van de datum in de kolom Aangemaakt.
2. Klik op Herstellen.
3. Lees de waarschuwing en bevestig die door de schuifregelaar te verslepen (“Schuif om te herstellen”).
4. Wacht tot het klaar is. Tijdens het herstellen is de VPS uitgeschakeld en vergrendeld, de console maakt geen verbinding.
5. Start de VPS na het herstellen (als die niet vanzelf start) en controleer je services.

Alles herstellen, of losse bestanden?#

De 3-⁠2-⁠1-⁠regel#

Een beproefde regel voor back-ups: 3 kopieën van je gegevens, op 2 verschillende plekken of soorten opslag, waarvan 1 buiten de hoofdinfrastructuur.

Voor een VPS betekent dat:

1. De gegevens op de VPS (de oorspronkelijke kopie).
2. Onze automatische back-ups (de tweede kopie, buiten jouw VPS).
3. Je eigen back-up ergens anders: een NAS thuis, een andere server, cloudopslag (de derde kopie, buiten onze infrastructuur).

De derde kopie beschermt je ook in situaties waarin herstellen in je klantaccount niet helpt: je hebt een oudere toestand nodig, een los bestand, of je wilt verhuizen.

Wat je back-upt#

Het back-upscript#

Het script maakt elke dag een export van alle databases en een archief van de belangrijke mappen, en verwijdert back-ups die ouder zijn dan 7 dagen.

1. Maak het scriptbestand aan:

   nano /usr/local/sbin/zaloha.sh

2. Plak de inhoud erin:

   #!/bin/bash
   set -euo pipefail
   umask 077
   
   CIL=/var/backups/vps
   DNES=$(date +%F)
   UCHOVAT_DNI=7
   
   mkdir -p "$CIL"
   
   # 1) databases (alleen als MariaDB/MySQL is geïnstalleerd)
   if command -v mariadb-dump >/dev/null 2>&1; then
     mariadb-dump --single-transaction --routines --events --all-databases | gzip > "$CIL/db-$DNES.sql.gz"
   fi
   
   # 2) bestanden
   tar -czf "$CIL/soubory-$DNES.tar.gz" --ignore-failed-read /etc /home /root /var/www /opt /srv || [ $? -eq 1 ]
   
   # 3) oude back-ups verwijderen
   find "$CIL" -type f -name '*.gz' -mtime +"$UCHOVAT_DNI" -delete
   
   echo "$(date '+%F %T') back-up klaar"

3. Sla op (Ctrl+O, Enter), sluit af (Ctrl+X) en maak het script uitvoerbaar:

   chmod 700 /usr/local/sbin/zaloha.sh

   • chmod 700 – alleen root mag het script lezen en uitvoeren.

Wat het script doet:

4. Probeer het script handmatig uit:

   /usr/local/sbin/zaloha.sh
   ls -lh /var/backups/vps

   Je ziet back-up klaar en de bestanden db-….sql.gz en soubory-….tar.gz. De melding tar: Removing leading '/' from member names is normaal: paden worden zonder de eerste schuine streep in het archief opgeslagen.

Automatisch uitvoeren met cron#

1. Zorg dat cron is geïnstalleerd (staat het er al, dan gebeurt er niets):

   apt -y install cron

2. Open de crontab van root:

   crontab -e

   Kies bij de eerste keer de editor nano.

3. Voeg aan het einde deze regel toe:

   30 3 * * * /usr/local/sbin/zaloha.sh >> /var/log/zaloha.log 2>&1

4. Sla op en sluit de editor. Je ziet crontab: installing new crontab.

Een regel in de crontab heeft vijf tijdvelden en een commando:

Meer voorbeelden van tijden:

De tijd volgt de tijdzone van de VPS (timedatectl). Plan back-ups op een moment waarop de server het minst wordt gebruikt.

Overzetten buiten de VPS#

SSH-toegang tot de doelserver voorbereiden#

Je stuurt de back-ups naar een andere server (een NAS thuis met SSH, een andere VPS). In de voorbeelden heeft de doelserver het IP-adres 198.51.100.25, vul in plaats daarvan het adres van je eigen server in.

Maak op de doelserver (Ubuntu of Debian, ingelogd als root) een gebruiker aan en een map waarin die mag schrijven:

adduser zaloha
mkdir -p /srv/zalohy
chown zaloha:zaloha /srv/zalohy
chmod 700 /srv/zalohy

• adduser zaloha – maakt de gebruiker zaloha aan. Er wordt om een wachtwoord gevraagd (dat heb je nodig in stap 2 hieronder) en om optionele gegevens, die je bevestigt met de toets Enter.
• mkdir -p /srv/zalohy – de map voor de back-ups.
• chown zaloha:zaloha – de map wordt eigendom van de gebruiker zaloha, zodat die erin kan schrijven. Zonder dit eindigen zowel rsync als restic met de fout Permission denied.
• chmod 700 – niemand anders mag in de map komen.

Op de doelserver moet inloggen met een wachtwoord zijn toegestaan, in elk geval totdat je de sleutel hebt geüpload (stap 2). Volg bij een NAS de handleiding van het apparaat (gebruiker, gedeelde map, SSH ingeschakeld).

Daarna op de VPS waarvan je een back-up maakt:

1. Maak een SSH-sleutel zonder wachtwoord aan, die alleen voor de back-ups wordt gebruikt:

   ssh-keygen -t ed25519 -f /root/.ssh/zaloha -N "" -C "zaloha-vps"

   • -t ed25519 – een modern type sleutel.
   • -f /root/.ssh/zaloha – waar de sleutel wordt opgeslagen (er ontstaan zaloha en zaloha.pub).
   • -N "" – geen wachtwoord op de sleutel, zodat cron die zonder jou kan gebruiken.
   • -C "zaloha-vps" – een omschrijving van de sleutel.

2. Upload de publieke sleutel naar de doelserver (je voert het wachtwoord van de gebruiker zaloha op de doelserver in):

   ssh-copy-id -i /root/.ssh/zaloha.pub [email protected]

   Bij de eerste verbinding vraagt SSH Are you sure you want to continue connecting (yes/no/[fingerprint])?. Typ yes: de vingerafdruk van de doelserver wordt opgeslagen in /root/.ssh/known_hosts en cron krijgt die vraag daarna niet meer.

3. Maak een snelkoppeling voor de verbinding. Open nano /root/.ssh/config en voeg toe:

   Host zalohy
       HostName 198.51.100.25
       User zaloha
       IdentityFile /root/.ssh/zaloha

   • Host zalohy – de snelkoppeling die je daarna in plaats van het adres gebruikt.
   • HostName – het IP-adres of domein van de doelserver.
   • User – de gebruiker op de doelserver.
   • IdentityFile – de sleutel om mee in te loggen.

4. Test de verbinding: ssh zalohy moet zonder wachtwoord inloggen. Log uit met het commando exit.

Het werken met sleutels in detail: SSH-sleutel.

rsync#

rsync kopieert alleen gewijzigde bestanden en is daardoor ook bij grote back-ups snel. Het moet aan beide kanten geïnstalleerd zijn (apt -y install rsync).

rsync -az /var/backups/vps/ zalohy:/srv/zalohy/vps1/

• -a – archiefmodus: kopieert recursief en behoudt rechten, tijden en koppelingen.
• -z – comprimeert de gegevens tijdens de overdracht.
• /var/backups/vps/ – wat er wordt gekopieerd. De schuine streep aan het einde betekent “de inhoud van de map”, niet de map zelf.
• zalohy:/srv/zalohy/vps1/ – het doel: de snelkoppeling uit ~/.ssh/config en de map op de doelserver.

Neem de overdracht op als laatste regel van het script zaloha.sh, of in de crontab een uur na de back-up:

30 4 * * * rsync -az /var/backups/vps/ zalohy:/srv/zalohy/vps1/ >> /var/log/zaloha.log 2>&1

restic (voor gevorderden)#

restic slaat back-ups versleuteld en met deduplicatie op: gegevens die zich herhalen, worden maar één keer opgeslagen, zodat je tientallen dagelijkse versies kunt bewaren met weinig ruimte. Het kan back-ups maken naar een SFTP-server en ook naar cloudopslag.

1. Installeer restic: apt -y install restic.

2. Maak een bestand aan met het wachtwoord van de repository en beperk de rechten ervan:

   nano /root/.restic-heslo
   chmod 600 /root/.restic-heslo

   Zet in het bestand een lang, willekeurig wachtwoord (wachtwoordgenerator).

3. Maak de repository aan op de doelserver:

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo init

   • -r sftp:zalohy:/srv/zalohy/restic-vps1 – een repository via SFTP; zalohy is de snelkoppeling uit ~/.ssh/config.
   • --password-file – het bestand met het wachtwoord, zodat restic er niet om vraagt (nodig voor cron).
   • init – maakt een nieuwe, lege repository aan. Je ziet created restic repository ….

4. Maak een back-up (je kunt het commando in het script zetten in plaats van het tar-archief; laat de export van de database staan):

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo backup /etc /home /root /var/www /opt /srv /var/backups/vps

5. Verwijder oude versies volgens een regel:

   restic -r sftp:zalohy:/srv/zalohy/restic-vps1 --password-file /root/.restic-heslo forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

   • forget – verwijdert de versies (snapshots) die de regel niet bewaart.
   • --keep-daily 7 – bewaart de laatste versie van elk van de 7 laatste dagen met een back-up.
   • --keep-weekly 4, --keep-monthly 6 – daarnaast één versie per week over 4 weken en één per maand over 6 maanden.
   • --prune – verwijdert meteen de gegevens waar geen enkele versie meer naar verwijst (maakt ruimte vrij).

Handige commando's:

Een alternatief voor restic is BorgBackup (documentatie (opent in een nieuw venster)), dat volgens een vergelijkbaar principe werkt.

Het herstellen testen#

Een back-up die je nooit hebt geprobeerd te herstellen, is alleen maar hoop. Probeer het ten minste af en toe uit:

1. Toon de inhoud van het archief: tar -tzf /var/backups/vps/soubory-2026-10-01.tar.gz | head.

2. Pak één bestand uit in een tijdelijke map:

   mkdir -p /tmp/obnova
   tar -xzf /var/backups/vps/soubory-2026-10-01.tar.gz -C /tmp/obnova etc/nginx/nginx.conf

   • -x – uitpakken, -z – het formaat gzip, -f – uit een bestand.
   • -C /tmp/obnova – waar wordt uitgepakt (zo wordt het actieve bestand niet overschreven).
   • etc/nginx/nginx.conf – wat er wordt uitgepakt (het pad zonder de eerste schuine streep).

3. Controleer de export van de database: zcat /var/backups/vps/db-2026-10-01.sql.gz | head -n 20 moet het begin van een SQL-export tonen.

4. Doe een volledige test (de database herstellen, de applicatie starten) op een andere VPS, een test-VPS, niet op je productie-VPS.

Controle#

• De ochtend na de eerste nacht: tail /var/log/zaloha.log bevat de regel back-up klaar.
• ls -lh /var/backups/vps toont nieuwe bestanden met de datum van vandaag en een redelijke grootte (niet 0 bytes).
• Op de doelserver staan dezelfde bestanden (rsync), of restic snapshots toont de versie van vandaag.

Als iets niet werkt#

Cron heeft het script niet uitgevoerd#

Controleer of cron draait en wat er in het log is geschreven:

systemctl status cron
journalctl -u cron -n 50

Veelvoorkomende oorzaken: in de crontab ontbreekt het volledige pad naar het script, het script heeft geen uitvoerrecht (chmod 700), of je hebt de crontab van een andere gebruiker dan root aangepast (crontab -l toont die).

mariadb-dump: Got error: 1045: "Access denied for user …"#

Het script draait niet als root, of de root van de database gebruikt een wachtwoord in plaats van de unix socket. Voer het script uit vanuit de crontab van root. Heeft root in de database een wachtwoord, sla dat dan op in het bestand /root/.my.cnf, waar mariadb-dump het zelf uit leest:

[client]
user=root
password=<DB_ROOT_PASSWORD>

• [client] – de groep met opties voor alle clientprogramma's van MariaDB (mariadb, mariadb-dump).
• user, password – de inloggegevens. Vul in plaats van <DB_ROOT_PASSWORD> het wachtwoord van de databasegebruiker root in (zonder de punthaken).

Beveilig het bestand met het commando chmod 600 /root/.my.cnf, zodat niemand anders het wachtwoord kan lezen.

De back-up is 0 bytes of verdacht klein#

Het script is halverwege met een fout gestopt. Voer het handmatig uit en lees de fout. Dankzij set -euo pipefail blijft een fout bij de export niet onopgemerkt.

Permission denied (publickey) bij rsync of restic#

De doelserver heeft de sleutel niet geaccepteerd. Controleer ssh zalohy. Vraagt die om een wachtwoord of mislukt het, upload de sleutel dan opnieuw (ssh-copy-id) en controleer of IdentityFile in /root/.ssh/config naar het juiste bestand verwijst.

restic: Fatal: wrong password or no key found#

Het wachtwoord in het bestand /root/.restic-heslo komt niet overeen met de repository. Controleer of er in het bestand geen extra spatie of een ander wachtwoord staat.

restic: Fatal: unable to open config file … Is there a repository at the following location?#

Op het opgegeven pad bestaat geen repository (een typefout in het pad, of je hebt init niet uitgevoerd).

De schijf raakt vol#

De back-ups worden niet verwijderd, of ze zijn te groot. Controleer of de stap find … -delete wordt uitgevoerd, verlaag UCHOVAT_DNI en laat mappen met veel gegevens weg waarvan je op een andere manier een back-up maakt.

Meer bronnen#

• restic: documentatie (opent in een nieuw venster)
• BorgBackup: documentatie (opent in een nieuw venster)
• rsync: manpagina (opent in een nieuw venster)
• crontab(5): het formaat van de crontab (opent in een nieuw venster)
• MariaDB: mariadb-dump (opent in een nieuw venster)