Point-in-Time Recovery vs snapshots: Hvad mister du?

En person kører en DELETE uden en WHERE-klausul kl. 16.15. Din seneste backup er fra kl. 03.00. Alt mellem de to tidspunkter er væk, og ingen gendannelse kan bringe det tilbage.

Det hul har et navn — recovery point objective, eller RPO — og beslutningen mellem point-in-time recovery vs snapshots handler udelukkende om, hvor stort du er villig til at lade det være.

De to modeller

Snapshots gemmer tilstanden af dine data på et bestemt tidspunkt. De kører efter en tidsplan, som regel nightly. Når du gendanner et snapshot, er du præcis tilbage dér, hvor du var, da det blev oprettet, og alt derefter går tabt.

Point-in-time recovery kombinerer en basebackup med en kontinuerlig strøm af databasens write-ahead log. Fordi alle ændringer registreres i rækkefølge, kan du afspille dem frem til et hvilket som helst tidspunkt, der er dækket af den gemte log — inklusive kl. 16.14, ét minut før sletningen.

Forskellen er ikke trinvis. Det er forskellen på "vi mistede en dag" og "vi mistede et minut".

Tallet, der afgør det

Stil dig selv ét spørgsmål, helt ærligt: Hvis du mistede alt, der er skrevet inden for de seneste tolv timer, hvad ville der så ske?

For et personligt projekt, et dokumentationssite eller et internt værktøj, hvor data kan genskabes: ikke det store. Nightly snapshots er helt oprigtigt det rigtige svar, og det ville være spild at betale for kontinuerlig arkivering.

For alt, hvor kunder skriver data til systemet, er svaret som regel en variation af "vi bliver nødt til at sende folk en mail og forklare det". Ordrer, der ikke længere findes. Uploads, der er forsvundet. Beskeder, der blev sendt, men nu ikke længere er der. Alene supportomkostningerne overstiger typisk forskellen i infrastrukturudgifter for et helt år.

Fejlen er ikke at vælge snapshots. Fejlen er at vælge snapshots som standard uden nogensinde at spørge, hvad et hul på tolv timer ville koste.

Det, snapshots faktisk er gode til

De er ikke et ringere produkt. De dækker fejlscenarier, som PITR ikke gør:

• Tab af en hel disk. Et snapshot på separat storage gendanner alt, også filer som databasen ikke ejer.
• Hurtig, grovkornet rollback. Det er hurtigere at rulle en fejlslagen migration tilbage i et staging-miljø fra et snapshot end ved at afspille en log.
• Pris. Det er billigere at gemme én kopi om dagen end at gemme hver eneste skrivning.
• Enkelhed. Færre moving parts er en reel operationel fordel, især for et lille team.

Fælden er at betragte dem som tilstrækkelige til en database, der modtager kontinuerlige writes.

Hvad PITR koster dig

Det er ikke gratis, og omkostningerne fortjener at blive nævnt:

• Storage. Du opbevarer basebackupen plus alle writes i retention-perioden.
• Kompleksitet. Arkiveringen skal fungere kontinuerligt. En archiver, der i stilhed har fejlet i en uge, betyder, at dit gendannelige vindue sluttede for en uge siden — og derfor er overvågning af arkivet lige så vigtigt som konfigurationen.
• Gendannelsestid. Det tager længere tid at afspille en log end at gendanne et snapshot. Din RPO bliver bedre, mens din RTO som regel bliver dårligere.

Den sidste afvejning kommer bag på mange. PITR betyder, at du mister mindre data — ikke at du er hurtigere online igen.

Det lagdelte svar, som de fleste teams faktisk har brug for

I praksis er det ikke et valg mellem to ting. Produktionsdatabaser har som regel brug for tre lag, fordi de fejler på tre forskellige måder:

Snapshots, dagligt, gemt i en uge eller to. Billig forsikring mod at miste maskinen. Det er også det, der dækker filer uden for databasen, som ligger på samme volume.

Logiske dumps, dagligt, gemt uden for hosten. En pg_dump er portabel og konsistent by design. Den kan gendannes på en anden major version, hos en anden provider eller på en laptop — og det er præcis, hvad du har brug for, når problemet er platformen og ikke dataene.

Kontinuerlig arkivering, når databasen indeholder kundedata. Det lag, der ændrer "vi mistede i dag" til "vi mistede et minut".

Hvert lag dækker det, de andre ikke gør. Et snapshot hjælper dig ikke med at skifte provider. Et logisk dump hjælper dig ikke med at gendanne en fil, der ikke lå i databasen. Ingen af delene hjælper dig med at fortryde en sletning fra for fire timer siden.

Hvor Dockup passer ind

Dockup giver dig de to lag, der dækker de mest almindelige fejl, og det er værd at være præcis om, hvilke det er.

Volume-snapshots, efter behov eller efter en tidsplan med et fast antal gemte versioner:

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

Logiske databasebackups, streamet direkte til object storage og krypteret undervejs:

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

To egenskaber ved den sidste løsning er vigtige for gendannelse. Backuppen lander aldrig på databasehosten — den streames til storage, mens pg_dump producerer den, så den deler ikke skæbne med den disk, den kommer fra. Og et dump, der afsluttes med en status forskellig fra nul eller producerer nul bytes, slettes og registreres som fejlslået i stedet for at ligge på listen og ligne en backup.

Kontinuerlig arkivering er ikke noget, Dockup kører for dig i dag. Hvis din RPO reelt skal være målt i minutter, er det værd at vide, før du vælger, og det er helt rimeligt at køre det selv mod en managed database, mens du bruger platformen til alt andet.

Øvelsen, der er værd at lave i denne uge

Skriv to tal ned for din produktionsdatabase:

1. RPO — hvor meget data du kan miste. Målt i tid.
2. RTO — hvor længe du kan være nede. Også målt i tid.

Tjek derefter, hvad din nuværende opsætning faktisk leverer, ved at gendanne noget. Hvis tallene, du skrev ned, og de tal, din opsætning leverer, er forskellige, har du fundet en beslutning, der kan træffes, mens intet brænder — og det er det eneste gode tidspunkt at træffe den på.

Ofte stillede spørgsmål

Hvad er forskellen på RPO og RTO? RPO er, hvor meget data du mister — hullet mellem det seneste gendannelige tidspunkt og fejlen. RTO er, hvor lang tid gendannelsen tager. Snapshots giver dig en stor RPO og en kort RTO; PITR vender det forhold om.

Kan jeg gendanne rækker, der blev slettet for en time siden, fra et nightly snapshot? Nej. Et snapshot gendanner tilstanden på det tidspunkt, hvor det blev taget. Alt, der er skrevet efter det, findes ikke i filen. Gendannelse til et vilkårligt tidspunkt kræver kontinuerlig arkivering.

Er et volume-snapshot det samme som en databasebackup? Nej. Et snapshot gemmer disken, inklusive den tilstand databasen var i midt under en skrivning. Et logisk dump er internt konsistent og portabelt til andre versioner og providere. De fleste produktionsopsætninger har brug for begge dele.

Hvor længe bør jeg opbevare backups? Længe nok til at opdage et problem. Korruption eller en fejlslagen migration bliver ofte opdaget flere dage senere, så én dags retention betyder ofte, at de eneste backups, du har, allerede indeholder skaden.