Come aggiungere un nuovo disco a un server Linux esistente

Quando aggiungi un nuovo disco a un server Linux, la differenza tra un intervento pulito e un disastro sta quasi sempre in tre punti: identificare il device giusto, scegliere un layout coerente con l’uso reale e rendere il mount persistente senza toccare il disco sbagliato. Qui sotto trovi una procedura lineare, pensata per server recenti con systemd, valida sia per dischi SATA/SAS sia per volumi virtuali presentati da hypervisor o storage SAN.

La regola operativa è semplice: prima osservi, poi modifichi. Non partire mai da /dev/sdb “perché di solito è il secondo disco”. Verifica sempre dimensione, seriale, modello e punti di mount già in uso. Se il server è in produzione, considera l’impatto come potenzialmente alto fino a prova contraria: un errore qui non rompe solo un filesystem, ma può fermare servizi, database o backup.

1. Identificare il disco nuovo senza ambiguità

Il primo obiettivo è capire come il kernel vede il nuovo disco. Subito dopo l’attach fisico o la presentazione dal controller, raccogli l’inventario dei block device e confrontalo con la situazione precedente.

Comandi utili:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL,WWN

sudo fdisk -l

ls -l /dev/disk/by-id/

Quello che vuoi vedere è un device nuovo, con dimensione coerente e possibilmente un identificatore stabile in /dev/disk/by-id/. Se il disco è vuoto, lsblk non mostrerà filesystem né mountpoint. Se invece compare già un filesystem inatteso, fermati: potrebbe essere un disco riutilizzato o un LUN assegnato male.

Osservazione pratica: sui server con più dischi uguali, il nome /dev/sdX può cambiare dopo reboot o reorder del bus. Per questo, quando devi montare in modo persistente, è meglio usare UUID o il path stabile in /dev/disk/by-id/, non il nome temporaneo del kernel.

2. Scegliere tra partizione singola e layout più strutturato

Per un disco nuovo hai due strade comuni: usare tutto il disco con una singola partizione oppure costruire un layout con più partizioni o volumi logici. La scelta dipende dal ruolo del server.

Se il disco serve per dati applicativi, cache, backup o storage generico, una singola partizione è spesso sufficiente. Se invece prevedi growth separato per dati, log o snapshot, conviene usare LVM o almeno partizioni distinte. La decisione non è estetica: separare i mountpoint riduce il rischio di saturare tutto il sistema per colpa di una directory che cresce fuori controllo.

Per iniziare in modo semplice, puoi creare una partizione GPT che occupi l’intero disco.

sudo parted /dev/sdX --script mklabel gpt mkpart primary 0% 100%

Sostituisci /dev/sdX con il device corretto, verificato prima. Se il disco deve superare i 2 TB, GPT è la scelta giusta; MBR non è il formato adatto per questo scenario.

Se preferisci fdisk, va bene ugualmente per dischi non avviabili, ma GPT con parted o sgdisk è più pulito nei contesti moderni. Per esempio:

sudo sgdisk -o /dev/sdX

sudo sgdisk -n 1:0:0 -t 1:8300 /dev/sdX

Dopo la creazione della partizione, il nuovo device sarà in genere qualcosa come /dev/sdX1. Controlla subito:

lsblk -f /dev/sdX

3. Creare il filesystem giusto per il carico reale

Il filesystem non è una formalità. Sceglilo in base a carico, dimensione e necessità di recovery. Per la maggior parte degli usi generici su Linux, ext4 resta una scelta solida e prevedibile. XFS è ottimo per volumi grandi e carichi con file di dimensione variabile, soprattutto quando il disco deve ospitare dati o log con crescita continua.

Esempio con ext4:

sudo mkfs.ext4 -L data01 /dev/sdX1

Esempio con XFS:

sudo mkfs.xfs -L data01 /dev/sdX1

Se il disco ospiterà backup o archivi di file grandi, XFS ha spesso una gestione più naturale del throughput sequenziale. Se vuoi una compatibilità molto ampia con tool e procedure, ext4 è la scelta più conservativa. Non inventare tuning a caso: prima misura il pattern I/O. Un disco per database, uno per repository e uno per backup non hanno gli stessi requisiti.

Dopo la formattazione verifica l’etichetta e l’UUID:

blkid /dev/sdX1

Annota l’UUID: ti serve per il mount persistente. Se non compare, il filesystem non è stato creato correttamente oppure stai interrogando il device sbagliato.

4. Montare il disco in modo persistente con UUID

La parte che crea meno problemi nel tempo è sempre la stessa: mount su directory dedicata, voce in /etc/fstab con UUID e test immediato. Evita mount “a mano” che poi spariscono al reboot.

Prima crea il punto di mount:

sudo mkdir -p /data

Poi recupera l’UUID:

sudo blkid /dev/sdX1

Inserisci una riga in /etc/fstab simile a questa:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /data ext4 defaults,noatime 0 2

Per XFS il tipo filesystem diventa xfs. L’opzione noatime può ridurre scritture inutili in alcuni carichi; non è sempre necessaria, ma su storage dati spesso è una scelta sensata.

Prima di riavviare, testa la configurazione in modo esplicito:

sudo mount -a

Se il comando non produce errori, controlla il mount attivo:

findmnt /data

Se mount -a fallisce, non forzare il reboot “per vedere se si sistema”: il problema è quasi sempre una voce errata in /etc/fstab, un UUID sbagliato o un filesystem type non coerente.

5. Permessi, ownership e utilizzo applicativo

Un disco montato ma non accessibile dall’utente o dal servizio giusto è solo metà lavoro. Dopo il mount, imposta ownership e permessi in base al servizio che dovrà scriverci sopra.

Per esempio, se il mount point serve a un servizio web o a un demone dedicato:

sudo chown -R www-data:www-data /data

Oppure, se vuoi un controllo più fine, crea una directory interna specifica e assegna i permessi solo lì, lasciando il mount point root-owned. È spesso una scelta migliore quando sullo stesso disco ospiti più dataset o vuoi limitare l’impatto di un processo compromesso.

Se il server usa SELinux, non basta cambiare ownership: devi anche verificare i contesti. In quel caso il problema non è il mount, ma il policy labeling. Il controllo minimo è osservare eventuali deny nei log di audit; il fix passa da contesti corretti, non da permessi più larghi a caso.

6. Se il disco deve entrare in LVM

Se vuoi flessibilità futura, il nuovo disco può diventare un physical volume LVM invece di un filesystem diretto. Questo ha senso quando prevedi estensione, snapshot o separazione logica dei volumi.

Flusso tipico:

sudo pvcreate /dev/sdX1

sudo vgextend vgdata /dev/sdX1

sudo lvextend -r -l +100%FREE /dev/vgdata/lvdata

Qui il vantaggio è operativo: puoi aggiungere capacità senza cambiare subito il layout applicativo. Il flag -r tenta anche il resize del filesystem, ma verifica sempre che il filesystem supporti l’operazione online. XFS ed ext4 lo fanno, ma con modalità diverse.

Se sei in un ambiente già in produzione, LVM riduce il rischio di dover rifare il layout dopo poche settimane. Il rovescio della medaglia è che aggiungi un livello di complessità. Se il team non lo gestisce bene, meglio un filesystem diretto ben documentato che un LVM “misterioso”.

7. Verifiche dopo il primo mount

Dopo aver montato il disco, fai una verifica che non sia solo “c’è il path, quindi va bene”. Devi controllare stabilità, spazio e coerenza del mount.

echo test | sudo tee /data/.write-test

cat /data/.write-test

Se il disco deve servire un servizio specifico, riavvia solo quel servizio e osserva i log. Un mount corretto ma una permission errata emergono subito nei log applicativi o di systemd.

Per controllare che il mount sia realmente persistente, esegui un test di reboot solo quando hai già verificato /etc/fstab e hai una finestra operativa. In ambienti critici, prima di riavviare conviene avere accesso console o out-of-band, perché un errore su fstab può bloccare l’avvio o lasciare il sistema in emergency mode.

Il primo errore classico è formattare il disco sbagliato. Evitalo con una verifica doppia di modello, seriale e dimensione prima di ogni comando distruttivo. Il secondo è usare il nome device al posto dell’UUID in /etc/fstab. Il terzo è dimenticare che il mount point deve esistere già, altrimenti il mount fallisce o viene creato in modo non previsto da script improvvisati.

Un altro errore frequente è riempire il disco con dati senza aver pensato a monitoring e alert. Un nuovo disco non è solo spazio in più: è un nuovo punto da osservare. Configura almeno una soglia di warning e una di critical su utilizzo, inode se rilevante, e stato SMART quando il disco è locale.

Se il disco è fisico, un controllo SMART di base è utile subito dopo l’installazione:

sudo smartctl -a /dev/sdX

Su volumi virtuali o cloud, SMART può non essere disponibile o non essere significativo; in quel caso affidati ai tool del provider, al monitoraggio del layer storage e alle metriche del guest OS.

Se vuoi una sequenza compatta per un disco dati singolo, il flusso minimo è questo:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL

sudo parted /dev/sdX --script mklabel gpt mkpart primary 0% 100%

sudo mkfs.ext4 -L data01 /dev/sdX1

sudo mkdir -p /data

sudo blkid /dev/sdX1

sudo nano /etc/fstab

sudo mount -a

findmnt /data

Questa sequenza è volutamente conservativa. Funziona bene quando l’obiettivo è aggiungere capacità in modo prevedibile, senza introdurre strumenti inutili. Se poi il carico cresce, puoi evolvere verso LVM, RAID software o storage distribuito, ma la base resta la stessa: identificazione corretta, filesystem coerente, mount persistente e verifica finale.

Se il disco non compare in lsblk, se il device ha già un filesystem inatteso, se il server è in HA o se il volume è parte di una catena storage più complessa, non andare avanti per intuito. Servono almeno il layout attuale, il tipo di storage e l’uso previsto del disco. Senza questi dati, la procedura corretta non è “provare”: è fermarsi, raccogliere evidenze e chiudere il gap prima di toccare configurazione o dati.

In pratica: osserva, scegli il layout, crea il filesystem, monta con UUID, testa fstab, poi integra permessi e monitoraggio. È un intervento semplice solo se ogni passaggio è verificato. Se uno dei passaggi salta, il problema di solito non è Linux: è l’assenza di controllo sul device e sul suo ciclo di vita.