NLEN
Direct technisch advies?
Home > Blog

Klonen en schonen: Master or Disaster

Tino Dudink 09-03-2021 1:03 PM
Categories: Beheer, BLOG, DBMS, Tips

Het kopiëren van data lijkt bijna een dagelijkse behoefte geworden. En, ik geef het toe, aan de vraag om dit te automatiseren, werk ik graag mee. Het automatiseren van data- en databasekopieën naar afslagen voor ontwikkel-, test- en acceptatie-omgevingen is dagelijkse kost en er ligt vaak een valide 'businesscase' aan ten grondslag. De eenvoud en kracht van een geautomatiseerde procedure vormt meteen een belangrijke valkuil. Storage is kostbaar, zeker flash-storage in een enterprise-compute-omgeving, zoals HyperConverged Infrastructure (HCI). Ons datagebruik blijft maar groeien en lijkt weleens onbeheersbaar te worden. In deze blog vertelt Tino Dudink, DBA Consultant en Senior Database Reliability Engineer, over zijn visie op datagebruik.

Zinvoller vraag

Ik vergelijk het vaak met rapportages, het is inmiddels een onbewust gebruik om deze bij migraties en vernieuwingen vaak een-op-een over te zetten en mee te nemen, terwijl het zinvoller zou zijn jezelf af te vragen: voldoet dit rapport nog steeds aan een actuele vraag? Zo is dat ook met klonen en data kopiëren. Het kopiëren van slechts een selectie aan data (tabellen, sources) naar een staging-area of datalake is al wat efficiënter qua datagebruik en storagebeslag, maar kostbaarder in onderhoud bij aanpassingen, ondanks alle innovaties die er zijn. Met datavirtualisatie is een trend op gang gebracht waarin data niet meer op meerdere plekken wordt opgeslagen. Nadeel: aan deze oplossingen hangt een prijskaartje en vragen om een heel implementatietraject.

Na clonen komt schonen

Keuzes en keuzes. En dan hebben we het nog niet over het schonen gehad. Want na al dat bewaren en kopiëren, komt er een moment dat het technisch, operationeel, maar ook juridisch en financieel noodzakelijk wordt om te schonen. Juridisch in het kader van de AVG. Financieel omdat schaalbaarheid op het gebied van enterprise-storage uiteindelijk toch aardig in de papieren gaat lopen. Vanuit technisch beheersaspect (contingentie, back-up) en vanuit operationeel oogpunt (doorlooptijden van dagelijkse back-ups en onderhoudswindows) is het ook noodzakelijk om de omvang van databases, storagevolumes en data in de smiezen te houden. Nog steeds kom ik veel financiële, operationele en andere zakelijke software tegen die data wegschrijft in databases zonder ergens een faciliteit geregeld te hebben om die data op z'n tijd te archiveren en te schonen.

Toverwoord

'Opschonen by design' zou het toverwoord kunnen en moeten zijn, net als 'privacy by design' dat tegenwoordig ook is. Anders groeien de databases met logistieke en financiële gegevens elk jaar verder. Dat dit thema niet ouderwets maar actueler is dan ooit, door de voortgaande digitalisering , daar wil ik graag voor pleiten. Het zou een goed idee zijn wanneer elke ontwikkelaar die procedures ontwikkelt waarbij data worden opgeslagen, ook een archiverings- en verwijderprocedure ontwerpt én realiseert. Toch wordt daar vaak vooraf niet aan gedacht, en wordt er pas prioriteit aan gegeven op het moment dat de nood het hoogst is. Of het nu om gaat om partitionering, archivering en opschonen, of er nu sprake is van een datalek, uitval van bedrijfskritieke systemen of van een andere escalatie, pas dan wordt er prioriteit aan toegekend en geld voor vrijgemaakt.

Anonimiseren van data

Dat brengt mij op het verbindende slotstuk: het anonimiseren van data. Het klonen van data moet tegenwoordig altijd vergezeld gaan van het anonimiseren van klantgegevens en andere vertrouwelijke gegevens. Dat houdt natuurlijk verband met de AVG ofwel GDPR, maar kan ook bedrijfseconomische redenen hebben. De mogelijk imagoschade die je kunt oplopen bij incidenten waarbij zaken niet op de juiste wijze zijn verwerkt, is groot. Om dit te regelen zijn goede pakketten beschikbaar, maar je kunt ook kiezen voor maatwerk: controle, beheerbaarheid en toekomstbestendigheid zijn goede argumenten om het in eigen hand te willen houden.

Datazuinige benadering

Dit kan variëren van heel eenvoudige tot complexere procedures, als onderdeel zijn van de data-integratie- en datacopy-procedures. Naast het goed gebruik van least privilege in IT-securityverband, misstaat een datazuinige benadering in dit verband niet. Zoals - naar goed gebruik - in een Select query geen * of onnodige kolommen worden opgenomen, geldt dat voor data-integratie- en data-movement-oplossingen, des te meer. Elke duplicering van een persoonsgegeven leidt tot een verdubbeling van het risico en daarmee van de inspanning om dit risico beheersbaar te houden. Niks nieuws onder de zon, maar nog een keer extra aandacht vragen voor iets belangrijks als dit kan geen kwaad.

Datagovernance, de vergeten systemen

Tot slot vraag ik aandacht voor de vergeten systemen. Bij fusies en overnames worden IT-infrastructuren geïntegreerd en geconsolideerd. Maar wat te doen met de verouderde systemen die als legacysystemen worden bestempeld en waarbij de oorspronkelijke beheerders en eigenaren zijn vertrokken. Servers en databases die nog jaren(!) operationeel blijven op onderliggende systemen die niet meer worden gepatcht, omdat de onderliggende besturingssystemen en databasemanagementsystemen niet meer (kunnen) worden bijgewerkt. Ook dat kom ik geregeld tegen en dat vraagt om aandacht , tijd en inspanning.

Nieuwsgierig

Vanuit OptimaData werken we met een team van gedreven specialisten aan deze en andere thema's waarin we organisaties graag bijstaan bij het ontwerpen en implementeren van en het en overstappen naar een toekomstbestendige en robuuste (cloud)oplossing waarbij altijd passende aandacht is voor databases en data. Neem gerust eens vrijblijvend contact met ons op.

Andere interessante onderwerpen:

Invloed van Datamodelleren vaak onderschat

Al je data is van ons

Baas in eigen database

Klantcase VoiceWorks

Terug naar blogoverzicht

 

React