Een back-upplan voor je server

Module 8: Back-ups en bewaking · Leestijd: 11 minuten

Leerdoel: Na deze les kun je voor je eigen server een back-upplan maken: wat je bewaart, waar, hoe vaak en hoe lang, en hoe je zeker weet dat terugzetten werkt.

Kernbegrippen: 3-2-1-regel, snapshot, back-up van de aanbieder, eigen back-up buiten de aanbieder, RPO, RTO, databasedump (mariadb-dump, pg_dump), configuratie in /etc, Docker-volumes, versleuteling, ransomware, append-only, terugzettest

Waarom een plan, en niet "er is toch een back-up"?

Bijna iedereen die een server heeft verloren, dacht dat er een back-up was. Dan blijkt die alleen het besturingssysteem te bevatten en niet de database, of hij staat op dezelfde server die nu weg is, of hij is versleuteld door dezelfde ransomware, of niemand weet het wachtwoord. Een back-up is pas iets waard als je hem kunt terugzetten. Daarom begin je met een plan, en eindig je met een test.

Een plan beantwoordt vijf vragen:

1. Wat moet terug kunnen?
2. Hoeveel gegevens mag je kwijtraken? (RPO)
3. Hoe snel moet het weer werken? (RTO)
4. Waar staan de kopieën, en hoeveel?
5. Hoe weet je dat het werkt?

Wat moet terug kunnen?

Een server bestaat uit lagen. Niet elke laag hoeft in de back-up:

Let extra op databases. Een database die draait, schrijft continu. Kopieer je de bestanden van een draaiende MariaDB of PostgreSQL, dan kun je een beschadigde kopie krijgen. Maak daarom eerst een dump: een consistente momentopname als bestand, die je daarna meeneemt in de back-up.

root@web1:~# mariadb-dump --single-transaction --all-databases | gzip > /var/backups/db/alles-$(date +%F).sql.gz
root@web1:~# sudo -u postgres pg_dumpall | gzip > /var/backups/db/pg-$(date +%F).sql.gz

(mariadb-dump heette vroeger mysqldump; dat commando werkt meestal ook nog.) Draait de database in een container, dan doe je hetzelfde met docker compose exec (les 9.4).

RPO en RTO: hoeveel mag je verliezen?

Twee begrippen uit de beroepspraktijk helpen om keuzes te maken:

• RPO (recovery point objective): hoeveel tijd aan gegevens mag je hoogstens kwijtraken? Een dagelijkse back-up om 03:00 betekent: als de server om 22:00 crasht, ben je bijna een dag kwijt. Voor een webwinkel met bestellingen is dat te veel; voor een blog die eens per week verandert prima.
• RTO (recovery time objective): hoe lang mag het duren voor alles weer werkt? Een volledige back-up van de aanbieder terugzetten kan in minuten; een nieuwe server opbouwen en alles met de hand terugzetten kan uren kosten.

Schrijf ze voor je eigen server op. Ze bepalen hoe vaak je een back-up maakt en hoe je hem bewaart.

Snapshot, back-up van de aanbieder, eigen back-up

Op een VPS heb je meestal drie soorten vangnet. Ze lijken op elkaar, maar beschermen tegen iets anders.

1. De snapshot. Een momentopname van de hele virtuele schijf, gemaakt in het paneel van je aanbieder. Snel te maken, snel terug te zetten. Ideaal vlak voor een upgrade (les 4.3). Maar: een snapshot staat bij de meeste aanbieders op dezelfde opslag als je server. Gaat die opslag kapot, of verlies je je account, dan is de snapshot ook weg. En een snapshot bewaar je niet lang: hij groeit mee met alle wijzigingen daarna. Een snapshot is geen back-up.

2. De back-up van de aanbieder. Veel aanbieders maken (eventueel als optie) automatisch elke dag een kopie van je hele server, op andere opslag. Bij WebOké is dat bijvoorbeeld een dagelijkse back-up van de hele VPS die zeven dagen bewaard wordt; bij andere aanbieders werkt het vergelijkbaar, met eigen termijnen. Dat is een goede tweede laag tegen kapotte hardware en tegen je eigen vergissingen van gisteren. Maar het blijft één partij: je account, je betaling, hun storing. En terugzetten gaat meestal voor de hele server tegelijk.

3. Je eigen back-up, buiten de aanbieder. Een kopie van je gegevens bij een andere partij of op een andere plek, die jij maakt en beheert (les 8.2). Dit is de laag die overblijft als al het andere misgaat.

De 3-2-1-regel

Een gangbare vuistregel:

• 3 kopieën van je gegevens (het origineel plus twee back-ups);
• op 2 verschillende soorten opslag of systemen;
• waarvan 1 op een andere locatie.

Voor een VPS kan dat zijn: de gegevens op de server, de dagelijkse back-up van de aanbieder, en een versleutelde eigen back-up met restic naar opslag bij een andere partij. Een moderne aanvulling is dat minstens één kopie niet te wissen is door wie de server overneemt (offline, of append-only, les 8.2). Ransomware op een server zoekt actief naar back-ups om die ook te versleutelen of te wissen. Een back-up die de server zelf mag wissen, is daartegen geen bescherming.

Versleutelen en het wachtwoord van je back-up

Een back-up bij een andere partij moet versleuteld zijn: er staan klantgegevens, wachtwoorden en sleutels in. restic (les 8.2) versleutelt standaard. Maar daarmee ontstaat een nieuw risico: het wachtwoord van je back-up. Ben je dat kwijt, dan is de back-up onbruikbaar. En staat het alleen op de server die je kwijt bent, dan ook.

Bewaar het wachtwoord daarom ook buiten de server: in je wachtwoordmanager, en eventueel op papier in een kluis. Hetzelfde geldt voor de toegangsgegevens van de opslag waar je back-up staat.

Terugzetten testen

Het belangrijkste deel van het plan. Een terugzettest betekent: je zet een back-up echt terug, op een plek waar het niets kapotmaakt, en je controleert of het resultaat werkt.

• Klein en vaak: één bestand of één map terugzetten naar /tmp/terug en vergelijken (diff). Bijvoorbeeld maandelijks.
• Groot en af en toe: een complete nieuwe testserver opbouwen uit de back-up, de database importeren, de website starten. Bijvoorbeeld een keer per jaar, of bij elke grote wijziging. Dit is ook meteen de oefening voor als het echt misgaat (les 10.3).

Schrijf op hoe lang het duurde: dat is je echte RTO.

Bewaartermijnen

Bewaar niet alleen de laatste back-up. Ontdek je pas na twee weken dat een bestand beschadigd of gewist is, dan heb je een back-up van drie weken geleden nodig. Een gangbaar schema: zeven dagelijkse, vier wekelijkse en zes maandelijkse versies. restic regelt dat met forget (les 8.2). Denk ook aan de AVG: persoonsgegevens bewaar je niet langer dan nodig, ook niet in back-ups. Leg je bewaartermijnen vast.

In de praktijk

Gebruik de snapshot van je aanbieder vlak voor riskante wijzigingen en verwijder hem daarna; laat de dagelijkse back-up van de aanbieder aanstaan als die er is; en maak daarnaast je eigen versleutelde back-up van gegevens en configuratie naar een andere partij. Bij WebOké heet dat in het VPS-scherm Snapshots en Backups; bij andere aanbieders zijn de namen en termijnen anders, maar het principe is hetzelfde. Een hostingpakket of beheerde dienst heeft vaak andere afspraken: kijk wat er in jouw geval geregeld is.

Samenvatting

• Een back-up is pas iets waard als terugzetten werkt; begin met een plan en eindig met een test.
• Back-up vooral gegevens en configuratie: databases als dump, /etc, websites, Docker-volumes, compose-bestanden.
• Bepaal RPO (hoeveel mag je verliezen) en RTO (hoe snel moet het werken).
• Snapshot (zelfde opslag, kort), back-up van de aanbieder (andere opslag, zelfde partij) en een eigen back-up buiten de aanbieder zijn drie verschillende lagen; volg de 3-2-1-regel met minstens één kopie die de server zelf niet kan wissen.
• Versleutel, bewaar het back-upwachtwoord buiten de server, en test terugzetten klein en vaak, groot af en toe.

Quiz

Opdracht

Opdracht O8.1: Je back-upplan. Maak voor je eigen server een back-upplan op één pagina: wat moet terug kunnen (per laag), je RPO en RTO, welke kopieën je hebt (snapshot, aanbieder, eigen) en waar, je bewaartermijnen, waar het back-upwachtwoord staat, en wanneer je een terugzettest doet. Vul het formulier in; na het insturen zie je een voorbeeldplan om je eigen plan naast te leggen.

Verder lezen

• Snapshots en backups van je VPS
• Back-upstrategie: de 3-2-1-regel voor je eigen bedrijf
• Hoe maak ik een back-up van mijn MySQL-database?
• In de cursus Veilig online: de lessen over de 3-2-1-regel en back-ups die ransomware overleven.
• MariaDB, mariadb-dump: https://mariadb.com/docs/server/clients-and-utilities/backup-restore-and-import-clients/mariadb-dump
• PostgreSQL, Backup and Restore (SQL Dump): https://www.postgresql.org/docs/current/backup-dump.html