Oporavak u određenom trenutku u odnosu na snapshotove: što gubite

Netko pokrene DELETE bez klauzule WHERE u 16:15. Vaš najnoviji backup je iz 03:00. Sve između ta dva trenutka je izgubljeno i nikakvo vraćanje neće to vratiti.

Ta praznina ima naziv — cilj točke oporavka, odnosno RPO — a odluka između oporavka u određenom trenutku i snapshotova u potpunosti se svodi na to koliko veliku prazninu možete prihvatiti.

Dva modela

Snapshotovi bilježe stanje vaših podataka u određenom trenutku. Pokreću se prema rasporedu, najčešće svake noći. Vraćanje jednog snapshotova vraća vas točno na stanje u trenutku njegova izrade, a sve nakon toga je izgubljeno.

Oporavak u određenom trenutku kombinira osnovni backup s kontinuiranim tokom write-ahead loga baze podataka. Budući da se svaka promjena bilježi redoslijedom kojim se dogodila, možete ponoviti promjene do bilo kojeg trenutka pokrivenog zadržanim logom — uključujući 16:14, minutu prije brisanja.

Razlika nije postupna. To je razlika između „izgubili smo jedan dan” i „izgubili smo jednu minutu”.

Brojka koja donosi odluku

Postavite si jedno pitanje, iskreno: što se događa ako izgubite sve što je zapisano u posljednjih dvanaest sati?

Za osobni projekt, dokumentacijsku stranicu ili interni alat čiji se podaci mogu ponovno generirati: gotovo ništa. Noćni snapshotovi doista su pravi izbor, a plaćanje kontinuiranog arhiviranja bilo bi rasipanje novca.

Za sve što korisnici upisuju, odgovor obično glasi otprilike: „Morali bismo poslati e-poruku ljudima i objasniti im situaciju.” Narudžbe koje više ne postoje. Učitanja koja su nestala. Poruke koje su poslane, a sada ih nema. Sam trošak korisničke podrške obično premašuje razliku u troškovima infrastrukture za cijelu godinu.

Pogreška nije u odabiru snapshotova. Pogreška je odabrati snapshotove prema zadanim postavkama, a da se nikad ne zapitate koliko bi vas koštala rupa od dvanaest sati.

U čemu su snapshotovi doista dobri

Oni nisu manje vrijedno rješenje. Pokrivaju kvarove koje PITR ne pokriva:

• Potpuni gubitak diska. Snapshot na odvojenoj pohrani vraća sve, uključujući datoteke koje nisu u vlasništvu baze podataka.
• Brzo, grubo vraćanje. Vraćanje neuspjele migracije u staging okruženju brže je iz snapshotova nego ponovnim izvođenjem loga.
• Trošak. Pohrana jedne kopije dnevno je jeftinija od pohrane svake pojedinačne izmjene.
• Jednostavnost. Manje pokretnih dijelova stvarno je operativna prednost, osobito za mali tim.

Problem nastaje kada ih tretirate kao dovoljnu zaštitu za bazu podataka u koju se kontinuirano upisuju podaci.

Koliko vas PITR košta

Nije besplatan i vrijedi jasno navesti njegove troškove:

• Pohrana. Čuvate osnovni backup i svaku pojedinačnu izmjenu unutar razdoblja zadržavanja.
• Složenost. Arhiviranje mora neprekidno funkcionirati. Archiver koji je tjedan dana neprimjetno neuspješan znači da vaš prozor za oporavak završava prije tjedan dana — zato je nadzor arhive jednako važan kao i njezino konfiguriranje.
• Vrijeme vraćanja. Ponovno izvođenje loga traje dulje od vraćanja snapshotova. Vaš se RPO poboljšava, ali se RTO obično pogoršava.

Ta posljednja razmjena često iznenadi ljude. PITR znači da gubite manje podataka, a ne da ćete se brže vratiti na mrežu.

Slojevito rješenje koje je većini timova zapravo potrebno

U praksi ovo nije izbor između dvije mogućnosti. Produkcijske baze podataka obično trebaju tri sloja jer mogu otkazati na tri različita načina:

Snapshotovi, svakodnevno, zadržani tjedan ili dva. Jeftino osiguranje protiv gubitka računala. To također pokriva datoteke koje nisu dio baze podataka, a nalaze se na istom volumenu.

Logički dumpovi, svakodnevno, pohranjeni izvan hosta. pg_dump je prenosiv i po definiciji konzistentan. Može se vratiti na drugu glavnu verziju, kod drugog providera ili na laptop — upravo ono što vam treba kada je problem u platformi, a ne u podacima.

Kontinuirano arhiviranje kada se u bazi nalaze podaci korisnika. Sloj koji „izgubili smo današnji dan” pretvara u „izgubili smo jednu minutu”.

Svaki sloj pokriva ono što ostali ne pokrivaju. Snapshot vam ne pomaže prijeći kod drugog providera. Logički dump vam ne pomaže vratiti datoteku koja nije bila u bazi podataka. Ni jedno ni drugo ne pomaže poništiti brisanje od prije četiri sata.

Gdje se Dockup uklapa

Dockup vam daje dva sloja koji pokrivaju najčešće kvarove, a vrijedi precizno navesti koja su to dva sloja.

Snapshotovi volumena, na zahtjev ili prema rasporedu uz broj zadržanih snapshotova:

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

Logički backupi baza podataka, koji se izravno šalju u object storage i pritom šifriraju:

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

Za oporavak su važna dva svojstva ovog drugog sloja. Backup nikad ne završava na hostu baze podataka — šalje se u storage dok ga pg_dump generira, pa ne dijeli sudbinu s diskom s kojeg potječe. Osim toga, dump čija naredba završi s kodom različitim od nule ili koji proizvede nula bajtova briše se i bilježi kao neuspješan, umjesto da ostane na popisu i izgleda kao valjani backup.

Dockup danas ne pokreće kontinuirano arhiviranje umjesto vas. Ako vaš RPO zaista treba biti izražen u minutama, to morate znati prije odabira, a sasvim je razumno takvo arhiviranje pokretati samostalno nad upravljanom bazom podataka, dok platformu koristite za sve ostalo.

Vježba koju vrijedi napraviti ovaj tjedan

Zapišite dvije brojke za svoju produkcijsku bazu podataka:

1. RPO — koliko podataka možete izgubiti. Mjeri se vremenom.
2. RTO — koliko dugo možete biti nedostupni. Također se mjeri vremenom.

Zatim provjerite što vaša trenutna postavka doista omogućuje tako da nešto vratite iz backupa. Ako se brojke koje ste zapisali razlikuju od onih koje vaša postavka stvarno omogućuje, pronašli ste odluku koju možete donijeti dok ništa ne gori — a to je jedino dobro vrijeme za donošenje takve odluke.

Često postavljana pitanja

Koja je razlika između RPO-a i RTO-a? RPO je količina podataka koju izgubite — praznina između posljednjeg trenutka iz kojeg je moguć oporavak i kvara. RTO je vrijeme potrebno za oporavak. Snapshotovi vam daju velik RPO i kratak RTO; PITR to mijenja.

Mogu li iz noćnog snapshotova oporaviti retke obrisane prije sat vremena? Ne. Snapshot vraća stanje u trenutku kada je izrađen. Sve zapisano nakon toga nije u toj datoteci. Oporavak proizvoljnog trenutka zahtijeva kontinuirano arhiviranje.

Je li snapshot volumena isto što i backup baze podataka? Ne. Snapshot bilježi disk, uključujući stanje u kojem je baza podataka možda bila usred pisanja. Logički dump interno je konzistentan i prenosiv na druge verzije i kod drugih providera. Većini produkcijskih sustava potrebna su oba.

Koliko dugo trebam zadržati backupe? Dovoljno dugo da uočite problem. Oštećenje podataka ili neuspjela migracija često se otkriju tek nakon nekoliko dana, pa jedan dan zadržavanja često znači da jedini backupi koje imate već sadrže štetu.