Persistent volumes og snapshots på Dockup

Persistent volumes og snapshots løser to forskjellige problemer. Et volume bevarer filer når containere erstattes og applikasjonen deployes på nytt. Et snapshot tar vare på volumet på et bestemt tidspunkt, slik at operatører kan undersøke, beholde eller gjenopprette denne tilstanden senere.

Container-filsystemet kan erstattes. Alt som må overleve en deploy – opplastinger, genererte medier, indekser, pakkeartefakter eller applikasjonsstyrte filer – trenger en eksplisitt persistent plassering.

Hvilke applikasjonsdata hører hjemme på persistent lagring?

Bruk et volume når applikasjonen eier filer som ikke enkelt eller trygt kan gjenskapes fra en annen kilde.

Data	Volume?	Bedre alternativ når det er tilgjengelig
Brukeropplastinger	Ja	Object storage hvis arkitekturen bruker det
Genererte miniatyrbilder	Kanskje	Generer på nytt fra originalene
Søkeregister	Kanskje	Bygg på nytt fra kildedatabasen
Byggeartefakter	Vanligvis nei	Bygg på nytt under deployment
Applikasjonslogger	Vanligvis nei	Runtime-loggsystem
PostgreSQL-datakatalog	Ikke som et app-volume	Managed PostgreSQL
Midlertidig cache	Nei	Redis eller ephemeral storage
Lokal SQLite-produksjonsdatabase	Risikabelt	Managed database for samtidighet og sikkerhetskopier

Et volume bør ha én tydelig eier og mount path. To urelaterte prosesser som skriver til samme katalog, gjør gjenoppretting og analyse av tilgangsrettigheter vanskeligere.

Før du legger til lagring, bør du anslå startstørrelse, vekstrate, krav til oppbevaring og recovery objective. Disk måles mot planens saldo per minutt, så ubrukt kapasitet og ukontrollert filvekst har en kostnad.

Hvordan oppretter og undersøker du et Dockup-volume?

List eksisterende volumes for den nøyaktige tjenesten:

dockup volume list production/web --json

Legg til et volume med navn, absolutt container path og størrelse i gigabyte:

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

Applikasjonen må skrive til /app/uploads. Skriving til /uploads eller en annen lokal katalog omdirigeres ikke automatisk til mounten.

Etter deployment må du kontrollere at applikasjonen skriver til den deklarerte absolutte mount path-en, og ikke til det utskiftbare container-filsystemet.

Undersøk faktisk diskbruk med volume-ID-en du fikk tilbake:

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

Sammenlign faktisk bruk med den tildelte størrelsen og applikasjonsmålinger. Sett opp varsler før filsystemet er fullt. Et fullt volume kan føre til delvise skrivinger, mislykkede opplastinger eller applikasjonskrasj.

Gå gjennom forventningene til fileierskap. Runtime-brukeren i containeren må kunne lese og skrive til mount path-en uten at du gir bredere tilgang enn nødvendig.

Hvordan beskytter volume-snapshots data?

Et snapshot på forespørsel tar vare på innholdet i volumet:

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

List tilgjengelige snapshots:

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

Snapshots leser volumet på en skrivebeskyttet måte og krever ikke at applikasjonen skriver til en egen snapshot-katalog. De er nyttige før en risikofylt filflytting, en omfattende omskriving av medier eller en applikasjonsendring som transformerer lagrede data.

Et volume-snapshot er ikke automatisk konsistent med applikasjonen. Hvis applikasjonen aktivt skriver flere relaterte filer, kan snapshotet inneholde dem fra litt forskjellige tidspunkter. For en managed database bør du bruke systemet for sikkerhetskopiering av managed databaser i stedet for å ta snapshot av den rå datakatalogen.

Definer når applikasjonen bør settes i ro. En kort pause i vedlikehold eller skriving kan være hensiktsmessig før du tar et snapshot av høy verdi. Registrer snapshot-ID, årsak og forventet gjenopprettingspunkt.

Hvordan bør oppbevaring av snapshots planlegges?

Velg tidspunkt og oppbevaring av snapshots ut fra recovery-kravet, ikke av vane. Ta et snapshot på forespørsel før hver risikofylte filflytting, opprydding eller formatendring, og registrer snapshot-ID-en du får tilbake.

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

Behov for gjenoppretting	Praksis for snapshots	Begrensning
Angre en filflytting	Ta snapshot umiddelbart før endringen	Inneholder ikke senere skrivinger
Bevare historiske tidspunkter	Behold merkede gjenopprettingspunkter i henhold til policy	Oppbevaringen må gjennomgås aktivt
Beskytte hyppige skrivinger	Legg til applikasjonsnivå-sikkerhetskopiering som passer til dataene	Et snapshot fra ett tidspunkt er ikke kontinuerlig beskyttelse
Arkiv for regulatoriske krav	Bruk en dedikert arkivprosess	Operasjonelle snapshots oppfyller kanskje ikke kravene

Kontroller at forventede snapshots faktisk finnes. En skriftlig policy for oppbevaring er ikke bevis på at et brukbart gjenopprettingspunkt er opprettet.

Hvordan gjenoppretter du et volume-snapshot på en trygg måte?

En gjenoppretting erstatter innholdet i det nåværende volumet og starter containeren på nytt:

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

Dette er en forstyrrende operasjon som endrer tilstanden. Før du gjenoppretter:

1. Bekreft riktig tjeneste, volume-ID og snapshot-ID.
2. Forklar hvilke nåværende filer som blir erstattet.
3. Stopp eller begrens nye skrivinger der det er mulig.
4. Ta et nytt snapshot av den nåværende tilstanden hvis den kan bli nødvendig.
5. Registrer kompatibilitet for applikasjon og schema.
6. Innhent eksplisitt godkjenning for produksjon.
7. Planlegg verifisering etter gjenopprettingen.

Etter gjenoppretting må du kontrollere containerens tilstand og hvordan applikasjonen oppfører seg:

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

Test representative filer, tilgangsrettigheter, indekser og referanser fra applikasjonen. En vellykket restore-kommando beviser at snapshotet ble tatt i bruk, men ikke at alle applikasjonsposter peker til en gyldig fil.

Modellen for produksjonsretningslinjer for AI-agenter bør behandle restore som en operasjon som krever godkjenning, selv om det er en gjenopprettingsoperasjon.

Hvordan bør volumes oppføre seg under deployment og rollback?

En deployment erstatter applikasjonscontainere mens det mountede volumet blir værende. Det gjør at et nytt image kan se eksisterende filer, men skaper samtidig et kompatibilitetskrav.

En ny applikasjonsversjon bør ikke transformere lagrede filer irreversibelt før versjonen er utprøvd. Hvis den endrer filformater eller katalogstrukturer, bør du bruke en migrering som kan gjenopptas og er bakoverkompatibel der det er mulig.

En rollback av applikasjonen kjører en eldre deployment på nytt:

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

Volumet rulles ikke automatisk tilbake sammen med imaget. En eldre applikasjon kan være ute av stand til å lese filer som ble transformert av den nye versjonen. Koordiner rollback av image med gjenoppretting av snapshot bare når begge deler er nødvendige og godkjent.

Dette skillet er viktig:

Gjenopprettingshandling	Endrer image?	Endrer volumdata?
Deploy ny versjon	Ja	Nei, med mindre appen migrerer dem
Rull tilbake deployment	Ja	Nei
Gjenopprett snapshot	Nei	Ja
Gjenopprett og rull tilbake	Ja	Ja

Prosessen for deployment uten nedetid beskytter trafikkomleggingen, ikke kompatibiliteten til dataformatet.

Hva er en driftsrutine for persistent lagring?

Utpek en eier for hvert produksjonsvolume. Driftsrutinen bør inneholde:

• Tjenestemål og volume-ID.
• Mount path og forventet runtime-bruker.
• Tildelt størrelse og terskel for varsling.
• Databeskrivelse og hvor enkelt dataene kan bygges opp igjen.
• Plan for snapshots og oppbevaring.
• Sist verifiserte snapshot.
• Policy for godkjenning av restore.
• Trinn for validering av applikasjonen.
• Merknader om kompatibilitet mellom image og data.
• Policy for vekst og sletting.

Undersøk bruken regelmessig:

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

CPU, RAM og disk måles per minutt. Free-planen tilbyr $10 i startkreditt, mens den anbefalte Pro-planen koster $20 per måned med $20 i brukskreditt.

Øvelse i gjenoppretting av snapshot

Ikke vent på en hendelse før du oppdager at ingen vet hvilket snapshot som skal velges. Gjennomfør en kontrollert øvelse på en tjeneste som ikke er i produksjon, eller på en godkjent kopi:

1. Opprett testfiler som er enkle å kjenne igjen.
2. Ta et snapshot.
3. Endre filene.
4. Gjenopprett snapshotet.
5. Kontroller innhold og tilgangsrettigheter.
6. Observer at containeren starter på nytt.
7. Registrer tidsbruk og feilkilder.

En restore-øvelse gjør persistent volumes og snapshots fra en avkrysningsboks til en testet gjenopprettingsfunksjon.

For innledende tjenestedesign kan du se Fra Git repository til produksjon. Du finner detaljer om kommandoene i Dockup CLI-referansen.

Definer recovery objectives for fildata

Recovery point objective angir hvor mye nylige data virksomheten kan miste. Recovery time objective angir hvor lang tid gjenopprettingen kan ta. Et daglig snapshot med oppbevaring av sju kopier kan være tilstrekkelig for en intern mediecache, men ikke for et produkt med brukeropplastinger som lover nesten sanntids datalagring.

Dokumenter begge verdiene og test den faktiske gjenopprettingstiden. Hastigheten på oppretting av snapshot, datamengden, omstart av containeren, filvalidering og reindeksering av applikasjonen bidrar alle til gjenopprettingstiden.

Kontroller sletting og vekst av filer

Persistent lagring kan bli full fordi applikasjonen aldri fjerner midlertidige eller erstattede filer. Legg til en oppbevaringspolicy på applikasjonslaget, og skill mellom logisk sletting og umiddelbar fysisk sletting. Et kort gjenopprettingsvindu kan gjøre det fornuftig å utsette permanent sletting.

Før du kjører en omfattende opprydding:

1. Mål nåværende volumbruk.
2. Lag en liste over filer som kan slettes.
3. Ta et snapshot.
4. Kjør oppryddingen i avgrensede batcher.
5. Kontroller referanser fra applikasjonen.
6. Bekreft at forventet lagringsplass er frigjort.

Dette gir persistent volumes og snapshots en forebyggende rolle, ikke bare en rolle ved hendelser.

Kontroller snapshot-inventaret

Gå jevnlig gjennom snapshot-ID-er, opprettelsestidspunkter, oppbevaring og den siste vellykkede testen av gjenoppretting. En konfigurert jobb uten et nylig, brukbart snapshot er ikke et gjenopprettingssystem.

Tildel myndighet til å gjenopprette

Navngi hvem som kan godkjenne en gjenoppretting i produksjon, og hvem som gjennomfører valideringen etterpå. Når godkjenning og utførelse er adskilt, reduseres risikoen for at hastverk fører til at kontroll av mål og snapshot hoppes over.

Start med en deployment som kan verifiseres

Opprett ett volume utenfor produksjon, ta et snapshot, endre en testfil og fullfør en gjenopprettingsøvelse før du lagrer uerstattelige produksjonsdata.

Start gratis på app.dockup.ai. Free-planen koster $0 per måned, inkluderer $10 i startkreditt og støtter ett workspace, tre databaser og tre deployments.

Vanlige spørsmål

Overlever et Dockup-volume en deployment?

Ja. Volumet forblir persistent mens tjenestens containere erstattes, så lenge applikasjonen fortsatt bruker den konfigurerte mount path-en.

Er et volume-snapshot riktig sikkerhetskopi for PostgreSQL?

Nei. Et varmt snapshot av en databases datakatalog er kanskje ikke transaksjonskonsistent. For managed databaser bør du bruke systemet for sikkerhetskopiering av managed databaser.

Hva skjer når et volume-snapshot gjenopprettes?

Det nåværende innholdet i volumet erstattes med det valgte snapshotet, og containeren startes på nytt. Operasjonen bør derfor godkjennes og verifiseres.

Kan Dockup planlegge volume-snapshots?

Ja. Kommandoen for volume-planlegging støtter daglige snapshots med et antall kopier som skal beholdes, og planen kan deaktiveres eksplisitt.

Rulles volumet også tilbake når en applikasjon rulles tilbake?

Nei. Historikken for applikasjonsdeployments og historikken for volume-snapshots er separate. Koordiner dem bare når gjenopprettingsplanen krever det.