Recuperare la un anumit moment vs. snapshots: ce pierdeți

Cineva rulează un DELETE fără o clauză WHERE la 16:15. Cel mai recent backup este de la 03:00. Tot ce s-a întâmplat între cele două momente s-a pierdut, iar nicio restaurare nu îl va putea readuce.

Acest interval are un nume — obiectivul punctului de recuperare, sau RPO — iar decizia privind recuperarea la un anumit moment vs. snapshots ține în totalitate de dimensiunea pe care sunteți dispuși să o acceptați.

Cele două modele

Snapshots surprind starea datelor la un anumit moment. Rulează conform unui program, de obicei în fiecare noapte. Restaurarea unuia vă readuce exact în starea în care erați când a fost creat, iar tot ce s-a întâmplat după acel moment se pierde.

Recuperarea la un anumit moment combină un base backup cu un flux continuu al write-ahead log-ului bazei de date. Deoarece fiecare modificare este înregistrată în ordine, puteți face replay până la orice moment acoperit de log-ul păstrat — inclusiv la 16:14, cu un minut înainte de ștergere.

Diferența nu este una incrementală. Este diferența dintre „am pierdut o zi” și „am pierdut un minut”.

Numărul care decide

Puneți-vă o întrebare, cu sinceritate: dacă ați pierde tot ce s-a scris în ultimele douăsprezece ore, ce s-ar întâmpla?

Pentru un proiect personal, un site de documentație sau un tool intern ale cărui date pot fi regenerate: probabil nu mare lucru. Snapshots-urile nocturne sunt într-adevăr alegerea potrivită, iar plata pentru archiving continuu ar fi o risipă.

Pentru orice sistem în care clienții scriu date, răspunsul este de obicei o variantă a lui „ar trebui să le trimitem emailuri și să le explicăm”. Comenzi care nu mai există. Upload-uri care au dispărut. Mesaje care au fost trimise și acum nu mai sunt acolo. Numai costurile de suport depășesc de obicei diferența de cost pentru infrastructură pe durata unui an.

Greșeala nu este să alegeți snapshots. Greșeala este să le alegeți implicit, fără să vă întrebați vreodată cât ar costa un gol de douăsprezece ore.

La ce sunt cu adevărat bune snapshots-urile

Nu sunt un produs inferior. Acoperă situații de failure pe care PITR nu le acoperă:

• Pierderea întregului disc. Un snapshot pe storage separat restaurează totul, inclusiv fișierele pe care baza de date nu le deține.
• Rollback rapid și grosier. Revenirea după o migrare eșuată într-un mediu de staging este mai rapidă dintr-un snapshot decât prin replay-ul unui log.
• Costul. Stocarea unei singure copii pe zi este mai ieftină decât stocarea fiecărei scrieri.
• Simplitatea. Mai puține componente este o proprietate operațională reală, mai ales pentru o echipă mică.

Capcana este să le tratați ca fiind suficiente pentru o bază de date în care se fac scrieri continuu.

Ce vă costă PITR

Nu este gratuit, iar costurile merită menționate:

• Storage. Păstrați base backup-ul plus fiecare scriere din retention window.
• Complexitate. Archiving-ul trebuie să funcționeze continuu. Un archiver care a eșuat în tăcere timp de o săptămână înseamnă că fereastra recuperabilă se încheie cu o săptămână în urmă — motiv pentru care monitorizarea archive-ului este la fel de importantă ca configurarea lui.
• Timpul de restaurare. Replay-ul unui log durează mai mult decât restaurarea unui snapshot. RPO se îmbunătățește; RTO devine de obicei mai slab.

Ultimul compromis îi surprinde pe mulți. PITR înseamnă că pierdeți mai puține date, nu că reveniți mai repede online.

Răspunsul stratificat de care au nevoie, de fapt, majoritatea echipelor

În practică, nu este o alegere între două lucruri. Bazele de date de producție au de obicei nevoie de trei straturi, deoarece pot eșua în trei moduri diferite:

Snapshots, zilnic, păstrate timp de una sau două săptămâni. O asigurare ieftină împotriva pierderii mașinii. Acesta este și stratul care acoperă fișierele care nu țin de baza de date, dar se află pe același volum.

Logical dumps, zilnic, păstrate în afara hostului. Un pg_dump este portabil și consistent prin construcție. Îl puteți restaura pe o versiune majoră diferită, la un provider diferit sau pe un laptop — exact ce vă trebuie atunci când problema este platforma, nu datele.

Archiving continuu, atunci când baza de date conține date ale clienților. Stratul care transformă „am pierdut ziua de azi” în „am pierdut un minut”.

Fiecare acoperă ceea ce celelalte nu pot. Un snapshot nu vă ajută să schimbați providerul. Un logical dump nu vă ajută să recuperați un fișier care nu se afla în baza de date. Niciunul nu vă ajută să anulați un delete de acum patru ore.

Unde se încadrează Dockup

Dockup vă oferă cele două straturi care acoperă cele mai frecvente failure-uri și merită să precizăm exact care sunt acestea.

Volume snapshots, la cerere sau conform unui program, cu un număr stabilit de copii păstrate:

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

Backup-uri logice ale bazei de date, transmise direct în object storage și criptate în timpul transferului:

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

Două proprietăți ale celui de-al doilea mecanism contează pentru recuperare. Backup-ul nu ajunge niciodată pe hostul bazei de date — este transmis către storage pe măsură ce pg_dump îl produce, astfel încât nu are aceeași soartă ca discul de pe care provine. Iar un dump care se încheie cu un cod diferit de zero sau produce zero bytes este șters și înregistrat ca eșuat, în loc să rămână în listă și să pară un backup valid.

Dockup nu rulează archiving continuu în locul dvs. în acest moment. Dacă RPO-ul dvs. are nevoie cu adevărat să fie de ordinul minutelor, este important să știți acest lucru înainte de a alege și este perfect rezonabil să rulați acest mecanism pe cont propriu împotriva unei baze de date administrate, folosind platforma pentru toate celelalte.

Exercițiul pe care merită să-l faceți săptămâna aceasta

Notați două numere pentru baza de date de producție:

1. RPO — cât de multe date puteți pierde. Măsurat în timp.
2. RTO — cât timp puteți fi indisponibili. Tot măsurat în timp.

Apoi verificați ce oferă de fapt configurația actuală, restaurând ceva. Dacă numerele pe care le-ați notat diferă de cele pe care le oferă configurația, ați identificat o decizie pe care o puteți lua cât timp nimic nu arde — singurul moment potrivit pentru a o lua.

Întrebări frecvente

Care este diferența dintre RPO și RTO? RPO este cantitatea de date pe care o pierdeți — intervalul dintre ultimul moment recuperabil și momentul failure-ului. RTO este durata recuperării. Snapshots oferă un RPO mare și un RTO scurt; PITR inversează situația.

Pot recupera dintr-un snapshot nocturn rânduri șterse acum o oră? Nu. Un snapshot restaurează starea din momentul în care a fost creat. Orice a fost scris ulterior nu se află în fișier. Recuperarea unui moment arbitrar necesită archiving continuu.

Este un volume snapshot același lucru cu un backup al bazei de date? Nu. Un snapshot capturează discul, inclusiv starea în care se afla baza de date în timp ce efectua o scriere. Un logical dump este consistent intern și portabil către alte versiuni și provideri. Majoritatea sistemelor de producție au nevoie de ambele.

Cât timp ar trebui să păstrez backup-urile? Suficient de mult cât să observați o problemă. Corupția sau o migrare nereușită sunt descoperite adesea după câteva zile, astfel încât o singură zi de retenție înseamnă frecvent că toate backup-urile pe care le aveți conțin deja problema.