# Back-upstrategie voor servers: back-ups volgens de 3-2-1-regel

> Back-upstrategie voor servers volgens de 3-2-1-regel: wat u moet veiligstellen, hoe back-ups een aanval overleven en waarom u het herstel moet testen.

Bron: https://phpsos.de/nl/ratgeber/backups-3-2-1/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Een stevige back-upstrategie voor servers volgt de 3-2-1-regel: drie kopieën, twee opslagsoorten, één kopie buitenshuis. Opdat back-ups ook een aanval overleven, heeft minstens één kopie bescherming nodig tegen verwijdering door de server zelf. En pas een geslaagde herstelproef toont dat de back-up in een noodgeval werkt.

## Wat de 3-2-1-regel betekent

De 3-2-1-regel is een eenvoudig, al jaren bewezen uitgangspunt voor gegevensback-up:

- **3 kopieën:** de originele gegevens en twee back-ups.
- **2 opslagsoorten:** bijvoorbeeld lokale schijf en objectopslag, of serveropslag en tape.
- **1 kopie buitenshuis:** op een andere locatie, bij een andere aanbieder of offline.

Voor webservers betekent dat concreet: een back-up op dezelfde schijf als de website telt niet als zelfstandige kopie. Valt de server uit of wordt hij gecompromitteerd, dan zijn beide verloren. Voor de directie luidt de kernvraag daarom niet „Hebben we back-ups?”, maar „Kunnen we de bedrijfsvoering herstellen uit een kopie die het incident niet heeft bereikt?”

## Een back-upstrategie voor servers die een aanval overleeft

Aanvallers weten dat back-ups hun werk teniet doen. Wie toegang heeft tot een server, zoekt daarom vaak ook naar back-ups om ze te verwijderen of te versleutelen. Een moderne strategie breidt de 3-2-1-regel daarom vaak uit tot **3-2-1-1-0**: een extra kopie offline of onveranderbaar, en nul fouten bij de herstelproef.

Drie principes maken back-ups weerbaar:

- **Pull in plaats van push:** Een afzonderlijk back-upsysteem haalt de gegevens bij de webserver op. De webserver zelf heeft geen toegangsgegevens waarmee hij back-ups zou kunnen verwijderen.
- **Onveranderbaarheid:** Objectopslag met bewaarvergrendeling of snapshots die gedurende een vastgelegde tijd niet te verwijderen zijn.
- **Gescheiden toegangen:** Het back-upaccount is niet hetzelfde als het klantaccount bij de hoster en heeft een eigen tweede factor.

> **Belangrijk:**
> Versleutel back-ups die buitenshuis staan en bewaar de sleutel gescheiden. Een verloren sleutel maakt de back-up onbruikbaar, een meegeslagen sleutel maakt de versleuteling waardeloos.

## Wat moet worden veiliggesteld

Bij webservers wordt vaak alleen de webroot veiliggesteld. Voor een volledig herstel ontbreken dan belangrijke delen.

| Gebied | Voorbeelden | Aanwijzing |
|---|---|---|
| Toepassingsbestanden | Webroot, uploads, thema's, extensies | Uploads veranderen vaak |
| Databases | MySQL/MariaDB, PostgreSQL | consistent veiligstellen, niet alleen bestanden kopiëren |
| Configuratie | Webserver, PHP-FPM-pools, php.ini, cronjobs | nodig voor snelle heropbouw |
| Certificaten en sleutels | TLS-certificaten, toepassingssleutels | versleuteld en gescheiden opslaan |
| Documentatie | Toegangen, afhankelijkheden, verloop van het herstel | zonder dit duurt elke heropbouw langer |

## Voorbeeld: database en bestanden veiligstellen

Het volgende voorbeeld toont de basisbouwstenen van een dagelijkse back-up. In de praktijk neemt een back-uphulpmiddel met versleuteling, deduplicatie en bewaarregels de overdracht naar buiten het huis over.

```bash
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"

# Database consistent veiligstellen; toegangsgegevens uit beschermd bestand, niet in de opdracht
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
  --single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"

# Toepassingsbestanden en configuratie
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d

# Controlesommen voor latere controle
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
```

Het bestand `.backup-my.cnf` bevat de toegangsgegevens van een databasegebruiker die alleen mag lezen en heeft de rechten `0600`. `--single-transaction` zorgt bij InnoDB-tabellen voor een consistente stand, zonder de webshop stil te leggen.

Daarna draagt een afzonderlijk systeem de back-up over naar buiten het huis. Belangrijk is dat deze stap wordt bewaakt: een back-upopdracht die al dagen stilletjes mislukt, valt anders pas in een noodgeval op. Een dagelijkse melding over succes, grootte en duur volstaat, zolang iemand haar leest en afwijkingen nagaat.

Gebruikt u bovendien back-ups of snapshots van uw hoster, leg dan schriftelijk vast hoe lang deze worden bewaard, of u zelf kunt herstellen en of de back-ups bij een opgezegd of geblokkeerd account bewaard blijven. Deze kopieën zijn een goede aanvulling, maar vervangen geen eigen, onafhankelijke back-up.

## Bewaartermijn: waarom oudere standen na PHP2Shell belangrijk zijn

Na een aanval is niet de jongste back-up de waardevolste, maar de jongste schone. Bij PHP2Shell werd volgens mediaberichten op 17-10-2026 een eerste aanvalspoging waargenomen; de patches verschenen op 21-10-2026. Wie maar zeven dagen bewaart, heeft mogelijk geen stand meer die zeker vóór de mogelijke inbraak ligt.

Een bewezen schema combineert meerdere periodes, bijvoorbeeld dagelijkse back-ups voor enkele weken, wekelijkse voor enkele maanden en maandelijkse voor een jaar. De precieze periodes richten zich naar uw beschermingsbehoefte en naar verwijderplichten uit de gegevensbescherming.

Belangrijk is ook: een back-up uit de tijd na een inbraak kan webshells of gewijzigde bestanden bevatten. Zet na een incident nooit blind terug, maar vergelijk bestanden met een schone stand en controleer ze voordat de website weer online gaat. Aanwijzingen waarop u moet letten, vindt u onder [Tekenen van compromittering](https://phpsos.de/nl/php2shell/bin-ich-gehackt-anzeichen/). Een patch verwijdert geen binnengebrachte schadelijke software, en een back-up doet dat evenmin vanzelf.

## Herstel testen en documenteren

Een back-up zonder test is een aanname. Pas het herstel toont of alle delen aanwezig zijn, of de sleutel werkt en hoe lang het proces daadwerkelijk duurt.

- Zet regelmatig een volledige back-up terug in een testomgeving, inclusief database en configuratie.
- Controleer of de website daarna volledig werkt: aanmelding, bestellingen, formulieren, mails.
- Meet de duur en leg vast welke stappen handmatig waren. Vergelijk het resultaat met de tijd die uw bedrijf hoogstens zonder website kan.
- Leg de herstelhandleiding neer op een plek die ook bij een uitgevallen server bereikbaar is, bijvoorbeeld in het [IT-noodplan](https://phpsos.de/nl/compliance/notfallplan-erstellen/).

## Hoe helpt PHP SOS concreet?

- We controleren uw bestaande back-ups op volledigheid, bewaartermijn, scheiding van de server en bescherming tegen verwijdering.
- We richten een 3-2-1-back-up met onveranderbare kopie in en testen het herstel samen met u.
- Na een incident bepalen we de laatste schone stand en zetten we die in het kader van de [malwareverwijdering](https://phpsos.de/nl/leistungen/malware-entfernung/) terug op een gepatcht systeem.
- In het [beveiligingsonderhoudscontract](https://phpsos.de/nl/leistungen/security-wartungsvertrag/) bewaken we de back-ups voortdurend en voeren we regelmatig herstelproeven uit.


## Veelgestelde vragen

**Wat betekent de 3-2-1-regel bij back-ups?**  
Drie kopieën van uw gegevens, op twee verschillende opslagsoorten, waarvan één op een andere locatie. De regel zorgt ervoor dat noch een hardwaredefect noch een aanval of brand alle kopieën tegelijk treft.

**Volstaat de back-up van mijn hoster?**  
Hij is een goede aanvulling, maar zelden voldoende. Verduidelijk hoe lang de hoster standen bewaart, of u zelf kunt herstellen en of een aanvaller met uw klantaccount de back-ups zou kunnen verwijderen. Een eigen, onafhankelijke kopie wordt aanbevolen.

**Kan ik na een hack gewoon de laatste back-up terugzetten?**  
Alleen met voorzichtigheid. De laatste back-up kan al schadelijke code bevatten en de kwetsbaarheid waarlangs de aanvaller binnenkwam, staat daarna nog open. Eerst de oorzaak vaststellen en sluiten, dan een gecontroleerde stand terugzetten op een gepatcht systeem.

**Hoe vaak moet ik het herstel testen?**  
Regelmatig en na grotere wijzigingen aan het systeem. Een vast ritme, bijvoorbeeld één volledig herstel per kwartaal in een testomgeving, heeft zich bewezen. Belangrijk is dat de test wordt gedocumenteerd en dat gaten worden verholpen.

## Bronnen

- [BSI IT-Grundschutz (basisbeveiliging van de Duitse federale dienst voor informatiebeveiliging)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: gegevensback-up](https://www.bsi.bund.de/)
- [php.net: beveiligingsmeldingen over PHP2Shell](https://www.php.net/)