Persistent volumeni i snapshoti na Dockupu

Persistent volumeni i snapshoti rješavaju dva različita problema. Volumen zadržava datoteke prilikom zamjene containera i deploymenta. Snapshot bilježi stanje volumena u određenom trenutku kako bi ga operateri kasnije mogli pregledati, zadržati ili vratiti.

Filesystem containera može se zamijeniti. Sve što mora preživjeti deployment — uploadi, generirani mediji, indeksi, package artefakti ili datoteke kojima upravlja aplikacija — treba biti smješteno na eksplicitnoj persistent lokaciji.

Koji podaci aplikacije pripadaju persistent storageu?

Koristite volumen kada aplikacija upravlja datotekama koje se ne mogu jednostavno ili sigurno ponovno stvoriti iz drugog izvora.

Podaci	Volumen?	Bolja alternativa kada je dostupna
Uploadi korisnika	Da	Object storage ako ga arhitektura koristi
Generirane sličice	Možda	Ponovno ih generirati iz originala
Search indeks	Možda	Ponovno ga izgraditi iz izvorne baze podataka
Build artefakti	Obično ne	Ponovno ih izgraditi tijekom deploymenta
Logovi aplikacije	Obično ne	Runtime log sustav
PostgreSQL data direktorij	Ne kao app volumen	Managed PostgreSQL
Privremeni cache	Ne	Redis ili ephemeral storage
Lokalna SQLite produkcijska baza	Rizično	Managed baza podataka radi concurrencyja i backupa

Volumen treba imati jednog jasno definiranog vlasnika i mount putanju. Ako dva nepovezana procesa pišu u isti direktorij, oporavak i analiza dozvola postaju složeniji.

Prije dodavanja storagea procijenite početnu veličinu, stopu rasta, zahtjeve za retentionom i recovery cilj. Disk se obračunava prema stanju salda plana po minuti, pa neiskorišteni kapacitet i nekontrolirani rast datoteka imaju svoju cijenu.

Kako izraditi i provjeriti Dockup volumen?

Izlistajte postojeće volumene za točan servis:

dockup volume list production/web --json

Dodajte volumen s nazivom, apsolutnom putanjom u containeru i veličinom u gigabajtima:

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

Aplikacija mora pisati u /app/uploads. Pisanje u /uploads ili drugi lokalni direktorij neće se automatski preusmjeriti u mount.

Nakon deploymenta provjerite piše li aplikacija u deklariranu apsolutnu mount putanju, a ne u zamjenjivi filesystem containera.

Provjerite stvarnu zauzetost diska pomoću vraćenog ID-ja volumena:

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

Usporedite stvarnu zauzetost s dodijeljenom veličinom i metrikama aplikacije. Postavite alert prije nego što se filesystem popuni; pun volumen može uzrokovati djelomične upise, neuspjele uploade ili rušenje aplikacije.

Provjerite očekivanja vezana uz vlasništvo nad datotekama. Runtime korisnik containera mora moći čitati i pisati u mount putanju bez dodjele širih dozvola nego što je potrebno.

Kako snapshoti volumena štite podatke?

Snapshot na zahtjev bilježi sadržaj volumena:

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

Izlistajte dostupne snapshot-e:

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

Snapshoti čitaju volumen na read-only način i ne zahtijevaju da aplikacija zapisuje u poseban direktorij za snapshot-e. Korisni su prije rizične migracije datoteka, masovne izmjene medija ili promjene aplikacije koja transformira pohranjene podatke.

Snapshot volumena nije automatski konzistentan s aplikacijom. Ako aplikacija aktivno zapisuje nekoliko povezanih datoteka, snapshot ih može obuhvatiti iz malo različitih trenutaka. Za managed bazu podataka koristite managed database backup sustav umjesto izrade snapshot-a njezina raw data direktorija.

Definirajte kada aplikaciju treba staviti u quiescent stanje. Kratki maintenance ili write pause može biti prikladan prije snapshot-a visoke važnosti. Zabilježite ID snapshot-a, razlog i očekivanu restore točku.

Kako planirati retention snapshot-a?

Vrijeme izrade i retention snapshot-a odaberite prema zahtjevu za oporavkom, a ne prema navici. Izradite snapshot na zahtjev prije svake rizične migracije datoteka, cleanupa ili promjene formata i zabilježite vraćeni ID snapshot-a.

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

Potreba za oporavkom	Praksa sa snapshot-ima	Ograničenje
Poništavanje migracije datoteka	Izradite snapshot neposredno prije promjene	Ne uključuje kasnije upise
Očuvanje povijesnih točaka	Zadržite označene recovery točke prema pravilima	Retention treba aktivno preispitivati
Zaštita čestih upisa	Dodajte backup na razini aplikacije, primjeren podacima	Snapshot u jednoj vremenskoj točki nije kontinuirana zaštita
Regulatorna arhiva	Koristite namjenski archive workflow	Operativni snapshoti možda ne zadovoljavaju pravila

Provjerite postoje li očekivani snapshoti. Napisana retention politika nije dokaz da je izrađena upotrebljiva restore točka.

Kako sigurno vratiti snapshot volumena?

Restore zamjenjuje trenutačni sadržaj volumena i ponovno pokreće container:

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

Ovo je disruptivna operacija koja mijenja stanje. Prije restorea:

1. Potvrdite točan servis, ID volumena i ID snapshot-a.
2. Objasnite koje će trenutačne datoteke biti zamijenjene.
3. Zaustavite ili ograničite nove upise gdje je to moguće.
4. Izradite svježi snapshot trenutačnog stanja ako bi kasnije mogao biti potreban.
5. Zabilježite kompatibilnost aplikacije i sheme.
6. Ishodite izričito odobrenje za produkciju.
7. Isplanirajte provjeru nakon restorea.

Nakon restorea provjerite stanje containera i ponašanje aplikacije:

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

Testirajte reprezentativne datoteke, dozvole, indekse i reference aplikacije. Uspješna restore naredba dokazuje da je snapshot primijenjen; ne dokazuje da svaki zapis aplikacije upućuje na valjanu datoteku.

Model iz zaštitnih pravila za AI agente u produkciji trebao bi tretirati restore kao operaciju za koju je potrebno odobrenje, iako je riječ o operaciji oporavka.

Kako bi se volumeni trebali ponašati tijekom deploymenta i rollbacka?

Deployment zamjenjuje containere aplikacije, dok montirani volumen ostaje. To omogućuje novom imageu da vidi postojeće datoteke, ali stvara obvezu kompatibilnosti.

Nova verzija aplikacije ne bi trebala nepovratno transformirati pohranjene datoteke prije nego što se potvrdi njezino izdanje. Ako mijenja formate datoteka ili rasporede direktorija, koristite migraciju koja se može nastaviti nakon prekida i koja je, gdje je moguće, backward compatible.

Application rollback ponovno pokreće stariji deployment:

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

Volumen se ne vraća automatski zajedno s imageom. Starija aplikacija možda neće moći čitati datoteke koje je transformirala nova verzija. Uskladite rollback imagea s restoreom snapshot-a samo kada su oba potrebna i odobrena.

Ovo je razdvajanje važno:

Radnja oporavka	Mijenja image?	Mijenja podatke volumena?
Deployment nove verzije	Da	Ne, osim ako ih aplikacija migrira
Rollback deploymenta	Da	Ne
Restore snapshot-a	Ne	Da
Restore i rollback	Da	Da

Proces deploymenta bez prekida rada štiti preusmjeravanje prometa, a ne kompatibilnost formata podataka.

Što treba sadržavati operativni runbook za durable storage?

Dodijelite vlasnika svakom produkcijskom volumenu. Runbook treba sadržavati:

• Cilj servisa i ID volumena.
• Mount putanju i očekivanog runtime korisnika.
• Dodijeljenu veličinu i prag za alert.
• Opis podataka i mogućnost ponovne izgradnje.
• Raspored snapshot-a i retention.
• Posljednji provjereni snapshot.
• Pravila odobravanja restorea.
• Korake za provjeru aplikacije.
• Napomene o kompatibilnosti imagea i podataka.
• Pravila rasta i brisanja.

Redovito provjeravajte zauzetost:

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

CPU, RAM i disk obračunavaju se po minuti. Free plan nudi početni kredit od $10, dok preporučeni Pro plan košta $20 mjesečno i uključuje $20 kredita za upotrebu.

Vježba restorea snapshot-a

Nemojte čekati incident da biste otkrili da nitko ne zna koji snapshot odabrati. Provedite kontroliranu vježbu na neprodukcijskom servisu ili odobrenoj kopiji:

1. Izradite prepoznatljive testne datoteke.
2. Izradite snapshot.
3. Promijenite datoteke.
4. Vratite snapshot.
5. Provjerite sadržaj i dozvole.
6. Promatrajte ponovno pokretanje containera.
7. Zabilježite trajanje i točke neuspjeha.

Vježba restorea pretvara persistent volumene i snapshot-e iz stavke na checklisti u testiranu mogućnost oporavka.

Za početni dizajn servisa pogledajte Od Git repozitorija do produkcije. Za detalje naredbi koristite Dockup CLI referencu.

Definirajte ciljeve oporavka za podatke u datotekama

Recovery point objective odgovara na pitanje koliko nedavnih podataka poslovanje može izgubiti. Recovery time objective odgovara na pitanje koliko dugo restore smije trajati. Dnevni snapshot s retentionom od sedam kopija možda je dovoljan za interni media cache, ali ne i za proizvod s uploadima korisnika koji obećava trajnost podataka gotovo u stvarnom vremenu.

Dokumentirajte obje vrijednosti i testirajte stvarno trajanje restorea. Brzina izrade snapshot-a, veličina podataka, ponovno pokretanje containera, provjera datoteka i reindeksiranje aplikacije zajedno određuju vrijeme oporavka.

Kontrolirajte brisanje i rast datoteka

Persistent storage može se napuniti jer aplikacija nikad ne uklanja privremene ili zamijenjene datoteke. Dodajte retention politiku na razini aplikacije i razlikujte logičko brisanje od trenutačnog fizičkog brisanja. Kratak recovery prozor može opravdati odgodu trajnog uklanjanja.

Prije pokretanja masovnog čišćenja:

1. Izmjerite trenutačnu zauzetost volumena.
2. Izradite popis kandidata za brisanje.
3. Izradite snapshot.
4. Pokrenite čišćenje u ograničenim batchovima.
5. Provjerite reference aplikacije.
6. Potvrdite očekivano oslobađanje prostora.

Time persistent volumeni i snapshoti dobivaju preventivnu ulogu, a ne samo ulogu tijekom incidenta.

Provjeravajte inventar snapshot-a

Prema rasporedu provjeravajte ID-jeve snapshot-a, vremena izrade, retention i posljednji uspješan test restorea. Konfiguriran job bez nedavnog upotrebljivog snapshot-a nije sustav oporavka.

Dodijelite ovlasti za restore

Odredite tko smije odobriti restore u produkciji i tko provodi provjeru nakon restorea. Razdvajanje odobravanja od izvršavanja smanjuje mogućnost da hitnost zaobiđe provjeru cilja i snapshot-a.

Započnite s provjerljivim deploymentom

Izradite jedan neprodukcijski volumen, napravite snapshot, promijenite testnu datoteku i dovršite vježbu restorea prije pohrane nezamjenjivih produkcijskih podataka.

Započnite besplatno na app.dockup.ai. Free plan iznosi $0 mjesečno, uključuje početni kredit od $10 te podržava jedan workspace, tri baze podataka i tri deploymenta.

Česta pitanja

Preživljava li Dockup volumen deployment?

Da. Volumen ostaje persistentan dok se containeri servisa zamjenjuju, pod uvjetom da aplikacija i dalje koristi konfiguriranu mount putanju.

Je li snapshot volumena odgovarajući backup za PostgreSQL?

Ne. Hot snapshot data direktorija baze podataka možda neće biti transaction-consistent. Za managed baze podataka prednost dajte managed database backup sustavu.

Što se događa kada se snapshot volumena vrati?

Trenutačni sadržaj volumena zamjenjuje se odabranim snapshotom, a container se ponovno pokreće, pa operaciju treba odobriti i provjeriti.

Može li Dockup zakazati snapshot-e volumena?

Da. Naredba za raspored volumena podržava dnevne snapshot-e s brojem kopija za retention, a raspored se može izričito onemogućiti.

Vraća li rollback aplikacije i njezin volumen?

Ne. Povijest deploymenta aplikacije i povijest snapshot-a volumena odvojene su. Uskladite ih samo kada to zahtijeva plan oporavka.