Obnova k určitému okamžiku vs. snapshoty: Co ztratíte

Někdo ve 16:15 spustí DELETE bez klauzule WHERE. Poslední záloha je z 03:00. Všechno mezi těmito dvěma okamžiky je pryč a žádná obnova to už nevrátí.

Tato mezera má název — recovery point objective, neboli RPO — a rozhodnutí mezi obnovou k určitému okamžiku a snapshoty je celé o tom, jak velká tato mezera může být.

Dva modely

Snapshoty zachycují stav dat v určitém okamžiku. Spouštějí se podle plánu, obvykle každou noc. Obnovení snapshotu vás vrátí přesně do stavu, ve kterém byla data v okamžiku jeho vytvoření, a vše po tomto okamžiku je ztraceno.

Obnova k určitému okamžiku kombinuje základní zálohu s průběžným proudem databázového write-ahead logu. Protože je každá změna zaznamenána v pořadí, můžete ji přehrát do libovolného okamžiku pokrytého uchovávaným logem — včetně 16:14, tedy jednu minutu před smazáním.

Rozdíl není postupný. Je to rozdíl mezi „ztratili jsme den“ a „ztratili jsme minutu“.

Číslo, které rozhoduje

Položte si upřímně jednu otázku: co se stane, když ztratíte všechno, co bylo zapsáno za posledních dvanáct hodin?

U osobního projektu, dokumentačního webu nebo interního nástroje, jehož data lze znovu vytvořit, se toho příliš nestane. Noční snapshoty jsou skutečně správnou volbou a platit za průběžnou archivaci by bylo plýtvání.

U čehokoli, do čeho zapisují zákazníci, odpověď obvykle zní nějak takto: „Museli bychom lidem napsat e-mail a vysvětlit jim to.“ Objednávky, které už neexistují. Nahrané soubory, které zmizely. Zprávy, které byly odeslány, ale teď tam nejsou. Už samotné náklady na podporu obvykle převýší rozdíl v nákladech na infrastrukturu za celý rok.

Chyba není ve volbě snapshotů. Chyba je zvolit snapshoty automaticky, aniž byste si vůbec položili otázku, kolik by stála dvanáctihodinová mezera.

K čemu jsou snapshoty skutečně dobré

Nejde o horší produkt. Pokrývají selhání, která PITR nepokrývá:

• Ztráta celého disku. Snapshot na odděleném úložišti obnoví vše, včetně souborů, které databáze nevlastní.
• Rychlý, hrubší rollback. Vrácení chybně provedené migrace ve stagingovém prostředí je ze snapshotu rychlejší než přehrávání logu.
• Cena. Ukládat jednu kopii denně je levnější než ukládat každý zápis.
• Jednoduchost. Menší počet pohyblivých částí je skutečná provozní výhoda, zejména pro malý tým.

Problém nastává, když je začnete považovat za dostačující pro databázi, do které se průběžně zapisuje.

Co vás stojí PITR

Není zdarma a tyto náklady stojí za pojmenování:

• Úložiště. Uchováváte základní zálohu a každý zápis za celé retenční období.
• Složitost. Archivace musí fungovat nepřetržitě. Archivátor, který týden bez povšimnutí selhává, znamená, že vaše obnovitelné okno končí před týdnem — proto je monitorování archivu stejně důležité jako jeho konfigurace.
• Doba obnovy. Přehrávání logu trvá déle než obnova snapshotu. RPO se zlepší, ale RTO se obvykle zhorší.

Právě tento kompromis lidi často zaskočí. PITR znamená, že ztratíte méně dat, ne že budete rychleji zpět online.

Vrstvené řešení, které většina týmů skutečně potřebuje

V praxi nejde o volbu mezi dvěma možnostmi. Produkční databáze obvykle potřebují tři vrstvy, protože selhávají třemi různými způsoby:

Snapshoty, denně, uchovávané týden nebo dva. Levné pojištění proti ztrátě stroje. Pokryje také soubory mimo databázi, které se nacházejí na stejném svazku.

Logické dumpy, denně, uložené mimo hostitele. pg_dump je přenositelný a ze své podstaty konzistentní. Obnoví se na jiné hlavní verzi, u jiného poskytovatele nebo na notebooku — přesně to potřebujete, když je problém v platformě, nikoli v datech.

Průběžná archivace, pokud databáze obsahuje zákaznická data. Vrstva, která změní „ztratili jsme dnešek“ na „ztratili jsme minutu“.

Každá vrstva pokrývá to, co ostatní neumějí. Snapshot vám nepomůže přejít k jinému poskytovateli. Logický dump vám nepomůže obnovit soubor, který nebyl v databázi. Ani jedno vám nepomůže vrátit zpět smazání z doby před čtyřmi hodinami.

Kde je v tom Dockup

Dockup vám poskytuje dvě vrstvy, které pokrývají nejčastější selhání, a stojí za to přesně říct, které to jsou.

Snapshoty svazků, na vyžádání nebo podle plánu s nastaveným počtem uchovávaných kopií:

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

Logické zálohy databází, streamované přímo do object storage a šifrované během přenosu:

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

Pro obnovu jsou u druhé možnosti důležité dvě vlastnosti. Záloha se nikdy neuloží na hostitele databáze — streamuje se do úložiště už při jejím vytváření pomocí pg_dump, takže nesdílí osud disku, ze kterého pochází. A dump, který skončí s nenulovým návratovým kódem nebo vytvoří nulový počet bajtů, se smaže a zaznamená jako neúspěšný, místo aby zůstal v seznamu a vypadal jako záloha.

Průběžnou archivaci za vás Dockup dnes nespouští. Pokud vaše RPO skutečně musí být v řádu minut, je dobré to vědět ještě před rozhodnutím. Je zcela rozumné provozovat ji samostatně proti spravované databázi a platformu využívat pro všechno ostatní.

Úkol, který stojí za to udělat tento týden

Zapište si dvě čísla pro svou produkční databázi:

1. RPO — kolik dat můžete ztratit. Udává se v čase.
2. RTO — jak dlouho můžete být mimo provoz. Také se udává v čase.

Pak ověřte, co vaše současné nastavení skutečně poskytuje, a to obnovením něčeho ze zálohy. Pokud se čísla, která jste si zapsali, liší od toho, co vaše nastavení skutečně poskytuje, našli jste rozhodnutí, které je třeba udělat v době, kdy nic nehoří — a to je jediný vhodný okamžik.

Často kladené otázky

Jaký je rozdíl mezi RPO a RTO? RPO určuje, kolik dat ztratíte — tedy mezeru mezi posledním obnovitelným okamžikem a selháním. RTO určuje, jak dlouho obnova trvá. Snapshoty poskytují vysoké RPO a krátké RTO; PITR tento poměr obrací.

Mohu z nočního snapshotu obnovit řádky smazané před hodinou? Ne. Snapshot obnoví stav v okamžiku, kdy byl vytvořen. Cokoli zapsané později v souboru není. Obnovení libovolného okamžiku vyžaduje průběžnou archivaci.

Je snapshot svazku totéž co záloha databáze? Ne. Snapshot zachycuje disk včetně případného stavu, kdy databáze právě zapisovala. Logický dump je interně konzistentní a přenositelný mezi jinými verzemi a poskytovateli. Většina produkčních systémů potřebuje obojí.

Jak dlouho bych měl zálohy uchovávat? Dostatečně dlouho na to, abyste si problému všimli. Poškození nebo chybná migrace se často odhalí až po několika dnech, takže jednodenní retence často znamená, že jediné zálohy, které máte, už poškození obsahují.