Beständiga volymer och snapshots på Dockup

Beständiga volymer och snapshots löser två olika problem. En volym bevarar filer när containrar byts ut och nya deploymentar görs. En snapshot fångar volymen vid en viss tidpunkt så att operatörer senare kan inspektera, behålla eller återställa det tillståndet.

Containerfilsystemet kan bytas ut. Allt som måste överleva en deployment – uppladdningar, genererat media, index, package artifacts eller applikationshanterade filer – behöver en uttryckligt beständig plats.

Vilka applikationsdata hör hemma på beständig lagring?

Använd en volym när applikationen äger filer som inte kan återskapas billigt eller säkert från en annan källa.

Data	Volym?	Bättre alternativ när det finns
Användaruppladdningar	Ja	Object storage om arkitekturen använder det
Genererade thumbnails	Kanske	Generera om från originalen
Search index	Kanske	Bygg om från källdatabasen
Build artifacts	Vanligtvis nej	Bygg om under deployment
Applikationsloggar	Vanligtvis nej	Runtime-loggsystem
PostgreSQL-data directory	Inte som en appvolym	Managed PostgreSQL
Tillfällig cache	Nej	Redis eller ephemeral storage
Lokal SQLite-produktionsdatabas	Riskabelt	Managed database för concurrency och backups

En volym bör ha en tydlig ägare och mount-sökväg. Två orelaterade processer som skriver till samma directory gör recovery och permissionsanalys svårare.

Innan du lägger till storage bör du uppskatta initial storlek, tillväxttakt, retentionkrav och recoverymål. Disk mäts mot planens saldo per minut, så outnyttjad kapacitet och okontrollerad filstorlek har en kostnad.

Hur skapar och inspekterar du en Dockup-volym?

Lista befintliga volymer för den exakta tjänsten:

dockup volume list production/web --json

Lägg till en volym med namn, absolut sökväg i containern och storlek i gigabyte:

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

Applikationen måste skriva till /app/uploads. Att skriva till /uploads eller en annan lokal directory omdirigerar inte automatiskt till mounten.

Efter deployment ska du verifiera att applikationen skriver till den deklarerade absoluta mount-sökvägen i stället för till det utbytbara containerfilsystemet.

Inspektera faktisk disk-användning med det returnerade volym-ID:t:

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

Jämför faktisk användning med den allokerade storleken och applikationsmätvärdena. Skapa alerts innan filsystemet blir fullt; en full volym kan orsaka ofullständiga writes, misslyckade uppladdningar eller applikationskrascher.

Kontrollera förväntat filägarskap. Containerns runtime-användare måste kunna läsa och skriva till mount-sökvägen utan att du ger bredare behörigheter än vad som krävs.

Hur skyddar volume snapshots data?

En snapshot som skapas on demand fångar volymens innehåll:

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

Lista tillgängliga snapshots:

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

Snapshots läser volymen read-only och kräver inte att applikationen skriver till en särskild snapshot-directory. De är användbara före en riskfylld filmigration, en omfattande omskrivning av media eller en applikationsändring som transformerar lagrade data.

En volume snapshot är inte automatiskt application-consistent. Om applikationen aktivt skriver flera relaterade filer kan snapshoten fånga dem vid något olika tidpunkter. För en managed database ska du använda det hanterade databassystemets backup i stället för att ta en snapshot av dess råa data directory.

Definiera när applikationen ska quiescas. En kort maintenance- eller write-paus kan vara lämplig före en snapshot av högt värde. Dokumentera snapshot-ID, orsak och förväntad restore point.

Hur bör snapshot retention planeras?

Välj tidpunkter och retention för snapshots utifrån recoverykravet, inte av vana. Skapa en snapshot on demand före varje riskfylld filmigration, cleanup eller formatändring och dokumentera det returnerade snapshot-ID:t.

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

Recoverybehov	Snapshot-praxis	Begränsning
Ångra en filmigration	Skapa en snapshot direkt före ändringen	Inkluderar inte senare writes
Bevara historiska tidpunkter	Behåll märkta recovery points enligt policy	Retention kräver aktiv granskning
Skydda frekventa writes	Lägg till en applikationsnivå-backup som passar datan	En point-in-time-snapshot är inte kontinuerligt skydd
Arkiv för regelefterlevnad	Använd ett dedikerat arkiveringsflöde	Operativa snapshots kanske inte uppfyller policyn

Kontrollera att förväntade snapshots faktiskt finns. En dokumenterad retentionpolicy är inget bevis på att en användbar restore point har skapats.

Hur återställer du en volume snapshot säkert?

En återställning ersätter den aktuella volymens innehåll och startar om containern:

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

Detta är en störande operation som ändrar tillstånd. Före återställningen:

1. Bekräfta exakt tjänst, volym-ID och snapshot-ID.
2. Förklara vilka aktuella filer som kommer att ersättas.
3. Stoppa eller begränsa nya writes där det är möjligt.
4. Ta en färsk snapshot av det aktuella tillståndet om det kan behövas.
5. Dokumentera applikations- och schemakompatibilitet.
6. Skaffa uttryckligt produktionsgodkännande.
7. Planera verifiering efter återställningen.

Efter återställningen ska du verifiera containerns tillstånd och applikationens beteende:

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

Testa representativa filer, permissions, index och applikationsreferenser. Ett lyckat restore-kommando bevisar att snapshoten tillämpades; det bevisar inte att varje applikationspost pekar på en giltig fil.

Modellen för guardrails för AI-agenter i produktion bör behandla restore som en operation som kräver godkännande, även om det är en recovery-operation.

Hur bör volymer fungera under deployment och rollback?

En deployment ersätter applikationscontainrar medan den mountade volymen finns kvar. Det gör att en ny image kan se befintliga filer, men skapar samtidigt ett kompatibilitetskrav.

En ny applikationsversion bör inte irreversibelt transformera lagrade filer innan releasen är bekräftad. Om den ändrar filformat eller directory-strukturer ska du använda en migration som kan återupptas och som är bakåtkompatibel när det är möjligt.

En application rollback kör om en äldre deployment:

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

Volymen rullas inte automatiskt tillbaka tillsammans med imagen. En äldre applikation kanske inte kan läsa filer som transformerats av den nya versionen. Samordna image rollback med snapshot restore endast när båda krävs och har godkänts.

Denna åtskillnad är viktig:

Recovery-åtgärd	Ändrar image?	Ändrar volymdata?
Deploya ny version	Ja	Nej, om inte appen migrerar dem
Rulla tillbaka deployment	Ja	Nej
Återställa snapshot	Nej	Ja
Återställa och rulla tillbaka	Ja	Ja

Processen för deployment utan downtime skyddar trafikväxlingen, inte kompatibilitet för dataformat.

Vad är en runbook för drift av beständig lagring?

Utse en ägare för varje produktionsvolym. Runbooken bör innehålla:

• Tjänstens target och volym-ID.
• Mount-sökväg och förväntad runtime-användare.
• Allokerad storlek och alerttröskel.
• Databeskrivning och möjlighet att bygga om datan.
• Snapshot-schema och retention.
• Senast verifierade snapshot.
• Policy för restore-godkännande.
• Steg för applikationsvalidering.
• Kompatibilitetsanteckningar för image och data.
• Policy för tillväxt och borttagning.

Inspektera användningen regelbundet:

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

CPU, RAM och disk mäts per minut. Free-planen erbjuder $10 i startkredit, medan den rekommenderade Pro-planen kostar $20 per månad med $20 i användningskredit.

Övning i snapshot-återställning

Vänta inte på en incident innan du upptäcker att ingen vet vilken snapshot som ska väljas. Genomför en kontrollerad övning på en icke-produktions-tjänst eller en godkänd kopia:

1. Skapa igenkännbara testfiler.
2. Ta en snapshot.
3. Ändra filerna.
4. Återställ snapshoten.
5. Verifiera innehåll och permissions.
6. Observera om containern startas om.
7. Dokumentera tidsåtgång och felpunkter.

En restore-övning förvandlar beständiga volymer och snapshots från en punkt på en checklista till en testad recovery-förmåga.

För initial tjänstedesign, se Från Git repository till produktion. För kommandodetaljer, använd Dockup CLI reference.

Definiera recoverymål för fildata

Recovery point objective anger hur mycket nyliga data verksamheten kan förlora. Recovery time objective anger hur lång tid en återställning får ta. En daglig snapshot med retention för sju kopior kan vara tillräcklig för en intern mediacache, men inte för en produkt med användaruppladdningar som lovar near-real-time durability.

Dokumentera båda värdena och testa den faktiska restore-tiden. Hastigheten för att skapa snapshoten, datamängden, omstarten av containern, filvalideringen och applikationens omindexering bidrar alla till recovery-tiden.

Kontrollera borttagning och tillväxt av filer

Beständig lagring kan fyllas eftersom applikationen aldrig tar bort tillfälliga eller ersatta filer. Lägg till en retentionpolicy på applikationsnivå och skilj logisk borttagning från omedelbar fysisk borttagning. Ett kort recovery-fönster kan motivera att permanent borttagning fördröjs.

Innan du kör en omfattande cleanup:

1. Mät aktuell volymanvändning.
2. Ta fram en lista över filer som kan tas bort.
3. Ta en snapshot.
4. Kör cleanup i avgränsade batcher.
5. Verifiera applikationsreferenser.
6. Bekräfta att förväntat utrymme har frigjorts.

Detta ger beständiga volymer och snapshots en förebyggande roll, inte bara en roll vid incidenter.

Verifiera snapshot-inventeringen

Granska snapshot-ID:n, skapandetider, retention och det senaste lyckade restore-testet enligt ett schema. Ett konfigurerat jobb utan någon nylig användbar snapshot är inte ett recovery-system.

Tilldela behörighet för restore

Utse vem som får godkänna en restore i produktion och vem som genomför valideringen efteråt. Att skilja godkännande från utförande minskar risken för att brådska kringgår verifiering av target och snapshot.

Börja med en verifierbar deployment

Skapa en icke-produktionsvolym, ta en snapshot, ändra en testfil och genomför en restore-övning innan du lagrar oersättliga produktionsdata.

Starta gratis på app.dockup.ai. Free-planen kostar $0 per månad, inkluderar $10 i startkredit och stöder en workspace, tre databaser och tre deploymentar.

FAQ

Överlever en Dockup-volym en deployment?

Ja. Volymen förblir beständig medan tjänstens containrar byts ut, förutsatt att applikationen fortsätter att använda den konfigurerade mount-sökvägen.

Är en volume snapshot rätt backup för PostgreSQL?

Nej. En hot snapshot av en databas data directory kanske inte är transaktionskonsistent. Föredra det hanterade databassystemets backup för managed databases.

Vad händer när en volume snapshot återställs?

Den aktuella volymens innehåll ersätts med den valda snapshoten och containern startas om, så operationen bör godkännas och verifieras.

Kan Dockup schemalägga volume snapshots?

Ja. Volume schedule-kommandot stöder dagliga snapshots med ett retention-antal, och schemat kan inaktiveras uttryckligen.

Rullas volymen också tillbaka när en applikation rullas tillbaka?

Nej. Historiken för applikationsdeploymentar och historiken för volume snapshots är separata. Samordna dem endast när recovery-planen kräver det.