# Zálohy (https://docs.vitrinka.ai/cs/security/backups) ## Zapečetěný archiv [#archive] `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í](/cs/security/encryption#sealed)). S [úložištěm klíčů OpenBao](/cs/security/encryption#keystore) 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ýž. ```bash 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í](/cs/security/retention#shred)). ## Co vynechává [#excludes] 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](/cs/operator/operations#license-location)). ## Obnova [#restore] `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. Bezpečnostní snímky operátora míří do `VITRINKA_BACKUP_DIR`. Cesta, která se rozloží dovnitř `DATA_DIR`, je odmítnutá, takže zálohu nikdy nesmete to, co chrání. ## Snímek na úrovni compose [#compose] Nejjednodušší rutina vlastní instalace — zastavit, sbalit `/data` do taru, spustit — je v [Provozu](/cs/operator/operations#backup). 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 [#replica] 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 [#standby] 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](/cs/reference/env#core).