Backup- en herstelplanning: bescherm je bestanden goed

Een backup- en herstelplan beantwoordt twee getallen: RPO (hoeveel dataverlies kun je accepteren, gemeten in tijd) en RTO (hoe lang mag je systeem uitliggen). Definieer die per werkbelasting en werk dan terug. Een database met een RPO van 5 minuten vereist continue WAL-streaming; een wekelijks marketingrapport met een RPO van 24 uur heeft één nachtelijke taak nodig. Combineer dit met de 3-2-1-regel — drie kopieën, op twee mediatypen, waarvan één extern — en test herstel elk kwartaal. De meeste "we hebben backups"-verhalen lopen slecht af omdat niemand ooit het herstel heeft geoefend.

RPO en RTO: de uitgangspunten

RPO (Recovery Point Objective) = maximaal acceptabel dataverlies in tijd. RTO (Recovery Time Objective) = maximaal acceptabele uitvalsduur.

Voorbeelden per werkbelasting:

Productiedatabase voor een e-commercesite: RPO 5 min, RTO 1 uur
Klantgerichte bestandsuploads: RPO 15 min, RTO 2 uur
Interne bestandsserver: RPO 24 uur, RTO 8 uur
E-mailarchief: RPO 24 uur, RTO 48 uur
Marketinganalytics: RPO 24 uur, RTO 72 uur

Een strakker RPO/RTO kost meer. Een RPO van 5 minuten vereist continue replicatie (kostbare infrastructuur); een RPO van 24 uur betekent één nachtelijke taak (goedkoop). Niet elke werkbelasting heeft een hot standby nodig — overdrijf niet.

De 3-2-1-regel werkt nog steeds

Drie kopieën van de data, op twee verschillende opslagtypes, met één externe kopie. De 3-2-1-regel stamt van vóór de cloud en staat nog stevig:

Primair: productie-opslag (S3, EBS, PostgreSQL-schijf)
Secundair: backup op ander medium of in een andere regio (een andere S3-bucket met replicatie, Glacier)
Tertiair: extern, bij voorkeur van een andere leverancier of air-gapped (Backblaze B2, on-premises tape, fysieke schijven in een kluis)

Leveranciersdiversiteit is essentieel. Een gecompromitteerd AWS-rootaccount kan al je AWS-backups verwijderen. Een secundaire kopie bij Backblaze, Wasabi of on-premises overleeft dat scenario. Voor bedrijven onder de €50 miljoen omzet kost een kopij bij een tweede leverancier misschien €50–200 per maand en verzekert het tegen catastrofale tenantbrede problemen.

Volledige, incrementele en synthetisch volledige backup

Drie backupstrategieën:

Volledig: kopieer alles elke keer. Simpel, herstel is snel (één bestand), opslag is zwaar.
Incrementeel: kopieer alleen wat is gewijzigd sinds de laatste backup. Opslagzuinig, herstel vereist volledig + alle incrementele kopieën.
Synthetisch volledig: serversijdige samenvoeging van volledig + incrementele tot een nieuwe virtuele volledige backup. Snel herstel vanuit elk punt.

Moderne backuptools (Veeam, Rubrik, restic met prune, BorgBackup) gebruiken incrementeel-voor-altijd met synthetische volledige kopieën achter de schermen. Het patroon: nachtelijks incrementeel, wekelijks synthetisch volledig, 30 dagelijkse + 12 maandelijkse + 7 jaarlijkse kopieën bewaren (grootvader-vader-zoon-rotatie).

Voor een bestandsserver van 2 TB met 5% dagelijkse wijzigingsgraad slaat incrementeel-voor-altijd ongeveer 3–5 TB op voor een jaar retentie — tegenover 700+ TB bij een volledige nachtbackup.

Versleuteling voordat het vertrekt

Backups mogen niet onversleuteld worden verzonden of opgeslagen. Clientsijdige versleuteling met AES-256-GCM (de standaard in restic, Borg, Duplicacy, Veeam en andere) zorgt ervoor dat de backuphost nooit leesbare tekst ziet.

Sleutelbeheer is belangrijker dan de algoritmekeuze. Een backup versleuteld met een sleutel die is opgeslagen in hetzelfde AWS-account als de backup is schijnveiligheid — een aanvaller met IAM-toegang heeft beide. Bewaar sleutels in:

AWS KMS met een sleutel uit een apart account (cross-account ontsleuteling)
HashiCorp Vault in een out-of-band omgeving
Een hardware security module (YubiKey, HSM) voor de rootsleutel
Een afgedrukte, verzegelde papierkopie voor echt kritieke sleutels

Roteer regelmatig (jaarlijks), log elk gebruik en test herstel met een geroteerde sleutel vóórdat de rotatie in productie van kracht wordt.

Onveranderlijkheid: het antwoord op ransomware

Ransomware-aanvallen in 2025 richten zich vaak eerst op backups — productiedata versleutelen, dan backups verwijderen of versleutelen om herstel te blokkeren. Onveranderlijke backups maken dit onmogelijk.

Implementaties:

S3 Object Lock (Compliance Mode): zelfs root kan niet verwijderen gedurende de retentieperiode
Azure Blob onveranderlijke opslag: vergelijkbaar, afgedwongen op containerniveau
Veeam Hardened Linux Repository: alleen-toevoegen, alleen SSH, geen delete-API
Fysieke tape in een kluis: de ultieme air gap

Voor bedrijfskritieke data moet minimaal één backupkopie onveranderlijk zijn gedurende de retentieperiode. De extra kosten zijn doorgaans nul — je bewaarde het toch al. De waarde wanneer ransomware toeslaat is absoluut.

Testen: het niet-optionele deel

Een backup die je nooit hebt hersteld is geen backup; het is hoop. Testschema per prioriteit:

Tier 1 (bedrijfskritiek): volledig hersteldrill per kwartaal, willekeurige bestandsherstel maandelijks
Tier 2 (bedrijfsbelangrijk): volledig hersteldrill halfjaarlijks, willekeurige bestandsherstel per kwartaal
Tier 3 (standaard): volledig hersteldrill jaarlijks, willekeurige bestandsherstel per kwartaal

Leg vast bij de test:

Hoe lang duurde het herstel (vergelijk met RTO)
Kwamen de data overeen met de productiestatus (controlesommen tegen een bekend punt)
Zijn rechten of configuraties niet hersteld
Wat brak er en hoe is het opgelost

Bedrijven die testen overslaan ontdekken corrupte backups tijdens echte incidenten — het duurste moment om iets te leren.

Databasebackups vereisen een eigen plan

Bestanden en databases maken anders gebruik van backupmethoden. Een .pgdata-map gekopieerd midden in een transactie is corrupt. Gebruik native tools:

PostgreSQL: pg_basebackup + WAL-archivering voor PITR, pg_dump voor logisch
MySQL: Percona XtraBackup voor hot fysiek, mysqldump voor logisch
MongoDB: mongodump, replicasets met vertraagde secondaries
Microsoft SQL Server: native backup met BACKUP DATABASE, log shipping voor PITR

Voor een PostgreSQL-database van 500 GB met een RPO van 5 minuten bieden nachtelijkse basisbackups + continue WAL-archivering naar S3 point-in-time herstel tot elke seconde van de afgelopen 30 dagen. Hersteltijd: basisbackup ophalen (30 min), WAL herspelen tot doeltijdstip (5–30 min). Een strakke RTO vereist een warme replica die klaar is om te promoveren.

Applicatie-consistente snapshots

Bestandssysteemsnapshotse (ZFS, Btrfs, AWS EBS, Azure managed disks, GCP persistent disk) bevriezen een tijdstip op blokniveau. Combineer voor databases met applicatiestilstand:

pg_start_backup('label') (PostgreSQL) of FLUSH TABLES WITH READ LOCK (MySQL)
Neem de snapshot
pg_stop_backup() of ontgrendelen

De snapshot is applicatie-consistent — bruikbaar voor herstel zonder crash recovery. AWS Backup, Azure Backup en Google Cloud Backup automatiseren dit patroon voor gangbare databases.

Backuparchieven distribueren naar derden

Wanneer backups naar externe partijen moeten — auditors, toezichthouders, opvolgend beheer — vereist de overdracht zelf zorg. FTP is verouderd; e-mailbijlagen stoten op groottelimieten; USB-drives afgeven is traag.

End-to-end versleutelde bestandsoverdracht verzorgt ad-hoc backupdistributie op een nette manier. HexaTransfer verplaatst bestanden tot 10 GB met AES-256-GCM clientsijdige versleuteling en een eenmalige link. Handig voor het sturen van een databasesnapshot naar een auditor zonder hem toegang te geven tot je S3-buckets.

Documentatie is onderdeel van de backup

De beste backup ter wereld is nutteloos als de persoon die hem kan herstellen met verlof is en niemand anders weet hoe. Documenteer:

Wat wel en niet in de backup zit (expliciete uitsluitingen)
Schema en retentie per werkbelasting
Sleutelbeheer en toegang
Herstel-runbooks met stapsgewijze opdrachten
Contactlijst (leveranciersondersteuning, bereikbaarheidsdienst)
Testresultaten en datums

Druk een kopie af. Bewaar een kopie in de fysieke kluis met de noodsleutels. Als je backup-runbook alleen op een Confluence-pagina staat die wordt geserveerd vanuit dezelfde infrastructuur die net is uitgevallen, heb je een probleem. Papier werkt nog wanneer niets anders dat doet.

Definieer de RPO/RTO, implementeer 3-2-1 met onveranderlijkheid, versleutel clientsijdig, test elk kwartaal, documenteer obsessief. Backupsucces is 10% technologie en 90% discipline.

Probeer het op hexatransfer.com — gratis, geen account vereist, maximaal 10 GB.