Persistent volumes og snapshots på Dockup

Persistent volumes og snapshots løser to forskellige problemer. Et volume bevarer filer, når containere udskiftes, eller når der deployes. Et snapshot registrerer volumet på et bestemt tidspunkt, så operatører senere kan undersøge, opbevare eller gendanne denne tilstand.

Containerens filsystem kan udskiftes. Alt, der skal overleve et deploy — uploads, genererede medier, indeks, package artifacts eller applikationsstyrede filer — skal ligge på en eksplicit persistent placering.

Hvilke applikationsdata hører hjemme i persistent storage?

Brug et volume, når applikationen ejer filer, som ikke uden videre eller sikkert kan genskabes fra en anden kilde.

Data	Volume?	Bedre alternativ, hvis det er muligt
Brugeruploads	Ja	Object storage, hvis arkitekturen bruger det
Genererede thumbnails	Måske	Generér dem igen ud fra originalerne
Søgeindeks	Måske	Genopbyg det fra kildedatabasen
Build artifacts	Normalt nej	Genopbyg under deployment
Applikationslogs	Normalt nej	Runtime-logsystem
PostgreSQL-datafolder	Ikke som et app-volume	Managed PostgreSQL
Midlertidig cache	Nej	Redis eller ephemeral storage
Lokal SQLite-produktionsdatabase	Risikabelt	Managed database til samtidighed og backups

Et volume bør have én tydelig ejer og én mount path. To uafhængige processer, der skriver til den samme mappe, gør gendannelse og analyse af rettigheder vanskeligere.

Før du tilføjer storage, skal du vurdere den oprindelige størrelse, vækstraten, kravene til opbevaring og recovery-målet. Diskforbruget måles mod planens saldo pr. minut, så ubrugt kapacitet og ukontrolleret filvækst koster.

Hvordan opretter og undersøger du et Dockup-volume?

Vis eksisterende volumes for den præcise service:

dockup volume list production/web --json

Tilføj et volume med et navn, en absolut containersti og en størrelse i gigabytes:

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

Applikationen skal skrive til /app/uploads. Skrivning til /uploads eller en anden lokal mappe omdirigerer ikke automatisk data til mountet.

Efter deployment skal du kontrollere, at applikationen skriver til den deklarerede absolutte mount path i stedet for containerens udskiftelige filsystem.

Undersøg det faktiske diskforbrug med det returnerede volume-id:

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

Sammenhold det faktiske forbrug med den tildelte størrelse og applikationens metrics. Opret alerts, før filsystemet er fuldt; et fuldt volume kan føre til delvise skrivninger, mislykkede uploads eller applikationsnedbrud.

Gennemgå forventningerne til file ownership. Containerens runtime-bruger skal kunne læse og skrive til mount path uden at få bredere rettigheder end nødvendigt.

Hvordan beskytter volume snapshots data?

Et on-demand-snapshot registrerer indholdet af et volume:

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

Vis tilgængelige snapshots:

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

Snapshots læser volumet på en read-only-måde og kræver ikke, at applikationen skriver til en særlig snapshot-mappe. De er nyttige før en risikabel fil-migrering, en omfattende omskrivning af medier eller en applikationsændring, der transformerer gemte data.

Et volume snapshot er ikke automatisk application-consistent. Hvis applikationen aktivt skriver flere relaterede filer, kan snapshottet indeholde dem fra lidt forskellige tidspunkter. For en managed database skal du bruge den managed databases backup-system i stedet for at tage snapshot af dens rå datafolder.

Definér, hvornår applikationen skal sættes i bero. En kort maintenance- eller skrivepause kan være passende før et snapshot af data med høj værdi. Registrér snapshot-id, årsag og det forventede restore point.

Hvordan bør retention af snapshots planlægges?

Vælg tidspunkt og retention for snapshots ud fra recovery-kravet og ikke ud fra vane. Opret et on-demand-snapshot før enhver risikabel fil-migrering, oprydning eller formatændring, og registrér det returnerede snapshot-id.

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

Recovery-behov	Snapshot-praksis	Begrænsning
Fortryd en fil-migrering	Tag snapshot umiddelbart før ændringen	Omfatter ikke senere skrivninger
Bevar historiske tidspunkter	Opbevar navngivne recovery points efter en fastlagt policy	Retention kræver løbende gennemgang
Beskyt hyppige skrivninger	Tilføj application-level backup, der passer til dataene	Et point-in-time-snapshot er ikke kontinuerlig beskyttelse
Lovpligtigt arkiv	Brug et dedikeret archive-workflow	Operationelle snapshots opfylder muligvis ikke kravene

Kontrollér, om de forventede snapshots faktisk findes. En nedskrevet retention-policy er ikke dokumentation for, at der blev oprettet et brugbart restore point.

Hvordan gendanner du et volume snapshot sikkert?

En gendannelse erstatter det aktuelle indhold i volumet og genstarter containeren:

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

Dette er en forstyrrende operation, der ændrer tilstanden. Før du gendanner:

1. Bekræft den præcise service, volume-id og snapshot-id.
2. Gør det klart, hvilke aktuelle filer der bliver erstattet.
3. Stop eller begræns nye skrivninger, hvor det er muligt.
4. Tag et nyt snapshot af den aktuelle tilstand, hvis den kan blive nødvendig.
5. Registrér kompatibilitet mellem applikation og schema.
6. Indhent eksplicit godkendelse til production.
7. Planlæg verifikation efter gendannelsen.

Efter gendannelsen skal du kontrollere containerens tilstand og applikationens funktion:

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

Test repræsentative filer, rettigheder, indeks og applikationsreferencer. En vellykket restore-kommando beviser, at snapshottet blev anvendt; den beviser ikke, at alle applikationsrecords peger på en gyldig fil.

Modellen i AI-agenters guardrails til production bør behandle restore som en operation, der kræver godkendelse, selvom det er en recovery-operation.

Hvordan bør volumes håndteres under deployment og rollback?

Et deployment erstatter applikationscontainere, mens det mountede volume forbliver. Det gør det muligt for et nyt image at se eksisterende filer, men skaber samtidig et krav om kompatibilitet.

En ny applikationsversion bør ikke transformere gemte filer irreversibelt, før versionen er afprøvet. Hvis den ændrer filformater eller mappestrukturer, skal du så vidt muligt bruge en migration, der kan genoptages og er bagudkompatibel.

Et application rollback kører et ældre deployment igen:

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

Volumet rulles ikke automatisk tilbage sammen med imaget. En ældre applikation kan muligvis ikke læse filer, som den nye version har transformeret. Koordinér image rollback med snapshot restore, men kun når begge dele er nødvendige og godkendt.

Denne adskillelse er vigtig:

Recovery-handling	Ændrer image?	Ændrer volumets data?
Deploy ny version	Ja	Nej, medmindre appen migrerer dem
Roll back deployment	Ja	Nej
Restore snapshot	Nej	Ja
Restore plus rollback	Ja	Ja

Processen for zero-downtime deployment beskytter trafikskiftet, men ikke kompatibiliteten mellem dataformater.

Hvad er en driftsrunbook for durable storage?

Tildel en ejer til hvert production-volume. Runbooken bør indeholde:

• Servicemål og volume-id.
• Mount path og forventet runtime-bruger.
• Tildelt størrelse og alert-grænse.
• Databeskrivelse og mulighed for genopbygning.
• Snapshot-plan og retention.
• Senest verificerede snapshot.
• Policy for godkendelse af restore.
• Trin til validering af applikationen.
• Noter om image- og datakompatibilitet.
• Policy for vækst og sletning.

Undersøg forbruget regelmæssigt:

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

CPU, RAM og disk måles pr. minut. Free-planen tilbyder $10 i startkredit, mens den anbefalede Pro-plan koster $20 om måneden og inkluderer $20 i usage credit.

Øvelse i snapshot restore

Vent ikke på en incident, før du opdager, at ingen ved, hvilket snapshot der skal vælges. Gennemfør en kontrolleret øvelse på en non-production-service eller en godkendt kopi:

1. Opret genkendelige testfiler.
2. Tag et snapshot.
3. Redigér filerne.
4. Gendan snapshottet.
5. Kontrollér indhold og rettigheder.
6. Observer containerens genstart.
7. Registrér tidsforbrug og fejlpunkter.

En restore-øvelse gør persistent volumes og snapshots til en afprøvet recovery-egenskab i stedet for blot et afkrydsningsfelt.

Se Fra Git repository til production for det indledende servicedesign. Brug Dockup CLI reference for oplysninger om kommandoerne.

Definér recovery-mål for fildata

Recovery point objective angiver, hvor meget af de seneste data virksomheden kan miste. Recovery time objective angiver, hvor lang tid en gendannelse må tage. Et dagligt snapshot med retention af syv kopier kan være tilstrækkeligt til en intern mediecache, men ikke til et produkt med user uploads, der lover durability tæt på realtid.

Dokumentér begge værdier, og test den faktiske restore-varighed. Hastigheden på snapshot-oprettelsen, datamængden, containerens genstart, filvalideringen og applikationens genindeksering bidrager alle til recovery-tiden.

Styr sletning og vækst af filer

Persistent storage kan blive fyldt, fordi applikationen aldrig fjerner midlertidige eller erstattede filer. Tilføj en retention-policy på applikationslaget, og skeln mellem logisk sletning og øjeblikkelig fysisk sletning. Et kort recovery-vindue kan gøre det relevant at udskyde permanent fjernelse.

Før du kører en omfattende oprydning:

1. Mål det aktuelle forbrug på volumet.
2. Udarbejd en liste over filer, der kan slettes.
3. Tag et snapshot.
4. Kør oprydningen i afgrænsede batches.
5. Kontrollér applikationsreferencer.
6. Bekræft, at den forventede plads er frigivet.

Det giver persistent volumes og snapshots en forebyggende rolle og ikke kun en rolle under incidents.

Kontrollér snapshot-inventaret

Gennemgå snapshot-id'er, oprettelsestidspunkter, retention og den seneste vellykkede restore-test efter en fast plan. Et konfigureret job uden et nyligt, brugbart snapshot er ikke et recovery-system.

Tildel rettigheder til restore

Navngiv, hvem der må godkende en production-restore, og hvem der udfører valideringen efter restore. Når godkendelse og udførelse er adskilt, er der mindre risiko for, at hastværk omgår verifikation af mål og snapshot.

Start med et deployment, der kan verificeres

Opret ét non-production-volume, tag et snapshot, ændr en testfil, og gennemfør en restore-øvelse, før du gemmer uerstattelige production-data.

Kom gratis i gang på app.dockup.ai. Free-planen koster $0 om måneden, inkluderer $10 i startkredit og understøtter ét workspace, tre databaser og tre deployments.

Ofte stillede spørgsmål

Overlever et Dockup-volume deployment?

Ja. Volumet forbliver persistent, mens servicecontainere udskiftes, så længe applikationen fortsat bruger den konfigurerede mount path.

Er et volume snapshot den rigtige backup til PostgreSQL?

Nej. Et hot snapshot af en databases datafolder er muligvis ikke transaktionskonsistent. Brug i stedet managed databases eget backup-system for managed databases.

Hvad sker der, når et volume snapshot gendannes?

Det aktuelle indhold i volumet erstattes af det valgte snapshot, og containeren genstartes. Derfor bør operationen godkendes og verificeres.

Kan Dockup planlægge volume snapshots?

Ja. Volume schedule-kommandoen understøtter daglige snapshots med et retention-antal, og planen kan deaktiveres eksplicit.

Rulles et volumes application også tilbage, når en applikation rulles tilbage?

Nej. Historikken for application deployment og historikken for volume snapshots er separate. Koordinér kun begge dele, når recovery-planen kræver det.