Zálohy

Zapečetěný archiv

vitrinka backup pořídí konzistentní kopii VACUUM INTO řídicí databáze a každé databáze workspace — jen čtení, zdroje se nikdy nemění — sbalí je s manifestem do taru a zapečetí proud klíčem z vlastního prostředí: VITRINKA_KEK, se záložním VITRINKA_MASTER_KEY. Výsledkem je jeden soubor enc2f: rámované bloky AES-256-GCM pod čerstvým zabaleným datovým klíčem (Šifrování). S úložištěm klíčů OpenBao server běží bez VITRINKA_KEK a poté, co si ho úložiště klíčů převezme, i bez VITRINKA_MASTER_KEY, proto dejte běhu zálohy do prostředí VITRINKA_MASTER_KEY a klíč uchovávejte s materiálem pro obnovu — restore-backup potřebuje tentýž.

vitrinka backup -data /data -out /backups/vitrinka-2026-08-24.vtbk
vitrinka restore-backup -in /backups/vitrinka-2026-08-24.vtbk -out /restore

Ukradený archiv je šifrovaný text. Protože zapečetěné sloupce v něm zůstávají pod klíči svých workspaců, je workspace později kryptograficky skartovaný nečitelný v každém archivu pořízeném po skartaci (Uchovávání a mazání).

Co vynechává

Bloby v archivu záměrně nejsou. Jsou už v klidu šifrovaným textem per workspace, takže replikace úložiště blobů replikuje šifrovaný text; s BLOB_BACKEND=fs zálohujte vedle toho DATA_DIR/blobs, u S3 je trvalou kopií bucket.

Licenční soubor v DATA_DIR také není — leží v adresáři ./license/ v balíku (Provoz).

Obnova

restore-backup odpečetí a rozbalí jen do prázdného adresáře. Nikdy nepřepíše živý DATA_DIR; nasměrovat zastavený server na obnovený strom, nebo překopírovat soubory po vlastním porovnání, zůstává záměrným krokem operátora.

Snímek na úrovni compose

Nejjednodušší rutina vlastní instalace — zastavit, sbalit /data do taru, spustit — je v Provozu. Zachytí databáze i bloby na disku v jednom archivu, ale aplikace ho nepečetí; držte ho na šifrovaném svazku.

Průběžná replikace

Hostovaná služba replikuje databáze do objektového úložiště pomocí Litestreamu. Konfigurace nastavuje synchronizaci po 10 sekundách, denní snímky a ověření každých šest hodin. Dobu uchování objektů určuje samostatná politika úložiště; tyto intervaly proto nezaručují konkrétní období, ze kterého lze data obnovit. Šifrované sloupce zůstávají šifrované i v replice. Ochrana databázových metadat, včetně identifikátorů, časových údajů a adres, závisí na zabezpečení přenosu a přístupu k bucketu. Archiv popsaný výše je samostatný způsob zálohování.

Záloha v pohotovosti a ochrana zápisu

Pro nasazení na dvou hostitelích má server pohotovostní roli a ochranu proti dvěma zapisovatelům. VITRINKA_ROLE=standby spustí proces, který odpovídá na health checky a na nic jiného: /healthz vrací 200, /readyz i každá další cesta 503. Neotevře žádnou databázi a nespustí žádnou práci na pozadí, takže repliky, kterou do jeho DATA_DIR zapisuje replikace, se nikdy nedotkne; udržovat repliku aktuální je úkolem replikace, kterou provozujete. Převzetí provozu znamená roli smazat a restartovat.

VITRINKA_FENCE_URL je zápisová pojistka: před prvním zápisem při startu si zapisovatel stáhne tento malý dokument a odmítne nastartovat, pokud v něm není VITRINKA_FENCE_HOST. Nedostupný dokument start odmítne také a proces v pohotovosti ho nikdy nečte. Dokument se čte při startu, proto starého zapisovatele zastavte dřív, než dokument jmenuje nového. Obojí je v referenci konfigurace.