Databaserecovery. Heb jij al getest?

Door: Harry Splinter 16-3-2023

Categorieën
:
Beheer, BLOG, DBMS,

In het verleden schreef Harry Splinter, Database Reliability Engineer bij OptimaData, al eens over de SAP ASE back-up’s onder de titel ‘Thoughts on backups’, waarin hij ook aandacht besteedde aan recovery. Tijdens zijn loopbaan als DBA kwam hij al aardig wat situaties tegen waarbij recovery de laatste strohalm was. Dit leidde soms tot onaangename verrassingen. In deze blog deelt hij zijn ervaringen. Ter lering, ende ook zeker ter vermaeck.

Tapes

Iedereen kent het wel, het wisselen van tapes en deze afvoeren naar een veilige, off-site, omgeving of in een kluis. Het terugzetten van een tape is niet anders dan het teruglezen van de data op schijf. Daarbij is het natuurlijk wel relevant dat die data ook daadwerkelijk teruggelezen kan worden. Ook als de back-up-software meldt dat een back-up gelukt is, kan een tape-unit ‘out of sync’ zijn. Hierbij is de schrijfkop niet goed ‘aligned’. Klinkt ingewikkeld, maar het resultaat is dat de back-ups onleesbaar zijn. alhoewel. Gelukkig is dit euvel met hulp van een engineer te herstellen, maar dan moeten wel alle tapes opnieuw gelezen en geschreven worden. Het is mij een keer overkomen, en toen was het een kostbaar klusje van een week om alles te herstellen. In dit geval hadden we bij toeval nog de dag ervoor een back-up van deze ‘niet productiekritische database’ naar een testomgeving gekopieerd.

Databases

Ook corruptie in de database wordt niet altijd gedetecteerd door de back-up-software. Het is belangrijk om regelmatig dbcc-checks of andere checks uit te voeren, om corruptie tijdig te onderkennen en te herstellen. Cross-database query’s is een oorzaak van database-inconsistency. Point-in-time-recovery – een databasehersteltechniek die het mogelijk maakt om een database terug te zetten naar een bepaald tijdstip in het verleden – is dan vrijwel onmogelijk. Als je hier geen rekening mee houdt, is de recovery van één enkele database niet voldoende en moeten alle gerelateerde databases worden teruggezet waarbij er nog altijd dataverlies kan optreden. Back-ups worden vaak serieel uitgevoerd in een databasemanagementsysteem. Dat heeft ook invloed op de recoverytijd en welke point-in-time er wordt gekozen bij afhankelijkheden met andere systemen.

Andere media

Ook het uitvoeren van een back-up via het netwerk, naar disk of andere media kan misgaan. Dit kan door allerlei problemen worden veroorzaakt, zoals dataverlies door netwerkverstoringen – zogenaamde ‘dropped data-packets –, door verstoringen op de disk of memory leakage.

De menselijke inbreng

Verwijderen van data, het droppen van een tabel, database of andere handeling is iets wat vaker voorkomt dan ons lief is. Vaak wordt het veroorzaakt door het ontbreken van een toegangs- en rechtenbeleid waarvoor we zelf medeverantwoordelijk zijn. Recovery is ook hier de redder in nood, maar vaak wat complexer als er geen gehele database mag worden teruggezet. Voldoende ruimte binnen de omgeving of op de machine is dan ook van groot belang. Een herstelomgeving opbouwen en achter de hand houden kan de doorlooptijd van het recoveryproces flink versnellen.

Het recoveryplan

‘Staat op de bedrijfswiki’, is een vaak gehoord antwoord als we vragen waar het recoveryplan staat. De uitvoering laat vaak te wensen over. Door de dagelijkse beslommering wordt deze taak al snel uitgesteld. Bovendien is er vaak maar één medewerker die bekend is met de inhoud van het plan en geoefend in de uitvoering ervan. Geen klusje voor iemand die er geen ervaring mee heeft. In de huidige maatschappij heeft beschikbaarheid van data een hoge prioriteit en er wordt dan ook veel in geïnvesteerd, denk aan termen als Always On, Clusters-software, monitoring, 24/7-support, 99.999% uptime). Recovery is bijna altijd een punt op de agenda, maar krijgt daarmee niet altijd de aandacht die het zou moeten hebben.

Rust, Regelmaat en Recovery

Rust voor de DBA komt met de regelmaat waarmee recoveryplannen worden uitgevoerd. Verdeling van de kennis en controle daarop geeft vertrouwen. Niet leunen op één persoon, maar op meerdere medewerkers die weten hoe ze het plan moeten uitvoeren en daar ook regelmatig mee hebben beoefend. Dit kan ook een gedelegeerde verantwoordelijkheid zijn bij kleinere organisaties. Hierbij is het een goede procedurele beschrijving van het recoveryplan van groot belang. Recovery zou net zo eenvoudig moeten zijn als het maken van een back-up.

In de praktijk

Maandagnacht, vijf over twaalf. De telefoon gaat:

‘Goedenacht, met je collega. Over één uur verzamelen we ons voor een disaster-recovery. Het disk-array is gecrasht en we moeten terugvallen op de back-ups. De databaseservers zijn niet meer bereikbaar”.

Collega: ‘Geen probleem, ik kom eraan. Uit ervaring weet ik dat het recoveryproces ongeveer drie uur in beslag zal nemen’

Wat zou jouw antwoord zijn?

Rustig slapen dankzij een HealthCheck

Om snel en efficiënt een beeld te vormen van de staat van jouw back-ups, de efficiëntie van je recoveryproces én om te onderzoeken waar verbeteringen mogelijk zijn is de database HealthCheck van OptimaData een goed startpunt. Alle controlepunten die ik hier noem worden sowieso nagelopen en de HealthCheck omvat nog veel meer dan alleen back-up en recovery. Als je die met regelmaat uitvoert, kun je rustig slapen. En word je toch wakker gebeld, dan heb je in ieder geval je antwoord klaar.

Zijn jouw back-ups en recoveryproces je redder in nood?

Neem vrijblijvend contact met ons op als je meer wilt weten over de mogelijkheden van een HealthCheck of specifiek advies op jouw recoveryproces of als je je zorgen maakt om de performance van je databases.

Andere interessante blogs

Van het een komt het ander

De winst van database onderhoud

Klonen en schonen: Master or Disaster

Terug naar blog overzicht