Archiviazione persistente, add-on e volumi
I container possono essere sostituiti durante un deploy, una nuova build o un riavvio. I file salvati solo nel livello temporaneo scrivibile del container possono quindi andare persi. Usa un volume persistente per i file che l’applicazione deve conservare, oppure un add-on gestito per database e oggetti. Consulta la guida PaaS e la pagina dei container cloud .
Scegli il tipo di archiviazione
- Volumi persistenti: conserva upload, file multimediali e altri dati in un percorso montato nel servizio. Il percorso di montaggio deve corrispondere a quello in cui scrive l’applicazione.
- Add-on gestiti: usa un database o un servizio gestito, come PostgreSQL, Redis, MinIO, RabbitMQ, MariaDB o MongoDB, se il relativo modello di dati è adatto alla tua applicazione. Gli add-on hanno un ciclo di vita autonomo e si collegano ai servizi tramite variabili generate. Consulta la pagina dei database cloud .
Add-on gestiti
Un add-on viene eseguito separatamente dal servizio applicativo. Collegandolo al servizio, ricevi variabili con i dati di connessione, come DATABASE_URL o REDIS_URL. Usa add-on distinti per produzione e test quando i dati dei due ambienti devono restare separati.
Crea l’add-on nell’ambiente corretto
Prima di collegarlo, controlla il nome, il tipo, la versione e l’ambiente del progetto.
Collegalo al servizio
Seleziona l’add-on nelle impostazioni del servizio e configura l’applicazione perché legga i nomi delle variabili forniti.
Controlla la connessione ed esegui le migrazioni
Verifica che l’applicazione si connetta controllando i log runtime. Esegui le migrazioni dello schema in modo controllato; evita che più repliche eseguano la stessa migrazione contemporaneamente, a meno che lo strumento non lo gestisca in sicurezza.
Controlla i backup disponibili e prova un ripristino
Per gli add-on gestiti supportati, apri la sezione Backup dell’add-on per consultare gli snapshot notturni disponibili e lo stato dei ripristini. Il pannello permette di ripristinare gli add-on PostgreSQL, MariaDB e MongoDB; per altri tipi potresti vedere i backup senza avere questo comando di ripristino. Prima di procedere, controlla la data dello snapshot: il ripristino sostituisce i dati attuali. Quando possibile, prova il recupero su una copia non di produzione e conserva separatamente gli eventuali backup aggiuntivi su cui fai affidamento.
Per alcuni add-on gestiti sono disponibili snapshot notturni. Verifica che il backup sia presente e che la procedura di recupero funzioni: lo snapshot da solo non lo garantisce. Il ripristino sovrascrive i dati attuali; controlla la conferma e lo stato dell’operazione nel pannello.
Volumi persistenti
Un volume monta l’archiviazione persistente nel servizio, in un percorso come /app/uploads o /var/www/html/wp-content/uploads. Durante un normale deploy o riavvio, la sostituzione del container è progettata per lasciare disponibili i dati del volume. L’eliminazione del servizio o del volume può cancellare quei dati: conserva quindi una copia separata dei file importanti.
La piattaforma gestisce la capacità del volume: all’inizio è ridotta e può aumentare man mano che lo spazio si riempie. Non puoi scegliere una dimensione personalizzata nelle impostazioni del servizio. La crescita rispetta sia il limite del servizio sia il limite totale di archiviazione del pacchetto nella zona. Hobby include 10 GB totali per pacchetto di zona, Pro 40 GB. Sono limiti condivisi, non una quota aggiuntiva per ogni servizio. Pianifica i volumi entro i limiti del pacchetto accettato.
Esplora e trasferisci i file del volume con la CLI
La CLI permette di esplorare le cartelle e trasferisce singoli file. Se il servizio ha più volumi, selezionane uno indicando il percorso di montaggio o l’ID.
# Elenca i file nel percorso montato; ometti il percorso per mostrare la radice
deplomo service files my-app /app/uploads
# Scarica un singolo file dal volume
deplomo service pull -o ./photo.jpg my-app /app/uploads/photo.jpg
# Carica un singolo file locale in una cartella del volume
deplomo service push --dir /app/uploads my-app ./photo.jpg
# Seleziona un volume specifico quando il servizio ne ha più di uno
deplomo service files --volume /app/uploads my-app /app/uploadsOgni comando pull o push trasferisce un solo file. Per una raccolta di file numerosa o per un database, usa una procedura di backup e ripristino adatta all’applicazione. La gestione file della CLI non crea snapshot del volume né backup completi del servizio.
Prima di spostare o eliminare file, arresta il processo che li scrive e conserva un backup separato. Il volume mantiene i file durante i normali deploy del servizio, ma non offre uno storico delle versioni né garantisce il recupero dopo un’eliminazione o una corruzione.
Scegli l’archiviazione in base ai dati
| Dati | Archiviazione adatta | Verifica del recupero |
|---|---|---|
| File temporanei e cache | Spazio temporaneo del container | Verifica che l’applicazione possa ricrearli dopo un riavvio. |
| Upload degli utenti e file applicativi | Volume persistente | Conserva una copia separata e prova a ripristinare i file necessari. |
| Dati strutturati dell’applicazione | Add-on database gestito | Controlla gli snapshot disponibili e prova la procedura di ripristino. |
| File e oggetti | Add-on per l’archiviazione di oggetti, se disponibile nel progetto | Verifica i requisiti di backup e recupero specifici del servizio. |
Mantieni in buono stato l’archiviazione
- Controlla nel pannello lo spazio usato e il limite del pacchetto. Un volume non può crescere oltre il limite previsto.
- Conserva i dati del database nell’add-on dedicato; non copiare né modificare la sua cartella dati con la gestione file dei volumi.
- Prima di spostare molti file, arresta i processi che scrivono e verifica le copie prima di rimuovere gli originali.
- Conserva i backup separatamente dai dati protetti e verifica periodicamente di riuscire a ripristinarli.