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 Health Check 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 vrijblijvendcontact met ons opals je meer wilt weten over de mogelijkheden van eenHealthCheckof specifiek advies op jouw recoveryproces of als je je zorgen maakt om de performance van je databases.
