Point-in-time recovery versus snapshots: wat je verliest

Iemand voert om 16:15 uur een DELETE uit zonder WHERE-clause. Je meest recente backup is van 03:00 uur. Alles tussen die twee tijdstippen is weg en geen enkele restore kan het terugbrengen.

Die tussenruimte heeft een naam — recovery point objective, oftewel RPO — en de keuze tussen point-in-time recovery versus snapshots draait volledig om hoe groot je bereid bent die tussenruimte te laten zijn.

De twee modellen

Snapshots leggen de staat van je data op een bepaald moment vast. Ze worden volgens een schema gemaakt, meestal nightly. Als je er één terugzet, ga je exact terug naar de staat van het moment waarop de snapshot werd gemaakt, en alles daarna gaat verloren.

Point-in-time recovery combineert een base backup met een continue stroom van de write-ahead log van de database. Omdat elke wijziging in de juiste volgorde wordt vastgelegd, kun je terugspelen naar elk moment dat door de bewaarde log wordt gedekt — inclusief 16:14 uur, één minuut vóór de delete.

Het verschil is niet gradueel. Het is het verschil tussen "we zijn een dag kwijt" en "we zijn een minuut kwijt."

Het getal dat de doorslag geeft

Stel jezelf eerlijk één vraag: wat gebeurt er als je alles verliest wat in de afgelopen twaalf uur is geschreven?

Voor een persoonlijk project, een documentatiesite of een interne tool waarvan de data reproduceerbaar is: niet veel. Nightly snapshots zijn dan echt het juiste antwoord, en betalen voor continuous archiving zou verspilling zijn.

Voor alles waarop klanten data schrijven, luidt het antwoord meestal ongeveer: "we zouden mensen moeten mailen en uitleggen wat er is gebeurd." Bestellingen die niet meer bestaan. Uploads die verdwenen zijn. Berichten die zijn verstuurd en nu niet meer terug te vinden zijn. Alleen al de kosten van support zijn meestal hoger dan het verschil in infrastructuurkosten over een heel jaar.

De fout is niet dat je voor snapshots kiest. De fout is dat je standaard voor snapshots kiest, zonder ooit te vragen wat een gat van twaalf uur zou kosten.

Waar snapshots echt goed voor zijn

Ze zijn geen inferieur product. Ze dekken storingen af die PITR niet afdekt:

• Verlies van de volledige schijf. Een snapshot op afzonderlijke storage zet alles terug, inclusief bestanden die niet door de database worden beheerd.
• Snelle, grove rollback. Een mislukte migration terugdraaien in een stagingomgeving gaat sneller vanuit een snapshot dan door een log opnieuw af te spelen.
• Kosten. Eén kopie per dag opslaan is goedkoper dan elke write opslaan.
• Eenvoud. Minder bewegende onderdelen is een echte operationele eigenschap, vooral voor een klein team.

De valkuil is dat je ze als voldoende beschouwt voor een database waarin continu wordt geschreven.

Wat PITR je kost

Het is niet gratis, en het is belangrijk om de kosten te benoemen:

• Storage. Je bewaart de base backup plus elke write gedurende de retentionperiode.
• Complexiteit. Archiving moet continu werken. Een archiver die een week lang stilletjes faalt, betekent dat je recoverable window een week geleden eindigt — daarom is het monitoren van het archief net zo belangrijk als de configuratie ervan.
• Restore-tijd. Een log terugspelen duurt langer dan een snapshot terugzetten. Je RPO wordt beter; je RTO wordt meestal slechter.

Die laatste trade-off verrast mensen. PITR betekent dat je minder data verliest, niet dat je sneller weer online bent.

Het gelaagde antwoord dat de meeste teams echt nodig hebben

In de praktijk is dit geen keuze tussen twee dingen. Productiedatabases hebben meestal drie lagen nodig, omdat ze op drie verschillende manieren kunnen uitvallen:

Snapshots, dagelijks, één of twee weken bewaard. Goedkope verzekering tegen het verlies van de machine. Dit dekt ook de bestanden die geen deel uitmaken van de database maar wel op hetzelfde volume staan.

Logical dumps, dagelijks, buiten de host bewaard. Een pg_dump is portable en per definitie consistent. Je kunt het terugzetten op een andere major version, bij een andere provider of op een laptop — precies wat je wilt wanneer het probleem bij het platform ligt en niet bij de data.

Continuous archiving, wanneer er klantdata in staat. De laag die "we zijn vandaag alles kwijt" verandert in "we zijn een minuut kwijt."

Elke laag dekt wat de andere niet dekken. Een snapshot helpt je niet om van provider te wisselen. Een logical dump helpt je niet om een bestand te herstellen dat niet in de database stond. Geen van beide helpt je om een delete van vier uur geleden ongedaan te maken.

Waar Dockup zich bevindt

Dockup biedt de twee lagen die de meest voorkomende storingen afdekken, en het is de moeite waard om precies te zijn over welke dat zijn.

Volume snapshots, op aanvraag of volgens een schema met een retention count:

dockup volume snapshot <volumeId> my-project/my-api
dockup volume schedule <volumeId> my-project/my-api --daily --retention 7
dockup volume restore <volumeId> <snapshotId> my-project/my-api

Logical database backups, rechtstreeks naar object storage gestreamd en tijdens het transport versleuteld:

dockup db backup my-project/main-db --json
dockup db backups my-project/main-db --json

Twee eigenschappen van die tweede optie zijn belangrijk voor recovery. De backup komt nooit op de databasehost terecht — hij wordt naar storage gestreamd terwijl pg_dump hem produceert, zodat hij niet hetzelfde lot ondergaat als de schijf waarvan hij afkomstig is. En een dump die eindigt met een exitcode ongelijk aan nul of nul bytes produceert, wordt verwijderd en als mislukt geregistreerd in plaats van in de lijst te blijven staan en eruit te zien als een backup.

Continuous archiving voert Dockup momenteel niet voor je uit. Als je RPO echt minuten moet zijn, is het belangrijk dat je dit weet voordat je een keuze maakt. Het is ook redelijk om dit zelf op een managed database te draaien en het platform voor al het overige te gebruiken.

De oefening die je deze week moet doen

Noteer twee getallen voor je productiedatabase:

1. RPO — hoeveel data je kunt verliezen. Gemeten in tijd.
2. RTO — hoelang je offline kunt zijn. Ook gemeten in tijd.

Controleer vervolgens wat je huidige setup daadwerkelijk oplevert door iets te restoren. Als de getallen die je hebt opgeschreven verschillen van wat je setup oplevert, heb je een beslissing gevonden die je kunt nemen terwijl er niets in brand staat — en dat is het enige goede moment om die beslissing te nemen.

Veelgestelde vragen

Wat is het verschil tussen RPO en RTO? RPO is hoeveel data je verliest — het gat tussen het laatste herstelbare moment en de storing. RTO is hoelang recovery duurt. Snapshots geven je een grote RPO en een korte RTO; PITR draait dat om.

Kan ik rijen herstellen die een uur geleden zijn verwijderd vanuit een nightly snapshot? Nee. Een snapshot herstelt de staat op het moment waarop die werd gemaakt. Alles wat daarna is geschreven, staat niet in het bestand. Om een willekeurig moment te herstellen heb je continuous archiving nodig.

Is een volume snapshot hetzelfde als een databasebackup? Nee. Een snapshot legt de schijf vast, inclusief de staat waarin de database zich halverwege een write bevond. Een logical dump is intern consistent en portable naar andere versies en providers. De meeste productieomgevingen hebben beide nodig.

Hoelang moet ik backups bewaren? Lang genoeg om een probleem op te merken. Corruptie of een mislukte migration wordt vaak pas dagen later ontdekt, waardoor één dag retention vaak betekent dat de enige backups die je hebt de schade al bevatten.