Non esiste un “partizionamento ideale” valido per ogni server. Un mail server, un database, un hypervisor e un reverse proxy hanno pattern di crescita e failure mode differenti. La domanda utile non è quindi “quante partizioni devo creare?”, ma quali dati voglio isolare, quali volumi devono poter crescere e cosa deve succedere quando uno di essi finisce lo spazio.
Separare tutto in dieci partizioni minuscole può sembrare ordinato e trasformarsi rapidamente in un incubo operativo. Tenere tutto in un unico filesystem è semplicissimo ma permette, per esempio, a un log impazzito di riempire anche lo spazio necessario al sistema operativo. La progettazione sta nel mezzo.
Prima distinzione: disco, partizione, volume e filesystem
Nel linguaggio quotidiano questi termini vengono spesso confusi, ma rappresentano livelli diversi:
disco / SSD / NVMe
|
+-- GPT / partizioni
|
+-- RAID md / LUKS / LVM
|
+-- logical volume
|
+-- ext4 / XFS / altro filesystem
|
+-- mount point: /, /var, /srv...Non dobbiamo usare tutti i livelli. Ma capire dove siamo ci evita di confondere “aumentare la partizione” con “aumentare il filesystem” oppure RAID con backup.
Fotografare lo storage esistente
lsblk -o NAME,SIZE,TYPE,FSTYPE,FSVER,MOUNTPOINTS,UUID
findmnt
df -hT
blkid
# se usiamo LVM
pvs
vgs
lvs -a -o +devices
# se usiamo md RAID
cat /proc/mdstat
mdadm --detail --scanQuesti comandi descrivono livelli differenti. lsblk mostra la struttura a blocchi, findmnt i mount, df l’utilizzo dei filesystem e LVM/md lo strato di aggregazione sottostante.
GPT e UEFI
Su hardware moderno GPT è normalmente la tabella partizioni di riferimento. Un sistema UEFI utilizza inoltre una EFI System Partition, tipicamente FAT, montata sotto /boot/efi. La sua dimensione dipende da distribuzione e numero di sistemi installati, ma non è il posto in cui conservare dati applicativi.
Una partizione /boot separata può ancora servire in alcuni layout, per esempio quando cifratura, RAID o bootloader lo richiedono. Non va creata soltanto perché “sui server si è sempre fatto così”.
Una root unica può essere perfettamente valida
Per un server semplice, con crescita prevedibile e backup adeguato, una root capiente più EFI e swap può essere la scelta migliore. Meno filesystem significa meno possibilità di trovarsi con 200 GB liberi in /home e zero byte disponibili in /var.
La separazione diventa utile quando risolve un rischio concreto: crescita incontrollata, differenti politiche di mount, snapshot indipendenti, performance o amministrazione dello storage.
Perché LVM è spesso più utile di molte partizioni rigide
LVM introduce tre concetti:
- PV, physical volume: il dispositivo a blocchi sottostante;
- VG, volume group: un pool di capacità;
- LV, logical volume: il volume su cui creiamo normalmente il filesystem.
Il grande vantaggio è che la capacità non deve essere assegnata tutta il giorno dell’installazione. Possiamo lasciare spazio libero nel VG e aumentare il volume che ne avrà realmente bisogno.
pvs
vgs
lvs
# esempio: aggiungere 20 GiB a un LV e chiedere a LVM
# di ridimensionare anche il filesystem se supportato
lvextend -L +20G --resizefs /dev/vg0/varCanonical documenta proprio LVM come livello più flessibile rispetto al partizionamento tradizionale; i logical volume possono essere estesi usando spazio libero del volume group, anche proveniente da più dischi.
Non allocare necessariamente il 100% del VG
Lasciare una quota non allocata è spesso una scelta prudente. Se tra sei mesi scopriamo che /var cresce più del previsto possiamo espanderlo senza dover indovinare oggi il suo consumo futuro.
Questo margine non sostituisce capacity planning e monitoring: semplicemente rende meno costoso correggere una previsione sbagliata.
Quando separare /var
/var contiene dati variabili: log, cache, spool e molto stato applicativo sotto /var/lib. Un mail server, un sistema di logging o un host container può quindi farlo crescere molto più della root.
Separarlo può impedire che una crescita incontrollata riempia il filesystem root. Ma isolare tutto /var non è sempre la scelta migliore: per un database molto grande può essere più sensato dedicare un volume direttamente alla sua datadir, lasciando il resto di /var sulla root.
/srv, /var/lib e /home
Il Filesystem Hierarchy Standard assegna a /srv i dati site-specific serviti dal sistema. /var/lib viene invece usato normalmente per stato applicativo non destinato a essere esposto direttamente agli utenti.
/home ha senso come volume separato quando esistono utenti interattivi con una quantità significativa di dati personali. Su molti server moderni può invece essere quasi vuoto, mentre centinaia di gigabyte vivono in /srv, /var/lib o volumi applicativi dedicati.
Esempio 1: server semplice
EFI 1 GiB
/ LV 60 GiB
swap file o LV secondo necessità
VG:
root 60 GiB
libero tutto il restoSe il carico è piccolo e prevedibile, questa struttura può essere più robusta di un mosaico di filesystem da pochi gigabyte.
Esempio 2: server che ospita dati applicativi
EFI 1 GiB
/ LV 40 GiB
/var LV 40 GiB
/srv LV 200 GiB
swap LV/file secondo necessità
spazio VG non allocato per crescita futuraUn database molto grande potrebbe avere un volume specifico al posto di un generico /srv. Un mail server potrebbe isolare lo spool o il percorso delle mailbox. La disposizione deve riflettere il workload.
ext4 o XFS?
Entrambi sono filesystem maturi. Per molti server il default della distribuzione è una scelta eccellente.
- ext4 è molto diffuso, può crescere e supporta anche riduzione del filesystem con le dovute condizioni e procedure;
- XFS è particolarmente adatto a filesystem grandi e può crescere online, ma non supporta lo shrink.
Questa differenza conta nella progettazione: creare un XFS da 900 GB “perché tanto il disco è da 1 TB” significa accettare che ridurlo in seguito richiederà migrazione dei dati verso un filesystem nuovo.
Swap: partizione, LV o file
Su molti server una swapfile è sufficiente e molto più facile da ridimensionare. Una swap partition o un LV dedicato restano perfettamente validi. La scelta dipende anche da dump, cifratura e requisiti di ibernazione, quest’ultima normalmente poco rilevante su un server.
swapon --show
free -h“Ho molta RAM quindi non voglio swap” non è automaticamente una strategia migliore: la memoria virtuale e la gestione della pressione RAM sono argomenti più ampi del semplice overflow.
Mount options: separare può anche cambiare la policy
Filesystem separati permettono opzioni differenti. Su aree che non devono contenere device, programmi setuid o codice eseguibile possiamo valutare nodev, nosuid e noexec.
UUID=... /srv/dati ext4 defaults,nodev,nosuid 0 2Non copiamo però noexec ovunque per sport. Può rompere installer, runtime, script e applicazioni; inoltre non è una barriera assoluta contro l’interpretazione di un file da parte di un programma già eseguibile. Le mount option devono corrispondere all’uso reale del filesystem.
fstab: usare identificatori stabili
Il nome /dev/sdb1 può cambiare in seguito a boot, modifiche hardware o controller. Per i mount persistenti preferiamo UUID o altri identificatori stabili.
blkid
ls -l /dev/disk/by-uuid/
findmnt --verify --verboseDopo una modifica a /etc/fstab la validazione è molto meno emozionante di scoprire l’errore durante il reboot successivo.
Non separare /usr per “salvarlo” durante una reinstallazione
Il vecchio articolo proponeva di mantenere /usr e /var per preservare programmi, librerie, log e buona parte delle configurazioni durante una reinstallazione. Oggi è una strategia che sconsigliamo.
/usr contiene file gestiti dal package manager e deve essere coerente con la nuova installazione, le sue librerie e i suoi database pacchetti. Anche /var contiene un miscuglio di dati preziosi e stato specifico dell’installazione. Riattaccare entrambi “così come sono” può creare un sistema ibrido difficile da comprendere e aggiornare.
Reinstallare bene significa ricostruire, non conservare il vecchio sistema
Ciò che vogliamo preservare deve essere definito esplicitamente:
- dati applicativi e database;
- configurazioni realmente amministrate sotto
/etce altrove; - certificati e segreti necessari al servizio;
- cron e timer applicativi;
- lista dei pacchetti o, ancora meglio, procedure di provisioning;
- documentazione su utenti, servizi e dipendenze.
Il sistema operativo dovrebbe essere il più possibile riproducibile. Backup, configuration management, repository Git e script di setup valgono molto più di una vecchia /usr conservata come capsula del tempo.
Snapshot LVM: utile, ma non è backup
LVM permette di creare snapshot di un logical volume e ottenere una vista congelata utile, per esempio, come sorgente di un backup consistente. Lo snapshot rimane però nello stesso dominio di guasto del volume originale e non deve essere confuso con una copia off-site.
La distinzione è approfondita in Backup: come e perché progettarlo.
Monitoring: lo spazio deve avvisarci prima di finire
df -hT
df -i
du -xhd1 /var | sort -h
journalctl --disk-usage
vgs
lvsUn filesystem separato limita il danno soltanto se sappiamo che sta per riempirsi. Senza monitoring il risultato può essere semplicemente spostare l’ENOSPC da / a /var.
Checklist di progettazione
- quali dati crescono più rapidamente?
- quale filesystem non deve poter riempire la root?
- quali dati hanno politiche di backup differenti?
- serve cifratura a blocchi?
- serve RAID o altra ridondanza?
- quali volumi devono crescere online?
- possiamo lasciare spazio libero nel VG?
- quali mount option sono compatibili con il workload?
- come ricostruiamo il server se perdiamo completamente il disco?
Se l’ultima domanda non ha una risposta, il problema principale non è ancora il partizionamento.
Riferimenti
Ubuntu Server: Logical Volume Management · RHEL: Logical Volume Management · Filesystem Hierarchy Standard 3.0.
