Persistent volumes a snapshoty v Dockup

Persistent volumes a snapshoty řeší dva různé problémy. Volume zachovává soubory při nahrazení kontejneru a nasazení. Snapshot zachytí volume v určitém okamžiku, takže tento stav lze později prohlížet, uchovat nebo obnovit.

Souborový systém kontejneru lze kdykoli nahradit. Vše, co musí přežít nasazení — nahrané soubory, vygenerovaná média, indexy, artefakty balíčků nebo soubory spravované aplikací — potřebuje explicitně určené persistentní umístění.

Která data aplikace patří na persistentní úložiště?

Volume použijte, pokud aplikace vlastní soubory, které nelze levně nebo bezpečně znovu vytvořit z jiného zdroje.

Data	Volume?	Lepší alternativa, pokud je k dispozici
Uživatelské uploady	Ano	Object storage, pokud ho architektura používá
Vygenerované náhledy	Možná	Znovu je vygenerovat z originálů
Search index	Možná	Znovu ho sestavit ze zdrojové databáze
Build artefakty	Obvykle ne	Znovu je sestavit během nasazení
Logy aplikace	Obvykle ne	Systém logů runtime
Datový adresář PostgreSQL	Ne jako app volume	Managed PostgreSQL
Dočasná cache	Ne	Redis nebo ephemeral storage
Lokální produkční SQLite DB	Rizikové	Managed database kvůli souběžnosti a zálohám

Volume by měl mít jednoho jasně určeného vlastníka a jednu cestu pro připojení. Pokud do stejného adresáře zapisují dva nesouvisející procesy, obnova i analýza oprávnění jsou obtížnější.

Před přidáním úložiště odhadněte počáteční velikost, rychlost růstu, požadavky na retenci a cíl obnovy. Disk se započítává do zůstatku plánu po minutách, takže nevyužitá kapacita i nekontrolovaný růst souborů něco stojí.

Jak vytvořit a zkontrolovat volume v Dockup?

Pro výpis existujících volumes konkrétní služby použijte:

dockup volume list production/web --json

Přidejte volume s názvem, absolutní cestou v kontejneru a velikostí v gigabajtech:

dockup volume add production/web \
  --name uploads \
  --path /app/uploads \
  --size 20 \
  --json

Aplikace musí zapisovat do /app/uploads. Zápis do /uploads nebo jiného lokálního adresáře automaticky nepřesměruje data do mountu.

Po nasazení ověřte, že aplikace zapisuje do deklarované absolutní cesty mountu, nikoli do nahraditelného souborového systému kontejneru.

Skutečné využití disku zkontrolujte pomocí vráceného ID volume:

dockup volume usage <volumeId> production/web --json

Porovnejte skutečné využití s přidělenou velikostí a metrikami aplikace. Nastavte alert dříve, než se souborový systém zaplní; plný volume může způsobit částečné zápisy, neúspěšné uploady nebo pády aplikace.

Ověřte očekávané vlastnictví souborů. Runtime uživatel kontejneru musí mít možnost číst z cesty mountu a zapisovat do ní, aniž by dostal širší oprávnění, než je nutné.

Jak snapshoty volumes chrání data?

Snapshot na vyžádání zachytí obsah volume:

dockup volume snapshot <volumeId> production/web --json

Seznam dostupných snapshotů zobrazíte takto:

dockup volume snapshots <volumeId> production/web --json

Snapshoty čtou volume read-only způsobem a nevyžadují, aby aplikace zapisovala do speciálního adresáře pro snapshoty. Hodí se před rizikovou migrací souborů, hromadným přepisem médií nebo změnou aplikace, která transformuje uložená data.

Snapshot volume není automaticky konzistentní z pohledu aplikace. Pokud aplikace právě zapisuje několik souvisejících souborů, snapshot je může zachytit v mírně odlišných okamžicích. U managed database použijte systém zálohování managed database, nikoli snapshot jejího surového datového adresáře.

Definujte, kdy má být aplikace uvedena do klidového stavu. Před vytvořením důležitého snapshotu může být vhodná krátká údržbová pauza nebo pozastavení zápisů. Zaznamenejte ID snapshotu, důvod a očekávaný bod obnovy.

Jak naplánovat retenci snapshotů?

Načasování a retenci snapshotů zvolte podle požadavků na obnovu, nikoli ze zvyku. Před každou rizikovou migrací souborů, čištěním nebo změnou formátu vytvořte snapshot na vyžádání a zaznamenejte vrácené ID snapshotu.

dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json

Potřeba obnovy	Praxe se snapshoty	Omezení
Vrácení migrace souborů	Vytvořit snapshot bezprostředně před změnou	Neobsahuje pozdější zápisy
Uchování historických bodů	Uchovávat označené body obnovy podle pravidel	Retenci je nutné aktivně kontrolovat
Ochrana častých zápisů	Přidat zálohování na úrovni aplikace vhodné pro daná data	Snapshot v jednom okamžiku není průběžná ochrana
Archivace z regulatorních důvodů	Použít vyhrazený archivační postup	Provozní snapshoty nemusí splňovat pravidla

Ověřujte, zda očekávané snapshoty skutečně existují. Zapsaná retenční politika není důkazem, že byl vytvořen použitelný bod obnovy.

Jak bezpečně obnovit snapshot volume?

Obnovení nahradí aktuální obsah volume a restartuje kontejner:

dockup volume restore \
  <volumeId> \
  <snapshotId> \
  production/web \
  --json

Jde o rušivou operaci, která mění stav. Před obnovením:

1. Ověřte přesnou službu, ID volume a ID snapshotu.
2. Vysvětlete, které aktuální soubory budou nahrazeny.
3. Pokud je to možné, zastavte nové zápisy nebo jejich objem omezte.
4. Vytvořte nový snapshot aktuálního stavu, pokud by mohl být později potřeba.
5. Zaznamenejte kompatibilitu aplikace a schématu.
6. Získejte výslovné schválení pro produkci.
7. Naplánujte kontrolu po obnovení.

Po obnovení ověřte stav kontejneru a chování aplikace:

dockup status production/web --json
dockup logs production/web --json

Otestujte reprezentativní soubory, oprávnění, indexy a reference aplikace. Úspěšný příkaz pro obnovení dokazuje, že byl snapshot aplikován; nedokazuje však, že každý záznam aplikace odkazuje na platný soubor.

Model ochranných pravidel pro AI agenty v produkci by měl obnovení považovat za operaci vyžadující schválení, přestože jde o recovery operaci.

Jak se mají volumes chovat během nasazení a rollbacku?

Při nasazení se aplikační kontejnery nahradí, zatímco připojený volume zůstává. Nový image tak může pracovat s existujícími soubory, zároveň to ale vytváří požadavek na kompatibilitu.

Nová verze aplikace by neměla nevratně transformovat uložené soubory dříve, než je její release ověřený. Pokud mění formáty souborů nebo strukturu adresářů, použijte pokud možno migraci, kterou lze bezpečně obnovit a která je zpětně kompatibilní.

Rollback aplikace znovu spustí starší deployment:

dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json

Volume se s imagem automaticky nevrátí zpět. Starší aplikace nemusí umět číst soubory transformované novou verzí. Rollback image koordinujte s obnovením snapshotu pouze tehdy, pokud jsou potřebné a schválené obě operace.

Toto oddělení je důležité:

Recovery akce	Změní image?	Změní data ve volume?
Nasazení nové verze	Ano	Ne, pokud je nemigruje aplikace
Rollback deploymentu	Ano	Ne
Obnovení snapshotu	Ne	Ano
Obnovení a rollback	Ano	Ano

Proces nasazení bez výpadku chrání přepnutí provozu, nikoli kompatibilitu datových formátů.

Co je provozní runbook pro durable storage?

Každému produkčnímu volume přiřaďte vlastníka. Runbook by měl obsahovat:

• Cíl služby a ID volume.
• Cestu mountu a očekávaného runtime uživatele.
• Přidělenou velikost a práh alertu.
• Popis dat a možnost jejich znovuvytvoření.
• Plán snapshotů a retenci.
• Poslední ověřený snapshot.
• Pravidla schvalování obnovení.
• Kroky validace aplikace.
• Poznámky ke kompatibilitě image a dat.
• Pravidla růstu a mazání.

Využití pravidelně kontrolujte:

dockup volume usage <volumeId> production/web --json

CPU, RAM a disk se měří po minutách. Free plan nabízí počáteční kredit $10, zatímco doporučený Pro plan stojí $20 měsíčně a zahrnuje kredit na využití ve výši $20.

Cvičné obnovení snapshotu

Nečekejte na incident, abyste zjistili, že nikdo neví, který snapshot vybrat. Proveďte řízené cvičení na non-production službě nebo schválené kopii:

1. Vytvořte snadno rozpoznatelné testovací soubory.
2. Vytvořte snapshot.
3. Soubory změňte.
4. Obnovte snapshot.
5. Ověřte obsah a oprávnění.
6. Sledujte restart kontejneru.
7. Zaznamenejte časování a místa selhání.

Cvičné obnovení mění persistent volumes a snapshoty z položky v checklistu na otestovanou schopnost obnovy.

Pro úvodní návrh služby viz Od Git repository do produkce. Podrobnosti k příkazům najdete v referenci Dockup CLI.

Definujte cíle obnovy pro souborová data

Recovery point objective určuje, kolik nedávných dat může firma ztratit. Recovery time objective určuje, jak dlouho může obnova trvat. Denní snapshot se sedmidenní retencí může vyhovovat interní cache médií, ale ne produktu s uživatelskými uploady, který slibuje téměř realtime odolnost dat.

Obě hodnoty zdokumentujte a otestujte skutečnou dobu obnovení. K době obnovy přispívá rychlost vytváření snapshotu, velikost dat, restart kontejneru, validace souborů i reindexace aplikace.

Kontrolujte mazání a růst souborů

Persistentní úložiště se může zaplnit, protože aplikace nikdy nemaže dočasné nebo nahrazené soubory. Přidejte retenční politiku na aplikační vrstvě a rozlišujte logické odstranění od okamžitého fyzického smazání. Krátké okno pro obnovu může odůvodnit odložení trvalého odstranění.

Před spuštěním hromadného čištění:

1. Změřte aktuální využití volume.
2. Vytvořte seznam kandidátů na odstranění.
3. Vytvořte snapshot.
4. Spusťte čištění v omezených dávkách.
5. Ověřte reference aplikace.
6. Potvrďte očekávané uvolnění místa.

Díky tomu mají persistent volumes a snapshoty preventivní úlohu, nejen úlohu při incidentu.

Ověřujte inventář snapshotů

Pravidelně kontrolujte ID snapshotů, časy vytvoření, retenci a poslední úspěšný test obnovení. Nakonfigurovaný job bez nedávného použitelného snapshotu není systémem obnovy.

Určete oprávnění k obnovení

Určete, kdo může schválit obnovení v produkci a kdo provede validaci po obnovení. Oddělení schválení od provedení snižuje riziko, že naléhavost obejde ověření cíle a snapshotu.

Začněte s ověřitelným nasazením

Vytvořte jedno non-production volume, vytvořte snapshot, změňte testovací soubor a dokončete cvičné obnovení, než začnete ukládat nenahraditelná produkční data.

Začněte zdarma na app.dockup.ai. Free plan stojí $0 měsíčně, zahrnuje počáteční kredit $10 a podporuje jeden workspace, tři databáze a tři deploymenty.

Časté dotazy

Přežije volume v Dockup nasazení?

Ano. Volume zůstane persistentní, i když jsou servisní kontejnery nahrazeny, pokud aplikace nadále používá nakonfigurovanou cestu mountu.

Je snapshot volume vhodnou zálohou pro PostgreSQL?

Ne. Hot snapshot datového adresáře databáze nemusí být konzistentní z pohledu transakcí. U managed databases upřednostněte systém zálohování managed database.

Co se stane při obnovení snapshotu volume?

Aktuální obsah volume se nahradí vybraným snapshotem a kontejner se restartuje, takže operace by měla být schválena a ověřena.

Umí Dockup plánovat snapshoty volumes?

Ano. Příkaz pro plánování volumes podporuje denní snapshoty s počtem uchovávaných kopií a plán lze explicitně deaktivovat.

Vrátí rollback aplikace zpět i její volume?

Ne. Historie deploymentů aplikace a historie snapshotů volume jsou oddělené. Koordinujte je pouze tehdy, když to vyžaduje recovery plán.