1,202 26/03/2026 07/04/2026 7 min

Il sintomo arriva spesso nel momento peggiore: backup notturno fallito, snapshot btrfs non creato e log pieni di errori su spazio insufficiente. In un hosting Linux il caso tipico è un volume LVM quasi saturo, con /var che cresce per log, cache o dati applicativi. Il risultato è doppio: il filesystem va in sola lettura o quasi, e la finestra di snapshot sparisce.

Qui parto da un caso concreto: /var/lib sta crescendo, lvdisplay mostra il logical volume al limite, e il job di snapshot fallisce con un errore di spazio. L’obiettivo non è “fare manutenzione”, ma riportare il servizio in una condizione stabile senza perdere dati e senza improvvisare.

Prerequisiti

Serve accesso root o sudo. Le operazioni sotto toccano LVM e filesystem, quindi vanno eseguite con attenzione.

  • Server Linux con LVM attivo.
  • Filesystem btrfs su un volume logico, oppure un volume dedicato che ospita dati con snapshot.
  • Spazio libero minimo su VG per creare un LV temporaneo, anche piccolo.
  • Accesso alla console o SSH, meglio se fuori da finestre di carico.

Note: se gestisci il server da pannello, controlla prima dove sono montati i volumi. In Plesk, ad esempio, vai in Tools & Settings → Server Information e verifica uso disco e mount point. In cPanel la vista equivalente è in Server Information o nei report di spazio, ma per LVM serve quasi sempre la shell.

Step 1: conferma il sintomo e identifica il mount pieno

Prima di toccare i volumi, devi capire cosa è pieno davvero. Un filesystem al 100% non si risolve allo stesso modo di un VG senza extents liberi.

df -hT /var / /home
lvs -o lv_name,vg_name,lv_size,lv_path,data_percent,metadata_percent
vgs -o vg_name,vg_size,vg_free
findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /var

# Output:

/dev/mapper/vg0-var  btrfs  120G  120G   0G 100% /var
vg0   500G  0G
var   vg0   120.00g  /dev/vg0/var

Se vg_free è zero e /var è al 100%, il problema è strutturale. Non basta cancellare un file piccolo. Serve liberare spazio subito o spostare dati.

Warning: non eseguire subito lvreduce su un filesystem montato. Qui stai gestendo saturazione, non ridimensionamento cieco.

Step 2: trova il consumo anomalo prima di cancellare

Un volume pieno non significa sempre “troppi dati”. Spesso il colpevole è un log rotato male, una cache applicativa o una directory di snapshot cresciuta senza limiti.

du -xhd1 /var | sort -h
journalctl --disk-usage
btrfs subvolume list -s /var 2>/dev/null || true
ls -lh /var/log | tail -n 20

# Output:

8.0G  /var/cache
42G   /var/lib
61G   /var/log

Se /var/log domina, controlla subito journal e log applicativi. Se /var/lib cresce, guarda database, container o repository temporanei. Se usi btrfs subvolume, verifica che non ci siano snapshot vecchi dimenticati.

Note: su interfacce come Plesk o ISPConfig puoi vedere il consumo per dominio o servizio, ma per distinguere tra log, cache e snapshot il terminale resta il metodo più rapido.

Step 3: libera spazio con un taglio sicuro

Qui l’obiettivo è recuperare almeno qualche gigabyte senza rompere il servizio. La priorità è cancellare ciò che è chiaramente temporaneo.

journalctl --vacuum-size=500M
find /var/log -type f -name '*.gz' -mtime +14 -delete
find /var/cache -type f -mtime +7 -delete

# Output:

Vacuuming done, freed 6.2G of archived journals from /var/log/journal.

Se il nodo ospita servizi critici, fai prima una verifica dei processi che scrivono nei log. Se cancelli file ancora aperti, lo spazio non torna subito.

lsof +L1 | head -n 20

# Output:

php-fpm  1234 root  5w  REG  0,45  2147483648  1234567 /var/log/app.log (deleted)

In quel caso riavvia il servizio responsabile, oppure ruota il log correttamente.

Step 4: allarga il volume LVM prima dello snapshot

Se hai recuperato solo una parte del problema, il passo giusto è aggiungere spazio al volume logico. È il modo più pulito per far ripartire snapshot e scritture.

lvextend -L +20G /dev/vg0/var
btrfs filesystem resize max /var

# Output:

Size of logical volume vg0/var changed from 120.00 GiB to 140.00 GiB.
Resize device id 1 (/dev/mapper/vg0-var) from 120.00GiB to max

Se il filesystem non è btrfs ma ext4, il resize finale cambia. Su ext4 useresti resize2fs. Qui il punto è evitare di lasciare il filesystem al limite, perché btrfs soffre molto quando non trova margine per le operazioni di CoW e snapshot.

Note: l’allargamento online è disponibile da riga di comando. Se gestisci il disco da pannello, il ridimensionamento LVM quasi mai è esposto in modo affidabile.

Step 5: crea lo snapshot btrfs con quota controllata

Molti snapshot falliscono perché vengono creati troppo grandi o senza politica di retention. Su btrfs conviene usare quota e una destinazione chiara.

btrfs subvolume snapshot -r /var/lib/app /snapshots/app-$(date +%F-%H%M)
btrfs qgroup show /var

# Output:

Create a readonly snapshot of '/var/lib/app' in '/snapshots/app-2026-03-26-0711'
qgroupid         rfer         excl
0/5         12.00GiB     12.00GiB

Se usi quote, controlla che il limite del qgroup non sia troppo stretto. Un errore comune è impostare una quota uguale al consumo corrente, lasciando zero margine per la scrittura del metadata.

btrfs qgroup limit 15G /snapshots/app-2026-03-26-0711

# Output:

Set limit to 15.00GiB on qgroup 0/5

Warning: le quote btrfs non sono un “bonus” opzionale. Se il volume ospita più servizi, senza qgroup un singolo tenant può saturare tutto il filesystem.

Step 6: riduci lo stress da I/O con lo scheduler giusto

Quando il disco è quasi pieno, il problema non è solo la capacità. Anche la latenza sale, e i backup peggiorano. Su SSD moderni il scheduler deve essere coerente con il device.

cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/sda/queue/scheduler

# Output:

none mq-deadline [kyber]

Su NVMe spesso none o kyber sono scelte sensate. Su SATA SSD e dischi tradizionali, mq-deadline può dare una latenza più prevedibile. Il punto non è inseguire il “più veloce”, ma ridurre i picchi mentre il filesystem è sotto pressione.

Per un cambio temporaneo:

echo mq-deadline > /sys/block/sda/queue/scheduler

# Output:

bash: echo: write error: Invalid argument

Se compare questo errore, il device non supporta quello scheduler. In quel caso prova quello elencato tra le opzioni disponibili.

Step 7: imposta una retention che eviti il prossimo blocco

Il problema reale, quasi sempre, è la mancanza di una soglia di allarme. Se aspetti il 100%, i backup diventano reattivi e fragili.

cat > /etc/cron.d/var-cleanup <<'EOF'
0 3 * * * root journalctl --vacuum-size=700M
15 3 * * * root find /var/log -type f -name '*.gz' -mtime +14 -delete
EOF

# Output:

nessun output, file cron creato

Se preferisci il pannello, usa il gestore cron del tuo hosting e pianifica una pulizia giornaliera o settimanale. La regola è semplice: i log compressi e vecchi vanno rimossi prima che consumino lo spazio del backup.

Note: per ambienti multi-tenant, aggiungi una quota per directory o per subvolume btrfs. È più efficace della pulizia manuale fatta a emergenza.

Verifica finale

Dopo le correzioni, controlla tre cose: spazio libero, integrità del filesystem e possibilità di creare uno snapshot.

df -hT /var
btrfs filesystem df /var
btrfs subvolume snapshot -r /var/lib/app /snapshots/test-$(date +%s)

# Output:

Filesystem      Type  Size  Used Avail Use% Mounted on
/dev/mapper/vg0-var btrfs  140G  118G   22G  85% /var
Data, single: total=... used=...
Create a readonly snapshot of '/var/lib/app' in '/snapshots/test-...'

Se il test snapshot va a buon fine, il blocco operativo è rientrato. A questo punto puoi rimettere in esecuzione backup, repliche o job di manutenzione.

Troubleshooting

1) ERROR: unable to create snapshot: No space left on device

Causa: il filesystem ha spazio libero apparente, ma manca margine per metadata o CoW.

Fix:

btrfs balance start -dusage=75 /var
btrfs balance start -musage=75 /var

# Output:

Done, had to relocate chunks

2) device-mapper: reload ioctl on failed: No space left on device

Causa: il VG non ha extents liberi e il volume non può essere esteso.

Fix:

vgs -o vg_name,vg_free
pvs
lvextend -L +10G /dev/vg0/var

# Output:

VG   VFree
vg0  10.00g

3) warning: mountpoint is not empty, cannot mount subvolume

Causa: stai cercando di montare un subvolume btrfs sopra una directory con file già presenti.

Fix:

umount /var
mv /var /var.old
mount /dev/vg0/var /var

# Output:

mounted /dev/mapper/vg0-var on /var

Conclusione

Quando LVM e btrfs si avvicinano al limite, il problema non è solo “spazio finito”. Il vero rischio è perdere la capacità di creare snapshot utili proprio quando servono.

La correzione giusta passa da tre mosse: liberare spazio reale, estendere il volume e mettere una retention che blocchi la crescita prima dell’emergenza. Il prossimo passo concreto è impostare un alert al 75% su /var e testare uno snapshot di prova ogni settimana.