Point-in-Time Recovery jämfört med snapshots: Vad du förlorar

Någon kör en DELETE utan en WHERE-sats klockan 16:15. Din senaste backup är från 03:00. Allt mellan de två tidpunkterna är borta, och ingen återställning i världen kan få tillbaka det.

Det gapet har ett namn — recovery point objective, eller RPO — och beslutet mellan point-in-time recovery och snapshots handlar helt och hållet om hur stort du är villig att låta det vara.

De två modellerna

Snapshots fångar tillståndet för dina data vid en viss tidpunkt. De körs enligt ett schema, vanligtvis varje natt. När du återställer en snapshot hamnar du exakt där du var när den skapades, och allt därefter går förlorat.

Point-in-time recovery kombinerar en base backup med en kontinuerlig ström av databasens write-ahead log. Eftersom varje ändring registreras i ordning kan du spela upp loggen till valfri tidpunkt som täcks av den sparade loggen — inklusive 16:14, en minut före raderingen.

Skillnaden är inte inkrementell. Det är skillnaden mellan ”vi förlorade en dag” och ”vi förlorade en minut”.

Siffran som avgör

Ställ dig själv en fråga, och svara ärligt: om du förlorade allt som skrivits under de senaste tolv timmarna, vad skulle hända?

För ett hobbyprojekt, en dokumentationswebbplats eller ett internt verktyg där data går att återskapa: inte särskilt mycket. Snapshots varje natt är verkligen rätt svar, och att betala för kontinuerlig arkivering vore slöseri.

För allt där kunder skriver data är svaret oftast någon variant av ”vi skulle behöva mejla folk och förklara”. Ordrar som inte längre finns. Uppladdningar som försvunnit. Meddelanden som skickats men nu inte finns kvar. Bara kostnaden för support brukar överstiga ett års skillnad i infrastrukturkostnader.

Misstaget är inte att välja snapshots. Misstaget är att välja snapshots som standard, utan att någonsin fråga vad ett hål på tolv timmar skulle kosta.

Vad snapshots faktiskt är bra på

De är inte en sämre produkt. De täcker fel som PITR inte gör:

• Total förlust av disken. En snapshot på separat lagring återställer allt, även filer som databasen inte äger.
• Snabb, grovkornig rollback. Att återställa en misslyckad migration i en stagingmiljö går snabbare från en snapshot än genom att spela upp en logg.
• Kostnad. Att lagra en kopia om dagen är billigare än att lagra varje skrivning.
• Enkelhet. Färre rörliga delar är en verklig operativ egenskap, särskilt för ett litet team.

Fällan är att behandla dem som tillräckliga för en databas som tar emot kontinuerliga skrivningar.

Vad PITR kostar dig

Det är inte gratis, och kostnaderna är värda att nämna:

• Lagring. Du behåller base backup plus varje skrivning under retentionstiden.
• Komplexitet. Arkiveringen måste fungera kontinuerligt. En archiver som har misslyckats i tysthet i en vecka innebär att ditt återställningsbara tidsfönster slutar för en vecka sedan — därför är övervakning av arkivet lika viktigt som att konfigurera det.
• Återställningstid. Att spela upp en logg tar längre tid än att återställa en snapshot. Ditt RPO förbättras, medan ditt RTO vanligtvis blir sämre.

Den sista kompromissen överraskar många. PITR innebär att du förlorar mindre data, inte att du är tillbaka online snabbare.

Det skiktade svar som de flesta team faktiskt behöver

I praktiken handlar det här inte om att välja mellan två saker. Produktionsdatabaser behöver vanligtvis tre lager, eftersom de kan fallera på tre olika sätt:

Snapshots, dagligen, sparade i en eller två veckor. Billig försäkring mot att förlora maskinen. Det här täcker även filer som inte hör till databasen men ligger på samma volym.

Logiska exporter, dagligen, sparade utanför värden. En pg_dump är portabel och konsekvent av naturen. Den kan återställas till en annan major version, hos en annan leverantör eller på en laptop — vilket är vad du vill när problemet ligger i plattformen snarare än i datan.

Kontinuerlig arkivering när datan innehåller kunddata. Lagret som förvandlar ”vi förlorade idag” till ”vi förlorade en minut”.

Varje lager täcker det som de andra inte gör. En snapshot hjälper dig inte att byta leverantör. En logisk export hjälper dig inte att återställa en fil som inte låg i databasen. Inget av dem hjälper dig att ångra en radering från för fyra timmar sedan.

Var Dockup passar in

Dockup ger dig de två lager som täcker de vanligaste felen, och det är värt att vara tydlig med vilka de är.

Volymsnapshots, vid behov eller enligt ett schema med ett angivet antal sparade 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

Logiska databasbackuper, strömmade direkt till objektlagring och krypterade under överföringen:

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

Två egenskaper hos den andra funktionen är viktiga för återställning. Backupen hamnar aldrig på databasvärden — den strömmas till lagring medan pg_dump producerar den, så den delar inte öde med disken den kom från. Och en dump som avslutas med en status som inte är noll eller producerar noll byte tas bort och registreras som misslyckad, i stället för att ligga kvar i listan och se ut som en backup.

Kontinuerlig arkivering är inget Dockup kör åt dig i dag. Om ditt RPO verkligen behöver vara minuter är det viktigt att känna till innan du väljer, och det är rimligt att köra detta själv mot en hanterad databas medan du använder plattformen för allt annat.

Övningen som är värd att göra den här veckan

Skriv ned två siffror för din produktionsdatabas:

1. RPO — hur mycket data du kan förlora. Mätt i tid.
2. RTO — hur länge du kan vara nere. Också mätt i tid.

Kontrollera sedan vad din nuvarande setup faktiskt levererar genom att återställa något. Om siffrorna du skrev ned skiljer sig från dem din setup levererar har du hittat ett beslut som behöver fattas medan inget brinner — vilket är den enda bra tidpunkten att fatta det.

Vanliga frågor

Vad är skillnaden mellan RPO och RTO? RPO är hur mycket data du förlorar — gapet mellan den senaste återställningsbara tidpunkten och felet. RTO är hur lång tid återställningen tar. Snapshots ger dig ett stort RPO och ett kort RTO; PITR vänder på det.

Kan jag återställa rader som raderades för en timme sedan från en snapshot som togs i natt? Nej. En snapshot återställer tillståndet vid tidpunkten då den skapades. Allt som skrevs därefter finns inte i filen. För att återställa en godtycklig tidpunkt krävs kontinuerlig arkivering.

Är en volymsnapshot samma sak som en databasbackup? Nej. En snapshot fångar disken, inklusive det tillstånd databasen befann sig i mitt under en skrivning. En logisk dump är internt konsekvent och portabel till andra versioner och leverantörer. De flesta produktionsmiljöer behöver båda.

Hur länge bör jag spara backuper? Tillräckligt länge för att hinna upptäcka ett problem. Korruption eller en misslyckad migration upptäcks ofta flera dagar senare, så en enda dags retention innebär ofta att de enda backuperna du har redan innehåller skadan.