Point-in-time recovery és snapshotok: mit veszítünk?

Valaki 16:15-kor futtat egy DELETE utasítást WHERE feltétel nélkül. A legutóbbi mentésed 03:00-kor készült. A két időpont között minden elveszett, és semmilyen visszaállítás nem hozza vissza.

Ennek a résnek neve is van: recovery point objective, azaz RPO – a point-in-time recovery és snapshotok közötti választás pedig teljes egészében arról szól, mekkora rést vagy hajlandó elfogadni.

A két modell

A snapshotok egy adott pillanatban rögzítik az adatok állapotát. Ütemezés szerint készülnek, általában éjszakánként. Egy snapshot visszaállítása pontosan arra az állapotra visz vissza, amelyben a létrehozásakor voltál, és minden azt követő változás elveszik.

A point-in-time recovery egy base backupot és az adatbázis folyamatosan archivált write-ahead logját kombinálja. Mivel minden változás sorrendben rögzítve van, a megőrzött log alapján bármelyik lefedett időpontra visszajátszhatod az adatokat – akár 16:14-re, egy perccel a törlés előttre is.

A különbség nem fokozatos. A különbség aközött van, hogy „egy napnyi adatot veszítettünk”, vagy aközött, hogy „egy percnyi adatot veszítettünk”.

A döntő szám

Tegyél fel magadnak őszintén egy kérdést: mi történik, ha az elmúlt tizenkét órában írt összes adat elveszne?

Egy személyes projekt, egy dokumentációs oldal vagy egy olyan belső eszköz esetében, amelynek adatai újra előállíthatók, nem sok minden. Az éjszakai snapshotok ilyenkor valóban jó megoldást jelentenek, a folyamatos archiválásért pedig felesleges lenne fizetni.

Bármi esetében, amibe ügyfelek írnak adatokat, a válasz általában valami olyasmi, hogy „e-mailt kellene küldenünk az embereknek, és el kellene magyaráznunk a helyzetet”. Már nem létező rendelések. Eltűnt feltöltések. Elküldött, de most már nem látható üzenetek. Már önmagában a support költsége jellemzően meghaladja az infrastruktúra költségében jelentkező különbség egyéves értékét.

Nem az a hiba, ha a snapshotokat választod. Az a hiba, ha alapértelmezés szerint választod őket anélkül, hogy valaha feltennéd a kérdést: mennyibe kerülne egy tizenkét órás adatlyuk?

Amire a snapshotok valóban jók

A snapshotok nem egy alacsonyabb szintű megoldást jelentenek. Olyan hibák ellen védenek, amelyek ellen a PITR nem:

• A teljes lemez elvesztése. Egy külön tárolón lévő snapshot mindent visszaállít, beleértve azokat a fájlokat is, amelyek nem az adatbázishoz tartoznak.
• Gyors, nagy léptékű visszaállítás. Egy elrontott migráció visszavonása staging környezetben gyorsabb snapshotból, mint egy log visszajátszásával.
• Költség. Napi egy példány tárolása olcsóbb, mint minden egyes írás tárolása.
• Egyszerűség. A kevesebb mozgó alkatrész valódi üzemeltetési előny, különösen egy kis csapat számára.

A csapda az, ha elegendőnek tekinted őket egy olyan adatbázisnál, amelybe folyamatosan érkeznek írások.

Mibe kerül a PITR?

Nem ingyenes, és érdemes megnevezni a költségeit:

• Tárhely. A base backup mellett a megőrzési időszak minden írását is tárolnod kell.
• Komplexitás. Az archiválásnak folyamatosan működnie kell. Ha az archiver egy hete észrevétlenül hibásan működik, akkor a helyreállítható időablak egy héttel korábban ér véget – ezért ugyanolyan fontos az archívum monitorozása, mint a beállítása.
• Visszaállítási idő. Egy log visszajátszása tovább tart, mint egy snapshot visszaállítása. Az RPO javul, az RTO viszont általában romlik.

Ez az utolsó kompromisszum sokakat meglep. A PITR azt jelenti, hogy kevesebb adatot veszítesz, nem azt, hogy gyorsabban újra elérhető lesz a rendszer.

A rétegezett megoldás, amire a legtöbb csapatnak valóban szüksége van

A gyakorlatban ez nem két lehetőség közötti választás. A production adatbázisoknak általában három rétegre van szükségük, mert három különböző módon hibásodhatnak meg:

Snapshotok naponta, egy-két hétig megőrizve. Olcsó védelem a gép elvesztése ellen. Ez fedezi a kötet ugyanazon a lemezen található, nem adatbázishoz tartozó fájljait is.

Logikai dumpok naponta, a hosttól elkülönítve tárolva. A pg_dump hordozható és eleve konzisztens. Másik major verzióra, másik szolgáltatóhoz vagy laptopra is visszaállítható – pontosan erre van szükséged, ha nem az adatokkal, hanem a platformmal van probléma.

Folyamatos archiválás, amikor az adatbázisban ügyféladatok vannak. Ez a réteg változtatja a „ma mindent elveszítettünk” helyzetet „egy percet veszítettünk” helyzetté.

Mindegyik azt fedi le, amit a többi nem. Egy snapshot nem segít szolgáltatót váltani. Egy logikai dump nem segít helyreállítani egy olyan fájlt, amely nem volt az adatbázisban. Egyik sem segít visszavonni egy négy órával korábban végrehajtott törlést.

Hol helyezkedik el a Dockup?

A Dockup a leggyakoribb hibákat lefedő két réteget biztosítja, és érdemes pontosan látni, melyek ezek.

Volume snapshotok, igény szerint vagy ütemezetten, megőrzési darabszámmal:

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

Logikai adatbázis-mentések, közvetlenül object storage-ba streamelve és útközben titkosítva:

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

A második megoldás két tulajdonsága fontos a helyreállítás szempontjából. A mentés soha nem kerül az adatbázis hostjára – a pg_dump kimenetével együtt közvetlenül a storage-ba streamelődik, így nem ugyanaz a sors jut neki, mint annak a lemeznek, amelyről származik. Ha pedig egy dump nem nulla kilépési kóddal fejeződik be, vagy nulla bájtot állít elő, a rendszer törli és hibásként rögzíti, ahelyett hogy a listában mentésnek látszó bejegyzésként maradna.

A folyamatos archiválást a Dockup jelenleg nem végzi el helyetted. Ha az RPO-dnak valóban perces nagyságrendűnek kell lennie, ezt érdemes tudnod, mielőtt választasz, és teljesen ésszerű megoldás lehet, ha egy managed adatbázissal szemben magad futtatod, miközben minden másra a platformot használod.

A feladat, amit érdemes ezen a héten elvégezni

Írj le két számot a production adatbázisodhoz:

1. RPO – mennyi adatot veszíthetsz. Időben mérve.
2. RTO – mennyi ideig lehet kiesés. Szintén időben mérve.

Ezután ellenőrizd, hogy a jelenlegi beállításod a gyakorlatban mit biztosít: állíts vissza valamit. Ha a leírt számok és a rendszered által biztosított számok eltérnek, találtál egy döntést, amelyet még akkor hozhatsz meg, amikor semmi sem ég – ez az egyetlen jó időpont az ilyen döntések meghozatalára.

Gyakran ismételt kérdések

Mi a különbség az RPO és az RTO között? Az RPO azt mutatja meg, mennyi adatot veszítesz – mekkora a rés a legutóbbi helyreállítható időpont és a hiba között. Az RTO azt mutatja meg, mennyi ideig tart a helyreállítás. A snapshotok nagy RPO-t és rövid RTO-t adnak; a PITR ezt megfordítja.

Visszaállíthatom egy órával korábban törölt sorokat egy éjszakai snapshotból? Nem. A snapshot a létrehozásának pillanatában fennálló állapotot állítja vissza. Az ezután írt adatok nincsenek benne. Egy tetszőleges időpont helyreállításához folyamatos archiválás szükséges.

A volume snapshot ugyanaz, mint egy adatbázis-mentés? Nem. A snapshot a lemezt rögzíti, beleértve azt az állapotot is, amelyben az adatbázis éppen írás közben volt. A logikai dump belsőleg konzisztens, és más verziókra, illetve más szolgáltatókhoz is hordozható. A legtöbb production környezetnek mindkettőre szüksége van.

Mennyi ideig érdemes megőrizni a mentéseket? Addig, amíg észre nem veheted a problémát. A sérülés vagy egy hibás migráció felfedezése gyakran napokkal később történik, ezért az egyetlen napos megőrzés sokszor azt jelenti, hogy már az összes rendelkezésre álló mentés tartalmazza a hibát.