Het begrip Point-In-time-Recovery, kortweg PITR, betekent dat data vanaf een back-up teruggehaald kan worden tot een willekeurig moment. In de praktijk betekent dit dat u in geval van een incident een database (in de meeste gevallen) kunt herstellen tot vlak voor het moment dat het incident zich voordeed. Het doel van PITR is gegevens te kunnen herstellen van een incident met zo weinig mogelijk of nog idealer; geen dataverlies.
Dit klinkt mooi, maar er zijn wat voorwaarden aan verbonden en de vraag is of de extra kosten van deze voorwaarden opwegen tegen de mogelijke schade. Laten we eerst eens kijken hoe PITR in zijn werk gaat.
Bij een standaard back-up oplossing zal één keer per dag een back-up worden gemaakt. Vaak gebeurt dit ’s avonds of ’s nachts. Als er een incident optreedt waarbij een restore van de database noodzakelijk is, dan zullen de mutaties tussen het back-up moment en het incident verloren zijn nadat de back-up teruggeplaatst is. Het voordeel is dat een dergelijke restore vaak snel kan worden uitgevoerd zodat de applicatie of website snel weer actief kan zijn.
Bij een PITR back-up procedure gaat het iets anders. Databases hebben de mogelijkheid om hun transacties te loggen. MySQL gebruikt bijvoorbeeld binlog, Postgresql WAL (Write Ahead Log) en MSSQL gebruikt transaction logs. Deze logs bevatten alle mutaties die op de databases zijn toegepast. Standaard staat deze vorm van logging uit. Als u dus met uw back-up routine deze transacties opslaat, kunt u een restore uitvoeren door de laatste back-up terug te zetten en vanaf de laatste mutatie in de back-up de overige mutaties vanuit de opgeslagen transactie logs in te laten lezen door de database server. Vanwege de mogelijk meerdere stappen die gedaan moeten worden zal deze vorm van database restore langer duren dan het teruglezen van een enkele database back-up.
Hoewel de data dus vanaf de laatste back-up tot vlak voor het incident teruggehaald kan worden, is de tijd die benodigd is om deze handelingen uit te voeren langer dan bij het terughalen van één enkele database back-up.
Zorg ervoor dat er een dagelijkse/nachtelijke back-up geschikt is om aangevuld te worden met transactie logs. Transactie logs werken niet per database, maar per server. Alle mutaties van alle databases staan door elkaar in hetzelfde bestand. Als u alleen losse back-ups maakt per database, zal het tijdstip van de laatste mutatie bij elke database back-up verschillen, hoe bepaalt u dan vanaf welk moment u transacties opnieuw wilt laten invoeren?
Uw back-up moet dus alle databases bevatten met een markering welke positie de laatste in de back-up is. MySQL, Percona en MariaDB kennen bijvoorbeeld binlog position en GTID.
Vaak moet er slechts één database hersteld worden, maar de transactie logs bevatten transacties van alle databases. De restore moet dus plaatsvinden op een tweede server waar naderhand de getroffen database weer vandaan kan worden gehaald om in productie geplaatst te worden.
Wilt u meer weten over Point-In-Time-Recovery? ROOT beantwoord graag al uw vragen over PITR en hoe dit in uw situatie toegepast kan worden.
Vond je deze blog interessant? Schrijf je hieronder in voor onze nieuwsbrief, en blijf regelmatig op de hoogte van onze blogs!
Meer informatie over dit onderwerp