Een backup strategie is pas bruikbaar als je herstel ook echt werkt. Internationale cijfers laten zien hoe hard de praktijk afwijkt van de intentie, slechts 57% van de back-ups voltooit een volledige succesvolle run en maar 61% van de restores slaagt volledig, terwijl slechts 10% van de IT-gebruikers dagelijks een back-up maakt en 41% dit zelden of nooit doet. In dezelfde data zie je hoe ransomware het probleem verergert, want 96% van de organisaties gaf aan dat hun back-updata doelwit was van een aanval, en 59% gebruikt inmiddels immutable storage als primaire bescherming, met 81% die het als laatste verdedigingslinie noemt (bron over backupstatistieken en immutable storage).
Voor Nederlandse organisaties is dat geen theoretische waarschuwing. Continuïteit, ketenafhankelijkheid, gegevensbescherming en aantoonbaarheid drukken hier harder op de keuzes dan in veel generieke backupverhalen, zeker bij financiële administratie, klantdossiers en publieke dienstverlening. Een goede backup strategie gaat dus niet over opslag alleen, maar over herstelbaarheid, governance en de vraag of je onder druk kunt aantonen dat je weer veilig verder kunt werken.
Waarom een backup strategie meer is dan data kopiëren
Een backup strategie is een herstelplan met kopieën als middel, niet als doel. De echte vraag is niet of je data ergens staat, maar of je organisatie na uitval, corruptie of ransomware snel genoeg terug kan naar een werkende toestand. Daar wringt het vaak, want back-ups maken en back-ups herstellen zijn twee verschillende disciplines.
De harde realiteit van herstel
De 3-2-1-regel is een goed vertrekpunt, maar alleen als je hem koppelt aan hersteltests en meetbare uitkomsten. De kern is eenvoudig, 3 kopieën van data, op 2 verschillende opslagmedia, waarvan 1 kopie off-site staat, juist zodat een lokale ramp of storing niet meteen alles raakt (Acronis over de 3-2-1-regel). Voor Nederland is vooral relevant dat back-up ook echt herstelbaar moet zijn, met KPI's als backup success rate, RTO en RPO als harde stuurmiddelen (TechTarget over backupstrategie en herstel).
Praktische regel: als je restore niet getest is, is je backup nog geen controleerbaar herstelmiddel.
Waarom dit in Nederland zwaarder weegt
Nederlandse organisaties werken vaak in ketens, met leveranciers, SaaS-diensten en gedeelde processen. Een storing raakt dan niet één systeem, maar meerdere teams tegelijk. Daarbovenop komen eisen rond gegevensbescherming en continuïteit, waardoor een backupstrategie ook auditbaar en verdedigbaar moet zijn, niet alleen technisch functioneel.
De verschuiving naar cyber recovery maakt dat nog urgenter. Een gewone back-up kan prima zijn tegen een disk failure, maar ransomware richt zich juist op opslag, beheer en herstelpaden. Daarom zie je steeds vaker dat organisaties back-ups behandelen als onderdeel van hun security-architectuur, met immutable copies, gescheiden credentials en herstelprocedures die losstaan van de dagelijkse productieomgeving.
De 3-2-1-regel als fundament van je backup strategie
Volgens Backblaze is de 3-2-1-regel de praktische basis voor een backupstrategie, omdat je daarmee voorkomt dat één incident al je kopieën tegelijk raakt. Je bewaart 3 kopieën, op 2 verschillende mediatypen, waarvan 1 off-site staat. In een Nederlandse omgeving betekent dat meestal een lokale kopie voor snelle restores en een externe kopie voor uitval door brand, sabotage, ransomware of een storing die één locatie raakt (Backblaze over de 3-2-1-regel).
Hoe je dit vertaalt naar een Nederlandse omgeving
De valkuil zit in het woord off-site. Een cloudkopie is niet automatisch voldoende als die nog steeds te dicht tegen hetzelfde netwerk, dezelfde identiteitlaag of dezelfde beheerlaag aanhangt. In Nederlandse omgevingen moet je dus aantoonbaar kunnen laten zien dat de off-site kopie echt los staat van de primaire omgeving, ook als die in dezelfde cloudprovider of hetzelfde datacenterlandschap draait (TechTarget over 3-2-1 best practices).
Die scheiding is niet alleen technisch, maar ook bestuurlijk. Wie onder AVG en DORA moet kunnen aantonen dat data beschikbaar blijft en herstelbaar is, heeft meer nodig dan een opslaglocatie buiten de primaire omgeving. Dan moet je ook laten zien dat beheeraccounts, toegangsrechten en herstelpaden niet dezelfde kwetsbaarheid delen als productie.
De 3-2-1-1-variant voegt daar een extra laag aan toe, 1 offline of immutable kopie. Het National Cyber Security Centre van Nieuw-Zeeland beschrijft dit expliciet als 3 kopieën, op 2 mediatypen, met 1 off-site en 1 offline kopie, plus regelmatige restore-tests, waaronder een restore van een enkel bestand en periodiek een volledige systeemrestore (NCSC Nieuw-Zeeland over back-ups testen). Voor ransomwareweerbaarheid is dat verschil groot, want immutable storage beperkt de kans dat een aanvaller ook je herstelkopieën versleutelt of verwijdert.
Waar het vaak misgaat
- Alle kopieën in één beheerlaag: dan kan een gecompromitteerde beheeraccount alsnog alles raken.
- Off-site zonder isolatie: een kopie die wel elders staat, maar logisch verbonden blijft met hetzelfde domein, is kwetsbaar.
- Geen versiebeheer: dan overschrijf je een goede versie met een corrupte of versleutelde versie.
- Geen automatisering: handmatige back-ups missen snel een ritme.
Dat zijn geen theoretische fouten. In de praktijk zie je vaak dat organisaties wel een tweede locatie of cloudbucket hebben, maar nog steeds één set credentials, één beheerportaal of één herstelroute gebruiken. Dan lijkt de architectuur gespreid, terwijl een aanvaller of beheerfout nog steeds één punt heeft om alles te raken.
Een goede 3-2-1-architectuur is pas compleet als de off-site kopie ook herstelbaar is zonder afhankelijk te zijn van dezelfde beheerroute als productie.
RTO en RPO bepalen per applicatie en datadomein
RTO en RPO maken van een algemene backupstrategie een echte ontwerpkeuze. RTO is de tijd die je accepteert voordat een systeem weer beschikbaar moet zijn. RPO is hoeveel dataverlies je accepteert bij een incident. Zonder die twee definities ga je te veel back-uppen waar het niet nodig is, of te weinig waar het wel moet.
Begin bij bedrijfskritiek, niet bij techniek
De juiste volgorde is eerst een risicoanalyse en business impact analysis, daarna pas de scope, het backuptype, de opslaglocatie en de retentie. Enterprise-richtlijnen leggen ook nadruk op een restore- en DR-proces waarin je expliciet vastlegt hoe snel systemen terug moeten zijn en hoeveel dataverlies acceptabel is (TechTarget over backupplanning en herstel).
Een financiële administratie vraagt normaal gesproken strakkere RTO- en RPO-afspraken dan een intern kennissysteem. Dat is geen technisch detail, maar een bedrijfsbeslissing. Als een applicatie direct klantinteractie, betalingen of wettelijke verplichtingen raakt, hoort die hoger op de herstelprioriteiten te staan.
| Systeemtype | RTO | RPO | Backup-frequentie |
|---|---|---|---|
| Kritieke productieapplicatie | Kort en strak | Zeer beperkt | Frequent en met getest herstel |
| Ondersteunend bedrijfsproces | Matig | Beperkt | Dagelijks of volgens wijzigingsritme |
| Intern kennis- of archiefsysteem | Ruimer | Meer ruimte voor verlies | Minder frequent, maar nog steeds getest |
Kosten, complexiteit en dataverlies balanceren
Meer back-ups is niet automatisch beter. Elke extra frequentie vergroot opslag, beheer en testlast. Minder frequentie vergroot het risico dat je meer gegevens verliest dan acceptabel is. Voor operationele back-upplanning noemt Unitrends als praktische vuistregel dat je minimaal elke 24 uur incrementele wijzigingen moet vastleggen, zodat mogelijk dataverlies beperkt blijft (Unitrends over backupstrategie).
De fout die ik het vaakst zie, is dat teams een RPO wensen die hun opslag- en netwerkarchitectuur niet kan dragen. Dan moet het beleid omlaag of de infrastructuur omhoog.
Interne link: disaster recovery
Opslagarchitectuur en beveiligingslagen kiezen
De keuze voor opslagarchitectuur bepaalt of je backupstrategie standhoudt als een aanvaller, storing of herstelverzoek echt druk zet op je omgeving. In de praktijk werkt één maatregel zelden goed genoeg. Je hebt een mix nodig van immutable storage, logisch of fysiek afgescheiden kopieën, versleuteling at-rest en in transit, en aparte beheertoegang voor backupadministratie. Die lagen vullen elkaar aan, maar ze hebben elk een eigen trade-off in kosten, beheer en herstelsnelheid.
Welke maatregel past bij welk risico
Immutable storage is sterk tegen ransomware, omdat opgeslagen data niet zomaar overschreven of verwijderd kan worden. Air-gapped kopieën gaan verder, omdat ze fysiek of logisch buiten het operationele netwerk staan. Versleuteling at-rest beschermt data tijdens opslag, terwijl versleuteling in transit het transport afschermt. Samen geven die maatregelen meer zekerheid dan één losse voorziening, zeker als je ook kijkt naar praktijkrichtlijnen voor veilige data-opslag.
De keuze hangt ook samen met hybride cloud. Voor Nederlandse organisaties is het niet genoeg dat backupdata “ergens in de cloud” staat. Je wilt kunnen aantonen dat die kopieën losstaan van het primaire netwerk, met eigen toegangsstructuren, herstelpaden en duidelijke verantwoordelijkheden. Soevereiniteit en datalocatie zijn dan geen abstracte juridische begrippen, maar ontwerpkeuzes die je in je platformarchitectuur moet vastleggen.
| Maatregel | Sterkte | Aandachtspunt |
|---|---|---|
| Immutable storage | Sterk tegen overschrijven en sabotage | Goed beheer van retentie en toegangsrechten nodig |
| Air-gapped kopie | Sterk tegen netwerkcompromittering | Minder snel beschikbaar voor herstel |
| Encryptie at-rest | Beschermt opgeslagen data | Sleutelbeheer is cruciaal |
| Encryptie in transit | Beschermt transport | Lost geen beheerfouten op |
Waarom aparte credentials geen detail zijn
Als backup en productie dezelfde beheertoegang delen, creëer je één foutpunt. Een aanvaller die productie raakt, kan dan vaak ook de backupketen beïnvloeden. Gescheiden credentials, aparte rollen en strakke toegangscontrole beperken dat risico en maken misbruik lastiger zonder dat herstel onnodig complex wordt.
Bij opslagarchitectuur hoort ook discipline in beheer. Back-ups automatiseren, versiebeheer toepassen en herstel regelmatig oefenen helpt om te controleren of retentie, encryptie en toegangscontrole echt werken. Een goedkopere opslaglaag zonder isolatie lijkt aantrekkelijk, maar kan bij een incident alsnog een dure schijnoplossing blijken. Voor een stevige opzet is de combinatie van scheiding, controle en herstelvalidatie belangrijker dan één enkele techniek.
AVG-compliance en aantoonbaarheid in je backup strategie
Een backup strategie voor Nederlandse organisaties moet aantoonbaar voldoen aan de AVG. De Autoriteit Persoonsgegevens verwacht passende technische en organisatorische maatregelen, en die moet je ook kunnen laten zien. Daarom is een backup niet alleen een technische kopie, maar ook bewijs van logging, toegangsbeheer, hersteldiscipline en controleerbare processen.
Wat je moet kunnen aantonen
De kernvraag is niet alleen of persoonsgegevens veilig zijn opgeslagen, maar of je kunt bewijzen hoe je ze beschermt en herstelt. Dat betekent dat je restore-tests, toegangslogs en wijzigingen in retentie zichtbaar maakt voor audit en intern toezicht. Een back-upbeleid zonder logische bewijslijn is in de praktijk moeilijk verdedigbaar, zeker als een incident uitloopt op een compliance-vraagstuk.
Dataminimalisatie en bewaartermijnen horen daar direct bij. Je wilt niet meer backupdata bewaren dan nodig is voor herstel en compliance, maar ook niet zo weinig dat je bij een corruptie of ransomware-incident geen bruikbare herstelpunten meer hebt. Die balans vraagt om een expliciet beleid, niet om losse gewoontes van systeembeheerders.
Backupbeleid verbinden met incidentrespons
Back-ups moeten in hetzelfde denkmodel vallen als incidentrespons. Als iets misgaat, moet je kunnen aantonen welke versie je herstelt, wie toestemming geeft, welke systemen prioriteit krijgen en hoe je controleert dat de herstelde data integer is. De eerder genoemde restore-tests zijn daarmee niet alleen technisch nuttig, maar ook een onderdeel van bewijsvoering.
Bestaande uitleg over backupstrategie blijft vaak steken bij kopieën en off-site opslag, terwijl Nederlandse organisaties juist te maken hebben met aantoonbaarheid, bewaartermijnen en gegevenslocatie als dagelijkse realiteit (Object First over het Nederlandse compliancegat in backupstrategie). Dat sluit aan bij de bredere praktijk waarin Nederland extra scherp kijkt naar incidentafhandeling en verwerkingsverantwoordelijkheid.
Interne link: dataretentie
Als je restore-test niet documenteert, kun je hem later moeilijk gebruiken als bewijs dat je proces echt werkt.
Restore-tests uitvoeren en documenteren
Een restore-test laat zien of je backupstrategie in de praktijk werkt, niet alleen op papier. Je ontdekt dan of de kopie bruikbaar is, of sleutels beschikbaar zijn, of rechten goed staan en of de hersteltijd binnen je RTO blijft. Zonder test heb je hooguit een aanname. In een omgeving waar ransomware, configuratiefouten en menselijke vergissingen gewoon realistische scenario's zijn, is dat te weinig.
Test op drie niveaus
Op file-niveau controleer je of losse bestanden terug te halen zijn. Op database-niveau kijk je of transacties, schema's en consistentie overeind blijven. Op systeemniveau toets je of een complete server of VM weer start en functioneert zoals verwacht. Die driedeling is praktisch, omdat elke laag andere risico's zichtbaar maakt en je dus ook andere herstelproblemen vindt.
Het Amerikaanse NIST benadrukt in contingency planning dat back-ups niet alleen gemaakt moeten worden, maar ook getest, en dat herstelprocedures periodiek geverifieerd moeten worden (NIST-continuïteitsrichtlijnen via Splunk).
Maak testen meetbaar en herhaalbaar
Een goede test leg je zó vast dat een collega hem later exact kan herhalen. Noteer minimaal welke omgeving of welk datadomein is getest, welke backupbron is gebruikt, hoe lang herstel duurde, of de herstelde data bruikbaar was en welke afwijkingen zijn gevonden. Voeg daar ook aan toe welke versie van de procedure is gebruikt, want kleine wijzigingen in tooling of rechten kunnen het resultaat al beïnvloeden.
Dat is geen administratieve luxe. Voor Nederlandse organisaties met AVG- en DORA-verplichtingen telt vooral dat je kunt laten zien dat herstel niet toevallig lukt, maar beheerst is ingericht. Documentatie maakt het verschil tussen een eenmalige technische oefening en aantoonbare beheersing.
Frequentie hangt af van de kritikaliteit. Regelmatige restoretests horen standaard te zijn, net als tests van een enkel bestand en periodieke volledige systeemrestores. Die combinatie laat zien of je de dagelijkse herstelvragen én de zwaardere scenario's onder controle hebt, zeker als immutable storage een rol speelt in je ransomware-verweer.
Wat je moet monitoren
Je volgt niet alleen een backup success rate, maar ook de feitelijke hersteltijd, afwijkingen ten opzichte van je RTO en fouten tijdens de restore. Een back-up die technisch geslaagd is maar niet bruikbaar herstelt, lost het bedrijfsrisico niet op. Juist bij compliance-eisen is dat onderscheid relevant, want een geslaagde job zegt niets over aantoonbaar herstel.
Daarom hoort een restoretestverslag meer te zijn dan een vinklijst. Leg vast wat er hersteld is, wie akkoord gaf, welke controles zijn uitgevoerd op integriteit en welke vervolgstappen nodig zijn als een test faalt. Dat geeft je een audit trail die bruikbaar is voor beheer, intern toezicht en verantwoording richting bestuur of auditor.
Een sterke backupstrategie voor Nederlandse organisaties combineert de 3-2-1-basis met immutable opslag, duidelijke RTO- en RPO-keuzes, en aantoonbare restore-tests. Wie dat goed inricht, verkleint niet alleen uitvalrisico, maar maakt herstel ook verdedigbaar richting auditors, bestuur en ketenpartners.
Wil je woningdata, energie-inzichten en datakwaliteit in je eigen platform beschikbaar maken met herleidbare API-koppelingen, kijk dan naar Altum AI. Je kunt daar direct zien hoe je betrouwbare data-opbouw, validatie en procesinrichting vertaalt naar een API-first aanpak voor Nederlandse vastgoedtoepassingen.