Docker Volumes — Persistenza dei Dati e Gestione Storage per PMI che Non Possono Perdere un Byte

Il tuo container si ferma e i dati spariscono. Succede quando un'applicazione in PHP scrive upload su un filesystem efimero, o quando un database MySQL nel container azzera tutto a ogni riavvio. Se lavori con Docker in produzione, sai che il dato deve vivere oltre il ciclo di vita del container. Noi, di Meteora Web, ci siamo passati con clienti che perdevano ordini e fatture perché il volume era mal configurato. In questa guida vediamo come funzionano i Docker Volumes, quando usarli e come gestirli senza perdere sonno — o fatturato.

Perché un Container Senza Volume Perde Dati a Ogni Riavvio?

I container nascono per essere effimeri: leggeri, riproducibili, sostituibili. Il filesystem di un container è temporaneo. Quando lo fermi e lo elimini con docker rm, tutto quello che hai scritto dentro — upload, log, sessioni, database SQLite — viene cancellato. Per un'applicazione reale è un disastro. Pensaci: un e-commerce WooCommerce che perde le immagini dei prodotti a ogni deploy. Oppure un gestionale Laravel che azzera i report mensili. Noi lo abbiamo visto: un cliente aveva un'istanza MariaDB su container senza volume. Ogni aggiornamento di WordPress azzerava il database. Abbiamo dovuto recuperare tutto da un backup manuale. Una lezione imparata a caro prezzo.

La soluzione si chiama volume. Docker mette a disposizione tre meccanismi di persistenza: volumes (gestiti da Docker), bind mounts (montaggio diretto di una cartella del host) e tmpfs (in RAM, solo per dati temporanei). I primi due sono quelli che usi in produzione. Il terzo lo usiamo solo per cache di sessione o file temporanei.

Cosa puoi fare subito: controlla il tuo docker-compose.yml. Se sotto services non c'è una sezione volumes:, i tuoi dati probabilmente non sono persistenti. Ferma tutto, aggiungi un volume e testa con un file di prova. Fallo ora, non dopo il prossimo crash.

Come Funzionano i Docker Volumes e Quale Scegliere?

I volumes Docker sono directory create e gestite da Docker stesso, memorizzate in /var/lib/docker/volumes/ sul host. Sono la scelta consigliata per performance e portabilità. Puoi fare backup, spostarli tra host, gestirli con driver remoti (come NFS o cloud). I bind mounts montano una cartella del host (es. /home/user/app/uploads) dentro il container. Sono comodi in sviluppo per riflettere le modifiche live, ma in produzione creano dipendenze dal filesystem del host — meno portabili, più rischiosi per la sicurezza.

Noi, di Meteora Web, usiamo quasi sempre named volumes in produzione. Ecco perché: se devi spostare il container su un altro server, basta copiare la cartella del volume. Con un bind mount devi ricreare la struttura esatta delle directory sul nuovo host. Un errore di percorso e l'applicazione non vede più i dati. Lo abbiamo visto fare danni: un team che spostava un progetto Laravel e dimenticava di creare la cartella storage — 500 error per giorni.

Ecco un esempio pratico con docker-compose.yml per WooCommerce con MariaDB:

version: '3.8'

services:
  db:
    image: mariadb:10.11
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: rootpass
      MYSQL_DATABASE: woocommerce
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: wppass

  wordpress:
    image: wordpress:latest
    volumes:
      - wp_content:/var/www/html/wp-content
    ports:
      - "8080:80"
    depends_on:
      - db

volumes:
  db_data:
  wp_content:

Qui db_data e wp_content sono named volumes. Se fai docker-compose down -v, attento: rimuovi anche i volumi. Per fermare senza perdere dati usa docker-compose down senza -v.

Cosa puoi fare subito: nel tuo progetto, dichiara i volumi a livello di servizio e crea il loro nome nel blocco volumes: in fondo. Poi fai docker-compose up -d e verifica con docker volume ls che appaiano.

Bind Mount o Named Volume — Quale Usare in Produzione per lo Storage?

La scelta dipende dal caso d'uso. I named volumes sono più sicuri: non esponi il filesystem del host al container, e Docker gestisce i permessi in automatico. I bind mounts sono utili quando devi condividere file tra host e container in modo diretto, come i certificati SSL o i file di configurazione. Ma attenzione: con i bind mounts, se modifichi i file dal container, li modifichi anche sull'host. Un bug nel codice può cancellare dati critici.

Noi, di Meteora Web, abbiamo una regola pratica: named volumes per i dati applicativi (database, upload, storage), bind mounts solo per configurazioni e sviluppo. Un esempio concreto: per il deploy di una piattaforma Laravel che gestiamo, il volume storage è named, mentre la cartella certs con i certificati SSL è un bind mount. In questo modo il dato applicativo è portabile e sicuro, mentre la configurazione è facilmente aggiornabile dall'esterno.

Cosa puoi fare subito: rivedi i tuoi servizi. Se hai bind mounts per dati di database o upload, valuta di migrare a named volumes. Per farlo, crea il volume con docker volume create myapp_data e montalo al posto del bind mount.

Come Gestire il Backup e il Ripristino dei Volumes Docker?

I volumi Docker non sono backup. Se il disco del host si rompe, perdi tutto. La buona notizia è che fare backup di un volume è semplice: basta archiviare il contenuto. Ecco uno script che usiamo internamente per backup giornalieri dei volumi dei clienti:

#!/bin/bash
# backup_volume.sh — backup di un volume Docker
# Uso: ./backup_volume.sh nome_volume [container_name]

VOLUME=$1
CONTAINER=$2
BACKUP_DIR="/backup/volumes"
DATE=$(date +%Y%m%d_%H%M%S)

mkdir -p $BACKUP_DIR

echo "Backup del volume $VOLUME..."
docker run --rm --volumes-from $CONTAINER \
  -v $BACKUP_DIR:/backup \
  busybox tar -czf /backup/${VOLUME}_${DATE}.tar.gz /data

echo "Backup salvato in ${BACKUP_DIR}/${VOLUME}_${DATE}.tar.gz"

Per ripristinare: docker run --rm -v nome_volume:/data -v $(pwd):/backup busybox tar -xzf /backup/nome_file.tar.gz -C /data. Questo comando monta il volume e il file di backup, poi estrae il contenuto.

Attenzione: il backup in hot (con container in esecuzione) può causare corruzione sui database. Per MariaDB o PostgreSQL, usa strumenti nativi come mysqldump o pg_dump. Noi programmiamo dump SQL prima del backup del volume.

Cosa puoi fare subito: crea una directory /backup/volumes sul server, imposta uno script di backup automatico via cron (0 3 * * * /path/to/backup_volume.sh db_data mysql) e testa un ripristino su un ambiente di staging. Se non testi il ripristino, il backup non esiste.

Quali Driver di Storage Usare per Volumi Condivisi tra Più Host?

Se hai più server Docker in cluster (Swarm, Kubernetes o semplici macchine separate), i volumi locali non bastano. Hai bisogno di un driver che renda lo storage condiviso. Docker supporta driver come NFS, CIFS/SMB, Amazon EFS, Azure File. Noi, per clienti italiani con budget contenuti, consigliamo NFS su server Linux dedicato. È gratuito, stabile, e si integra bene con Docker.

Ecco come creare un volume Docker basato su NFS:

docker volume create \
  --driver local \
  --opt type=nfs \
  --opt o=addr=192.168.1.100,rw,nfsvers=4 \
  --opt device=:/exported/path \
  shared_volume

Poi lo monti come un volume normale: -v shared_volume:/app/storage.

Attenzione alla latenza di rete: un database su NFS può diventare lentissimo. Per database restiamo sui volumi locali o su storage block (iSCSI, EBS). Lo storage condiviso lo usiamo per file statici e upload, non per dati transazionali.

Cosa puoi fare subito: se hai un cluster, configura un server NFS (basta apt install nfs-kernel-server), esporta una directory e crea un volume Docker con il comando sopra. Poi montalo su uno o più servizi.

Errori Comuni e Come Evitarli nella Gestione dei Volumi

Ne abbiamo visti parecchi. Ecco i tre peggiori:

1. Volume non dichiarato nel blocco root. Scrivere volumes: db_data: sotto il servizio non basta: devi dichiararlo anche nel blocco volumes: in fondo al file, altrimenti Docker lo crea anonimo e lo perdi al down.

2. Permessi errati. Se il container scrive come utente www-data (uid 33) ma il volume ha permessi root, l'applicazione non scrive. Soluzione: nel Dockerfile o nel entrypoint, imposta l'utente o usa chown all'avvio.

3. Volume mai pulito. I volumi non rimossi occupano spazio. Usa docker system prune -a --volumes con cautela solo in ambienti di sviluppo. In produzione, monitora lo spazio con du -sh /var/lib/docker/volumes/.

Noi, di Meteora Web, abbiamo risolto il caso di un cliente che aveva TB di log accumulati in un volume di WordPress perché il plugin di log scriveva senza rotazione. Abbiamo aggiunto un cron che per i volumi di log applica una retention di 7 giorni con find /path -type f -mtime +7 -delete.

Cosa puoi fare subito: controlla lo spazio occupato da ogni volume con docker system df. Se un volume supera il previsto, ispeziona il contenuto con docker run --rm -it -v nome_volume:/data alpine ls -la /data.

Cosa Fare Adesso per Mettere in Sicurezza i Tuoi Dati su Docker

1. Controlla ogni servizio in produzione: verifica che database, upload e storage usino named volumes, non bind mounts per dati critici.
2. Aggiungi backup automatici: imposta uno script che fa dump dei database e archivia i volumi in una directory fuori dal server (NFS, cloud, backup remoto).
3. Testa un ripristino: ferma un container, cancella il volume, ripristina dal backup e riavvia. Se funziona in staging, funzionerà in produzione.
4. Monitora lo spazio: configura un alert se il disco del volume supera l'80%. Usa Prometheus + Grafana o anche un semplice script bash con mail.
5. Documenta la configurazione: tieni un README che elenca ogni volume con il suo scopo e la policy di backup. Quando arriva un nuovo sviluppatore, sa esattamente cosa fare.

Noi, di Meteora Web, usiamo questi stessi principi per ogni progetto che gestiamo. I volumi Docker sono come la contabilità: se li trascuri, il bilancio finale è sempre in rosso. Trattali con lo stesso rigore con cui gestisci le fatture dei clienti — perché quando il dato va perso, il costo è reale.

Per approfondire l'intero ecosistema Docker dalla prototipazione alla produzione per PMI, visita la nostra pillar page su Docker e containerizzazione.