Perzisztens kötetek és pillanatképek a Dockupon

A perzisztens kötetek és pillanatképek két különböző problémát oldanak meg. A kötet megőrzi a fájlokat a konténerek cseréje és az új deploymentek után is. A pillanatkép egy adott időpontban rögzíti a kötet állapotát, hogy az üzemeltetők később megvizsgálhassák, megőrizhessék vagy visszaállíthassák azt.

A konténer fájlrendszere lecserélhető. Minden olyan adatnak, amelynek túl kell élnie egy deploymentet — például a feltöltéseknek, a generált médiának, az indexeknek, a csomag-artifactoknak vagy az alkalmazás által kezelt fájloknak — explicit perzisztens helyre van szüksége.

Mely alkalmazásadatokat érdemes perzisztens tárolón elhelyezni?

Akkor használj kötetet, ha az alkalmazás olyan fájlokat kezel, amelyek más forrásból nem állíthatók elő olcsón vagy biztonságosan.

Adat	Kötet?	Jobb alternatíva, ha elérhető
Felhasználói feltöltések	Igen	Object storage, ha az architektúra használ ilyet
Generált bélyegképek	Esetleg	Újragenerálás az eredetikből
Keresési index	Esetleg	Újraépítés a forrás-adatbázisból
Build-artifactok	Általában nem	Újraépítés a deployment során
Alkalmazásnaplók	Általában nem	Runtime naplózási rendszer
PostgreSQL adatkönyvtára	Ne alkalmazáskötetként	Kezelt PostgreSQL
Ideiglenes cache	Nem	Redis vagy ephemeral storage
Helyi SQLite production adatbázis	Kockázatos	Kezelt adatbázis a párhuzamosság és a biztonsági mentések miatt

Egy kötetnek egyértelmű tulajdonossal és csatolási útvonallal kell rendelkeznie. Ha két, egymástól független folyamat ugyanabba a könyvtárba ír, az megnehezíti a helyreállítást és a jogosultságok elemzését.

Mielőtt tárhelyet adnál hozzá, becsüld meg a kezdeti méretet, a növekedési ütemet, a megőrzési követelményeket és a helyreállítási célokat. A lemezhasználatot percenként számítják a csomag egyenlegéhez, ezért a kihasználatlan kapacitásnak és a kontrollálatlan fájlnövekedésnek is költsége van.

Hogyan hozhatsz létre és vizsgálhatsz meg egy Dockup-kötetet?

Listázd az adott service meglévő köteteit:

dockup volume list production/web --json

Adj hozzá egy kötetet névvel, abszolút konténerútvonallal és gigabájtban megadott mérettel:

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

Az alkalmazásnak az /app/uploads útvonalra kell írnia. Ha az /uploads vagy egy másik lokális könyvtár az írás célpontja, az nem irányítja át automatikusan az adatokat a csatolásba.

A deployment után ellenőrizd, hogy az alkalmazás a megadott abszolút csatolási útvonalra ír-e, nem pedig a lecserélhető konténer-fájlrendszerbe.

A visszaadott kötetazonosítóval vizsgáld meg a tényleges lemezhasználatot:

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

Hasonlítsd össze a tényleges használatot a lefoglalt mérettel és az alkalmazás metrikáival. Még a fájlrendszer megtelése előtt állíts be riasztást; a megtelt kötet részleges írásokat, sikertelen feltöltéseket vagy alkalmazás-összeomlásokat okozhat.

Ellenőrizd a fájltulajdonlással kapcsolatos elvárásokat. A konténer runtime-felhasználójának tudnia kell olvasni és írni a csatolási útvonalon anélkül, hogy a szükségesnél szélesebb jogosultságokat kapna.

Hogyan védik az adatokat a kötet-pillanatképek?

Az igény szerint készített pillanatkép rögzíti a kötet tartalmát:

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

Az elérhető pillanatképek listázása:

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

A pillanatképek csak olvasható módon olvassák a kötetet, és nem igénylik, hogy az alkalmazás egy speciális pillanatkép-könyvtárba írjon. Hasznosak kockázatos fájlmigráció, nagy tömegű média-újraírás vagy az elmentett adatokat átalakító alkalmazásmódosítás előtt.

A kötet-pillanatkép nem automatikusan alkalmazáskonzisztens. Ha az alkalmazás aktívan ír több, egymáshoz kapcsolódó fájlt, a pillanatkép kissé eltérő időpontokban rögzítheti ezeket. Kezelt adatbázis esetén a nyers adatkönyvtár pillanatképezése helyett a kezelt adatbázis biztonsági mentési rendszerét használd.

Határozd meg, mikor kell az alkalmazást quiesce állapotba hozni. Egy rövid karbantartási vagy írási szünet indokolt lehet egy kiemelten fontos pillanatkép készítése előtt. Rögzítsd a pillanatkép azonosítóját, okát és a várt helyreállítási pontot.

Hogyan érdemes megtervezni a pillanatképek megőrzését?

A pillanatképek időzítését és megőrzését a helyreállítási követelmények, ne pedig a megszokás alapján válaszd meg. Készíts igény szerinti pillanatképet minden kockázatos fájlmigráció, tisztítás vagy formátumváltás előtt, és jegyezd fel a visszaadott pillanatkép-azonosítót.

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

Helyreállítási igény	Pillanatkép-stratégia	Korlátozás
Fájlmigráció visszavonása	Készíts pillanatképet közvetlenül a módosítás előtt	A későbbi írásokat nem tartalmazza
Korábbi állapotok megőrzése	A szabályzat szerint őrizz meg címkézett helyreállítási pontokat	A megőrzést rendszeresen felül kell vizsgálni
Gyakori írások védelme	Az adatoknak megfelelő alkalmazásszintű biztonsági mentést is adj hozzá	Az időponthoz kötött pillanatkép nem folyamatos védelem
Szabályozási célú archiválás	Használj dedikált archiválási folyamatot	Az üzemeltetési pillanatképek nem feltétlenül felelnek meg a szabályzatnak

Ellenőrizd, hogy a várt pillanatképek ténylegesen léteznek-e. Egy leírt megőrzési szabályzat nem bizonyítja, hogy használható helyreállítási pont is létrejött.

Hogyan állíthatsz vissza biztonságosan egy kötet-pillanatképet?

A visszaállítás lecseréli az aktuális kötet tartalmát, majd újraindítja a konténert:

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

Ez megszakítással járó, állapotot módosító művelet. Visszaállítás előtt:

1. Erősítsd meg a pontos service-t, kötetazonosítót és pillanatkép-azonosítót.
2. Ismertesd, mely aktuális fájlokat cseréli le a művelet.
3. Ahol lehetséges, állítsd le vagy korlátozd az új írásokat.
4. Készíts friss pillanatképet az aktuális állapotról, ha később szükség lehet rá.
5. Rögzítsd az alkalmazás- és sémakompatibilitást.
6. Szerezz kifejezett production jóváhagyást.
7. Tervezd meg a visszaállítás utáni ellenőrzést.

A visszaállítás után ellenőrizd a konténer állapotát és az alkalmazás működését:

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

Tesztelj reprezentatív fájlokat, jogosultságokat, indexeket és alkalmazáshivatkozásokat. A sikeres restore parancs azt bizonyítja, hogy a pillanatkép alkalmazása megtörtént; azt nem, hogy minden alkalmazásrekord érvényes fájlra mutat.

Az AI agent production guardrails modellje szerint a restore műveletet jóváhagyáshoz kell kötni, még akkor is, ha helyreállítási műveletről van szó.

Hogyan kell viselkedniük a köteteknek deployment és rollback közben?

Egy deployment lecseréli az alkalmazáskonténereket, miközben a csatolt kötet megmarad. Így az új image hozzáférhet a meglévő fájlokhoz, ez azonban kompatibilitási kötelezettséget teremt.

Az alkalmazás új verziója nem alakíthatja át visszafordíthatatlanul a tárolt fájlokat azelőtt, hogy a release bizonyítottan működőképes lenne. Ha módosítja a fájlformátumokat vagy a könyvtárszerkezetet, lehetőség szerint használj folytatható és visszafelé kompatibilis migrációt.

Az alkalmazás rollbackje egy korábbi deploymentet futtat újra:

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

A kötet nem áll vissza automatikusan az image-dzsel együtt. Előfordulhat, hogy egy régi alkalmazás nem tudja beolvasni az új verzió által átalakított fájlokat. Az image rollbackjét csak akkor hangold össze a pillanatkép visszaállításával, ha mindkettőre szükség van, és mindkettőt jóváhagyták.

Ez a szétválasztás fontos:

Helyreállítási művelet	Módosítja az image-et?	Módosítja a kötet adatait?
Új verzió deploymentje	Igen	Nem, kivéve, ha az alkalmazás migrálja
Deployment visszaállítása	Igen	Nem
Pillanatkép visszaállítása	Nem	Igen
Visszaállítás és rollback	Igen	Igen

A zero-downtime deployment folyamat a forgalom átirányítását védi, nem az adatformátum-kompatibilitást.

Mi az a tartós tárhely üzemeltetési runbook?

Minden production kötethez rendelj felelőst. A runbooknak a következőket kell tartalmaznia:

• Service-cél és kötetazonosító.
• Csatolási útvonal és a várt runtime-felhasználó.
• Lefoglalt méret és riasztási küszöb.
• Az adatok leírása és újraépíthetősége.
• Pillanatkép-ütemezés és megőrzés.
• Az utolsó ellenőrzött pillanatkép.
• Visszaállítási jóváhagyási szabályzat.
• Alkalmazás-ellenőrzési lépések.
• Az image- és adatkompatibilitással kapcsolatos megjegyzések.
• Növekedési és törlési szabályzat.

Rendszeresen ellenőrizd a használatot:

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

A CPU-t, a RAM-ot és a lemezt percenként mérik. A Free csomag 10 dollár kezdő egyenleget kínál, míg az ajánlott Pro csomag havi 20 dollárba kerül, és 20 dollár használati egyenleget tartalmaz.

Pillanatkép-visszaállítási gyakorlat

Ne várj meg egy incidenst annak kiderítésével, hogy senki sem tudja, melyik pillanatképet kell választani. Futtass ellenőrzött gyakorlatot egy nem production service-en vagy jóváhagyott másolaton:

1. Hozz létre jól felismerhető tesztfájlokat.
2. Készíts pillanatképet.
3. Módosítsd a fájlokat.
4. Állítsd vissza a pillanatképet.
5. Ellenőrizd a tartalmat és a jogosultságokat.
6. Figyeld meg a konténer újraindulását.
7. Rögzítsd az időzítést és a hibapontokat.

A visszaállítási gyakorlat a perzisztens köteteket és pillanatképeket kipipálandó tételből tesztelt helyreállítási képességgé alakítja.

A kezdeti service-tervezéshez lásd a Git repository to production útmutatót. A parancsok részleteiért használd a Dockup CLI-referenciát.

Helyreállítási célok meghatározása a fájladatokhoz

A recovery point objective azt mutatja meg, hogy az üzletileg mennyi friss adat elvesztése elfogadható. A recovery time objective azt mutatja meg, hogy mennyi ideig tarthat a visszaállítás. A napi pillanatkép hét példányos megőrzéssel megfelelő lehet egy belső médiacache számára, de nem biztos, hogy elegendő egy olyan felhasználói feltöltési termékhez, amely közel valós idejű adatmegőrzést ígér.

Dokumentáld mindkét értéket, és teszteld a tényleges visszaállítási időt. A pillanatkép készítésének sebessége, az adatok mérete, a konténer újraindítása, a fájlok ellenőrzése és az alkalmazás újraindexelése mind hozzájárul a helyreállítási időhöz.

A fájltörlés és -növekedés szabályozása

A perzisztens tárhely azért is megtelhet, mert az alkalmazás soha nem törli az ideiglenes vagy lecserélt fájlokat. Vezess be megőrzési szabályzatot az alkalmazásrétegben, és különböztesd meg a logikai törlést az azonnali fizikai törléstől. Egy rövid helyreállítási időablak indokolhatja a végleges törlés késleltetését.

Tömeges tisztítás futtatása előtt:

1. Mérd meg az aktuális kötet használatát.
2. Készíts listát a törlésre jelölt elemekről.
3. Készíts pillanatképet.
4. Futtasd a tisztítást korlátozott méretű adagokban.
5. Ellenőrizd az alkalmazáshivatkozásokat.
6. Erősítsd meg a várt tárhely-felszabadulást.

Így a perzisztens kötetek és pillanatképek nemcsak incidenskezelési, hanem megelőző szerepet is kapnak.

A pillanatkép-készlet ellenőrzése

Ütemezetten vizsgáld felül a pillanatkép-azonosítókat, a létrehozási időpontokat, a megőrzést és az utolsó sikeres visszaállítási tesztet. Egy friss, használható pillanatkép nélküli, konfigurált job nem helyreállítási rendszer.

A visszaállítási jogosultság kiosztása

Nevezd meg, ki hagyhat jóvá egy production visszaállítást, és ki végzi a visszaállítás utáni validációt. A jóváhagyás és a végrehajtás szétválasztása csökkenti annak esélyét, hogy a sürgősség miatt elmaradjon a cél és a pillanatkép ellenőrzése.

Kezdd ellenőrizhető deploymenttel

Hozz létre egy nem production célú kötetet, készíts pillanatképet, módosíts egy tesztfájlt, majd végezz visszaállítási gyakorlatot, mielőtt pótolhatatlan production adatokat tárolnál.

Kezdd ingyenesen az app.dockup.ai oldalon. A Free csomag havi 0 dollárba kerül, 10 dollár kezdő egyenleget tartalmaz, és egy workspace-t, három adatbázist, valamint három deploymentet támogat.

Gyakran ismételt kérdések

Megmarad egy Dockup-kötet deployment után?

Igen. A kötet perzisztens marad a service-konténerek cseréje közben, feltéve, hogy az alkalmazás továbbra is a konfigurált csatolási útvonalat használja.

A kötet-pillanatkép a megfelelő biztonsági mentés a PostgreSQL számára?

Nem. Egy adatbázis adatkönyvtáráról készített működés közbeni pillanatkép nem feltétlenül tranzakciókonzisztens. Kezelt adatbázisok esetén inkább a kezelt adatbázis biztonsági mentési rendszerét használd.

Mi történik egy kötet-pillanatkép visszaállításakor?

Az aktuális kötet tartalmát lecseréli a kiválasztott pillanatkép, majd újraindítja a konténert, ezért a műveletet jóvá kell hagyni és ellenőrizni kell.

Ütemezhet a Dockup kötet-pillanatképeket?

Igen. A volume schedule parancs támogatja a napi pillanatképeket megőrzési darabszámmal, és az ütemezés kifejezetten letiltható.

Az alkalmazás rollbackje a kötetet is visszaállítja?

Nem. Az alkalmazás deployment-előzményei és a kötet pillanatkép-előzményei különállók. Csak akkor hangold össze a kettőt, ha a helyreállítási terv ezt megköveteli.