Persistente volumes en snapshots op Dockup

Persistente volumes en snapshots lossen twee verschillende problemen op. Een volume bewaart bestanden wanneer containers worden vervangen en deployments worden uitgevoerd. Een snapshot legt het volume op een bepaald moment vast, zodat operators die toestand later kunnen inspecteren, bewaren of herstellen.

Het bestandssysteem van een container kan worden vervangen. Alles wat een deployment moet overleven—uploads, gegenereerde media, indexen, package-artifacts of bestanden die door de applicatie worden beheerd—heeft een expliciete persistente locatie nodig.

Welke applicatiedata hoort op persistente opslag?

Gebruik een volume wanneer de applicatie bestanden beheert die niet goedkoop of veilig vanuit een andere bron kunnen worden gerecreëerd.

Data	Volume?	Beter alternatief indien beschikbaar
Gebruikersuploads	Ja	Object storage als de architectuur dit gebruikt
Gegenereerde thumbnails	Misschien	Opnieuw genereren vanuit originelen
Search-index	Misschien	Opnieuw opbouwen vanuit de brondatabase
Build-artifacts	Meestal niet	Opnieuw opbouwen tijdens de deployment
Applicatielogs	Meestal niet	Runtime-logsysteem
PostgreSQL-datadirectory	Niet als app-volume	Managed PostgreSQL
Tijdelijke cache	Nee	Redis of ephemeral storage
Lokale SQLite-productiedatabase	Riskant	Managed database voor concurrency en back-ups

Een volume moet één duidelijke eigenaar en één mountpad hebben. Twee niet-gerelateerde processen die naar dezelfde directory schrijven, maken herstel en analyse van permissies moeilijker.

Schat vóór je opslag toevoegt de initiële omvang, groeisnelheid, bewaartermijn en recoverydoelstelling. Schijfruimte wordt elke minuut verrekend met het plansaldo, dus ongebruikte capaciteit en onbeheerde bestandsgroei hebben een kostprijs.

Hoe maak en inspecteer je een Dockup-volume?

Bekijk de bestaande volumes voor de exacte service:

dockup volume list production/web --json

Voeg een volume toe met een naam, een absoluut containerpad en een omvang in gigabytes:

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

De applicatie moet naar /app/uploads schrijven. Schrijven naar /uploads of een andere lokale directory leidt niet automatisch naar de mount.

Controleer na de deployment of de applicatie naar het opgegeven absolute mountpad schrijft en niet naar het vervangbare bestandssysteem van de container.

Controleer het werkelijke schijfgebruik met de geretourneerde volume-ID:

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

Vergelijk het werkelijke gebruik met de toegewezen omvang en de applicatiemetrics. Stel een alert in voordat het bestandssysteem vol raakt; een vol volume kan gedeeltelijke writes, mislukte uploads of applicatiecrashes veroorzaken.

Controleer de verwachtingen rond bestandseigenaarschap. De runtimegebruiker van de container moet het mountpad kunnen lezen en beschrijven zonder ruimere permissies toe te kennen dan nodig.

Hoe beschermen volumesnapshots data?

Een on-demand snapshot legt de inhoud van het volume vast:

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

Bekijk de beschikbare snapshots:

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

Snapshots lezen het volume op een alleen-lezenmanier en vereisen niet dat de applicatie naar een speciale snapshotdirectory schrijft. Ze zijn nuttig vóór een risicovolle bestandsmigratie, een bulkbewerking van media of een applicatiewijziging die opgeslagen data transformeert.

Een volumesnapshot is niet automatisch consistent op applicatieniveau. Als de applicatie actief meerdere gerelateerde bestanden schrijft, kan de snapshot deze op iets verschillende momenten vastleggen. Gebruik voor een managed database het back-upsysteem van de managed database in plaats van een snapshot van de onbewerkte datadirectory.

Bepaal wanneer de applicatie moet worden stilgelegd. Een korte maintenance- of write-pauze kan passend zijn vóór een snapshot van hoge waarde. Leg de snapshot-ID, de reden en het verwachte herstelpunt vast.

Hoe plan je snapshotretentie?

Kies het tijdstip en de retentie van snapshots op basis van de recoveryvereisten, niet uit gewoonte. Maak vóór elke risicovolle bestandsmigratie, cleanup of formaatwijziging een on-demand snapshot en leg de geretourneerde snapshot-ID vast.

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

Recoverybehoefte	Snapshotpraktijk	Beperking
Een bestandsmigratie ongedaan maken	Maak direct vóór de wijziging een snapshot	Bevat geen latere writes
Historische momenten bewaren	Bewaar gelabelde herstelpunten volgens het beleid	Retentie moet actief worden gecontroleerd
Frequente writes beschermen	Voeg een back-up op applicatieniveau toe die past bij de data	Een point-in-time snapshot biedt geen continue bescherming
Archief voor regelgeving	Gebruik een speciale archiveringsworkflow	Operationele snapshots voldoen mogelijk niet aan het beleid

Controleer of de verwachte snapshots daadwerkelijk bestaan. Een vastgelegd retentiebeleid bewijst niet dat er een bruikbaar herstelpunt is aangemaakt.

Hoe herstel je een volumesnapshot veilig?

Een herstelactie vervangt de huidige inhoud van het volume en start de container opnieuw:

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

Dit is een verstorende operatie die de status wijzigt. Controleer vóór je herstelt het volgende:

1. Bevestig de exacte service, volume-ID en snapshot-ID.
2. Leg uit welke huidige bestanden worden vervangen.
3. Stop nieuwe writes of beperk deze waar mogelijk.
4. Maak een verse snapshot van de huidige toestand als die mogelijk nodig is.
5. Leg de compatibiliteit van de applicatie en het schema vast.
6. Verkrijg expliciete goedkeuring voor productie.
7. Plan controles na het herstel.

Controleer na het herstel de status van de container en het gedrag van de applicatie:

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

Test representatieve bestanden, permissies, indexen en verwijzingen vanuit de applicatie. Een geslaagde restore-opdracht bewijst dat de snapshot is toegepast; niet dat elke applicatierecord naar een geldig bestand verwijst.

Het model voor production guardrails voor AI-agents moet herstelacties behandelen als acties waarvoor goedkeuring nodig is, ook al gaat het om een recovery-operatie.

Hoe moeten volumes zich gedragen tijdens een deployment en rollback?

Bij een deployment worden applicatiecontainers vervangen terwijl het gemounte volume blijft bestaan. Daardoor kan een nieuwe image bestaande bestanden zien, maar dit brengt een compatibiliteitsverplichting met zich mee.

Een nieuwe applicatieversie mag opgeslagen bestanden niet onomkeerbaar transformeren voordat de release is bewezen. Als de versie bestandsformaten of directorystructuren wijzigt, gebruik dan waar mogelijk een migratie die hervatbaar en backward compatible is.

Bij een applicatie-rollback wordt een oudere deployment opnieuw uitgevoerd:

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

Het volume wordt niet automatisch teruggedraaid met de image. Een oudere applicatie kan bestanden die door de nieuwe versie zijn getransformeerd niet meer lezen. Combineer een image-rollback alleen met het herstellen van een snapshot wanneer beide nodig en goedgekeurd zijn.

Deze scheiding is belangrijk:

Recoveryactie	Wijzigt image?	Wijzigt volumedata?
Nieuwe versie deployen	Ja	Nee, tenzij de app deze migreert
Deployment terugdraaien	Ja	Nee
Snapshot herstellen	Nee	Ja
Herstel plus rollback	Ja	Ja

Het proces voor zero-downtime deployments beschermt de omschakeling van verkeer, niet de compatibiliteit van dataformaten.

Wat staat er in een runbook voor duurzaam storagebeheer?

Wijs voor elk productievolume een eigenaar aan. Het runbook moet het volgende bevatten:

• Servicedoel en volume-ID.
• Mountpad en verwachte runtimegebruiker.
• Toegewezen omvang en alertdrempel.
• Databeschrijving en mogelijkheid tot opnieuw opbouwen.
• Snapshotschema en retentie.
• Laatst geverifieerde snapshot.
• Beleid voor goedkeuring van herstelacties.
• Validatiestappen voor de applicatie.
• Notities over de compatibiliteit van image en data.
• Beleid voor groei en verwijdering.

Controleer het gebruik regelmatig:

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

CPU, RAM en schijfruimte worden per minuut gemeten. Het Free-plan biedt een starttegoed van $10, terwijl het aanbevolen Pro-plan $20 per maand kost met $20 gebruikstegoed.

Oefening voor het herstellen van een snapshot

Wacht niet op een incident om te ontdekken dat niemand weet welke snapshot moet worden gekozen. Voer een gecontroleerde oefening uit op een niet-productieservice of een goedgekeurde kopie:

1. Maak herkenbare testbestanden.
2. Maak een snapshot.
3. Wijzig de bestanden.
4. Herstel de snapshot.
5. Controleer de inhoud en permissies.
6. Observeer het opnieuw starten van de container.
7. Leg de doorlooptijd en foutpunten vast.

Een restore-oefening maakt van persistente volumes en snapshots geen vinkje op een checklist, maar een geteste recoverymogelijkheid.

Zie voor het initiële serviceontwerp Van Git-repository naar productie. Gebruik voor commando-informatie de Dockup CLI-referentie.

Definieer recoverydoelstellingen voor bestandsdata

De recovery point objective geeft aan hoeveel recente data het bedrijf kan verliezen. De recovery time objective geeft aan hoe lang herstel mag duren. Een dagelijkse snapshot met een retentie van zeven kopieën kan volstaan voor een interne mediacache, maar niet voor een product met gebruikersuploads dat bijna realtime duurzaamheid belooft.

Documenteer beide waarden en test de werkelijke hersteltijd. De snelheid waarmee de snapshot wordt gemaakt, de omvang van de data, het opnieuw starten van de container, bestandsvalidatie en het opnieuw indexeren van de applicatie dragen allemaal bij aan de hersteltijd.

Beheer het verwijderen en groeien van bestanden

Persistente opslag kan vollopen omdat de applicatie tijdelijke of vervangen bestanden nooit verwijdert. Voeg op applicatieniveau een retentiebeleid toe en maak onderscheid tussen logische verwijdering en onmiddellijke fysieke verwijdering. Een korte recoveryperiode kan het rechtvaardigen om definitieve verwijdering uit te stellen.

Voordat je een bulk-cleanup uitvoert:

1. Meet het huidige volumegebruik.
2. Stel een lijst op met bestanden die kunnen worden verwijderd.
3. Maak een snapshot.
4. Voer de cleanup uit in begrensde batches.
5. Controleer de verwijzingen vanuit de applicatie.
6. Bevestig dat de verwachte ruimte is vrijgekomen.

Zo krijgen persistente volumes en snapshots niet alleen een rol tijdens incidenten, maar ook een preventieve rol.

Controleer de snapshotinventaris

Controleer volgens een vast schema de snapshot-ID's, aanmaaktijden, retentie en de laatst geslaagde restore-test. Een geconfigureerde job zonder recente bruikbare snapshot is geen recovery-systeem.

Wijs bevoegdheden voor herstel toe

Leg vast wie een herstelactie in productie mag goedkeuren en wie de validatie na het herstel uitvoert. Door goedkeuring en uitvoering te scheiden, verklein je de kans dat urgentie ertoe leidt dat de controle van doel en snapshot wordt overgeslagen.

Begin met een verifieerbare deployment

Maak één volume voor niet-productie, maak een snapshot, wijzig een testbestand en voltooi een restore-oefening voordat je onvervangbare productiedata opslaat.

Start gratis op app.dockup.ai. Het Free-plan kost $0 per maand, bevat $10 starttegoed en ondersteunt één workspace, drie databases en drie deployments.

FAQ

Blijft een Dockup-volume bestaan na een deployment?

Ja. Het volume blijft persistent terwijl servicecontainers worden vervangen, zolang de applicatie het geconfigureerde mountpad blijft gebruiken.

Is een volumesnapshot de juiste back-up voor PostgreSQL?

Nee. Een hot snapshot van een datadirectory van een database is mogelijk niet transactioneel consistent. Geef bij managed databases de voorkeur aan het back-upsysteem van de managed database.

Wat gebeurt er wanneer een volumesnapshot wordt hersteld?

De huidige inhoud van het volume wordt vervangen door de geselecteerde snapshot en de container wordt opnieuw gestart. Daarom moet de operatie worden goedgekeurd en geverifieerd.

Kan Dockup volumesnapshots inplannen?

Ja. Het volume schedule-commando ondersteunt dagelijkse snapshots met een retentieaantal en het schema kan expliciet worden uitgeschakeld.

Wordt het volume ook teruggedraaid wanneer je een applicatie terugdraait?

Nee. De deploymentgeschiedenis van de applicatie en de snapshotgeschiedenis van het volume staan los van elkaar. Coördineer beide alleen wanneer het recoveryplan dat vereist.