Point-in-Time Recovery vs Snapshots: Hva du mister

Noen kjører en DELETE uten en WHERE-klausul kl. 16:15. Den nyeste backupen din er fra kl. 03:00. Alt mellom disse tidspunktene er borte, og ingen gjenoppretting i verden kan bringe det tilbake.

Dette gapet har et navn — recovery point objective, eller RPO — og avgjørelsen mellom point-in-time recovery vs snapshots handler utelukkende om hvor stort du er villig til å la det være.

De to modellene

Snapshots tar vare på tilstanden til dataene dine på et bestemt tidspunkt. De kjører etter en tidsplan, vanligvis hver natt. Når du gjenoppretter et snapshot, er du tilbake nøyaktig der du var da det ble tatt, og alt etter dette tidspunktet går tapt.

Point-in-time recovery kombinerer en base backup med en kontinuerlig strøm av databasens write-ahead log. Fordi hver endring registreres i riktig rekkefølge, kan du spille av loggen til ethvert tidspunkt som dekkes av den bevarte loggen — inkludert kl. 16:14, ett minutt før slettingen.

Forskjellen er ikke gradvis. Det er forskjellen mellom «vi mistet en dag» og «vi mistet ett minutt».

Tallet som avgjør

Still deg selv ett spørsmål, og vær ærlig: Hva skjer hvis du mister alt som er skrevet de siste tolv timene?

For et personlig prosjekt, et dokumentasjonsnettsted eller et internt verktøy med data som kan gjenskapes: ikke stort. Nightly snapshots er faktisk det riktige svaret, og det ville være sløsing å betale for kontinuerlig arkivering.

For alt som har kunder som skriver data til det, er svaret vanligvis en variant av «vi må sende e-post til folk og forklare». Ordrer som ikke lenger finnes. Opplastinger som forsvant. Meldinger som ble sendt, men som nå ikke finnes. Supportkostnadene alene overstiger som regel forskjellen i infrastrukturkostnader for et helt år.

Feilen er ikke å velge snapshots. Feilen er å velge snapshots som standard, uten noen gang å spørre hva et hull på tolv timer faktisk ville kostet.

Det snapshots faktisk er gode på

De er ikke et dårligere produkt. De dekker feil som PITR ikke dekker:

• Tap av hele disken. Et snapshot på separat lagring gjenoppretter alt, også filer som databasen ikke eier.
• Rask, grovkornet rollback. Det går raskere å rulle tilbake en mislykket migrering i et staging-miljø fra et snapshot enn å spille av en logg.
• Kostnad. Det er billigere å lagre én kopi om dagen enn å lagre hver eneste skriv operasjon.
• Enkelhet. Færre komponenter er en reell operasjonell egenskap, særlig for et lite team.

Fellen er å behandle dem som tilstrekkelige for en database som mottar kontinuerlige skriv.

Hva PITR koster deg

Det er ikke gratis, og kostnadene er verdt å sette ord på:

• Lagring. Du beholder base backupen pluss alle skriv i løpet av retention-vinduet.
• Kompleksitet. Arkiveringen må fungere kontinuerlig. En archiver som har feilet i det stille i en uke, betyr at det gjenopprettbare tidsvinduet slutter for en uke siden — derfor er overvåking av arkivet like viktig som konfigureringen.
• Gjenopprettingstid. Det tar lengre tid å spille av en logg enn å gjenopprette et snapshot. RPO blir bedre, mens RTO vanligvis blir dårligere.

Det siste bytteforholdet overrasker mange. PITR betyr at du mister mindre data, ikke at du er raskere tilbake på nett.

Det lagdelte svaret de fleste team faktisk trenger

I praksis er dette ikke et valg mellom to ting. Produksjonsdatabaser trenger vanligvis tre lag, fordi de feiler på tre forskjellige måter:

Snapshots, daglig, beholdt i én eller to uker. Billig forsikring mot å miste maskinen. Dette dekker også filer som ikke tilhører databasen, men som ligger på samme volume.

Logical dumps, daglig, lagret utenfor hosten. En pg_dump er portabel og konsistent by design. Den kan gjenopprettes på en annen major version, hos en annen provider eller på en laptop — akkurat det du trenger når problemet ligger i plattformen og ikke i dataene.

Kontinuerlig arkivering når dataene tilhører kunder. Laget som gjør «vi mistet alt fra i dag» til «vi mistet ett minutt».

Hvert lag dekker det de andre ikke gjør. Et snapshot hjelper deg ikke med å flytte mellom providers. En logical dump hjelper deg ikke med å gjenopprette en fil som ikke var i databasen. Ingen av delene hjelper deg med å angre en sletting fra for fire timer siden.

Hvor Dockup passer inn

Dockup gir deg de to lagene som dekker de vanligste feilene, og det er verdt å være presis på hvilke lag det er.

Volume snapshots, ved behov eller etter en tidsplan med et angitt antall beholdte kopier:

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, strømmet direkte til object storage og kryptert underveis:

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

To egenskaper ved det siste punktet er viktige for gjenoppretting. Backupen havner aldri på database-hosten — den strømmes til lagring mens pg_dump produserer den, slik at den ikke deler skjebne med disken den kommer fra. Og en dump som avsluttes med en status forskjellig fra null, eller som produserer null byte, slettes og registreres som mislykket i stedet for å bli liggende i listen og se ut som en backup.

Kontinuerlig arkivering er ikke noe Dockup kjører for deg i dag. Hvis RPO-et ditt faktisk måles i minutter, er dette verdt å vite før du velger, og det er helt rimelig å kjøre dette selv mot en managed database mens du bruker plattformen til alt annet.

Øvelsen det er verdt å gjøre denne uken

Skriv ned to tall for produksjonsdatabasen din:

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

Sjekk deretter hva oppsettet ditt faktisk leverer, ved å gjenopprette noe. Hvis tallene du skrev ned og tallene oppsettet ditt leverer, er forskjellige, har du funnet en beslutning du kan ta mens ingenting brenner — og det er det eneste gode tidspunktet å ta den på.

Vanlige spørsmål

Hva er forskjellen mellom RPO og RTO? RPO er hvor mye data du mister — gapet mellom det siste gjenopprettbare tidspunktet og feilen. RTO er hvor lang tid gjenopprettingen tar. Snapshots gir deg et stort RPO og et kort RTO, mens PITR snur dette på hodet.

Kan jeg gjenopprette rader som ble slettet for en time siden, fra et nightly snapshot? Nei. Et snapshot gjenoppretter tilstanden på tidspunktet det ble tatt. Alt som ble skrevet etterpå, finnes ikke i filen. For å gjenopprette et vilkårlig tidspunkt trenger du kontinuerlig arkivering.

Er et volume snapshot det samme som en database backup? Nei. Et snapshot tar vare på disken, inkludert eventuell tilstand der databasen var midt i en skriv operasjon. En logical dump er internt konsistent og portabel til andre versjoner og providers. De fleste produksjonsoppsett trenger begge deler.

Hvor lenge bør jeg beholde backuper? Lenge nok til at du rekker å oppdage et problem. Korrupsjon eller en mislykket migrering blir ofte oppdaget flere dager senere, så én dags retention betyr ofte at de eneste backupene du har, allerede inneholder skaden.