Volumi persistenti e snapshot su Dockup

Volumi persistenti e snapshot risolvono due problemi diversi. Un volume conserva i file quando un container viene sostituito o viene eseguito un deployment. Uno snapshot acquisisce il volume in un determinato momento, così gli operatori possono ispezionare, conservare o ripristinare quello stato in seguito.

Il filesystem del container è sostituibile. Tutto ciò che deve sopravvivere a un deploy—upload, media generati, indici, artifact dei package o file gestiti dall'applicazione—richiede un percorso persistente esplicito.

Quali dati dell'applicazione devono essere archiviati nello storage persistente?

Usa un volume quando l'applicazione gestisce file che non possono essere ricreati in modo economico o sicuro da un'altra origine.

Dati	Volume?	Alternativa migliore quando disponibile
Upload degli utenti	Sì	Object storage, se previsto dall'architettura
Thumbnail generate	Forse	Rigenerarle dagli originali
Indice di ricerca	Forse	Ricostruirlo dal database sorgente
Artifact di build	Di solito no	Ricostruirli durante il deployment
Log dell'applicazione	Di solito no	Sistema di log del runtime
Directory dei dati di PostgreSQL	Non come volume dell'applicazione	PostgreSQL gestito
Cache temporanea	No	Redis o storage effimero
Database SQLite locale in produzione	Rischioso	Database gestito per concorrenza e backup

Un volume dovrebbe avere un unico owner e un percorso di mount chiaro. Due processi non correlati che scrivono nella stessa directory rendono più difficili il ripristino e l'analisi dei permessi.

Prima di aggiungere storage, stima la dimensione iniziale, il tasso di crescita, i requisiti di retention e l'obiettivo di ripristino. Il disco viene conteggiato rispetto al saldo del piano ogni minuto, quindi la capacità inutilizzata e la crescita incontrollata dei file hanno un costo.

Come si crea e si ispeziona un volume Dockup?

Elenca i volumi esistenti per il servizio esatto:

dockup volume list production/web --json

Aggiungi un volume specificando un nome, un percorso assoluto nel container e la dimensione in gigabyte:

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

L'applicazione deve scrivere in /app/uploads. Scrivere in /uploads o in un'altra directory locale non reindirizza automaticamente i dati nel mount.

Dopo il deployment, verifica che l'applicazione scriva nel percorso assoluto di mount dichiarato, anziché nel filesystem sostituibile del container.

Controlla l'utilizzo effettivo del disco usando l'ID del volume restituito:

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

Confronta l'utilizzo reale con la dimensione allocata e le metriche dell'applicazione. Configura alert prima che il filesystem si riempia: un volume pieno può causare scritture parziali, upload non riusciti o crash dell'applicazione.

Verifica i requisiti relativi alla proprietà dei file. L'utente del runtime del container deve poter leggere e scrivere nel percorso di mount senza concedere permessi più ampi del necessario.

In che modo gli snapshot dei volumi proteggono i dati?

Uno snapshot on-demand acquisisce i contenuti del volume:

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

Elenca gli snapshot disponibili:

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

Gli snapshot leggono il volume in modalità di sola lettura e non richiedono che l'applicazione scriva in una directory speciale per gli snapshot. Sono utili prima di una migrazione rischiosa dei file, di una riscrittura massiva dei media o di una modifica dell'applicazione che trasformi i dati archiviati.

Uno snapshot del volume non garantisce automaticamente la coerenza applicativa. Se l'applicazione sta scrivendo attivamente diversi file correlati, lo snapshot può acquisirli in momenti leggermente diversi. Per un database gestito, usa il sistema di backup del database gestito invece di creare snapshot della sua directory dati grezza.

Definisci quando l'applicazione deve essere messa in pausa. Prima di uno snapshot importante può essere opportuno prevedere una breve finestra di manutenzione o una pausa delle scritture. Registra l'ID dello snapshot, il motivo e il punto di ripristino previsto.

Come va pianificata la retention degli snapshot?

Scegli tempistiche e retention degli snapshot in base ai requisiti di ripristino, non all'abitudine. Crea uno snapshot on-demand prima di ogni migrazione rischiosa dei file, operazione di pulizia o modifica del formato e registra l'ID restituito.

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

Esigenza di ripristino	Pratica per gli snapshot	Limitazione
Annullare una migrazione dei file	Crea subito uno snapshot prima della modifica	Non include le scritture successive
Conservare punti storici	Mantieni punti di ripristino etichettati secondo la policy	La retention richiede revisioni periodiche
Proteggere scritture frequenti	Aggiungi un backup a livello applicativo adeguato ai dati	Uno snapshot point-in-time non è una protezione continua
Archivio normativo	Usa un workflow di archiviazione dedicato	Gli snapshot operativi potrebbero non soddisfare la policy

Verifica che gli snapshot previsti esistano davvero. Una policy di retention scritta non dimostra che sia stato creato un punto di ripristino utilizzabile.

Come si ripristina in sicurezza uno snapshot del volume?

Un ripristino sostituisce i contenuti attuali del volume e riavvia il container:

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

Si tratta di un'operazione discontinua che modifica lo stato. Prima del ripristino:

1. Conferma il servizio, l'ID del volume e l'ID dello snapshot esatti.
2. Spiega quali file attuali verranno sostituiti.
3. Arresta o limita le nuove scritture, quando possibile.
4. Crea uno snapshot aggiornato dello stato corrente, se potrebbe servire in seguito.
5. Registra la compatibilità dell'applicazione e dello schema.
6. Ottieni un'approvazione esplicita per la produzione.
7. Pianifica le verifiche successive al ripristino.

Dopo il ripristino, verifica lo stato del container e il comportamento dell'applicazione:

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

Testa file rappresentativi, permessi, indici e riferimenti dell'applicazione. Un comando di ripristino eseguito con successo dimostra che lo snapshot è stato applicato, ma non dimostra che ogni record dell'applicazione punti a un file valido.

Il modello degli AI agent production guardrails dovrebbe trattare il ripristino come un'operazione soggetta ad approvazione, anche se si tratta di un'operazione di recovery.

Come devono comportarsi i volumi durante deployment e rollback?

Un deployment sostituisce i container dell'applicazione mentre il volume montato rimane invariato. Questo consente a una nuova image di vedere i file esistenti, ma introduce un vincolo di compatibilità.

Una nuova versione dell'applicazione non dovrebbe trasformare irreversibilmente i file archiviati prima che la release sia stata verificata. Se modifica i formati dei file o la struttura delle directory, usa una migrazione riprendibile e, quando possibile, retrocompatibile.

Il rollback dell'applicazione esegue nuovamente un deployment precedente:

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

Il volume non viene sottoposto automaticamente a rollback insieme all'image. Una versione precedente dell'applicazione potrebbe non riuscire a leggere file trasformati dalla nuova versione. Coordina il rollback dell'image con il ripristino dello snapshot solo quando entrambi sono necessari e approvati.

Questa distinzione è importante:

Azione di ripristino	Modifica l'image?	Modifica i dati del volume?
Eseguire il deploy di una nuova versione	Sì	No, a meno che l'applicazione non li migri
Eseguire il rollback del deployment	Sì	No
Ripristinare uno snapshot	No	Sì
Ripristinare e fare rollback	Sì	Sì

Il processo di deployment senza downtime protegge il passaggio del traffico, non la compatibilità dei formati dei dati.

Che cos'è un runbook operativo per lo storage durevole?

Assegna un owner a ogni volume di produzione. Il runbook dovrebbe contenere:

• Target del servizio e ID del volume.
• Percorso di mount e utente del runtime previsto.
• Dimensione allocata e soglia di alert.
• Descrizione dei dati e possibilità di ricostruzione.
• Pianificazione e retention degli snapshot.
• Ultimo snapshot verificato.
• Policy di approvazione dei ripristini.
• Passaggi di validazione dell'applicazione.
• Note sulla compatibilità tra image e dati.
• Policy di crescita ed eliminazione.

Controlla regolarmente l'utilizzo:

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

CPU, RAM e disco vengono misurati ogni minuto. Il piano Free offre un credito iniziale di $10, mentre il piano Pro consigliato costa $20 al mese e include $20 di credito per l'utilizzo.

Esercitazione sul ripristino di uno snapshot

Non aspettare un incidente per scoprire che nessuno sa quale snapshot scegliere. Esegui un'esercitazione controllata su un servizio non di produzione o su una copia approvata:

1. Crea file di test facilmente riconoscibili.
2. Crea uno snapshot.
3. Modifica i file.
4. Ripristina lo snapshot.
5. Verifica contenuti e permessi.
6. Osserva il riavvio del container.
7. Registra tempistiche e punti di errore.

Un'esercitazione di ripristino trasforma i volumi persistenti e gli snapshot da semplice voce di checklist a funzionalità di recovery verificata.

Per la progettazione iniziale del servizio, consulta Dal repository Git alla produzione. Per i dettagli sui comandi, usa il riferimento della Dockup CLI.

Definisci gli obiettivi di ripristino per i dati dei file

Il recovery point objective indica quanti dati recenti l'azienda può perdere. Il recovery time objective indica quanto può durare il ripristino. Uno snapshot giornaliero con retention di sette copie può essere sufficiente per una cache multimediale interna, ma non per un prodotto che gestisce upload degli utenti e promette una durabilità quasi in tempo reale.

Documenta entrambi i valori e verifica la durata effettiva del ripristino. La velocità di creazione dello snapshot, la dimensione dei dati, il riavvio del container, la validazione dei file e la reindicizzazione dell'applicazione contribuiscono tutti al tempo di ripristino.

Controlla l'eliminazione e la crescita dei file

Lo storage persistente può riempirsi perché l'applicazione non elimina mai i file temporanei o sostituiti. Aggiungi una policy di retention a livello applicativo e distingui l'eliminazione logica dalla cancellazione fisica immediata. Una breve finestra di recovery può giustificare il rinvio della rimozione definitiva.

Prima di eseguire una pulizia massiva:

1. Misura l'utilizzo attuale del volume.
2. Genera un elenco dei file candidati all'eliminazione.
3. Crea uno snapshot.
4. Esegui la pulizia in batch di dimensioni limitate.
5. Verifica i riferimenti dell'applicazione.
6. Conferma il recupero di spazio previsto.

In questo modo i volumi persistenti e gli snapshot assumono un ruolo preventivo, non solo legato agli incidenti.

Verifica l'inventario degli snapshot

Controlla periodicamente gli ID degli snapshot, gli orari di creazione, la retention e l'ultimo test di ripristino completato con successo. Un job configurato senza uno snapshot recente e utilizzabile non costituisce un sistema di recovery.

Assegna l'autorità sui ripristini

Indica chi può approvare un ripristino in produzione e chi esegue la validazione successiva. Separare l'approvazione dall'esecuzione riduce il rischio che l'urgenza faccia saltare la verifica del target e dello snapshot.

Inizia con un deployment verificabile

Crea un volume non di produzione, crea uno snapshot, modifica un file di test e completa un'esercitazione di ripristino prima di archiviare dati di produzione irrecuperabili.

Inizia gratuitamente su app.dockup.ai. Il piano Free costa $0 al mese, include un credito iniziale di $10 e supporta un workspace, tre database e tre deployment.

FAQ

Un volume Dockup sopravvive al deployment?

Sì. Il volume rimane persistente mentre i container del servizio vengono sostituiti, purché l'applicazione continui a utilizzare il percorso di mount configurato.

Uno snapshot del volume è il backup corretto per PostgreSQL?

No. Uno snapshot a caldo della directory dati di un database potrebbe non essere coerente a livello transazionale. Per i database gestiti, preferisci il sistema di backup del database gestito.

Cosa succede quando viene ripristinato uno snapshot del volume?

I contenuti attuali del volume vengono sostituiti con quelli dello snapshot selezionato e il container viene riavviato; l'operazione deve quindi essere approvata e verificata.

Dockup può pianificare gli snapshot dei volumi?

Sì. Il comando di pianificazione dei volumi supporta snapshot giornalieri con un numero di copie da conservare e la pianificazione può essere disabilitata esplicitamente.

Il rollback di un'applicazione esegue anche il rollback del volume?

No. La cronologia dei deployment dell'applicazione e quella degli snapshot del volume sono separate. Coordinale entrambe solo quando il piano di recovery lo richiede.