Persistent volumes a snapshots v Dockup

Persistent volumes a snapshots riešia dva odlišné problémy. Volume zachová súbory aj po nahradení containerov a deploymente. Snapshot zachytí volume v konkrétnom čase, takže tento stav môžete neskôr preskúmať, uchovať alebo obnoviť.

Filesystem containera je nahraditeľný. Všetko, čo musí prežiť deployment — uploady, vygenerované médiá, indexy, package artifacts alebo súbory spravované aplikáciou — potrebuje explicitné persistent umiestnenie.

Ktoré dáta aplikácie patria do persistent storage?

Volume použite vtedy, keď aplikácia spravuje súbory, ktoré nemožno lacno alebo bezpečne znovu vytvoriť z iného zdroja.

Dáta	Volume?	Lepšia alternatíva, ak je dostupná
Uploady používateľov	Áno	Object storage, ak ho architektúra používa
Vygenerované thumbnails	Možno	Znovu ich vygenerovať z originálov
Search index	Možno	Znovu ho vytvoriť zo zdrojovej databázy
Build artifacts	Zvyčajne nie	Vytvoriť znova počas deploymentu
Logy aplikácie	Zvyčajne nie	Runtime log systém
Dátový adresár PostgreSQL	Nie ako app volume	Managed PostgreSQL
Dočasná cache	Nie	Redis alebo ephemeral storage
Lokálna produkčná SQLite databáza	Rizikové	Managed databáza pre concurrency a backups

Každý volume by mal mať jedného jasného vlastníka a jednu mount path. Dva nesúvisiace procesy, ktoré zapisujú do rovnakého adresára, sťažujú obnovu a analýzu oprávnení.

Pred pridaním storage odhadnite počiatočnú veľkosť, tempo rastu, požiadavky na retention a recovery objective. Disk sa v rámci zostatku plánu účtuje po minútach, takže nevyužitá kapacita a nekontrolovaný rast súborov niečo stoja.

Ako vytvoriť a skontrolovať Dockup volume?

Zobrazte existujúce volumes pre konkrétnu službu:

dockup volume list production/web --json

Pridajte volume s názvom, absolútnou cestou v containery a veľkosťou v gigabajtoch:

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

Aplikácia musí zapisovať do /app/uploads. Zápis do /uploads alebo iného lokálneho adresára automaticky nepresmeruje dáta do mountu.

Po deploymente overte, že aplikácia zapisuje do deklarovanej absolútnej mount path, nie do nahraditeľného filesystemu containera.

Skontrolujte skutočné využitie disku pomocou vráteného ID volume:

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

Porovnajte skutočné využitie s pridelenou veľkosťou a metrikami aplikácie. Nastavte alert ešte pred zaplnením filesystemu; plný volume môže spôsobiť čiastočné zápisy, neúspešné uploady alebo pády aplikácie.

Skontrolujte očakávania týkajúce sa vlastníctva súborov. Runtime user containera musí mať možnosť čítať z mount path a zapisovať do nej bez udeľovania širších oprávnení, než je potrebné.

Ako snapshots volumes chránia dáta?

Snapshot vytvorený na požiadanie zachytí obsah volume:

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

Zobrazte dostupné snapshots:

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

Snapshots čítajú volume read-only spôsobom a nevyžadujú, aby aplikácia zapisovala do špeciálneho adresára pre snapshot. Sú užitočné pred riskantnou migráciou súborov, hromadným prepisom médií alebo zmenou aplikácie, ktorá transformuje uložené dáta.

Snapshot volume nie je automaticky application-consistent. Ak aplikácia aktívne zapisuje niekoľko súvisiacich súborov, snapshot ich môže zachytiť v mierne odlišných okamihoch. V prípade managed databázy použite systém zálohovania managed databázy namiesto snapshotovania jej raw dátového adresára.

Definujte, kedy má byť aplikácia quiesced. Pred hodnotným snapshotom môže byť vhodná krátka maintenance pauza alebo pozastavenie zápisov. Zaznamenajte ID snapshotu, dôvod a očakávaný restore point.

Ako plánovať retention snapshotov?

Časovanie a retention snapshotov určujte podľa požiadaviek na obnovu, nie podľa zvyku. Pred každou riskantnou migráciou súborov, čistením alebo zmenou formátu vytvorte snapshot na požiadanie a zaznamenajte vrátené ID snapshotu.

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

Potreba obnovy	Postup pri snapshots	Obmedzenie
Vrátenie migrácie súborov	Vytvorte snapshot bezprostredne pred zmenou	Nezahŕňa neskoršie zápisy
Uchovanie historických bodov	Uchovávajte označené recovery points podľa policy	Retention treba aktívne kontrolovať
Ochrana častých zápisov	Pridajte application-level backup vhodný pre dané dáta	Point-in-time snapshot nie je continuous protection
Regulačný archív	Použite vyhradený archivačný workflow	Operational snapshots nemusia spĺňať policy

Kontrolujte, či očakávané snapshots skutočne existujú. Zapísaná retention policy nie je dôkazom, že bol vytvorený použiteľný restore point.

Ako bezpečne obnoviť snapshot volume?

Obnova nahradí aktuálny obsah volume a reštartuje container:

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

Ide o disruptívnu operáciu, ktorá mení stav systému. Pred obnovou:

1. Potvrďte správnu službu, ID volume a ID snapshotu.
2. Vysvetlite, ktoré aktuálne súbory budú nahradené.
3. Ak je to možné, zastavte nové zápisy alebo ich obmedzte.
4. Ak môže byť aktuálny stav potrebný, vytvorte z neho nový snapshot.
5. Zaznamenajte kompatibilitu aplikácie a schémy.
6. Získajte výslovné production schválenie.
7. Naplánujte overenie po obnove.

Po obnove overte stav containera a správanie aplikácie:

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

Otestujte reprezentatívne súbory, oprávnenia, indexy a referencie aplikácie. Úspešný príkaz na obnovenie dokazuje, že snapshot bol aplikovaný; nedokazuje však, že každý záznam aplikácie odkazuje na platný súbor.

Model AI agent production guardrails by mal považovať obnovu za operáciu vyžadujúcu schválenie, aj keď ide o recovery operation.

Ako sa majú volumes správať počas deploymentu a rollbacku?

Deployment nahradí application containers, zatiaľ čo pripojený volume zostane zachovaný. Nový image tak môže vidieť existujúce súbory, no zároveň vzniká povinnosť zachovať kompatibilitu.

Nová verzia aplikácie by nemala nevratne transformovať uložené súbory skôr, než je release overený. Ak mení formáty súborov alebo štruktúru adresárov, použite migration, ktorú možno resumovať a ktorá je podľa možnosti backward compatible.

Application rollback znovu spustí starší deployment:

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

Volume sa automaticky nevráti do pôvodného stavu spolu s image. Staršia aplikácia nemusí vedieť čítať súbory transformované novou verziou. Rollback image koordinujte s obnovením snapshotu iba vtedy, keď sú potrebné a schválené obe operácie.

Toto oddelenie je dôležité:

Recovery action	Mení image?	Mení dáta volume?
Deploy novej verzie	Áno	Nie, pokiaľ ich aplikácia nemigruje
Rollback deploymentu	Áno	Nie
Obnovenie snapshotu	Nie	Áno
Obnovenie spolu s rollbackom	Áno	Áno

Proces zero-downtime deployment chráni prepnutie trafficu, nie kompatibilitu dátových formátov.

Čo by mal obsahovať runbook pre prevádzku durable storage?

Každému production volume priraďte vlastníka. Runbook by mal obsahovať:

• Cieľovú službu a ID volume.
• Mount path a očakávaného runtime usera.
• Pridelenú veľkosť a alert threshold.
• Popis dát a možnosť ich opätovného vytvorenia.
• Schedule snapshotov a retention.
• Posledný overený snapshot.
• Policy pre schvaľovanie obnovy.
• Kroky na validáciu aplikácie.
• Poznámky ku kompatibilite image a dát.
• Policy rastu a mazania.

Pravidelne kontrolujte využitie:

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

CPU, RAM a disk sa účtujú po minútach. Free plan ponúka počiatočný kredit $10, zatiaľ čo odporúčaný Pro plan stojí $20 mesačne a obsahuje usage credit $20.

Cvičenie obnovy snapshotu

Nečakajte na incident, aby ste zistili, že nikto nevie, ktorý snapshot vybrať. Vykonajte kontrolované cvičenie na non-production službe alebo schválenej kópii:

1. Vytvorte ľahko rozpoznateľné testovacie súbory.
2. Vytvorte snapshot.
3. Zmeňte súbory.
4. Obnovte snapshot.
5. Overte obsah a oprávnenia.
6. Sledujte reštart containera.
7. Zaznamenajte časovanie a miesta zlyhaní.

Cvičenie obnovy mení persistent volumes a snapshots z položky na checklist-e na otestovanú recovery capability.

Pri návrhu počiatočnej služby si pozrite Git repository to production. Podrobnosti o príkazoch nájdete v Dockup CLI reference.

Definujte recovery objectives pre súborové dáta

Recovery point objective určuje, koľko najnovších dát môže firma stratiť. Recovery time objective určuje, ako dlho môže obnova trvať. Denný snapshot so retention na sedem kópií môže vyhovovať internej media cache, nie však produktu s uploadmi používateľov, ktorý garantuje takmer real-time trvanlivosť dát.

Zdokumentujte obe hodnoty a otestujte skutočné trvanie obnovy. K času obnovy prispieva rýchlosť vytvorenia snapshotu, veľkosť dát, reštart containera, validácia súborov aj reindexovanie aplikácie.

Kontrolujte mazanie a rast súborov

Persistent storage sa môže zaplniť, pretože aplikácia nikdy neodstraňuje dočasné alebo nahradené súbory. Pridajte retention policy na application layer a odlišujte logické vymazanie od okamžitého fyzického vymazania. Krátke recovery window môže odôvodniť odklad trvalého odstránenia.

Pred spustením hromadného čistenia:

1. Zmerajte aktuálne využitie volume.
2. Vytvorte zoznam kandidátov na vymazanie.
3. Vytvorte snapshot.
4. Spustite čistenie v dávkach s obmedzenou veľkosťou.
5. Overte referencie aplikácie.
6. Potvrďte očakávané uvoľnenie priestoru.

Tým získajú persistent volumes a snapshots preventívnu úlohu, nielen úlohu pri incidente.

Overujte inventory snapshotov

Pravidelne kontrolujte ID snapshotov, časy vytvorenia, retention a posledný úspešný test obnovy. Nakonfigurovaný job bez nedávneho použiteľného snapshotu nie je recovery systém.

Priraďte oprávnenie na obnovu

Určte, kto môže schváliť production restore a kto vykoná validáciu po obnove. Oddelenie schválenia od vykonania znižuje riziko, že naliehavosť obíde overenie cieľa a snapshotu.

Začnite s overiteľným deploymentom

Vytvorte jeden non-production volume, vytvorte snapshot, zmeňte testovací súbor a dokončite cvičenie obnovy ešte pred uložením nenahraditeľných production dát.

Začnite bezplatne na app.dockup.ai. Free plan stojí $0 mesačne, obsahuje počiatočný kredit $10 a podporuje jeden workspace, tri databázy a tri deploymenty.

FAQ

Prežije Dockup volume deployment?

Áno. Volume zostáva persistentný aj po nahradení service containers, ak aplikácia naďalej používa nakonfigurovanú mount path.

Je volume snapshot správnou zálohou pre PostgreSQL?

Nie. Hot snapshot dátového adresára databázy nemusí byť transaction-consistent. Pri managed databázach uprednostnite systém zálohovania managed databázy.

Čo sa stane pri obnovení snapshotu volume?

Aktuálny obsah volume sa nahradí vybraným snapshotom a container sa reštartuje, preto by mala byť operácia schválená a overená.

Môže Dockup plánovať snapshots volumes?

Áno. Príkaz na plánovanie volume podporuje denné snapshots s počtom snapshotov v retention a schedule možno explicitne deaktivovať.

Vráti rollback aplikácie späť aj jej volume?

Nie. História deploymentov aplikácie a história snapshotov volume sú oddelené. Koordinujte ich iba vtedy, keď to vyžaduje recovery plán.