Veel organisaties denken dat ze hun databeheer op orde hebben zolang de back-ups netjes draaien. Er is een schema, er zijn meldingen, en af en toe wordt er iets teruggezet. Tot het moment dat er echt iets misgaat. Dan blijkt dat niemand precies weet wat er bewaard wordt, waarom het bewaard wordt, en hoe lang het eigenlijk had moeten blijven bestaan.
Die neiging om alles te bewaren staat niet op zichzelf; opslag is in veel organisaties jarenlang gegroeid zonder duidelijke keuzes, waardoor steeds minder helder is waarvoor data eigenlijk wordt bewaard.
Herkenbaar? Klanten vragen om zekerheid, maar bedoelen iets anders dan wat de techniek daadwerkelijk levert. Back-up, archief en dataretentie worden door elkaar gebruikt alsof het synoniemen zijn. Dat zijn ze niet. Het verschil wordt ook nog eens steeds relevanter, door strengere wetgeving, groeiende hoeveelheden data en de toenemende impact van incidenten.
Het misverstand
Hoe zat het ook weer? Back-up is bedoeld voor herstel. Het is een technische maatregel om data terug te kunnen zetten na verlies, corruptie of verstoring. Dat kan gaan om een per ongeluk verwijderde mailbox, een fout in een applicatie of een ransomware-incident. De focus ligt altijd op snelheid en beschikbaarheid: hoe snel kun je weer verder, en met zo min mogelijk dataverlies?
Back-up is dus niet een systeem om data langdurig, gestructureerd en doelgericht te bewaren. Toch zien veel organisaties back-ups als een soort vangnet voor alles wat ze ooit nodig zouden kunnen hebben. Oude projectbestanden, mailboxen van ex-medewerkers, historische administratie, klantdata die misschien ooit nog van pas komt. Alles blijft staan, want het kost weinig moeite en opslag kost niks meer.
En dat gaat heel lang goed, zolang niemand vragen stelt. Dan komt er een audit, een juridisch verzoek of er vindt een incident plaats waarbij blijkt dat herstel ingewikkelder is dan gedacht.
Drie verschillende begrippen
Even de begrippen op een rijtje.
Back-up draait om herstel. De vraag is, wat heb je nodig om operationeel weer door te kunnen na een storing of incident? De bewaartermijnen zijn meestal relatief kort en afgestemd op hersteldoelen. Denk aan dagen, weken of hooguit enkele maanden.
Archief gaat over bewaren met een doel. Data wordt vastgelegd omdat er een zakelijke, historische of wettelijke reden voor is. Het archief verandert niet (het groeit alleen), is doorzoekbaar en moet betrouwbaar zijn. Een archief is geen kopie van alles, maar een selectie van wat relevant is om te bewaren.
Dataretentie bepaalt hoe lang data mag of moet blijven bestaan. Geen techniek, maar een set afspraken dus. Sommige data moet jarenlang bewaard blijven, andere data mag juist niet te lang blijven staan.
Het probleem ontstaat wanneer deze drie door elkaar lopen. Als back-ups worden gebruikt als archief, ontbreekt structuur. Als retentie niet expliciet is vastgelegd, blijft alles staan. En als archivering wordt gezien als iets dat IT wel regelt, zonder afstemming met de business, ontstaan risico’s.
Alles bewaren ≠ strategie
Alles bewaren voelt veilig. Je weet nooit wat je nog nodig hebt, dus waarom zou je iets weggooien? Klinkt logisch, maar is in de praktijk riskant. Data groeit sneller dan veel organisaties beseffen. Niet alleen documenten en mail, maar ook logbestanden, exports, tijdelijke datasets en applicatiegegevens. Wat vandaag overzichtelijk lijkt, wordt over een paar jaar onhandelbaar. Dat maakt zoeken, herstellen en controleren steeds lastiger.
Daarnaast vergroot het bewaren van alles de impact van incidenten. Hoe meer data er is, hoe groter het oppervlak bij ransomware, datalekken of misbruik van accounts. Ook het herstel wordt complexer. Het terugzetten van een omgeving met jaren aan ongefilterde data kost meer tijd, meer capaciteit en meer geld.
Er zijn ook juridische risico’s. Data die je bewaart, kan opgevraagd worden. Data die je had moeten verwijderen maar nog steeds bezit, kan tegen je werken bij audits, rechtszaken of verzoeken van toezichthouders. Niet weten wat je bewaart, is geen verdedigbare positie.
Tot slot speelt kostenbeheersing een rol. Opslag lijkt goedkoop, maar back-ups, replicatie, egress-kosten en beheer tellen op. Zeker als bewaartermijnen ongemerkt steeds langer worden.
Data lifecycle management
Veel mkb-organisaties hebben geen expliciet data lifecycle management. Data komt binnen, wordt gebruikt en verdwijnt uit beeld, maar niet uit systemen. Als msp ligt hier een belangrijke rol: structuur aanbrengen zonder het onnodig ingewikkeld te maken.
Data lifecycle management begint bij een paar simpele vragen. Welke data maken we aan? Waar wordt die opgeslagen? Wie gebruikt die data actief? En wanneer verliest die data zijn waarde of noodzaak?
Op basis daarvan kun je onderscheid maken tussen actieve data, data die alleen nog geraadpleegd wordt, en data die eigenlijk geen functie meer heeft. Dat betekent niet dat alles meteen verwijderd moet worden, maar wel dat er keuzes gemaakt worden. Wat hoort in een archief, wat valt onder back-up, en wat moet na verloop van tijd verdwijnen?
Belangrijk is dat deze keuzes niet alleen technisch worden ingestoken. De business moet begrijpen waarom bepaalde data niet eindeloos beschikbaar blijft en wat daarvoor in de plaats komt. Een goed ingericht archief biedt vaak meer zekerheid dan een stapel oude back-ups waar niemand grip op heeft.
Juridische en operationele risico’s
Dataretentie raakt al snel aan juridische vragen, maar dat betekent niet dat elk gesprek juridisch hoeft te worden. Vaak gaat het vooral om een operationeel risico. Neem een medewerker die vertrekt. Mailboxen blijven vaak bestaan, soms jarenlang. Niemand weet precies wat erin zit, wie er toegang toe heeft en of die data nog nodig is. Bij een datalek of een inzageverzoek ontstaat ineens paniek.
Of klantdata die langer wordt bewaard dan nodig. Niet uit kwade wil, maar uit gemak. Dat kan botsen met privacyregels, maar ook met interne afspraken of contracten. Het ontbreken van een duidelijk retentiebeleid maakt het lastig om dit uit te leggen of te corrigeren.
Ook bij herstel na incidenten speelt dit mee. Als een omgeving teruggezet moet worden, is het belangrijk te weten welke data leidend is. Oude data die automatisch mee terugkomt kan fouten veroorzaken, verwarring geven of zelfs opnieuw risico’s introduceren.
Kosten en herstelbaarheid
Waar je bijna nooit iemand over hoort is de impact van dataretentie op herstel. Back-ups worden vaak ingericht met een focus op volledigheid. Alles wordt meegenomen, want dat is veilig. Maar bij een grootschalig incident blijkt die volledigheid vooral nadelen op te leveren.
Herstel duurt langer, want er moet meer data door het proces. De kans op het terugzetten van ongewenste of verouderde data neemt toe. En het kost meer capaciteit om alles weer beschikbaar te maken, zeker bij cloudomgevingen waar data-uitstroom en compute per gebruik worden afgerekend.
Je kunt ook nog denken aan meerdere recovery fases. Niet alles hoeft meteen terug. Herstel eerst de kernsystemen en actuele datasets, en archiefdata pas later. Of maak die op een andere manier beschikbaar.
Verwarring structureren
Voor jou als msp een herkenbaar spanningsveld. Klanten willen zekerheid, maar weten niet wat ze precies vragen. De neiging is om dat technisch op te lossen door meer back-ups, langere bewaartermijnen en extra opslag. Daarmee verschuif je het probleem, maar los je het niet op. De meerwaarde zit in het ontwarren van de verwarring. Door begrippen uit elkaar te trekken, voorbeelden te geven en consequent te blijven in taalgebruik. Niet alles is back-up. Niet alles hoeft bewaard te blijven. En niet alles wat bewaard blijft, hoort in een back-up.
Belangrijk is om keuzes expliciet te maken. Dat kan door scenario’s te schetsen. Wat gebeurt er bij een incident? Wat willen we binnen een dag terug hebben, en wat mag later? Wat moeten we wettelijk bewaren, en wat niet? Die gesprekken zijn vaak effectiever dan abstracte beleidsdocumenten.
Back-up is een essentieel onderdeel van databeheer, maar het is geen archief en geen retentiestrategie. Wie dat wel zo gebruikt, bouwt ongemerkt risico’s op. Pak je dit goed aan, dan ga je verder dan de techniek. Help klanten onderscheid te maken, keuzes te maken en die keuzes vast te houden.
