Testen van back-ups: waarom de meeste bedrijven er te laat achter komen dat hun back-ups niet werken

Volgens het Kaseya State of the MSP-rapport uit 2026 biedt 79% van de MSP’s tegenwoordig back-up en herstel aan als managed service. Maar het aanbieden van back-up en het leveren van geverifieerd herstel zijn twee verschillende zaken, en de kloof daartussen is groter dan de meeste MSP’s beseffen.

Uit onderzoek blijkt duidelijk: hoewel 92% van de organisaties beweert over back-ups te beschikken, slaagt 31% er niet in hun gegevens te herstellen wanneer ze door ransomware worden getroffen. Meer dan de helft van de bedrijven test hun noodherstelplan één keer per jaar of minder. En 33% test het zelden of helemaal niet. Het probleem is niet de back-up zelf, maar het feit dat nooit is aangetoond dat de back-up werkt.

Een back-uptaak die zonder fouten wordt voltooid, geeft een gevoel van veiligheid. Op elk dashboard en in elk rapport lijkt het alsof er bescherming is. De enige manier om te weten of er daadwerkelijk sprake is van bescherming, is door er een back-up te herstellen, en de meeste organisaties doen dat pas als er in de productie iets rampzaligs is misgegaan en er geen andere optie meer is.

Waarom back-ups zonder waarschuwing mislukken

Een storing in de back-up is juist zo verraderlijk omdat deze onzichtbaar is. Er is geen waarschuwing, geen rapport over mislukte taken, geen enkele aanwijzing dat er iets mis is, totdat er onder druk een poging tot herstel wordt ondernomen.

Back-uptaken worden voltooid, maar het terugzetten mislukt. Een back-uptaak kan aangeven dat deze is geslaagd, dat bestanden zijn overgezet en dat de taak is voltooid, terwijl er in werkelijkheid een onbruikbare back-up is gemaakt. Voorbeelden van verborgen fouten zijn: applicatiegegevens die in een inconsistente toestand zijn vastgelegd en na het terugzetten niet kunnen worden geopend; fouten met versleutelingssleutels waardoor ontsleuteling niet mogelijk is; problemen met bestandsrechten die de toegang tot afzonderlijke bestanden blokkeren; en VM-images die niet kunnen opstarten vanwege incompatibiliteit tussen stuurprogramma’s of hardware-abstracties.

Veranderingen in de omgeving. Servers veranderen: applicaties worden bijgewerkt, configuraties worden aangepast en er worden nieuwe gegevensbronnen toegevoegd. Een back-upconfiguratie die zes maanden geleden nog correct was, legt mogelijk niet langer de juiste gegevens vast, of vertoont compatibiliteitsproblemen met bijgewerkte applicatieversies die pas aan het licht komen bij een poging tot herstel.

Tekortkomingen in de bewaartermijn. Een zich langzaam verspreidende ransomware-aanval kan een verblijftijd hebben die langer is dan uw bewaartermijn. Een back-up met een bewaartermijn van 30 dagen biedt mogelijk geen bescherming tegen een aanval die 45 dagen geleden is begonnen en waarbij alle herstelpunten in de set al zijn beschadigd.

Storingen in de opslag. Back-upbestemmingen vallen stilletjes uit. Een lokale schijf, tapebibliotheek of cloudopslagbestemming die al wekenlang niet beschikbaar is, wordt mogelijk pas ontdekt wanneer er een poging tot herstel wordt ondernomen. Tegen die tijd is de volledige bewaartermijn wellicht al verstreken.

Het gevolg is niet alleen een mislukte herstelprocedure. Het gaat om langdurige uitval, onherstelbaar gegevensverlies, onderhandelingen over ransomware die niet nodig hadden hoeven plaatsvinden, en in het ergste geval het faillissement van het bedrijf. Bijna een op de vijf eigenaren van kleine en middelgrote bedrijven die te maken kregen met een cyberaanval, ging failliet of moest de deuren sluiten. Geteste back-ups vormen de meest directe technische bescherming tegen een dergelijke uitkomst.

Hoe back-uptests werken: de vijf soorten tests

Test voor herstel op bestandsniveau. Herstel specifieke bestanden uit back-ups, documenten, database-exports en e-mailarchieven, en controleer of ze correct openen en de verwachte gegevens bevatten. Dit is de minimale praktische test waarmee beschadigingen op bestandsniveau, problemen met toegangsrechten en versleutelingsproblemen kunnen worden opgespoord. Deze test kan regelmatig worden uitgevoerd zonder dat dit veel extra werk met zich meebrengt.

Hersteltest op systeemniveau. Herstel een volledige server of VM vanuit een back-up in een geïsoleerde testomgeving en controleer of het systeem opstart, de applicaties starten en de services correct functioneren. Dit is de test waarmee wordt gecontroleerd of volledig herstel van de server daadwerkelijk mogelijk is, en het is de test die het vaakst wordt overgeslagen. Door deze test in een geïsoleerd netwerk uit te voeren, wordt elke impact op de productieomgeving voorkomen.

Test voor databaseherstel. Herstel voor databaseservers de databaseback-up en de transactielogboeken, en controleer of de database consistent en toegankelijk is en zich op het verwachte herstelpunt bevindt. Bij testen op bestandsniveau worden databasespecifieke problemen, zoals inconsistenties in de transactielogboeken, niet opgemerkt. Dit kan ertoe leiden dat het herstel technisch gezien weliswaar succesvol is, maar dat er in de praktijk geen query’s kunnen worden uitgevoerd.

RTO-meting. Meet de duur van het herstelproces, van het begin tot de bevestiging van het herstel, en vergelijk deze met de vastgestelde RTO voor dat systeem. Een server met een RTO van vier uur waarvan het herstel negen uur duurt, vertoont een tekortkoming die moet worden verholpen vóór een daadwerkelijk incident, en niet pas tijdens een incident.

Volledige DR-simulatie. Een jaarlijkse of halfjaarlijkse oefening waarbij een vastgesteld onderhoudsvenster wordt behandeld als een gesimuleerde ramp: alle kritieke systemen worden omgeschakeld naar de back-upinfrastructuur, er wordt gecontroleerd of de bedrijfsvoering doorgaat, de werkelijke RTO’s worden gemeten en vervolgens wordt de productieomgeving hersteld. Dit is de test met de hoogste betrouwbaarheid en degene die systeemgebonden hiaten aan het licht brengt die bij testen op componentniveau over het hoofd worden gezien. Het omvat een DR-walk-through met sleutelfiguren om hiaten te identificeren, tabletop-oefeningen om checklists te valideren en een volledige failover-test waarbij de activiteiten vanuit de DR-omgeving worden uitgevoerd voordat er wordt teruggeschakeld.

Hoe vaak moet je testen?

Aanbevolen frequentie per testtype en systeemniveau:

Tier 1-systemen (systemen met de strengste RTO’s en de grootste impact op de bedrijfsvoering): maandelijkse controle van het herstel op bestandsniveau; driemaandelijks herstel op systeemniveau; jaarlijkse volledige DR-simulatie.

Tier 2-systemen: driemaandelijks herstel op bestandsniveau; twee keer per jaar herstel op systeemniveau; opgenomen in de jaarlijkse DR-simulatie.

Na elke ingrijpende wijziging – zoals het installeren van patches, het updaten van applicaties, wijzigingen in de infrastructuur en het toevoegen van nieuwe systemen aan het back-upbereik – moet er voor de betrokken systemen een gerichte hersteltest worden uitgevoerd.

Na een beveiligingsincident: zelfs als de back-upinfrastructuur niet direct is getroffen, moet u de herstelmogelijkheden testen voordat u het herstel als voltooid beschouwt. Ransomware richt zich specifiek op back-upinfrastructuur; controleer daarom of uw herstelpunten niet zijn aangetast.

Voor de meeste MSP’s is tijd de grootste praktische hindernis. Het handmatig testen van herstelprocedures in tientallen klantomgevingen met de hierboven genoemde frequentie is zonder automatisering operationeel niet haalbaar. Hier vult geautomatiseerde verificatie die leemte op.

De 3-2-1-regel en wat er aan ontbreekt

De 3-2-1-regel – drie kopieën van gegevens op twee verschillende soorten media, waarvan één kopie buiten het bedrijf – blijft de standaardaanbeveling voor een robuuste back-upoplossing. Deze regel biedt een goed antwoord op de vraag naar redundantie: als één kopie uitvalt, blijven de andere over.

Waar het echter geen rekening mee houdt, is de herstelbaarheid. Drie kopieën van beschadigde gegevens zijn drie back-ups die niet kunnen worden hersteld. Een externe kopie die niet is getest, is slechts een veronderstelling.

De 3-2-1-regel moet worden beschouwd als de minimale architectuurvereiste, niet als het einddoel van een back-upstrategie. Het einddoel van een back-upstrategie is een getest, geverifieerd en op tijd gemeten herstelproces, met documentatie die aantoont dat het werkt.

In sommige richtlijnen wordt nu verwezen naar een 3-2-2-variant, waarbij twee externe kopieën worden bewaard: één op een alternatieve locatie en één in onveranderlijke cloudopslag. Dit is specifiek bedoeld om ransomware-scenario’s het hoofd te bieden waarin zowel de back-ups op locatie als de primaire externe back-ups gecompromitteerd kunnen raken. Voor omgevingen met een hoog risico of klanten met strenge RPO’s is dit het overwegen waard.

Automatisering van de controle van back-ups

Handmatig testen heeft zijn voordelen, maar kent ook praktische beperkingen. Het is tijdrovend, vereist onderhoudsvensters, bestrijkt slechts een deel van de systemen en wordt slechts sporadisch uitgevoerd, waardoor de meeste herstelpunten tussen de tests door niet worden gecontroleerd.

Datto-screenshotverificatie start na elke back-uptaak automatisch elk geback-upte systeem op in een geïsoleerde virtualisatieomgeving en maakt een screenshot om te controleren of het systeem correct opstart. Dit zorgt voor een continue verificatie per back-up van elk beschermd systeem, waardoor opstartfouten direct na de back-uptaak aan het licht komen in plaats van weken of maanden later tijdens een herstelpoging. Aangedreven door Kaseya Intelligence, levert het een nauwkeurigheid van meer dan 99,9% bij opstartverificatie.

Integriteitscontroles van back-ups zorgen ervoor dat de back-upgegevens intact en onbeschadigd zijn, en signaleren afwijkingen in de checksum en opslagfouten voordat deze tot onherstelbaar gegevensverlies leiden.

Dashboards voor gezondheidsrapportage verzamelen gegevens over de status van back-uptaken, het tijdstip van de laatste succesvolle back-up en verificatieresultaten voor alle beveiligde systemen, waardoor operationeel inzicht wordt geboden dat proactieve detectie en rapportage aan klanten mogelijk maakt.

De combinatie van geautomatiseerde verificatie en handmatige hersteltests met regelmatige tussenpozen zorgt zowel voor voortdurende zekerheid als voor een periodiek gevalideerd herstelvermogen.

Testen van back-ups en cyberverzekeringen

Verzekeraars van cyberverzekeringen eisen steeds vaker bewijs van back-uptests als voorwaarde voor dekking, en in sommige polissen worden de vereisten voor de testfrequentie nu expliciet vermeld. Een organisatie die beweert over back-upbeveiliging te beschikken, maar geen bewijs kan leveren van geteste herstelmogelijkheden, kan te maken krijgen met betwistingen bij verzekeringsclaims in verband met gegevensverlies of herstel na een ransomware-aanval.

Voor MSP’s betekent dit zowel een verplichting op het gebied van naleving als een zakelijke kans. Documentatie van regelmatige back-uptests, resultaten van screenshotverificaties en verslagen van succesvolle herstelprocedures zijn precies het soort bewijs dat verzekeraars willen zien. MSP’s die deze documentatie systematisch aanleveren, helpen klanten om aan de verzekeringsvereisten te voldoen, versterken hun eigen aansprakelijkheidspositie en leveren materiaal voor het kwartaaloverleg (QBR) dat de concrete waarde van hun dienstverlening aantoont.

Een praktische invalshoek voor gesprekken met klanten: een cyberverzekering dekt ongeteste back-ups net zo min als een autoverzekering een voertuig dekt dat niet rijklaar is. De test is het bewijs.

Back-uptests voor MSP’s

Voor MSP’s is het testen van back-ups tegelijkertijd een operationele vereiste, een contractuele verplichting, een communicatiemiddel voor klanten en een methode voor het beheren van risico’s.

Contractuele verplichting. MSP’s die back-updiensten aanbieden met vastgelegde RTO- en RPO-doelstellingen, moeten aantonen dat hun back-upinfrastructuur daadwerkelijk aan die doelstellingen kan voldoen. Regelmatige tests vormen het enige bewijs. SLA’s zonder testresultaten zijn beloften zonder bewijs.

Rapportage aan klanten. Resultaten van back-uptests, geteste systemen, testuitkomsten, behaalde RTO’s en schermafbeeldingen van verificaties vormen waardevolle inhoud voor kwartaalrapportages (QBR’s). Klanten die bewijs zien van regelmatige back-upverificatie krijgen iets wat de meeste MSP’s niet bieden, en waar klanten steeds vaker om vragen naarmate vereisten van cyberverzekeringen steeds meer doorspelen in hun aankoopbeslissingen.

Risicobeheer. Een MSP die tijdens een daadwerkelijk incident bij een klant een storing in de back-up ontdekt, loopt het risico op aansprakelijkheid, reputatieschade, een verslechterde klantrelatie en mogelijk een contractgeschil. Door regelmatig te testen worden storingen aan het licht gebracht op een moment dat ze nog te verhelpen zijn, in plaats van tijdens een crisis.

Onderscheidende dienstverlening. De meeste MSP’s bieden back-ups aan. Maar slechts weinigen kunnen aantonen dat het ook echt werkt. De MSP’s die door middel van systematische tests en documentatie kunnen aantonen dat gegevens daadwerkelijk kunnen worden hersteld, beschikken over een concreet, aantoonbaar onderscheidend vermogen dat aanbieders van standaardback-ups niet kunnen evenaren.

Ontdek Datto BCDR en geautomatiseerde back-upcontrole voor MSP’s.

Het Unified Cyber Resilience Portal

Het beheren van back-ups binnen on-premises infrastructuur, SaaS-toepassingen, eindapparaten en cloudomgevingen betekende tot nu toe dat er meerdere afzonderlijke tools moesten worden beheerd, elk met een eigen console, waarschuwingssysteem en herstelworkflow. Voor MSP’s die meerdere klanten in al deze omgevingen beheren, zorgt die versnippering voor aanzienlijke operationele overhead en maakt het moeilijker om een consistente testaanpak te handhaven.

Het Unified Cyber Resilience Portal van Kaseya, gelanceerd tijdens Kaseya Connect 2026, brengt al het back-upbeheer samen in één geïntegreerde interface, waardoor er geen wildgroei aan tools meer is waardoor technici herstelprocessen bij verschillende, onderling niet-gekoppelde leveranciers moeten beheren. Het portaal wordt aangedreven door Kaseya Intelligence en biedt AI-gestuurde verificatie via schermafbeeldingen, gekoppelde herstelworkflows met intelligente prioritering en naleving van regelgeving, waaronder FIPS-functionaliteit en FedRAMP-gereedheid. Ondersteuning voor Azure Files is nu algemeen beschikbaar; agentloze Hyper-V-back-up komt in juni 2026 beschikbaar.

Voor MSP’s biedt het portaal één totaaloverzicht van de back-upomgeving van elke klant, waarbij de verificatieresultaten en de herstelstatus op één plek zijn gebundeld in plaats van verspreid over de dashboards van verschillende leveranciers.

Belangrijkste punten

• Hoewel 92% van de organisaties beweert over back-ups te beschikken, slaagt 31% er niet in om gegevens te herstellen wanneer ze door ransomware worden getroffen. De kloof tussen het hebben van een back-up en het hebben van een geteste, werkende back-up is waar de meeste mislukte herstelpogingen plaatsvinden.
• Back-uptaken kunnen aangeven dat ze zijn geslaagd, terwijl ze onbruikbare herstelpunten opleveren. Stille fouten, veranderingen in de omgeving en opslagstoringen blijven allemaal onzichtbaar totdat er een herstelpoging wordt ondernomen.
• De testfrequentie moet worden afgestemd op het systeemniveau: Tier 1-systemen vereisen maandelijkse controles op bestandsniveau, driemaandelijkse herstelprocedures op systeemniveau en een jaarlijkse volledige DR-simulatie.
• De 3-2-1-regel heeft betrekking op de back-uparchitectuur, maar niet op de herstelbaarheid. Geteste herstelprocessen waarvan de doorlooptijd is gemeten, maken de strategie compleet.
• Geautomatiseerde verificatie (screenshotverificatie via Datto BCDR, mogelijk gemaakt door Kaseya Intelligence) zorgt voor een continue controle per back-up zonder handmatige inspanningen, waardoor fouten al tijdens het maken van de back-up aan het licht komen in plaats van pas tijdens het herstel.
• Voor MSP’s is het testen van back-ups een contractuele verplichting, een vereiste voor het aanleveren van bewijsmateriaal bij cyberverzekeringen en het meest concrete onderscheidende kenmerk dat op de back-upmarkt beschikbaar is.