Serverback-ups: de 3-2-1-regel en hoe je herstelt

De 3-2-1-regel zegt: bewaar drie kopieën van je belangrijke gegevens (het origineel en twee back-ups), op twee verschillende soorten opslag, en bewaar minstens één kopie ergens anders. Op een VPS betekent dat minstens één kopie buiten de server, naast de gegevens op de server zelf.

Dezelfde regel wordt aanbevolen in het document Data Backup Options, opgesteld voor US-CERT en gepubliceerd op de website van CISA. Het doel is te zorgen dat één storing, fout of aanval niet alle kopieën tegelijk kan vernietigen.

Een back-up, een snapshot en schijfredundantie zijn niet hetzelfde

• Back-up: een aparte kopie van je gegevens, meestal met eerdere versies. Je haalt er een bestand mee terug dat per ongeluk is verwijderd of beschadigd.
• Snapshot: legt de toestand van de server op dat moment vast. Handig als snelle weg terug vóór een grote update. Maar hij is afhankelijk van de oorspronkelijke schijf, dus hij vervangt geen back-up.
• Schijfredundantie: dezelfde gegevens worden tegelijk naar twee schijven geschreven. Het beschermt je als één schijf uitvalt. Een bestand dat je verwijdert, verdwijnt van beide schijven, en gegevens die door ransomware zijn versleuteld, zijn op beide versleuteld. Het is dus geen back-up.

Zo pas je 3-2-1 toe op een VPS

De dagelijkse back-up van het paneel kun je als een van je kopieën meetellen. Maar de kopie die aan de voorwaarde "ergens anders" voldoet, is er een die je zelf instelt en beheert. In de gebruiksvoorwaarden van Seturack staat ook dat je een kopie van je belangrijke gegevens apart bewaart.

Wat je moet back-uppen

Bestanden van een draaiende database kopiëren kan een inconsistente back-up opleveren. Maak eerst een dump. Deze opdrachten draaien als root, zoals ze dat in een cronscript zouden doen:

mysqldump --single-transaction --all-databases | gzip > /var/backups/mysql-$(date +%F).sql.gz

sudo -u postgres pg_dumpall | gzip > /var/backups/pg-$(date +%F).sql.gz

Voor bestanden volstaat dit: /etc, de bestanden van je website, de gegevensmap van je applicatie, Docker-volumes als je Docker gebruikt, en .env-bestanden. Maak geen back-up van wat je opnieuw kunt downloaden, zoals pakketten en Docker-images. Heeft je applicatie een versleutelingssleutel, bewaar die dan ook apart. Bij sommige applicaties is een back-up zonder die sleutel waardeloos.

Hoe vaak je een back-up maakt hangt af van hoeveel gegevens je kunt missen. Eén back-up per dag betekent in het slechtste geval maximaal een dag aan gegevens kwijt. Bij een applicatie die bestellingen of betalingen vastlegt, is het veiliger om elk uur de database te dumpen en die naar buiten de server te sturen.

Een back-up buiten de server met restic

restic is een open source back-uptool die je back-ups versleutelt en herhaalde gegevens maar één keer opslaat. Het onderstaande voorbeeld schrijft de back-up naar een andere server die via SFTP wordt bereikt. Op het doel moet inloggen via SSH zonder wachtwoord (met een sleutel) mogelijk zijn, want een geautomatiseerde back-up kan geen wachtwoordvraag beantwoorden. Maak het wachtwoordbestand (/root/.restic-password) in een teksteditor en voer er chmod 600 op uit.

sudo apt install -y restic

export RESTIC_REPOSITORY=sftp:[email protected]:/backups/vps

export RESTIC_PASSWORD_FILE=/root/.restic-password

restic init

restic backup /etc /var/www /var/backups

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

De restic-documentatie waarschuwt dat je gegevens voorgoed kwijt zijn als je het wachtwoord verliest. Bewaar het wachtwoord ook in een wachtwoordmanager. Zet de twee export-regels, de databasedumps, restic backup en restic forget in die volgorde in een script zoals /usr/local/bin/backup.sh en maak het uitvoerbaar met chmod +x. Vergeet niet onderaan een regel toe te voegen die oude dumps verwijdert, find /var/backups -name '*.sql.gz' -mtime +2 -delete, anders lopen de dumpbestanden de schijf vol. Laat het script daarna elke nacht draaien, bijvoorbeeld vanuit /etc/cron.d/backup met deze regel:

30 3 * * * root /usr/local/bin/backup.sh

borg is een vergelijkbare tool. Voor gewone bestandskopieën kun je rsync gebruiken en voor het versturen van gegevens naar objectopslag rclone.

De echte test: herstellen

Een back-up die je niet kunt herstellen is waardeloos. Probeer het meteen nadat je alles hebt ingesteld en daarna met regelmatige tussenpozen:

• Pak met restic de nieuwste back-up uit naar een lege map en controleer de bestanden: restic restore latest --target /tmp/restore-test
• Laad een databasedump in een tijdelijke database en bekijk de tabellen.
• Klik in het paneel op het pictogram Bestanden eruit halen naast een back-up, blader erin en download één bestand. Een volledig herstel vervangt de volledige huidige schijf, dus één bestand terughalen is de veiligere manier om te testen.

Kies hoe lang je back-ups bewaart op basis van hoe laat je een probleem kunt opmerken. De paneelback-up bewaart de laatste 7 dagen en verder terug kun je niet. Heb je mogelijk oudere versies nodig, bewaar dan wekelijkse en maandelijkse versies in je eigen kopie. Zie voor de details van de paneelback-up het artikel over dagelijkse back-ups.

Veelgemaakte fouten

• De back-up naar de schijf van dezelfde server schrijven. Loopt de schijf vol of raak je de server kwijt, dan verdwijnt de back-up mee.
• Het wachtwoord of de sleutel van de back-up op dezelfde plek bewaren als de back-up zelf.
• Niet merken dat het script faalt. Voeg een melding toe aan het script, of controleer af en toe de datum van de laatste back-up met restic snapshots.
• Niet in de gaten houden dat het back-updoel volloopt. Een vol doel betekent back-ups die stilletjes mislukken.