ZFS RAIDZ expansion in Proxmox VE 9: checklist pratica per homelab

Proxmox VE 9 porta una novità che interessa molto chi gestisce homelab e piccole infrastrutture: ZFS 2.3 con supporto alla RAIDZ expansion. In pratica diventa possibile aggiungere un disco a un vdev RAIDZ esistente, aumentando la capacità del pool senza distruggere e ricreare tutto. È una funzione attesa da anni, soprattutto da chi ha iniziato con tre o quattro dischi e poi si è trovato con più VM, più backup e più dati del previsto.

La parte importante è non leggerla come una magia. RAIDZ expansion riduce il dolore operativo, ma non elimina pianificazione, backup e finestre di manutenzione. Se il pool contiene VM di produzione, servizi di casa critici o dati che non puoi perdere, va trattata come una modifica strutturale dello storage, non come un normale apt upgrade.

Cosa cambia davvero

Con i layout RAIDZ tradizionali, espandere un pool significava quasi sempre aggiungere un nuovo vdev completo, per esempio un altro gruppo RAIDZ1/RAIDZ2, oppure migrare i dati altrove, ricreare il pool e ripristinare. Nel mondo homelab questo era scomodo: non tutti hanno spazio, porte SATA, HBA e dischi sufficienti per raddoppiare un pool solo per crescere ordinatamente.

La RAIDZ expansion introdotta in OpenZFS 2.3 permette di aggiungere un disco a un vdev RAIDZ già esistente. Un RAIDZ1 da 4 dischi può diventare, dopo resilver, un RAIDZ1 da 5 dischi. Un RAIDZ2 può crescere allo stesso modo mantenendo il livello di parità scelto. Proxmox VE 9 include questa generazione di ZFS, quindi la funzione diventa interessante anche per installazioni reali su Debian 13/Trixie.

Attenzione però: l’operazione non converte automaticamente il vecchio spazio scritto in una distribuzione “perfetta” come se il pool fosse nato già con più dischi. I nuovi dati beneficiano della nuova geometria, mentre per ottenere una distribuzione più omogenea può servire riscrivere progressivamente i dataset, per esempio con migrazioni, send/receive o restore pianificati. È normale: l’obiettivo principale è espandere senza ricreare tutto, non riscrivere l’intero pool in modo istantaneo.

Quando ha senso usarla

La uso volentieri in tre scenari. Primo: homelab con un singolo pool ZFS per VM, container e dati non critici ma comunque importanti. Secondo: server piccolo di ufficio dove aggiungere un nuovo vdev completo sarebbe troppo costoso. Terzo: nodo Proxmox con storage locale, backup già solidi e necessità di aumentare capacità senza fermo lungo.

La eviterei invece se il pool è già degradato, se hai errori SMART, se non hai un backup verificato o se stai cercando di correggere una progettazione sbagliata. Se sei partito con RAIDZ1 su dischi grandi e dati importanti, aggiungere un disco non risolve il rischio di una seconda rottura durante resilver. In quel caso ha più senso pianificare una migrazione verso RAIDZ2, mirror multipli o storage separato per i carichi più delicati.

Checklist prima di toccare il pool

Prima di qualsiasi comando, fai questi controlli:

Aggiorna la documentazione del nodo: dischi, seriali, bay fisici, pool e dataset.
Verifica di avere un backup recente fuori dal pool, idealmente su Proxmox Backup Server o su storage esterno.
Controlla lo stato ZFS con zpool status e assicurati che sia ONLINE senza errori.
Controlla SMART e temperature dei dischi già presenti.
Usa nomi persistenti in /dev/disk/by-id/, mai /dev/sdX.
Pianifica una finestra in cui le prestazioni ridotte non siano un problema.
Evita di fare altre attività pesanti: scrub, migrazioni massive, restore o rebuild RAID del controller.

Su Proxmox puoi partire da:

zpool status
zpool list
zfs list
ls -l /dev/disk/by-id/ | less
smartctl -a /dev/disk/by-id/ID_DEL_DISCO

Se usi HBA o controller in IT mode, controlla anche firmware e log del kernel. Un’espansione RAIDZ stressa tutto il percorso I/O: disco, cavi, backplane, alimentazione e controller.

Esempio operativo

Immaginiamo un pool chiamato tank con un vdev raidz1-0 e un nuovo disco visibile come /dev/disk/by-id/ata-WDC_NEW_DISK. Prima identifichi il vdev corretto:

zpool status tank

Poi, su sistemi con supporto alla RAIDZ expansion attivo, l’aggiunta avviene con la sintassi di zpool attach, indicando il vdev RAIDZ esistente e il nuovo disco:

zpool attach tank raidz1-0 /dev/disk/by-id/ata-WDC_NEW_DISK

Durante il resilver monitora senza fretta:

watch -n 30 zpool status tank

Quando l’operazione termina, controlla capacità e salute:

zpool status tank
zpool list tank
zfs list -o name,used,avail,refer,mountpoint

Non lanciare il comando copiandolo alla cieca: verifica sempre la sintassi sulla versione installata e prova prima in un ambiente non critico. In un homelab serio, una VM di test con dischi virtuali basta per capire flusso, tempi e messaggi di stato.

Impatto su Proxmox

Per Proxmox la domanda pratica è: cosa succede alle VM? Se il pool resta online, le VM possono continuare a girare, ma aspettati latenza più alta durante il resilver. I workload più sensibili, come database, Home Assistant con recorder pesante, Nextcloud o storage per container rumorosi, possono risentirne. Se possibile, spegni ciò che non serve e limita backup concorrenti.

Controlla anche snapshot e repliche. Prima dell’intervento riduci il rumore: evita retention aggressive, job di backup sovrapposti e migrazioni live non necessarie. Se hai Proxmox Backup Server, fai un backup manuale delle VM importanti e verifica che almeno un restore di test sia già stato provato in passato. Un backup mai ripristinato è una speranza, non una procedura.

Errori da evitare

Il primo errore è usare dischi misti senza criterio. ZFS accetta molte combinazioni, ma capacità, velocità e affidabilità contano. Il secondo è ignorare l’alimentazione: aggiungere dischi aumenta spunto e calore. Il terzo è trattare RAIDZ come backup. RAIDZ protegge dalla rottura di dischi, non da cancellazioni, ransomware, bug, errori umani o incendio.

Il quarto errore è espandere un pool già troppo pieno. ZFS lavora meglio con spazio libero; arrivare stabilmente sopra l’80-85% rende tutto più scomodo. Se sei già al limite, valuta se spostare dataset freddi su un altro storage prima dell’espansione.

Procedura consigliata DanpLab

Per un nodo Proxmox domestico o piccolo ufficio seguirei questa sequenza: backup completo, verifica zpool status, test SMART, aggiunta disco, resilver monitorato, scrub finale e aggiornamento della documentazione. Dopo qualche giorno, controllerei i grafici di latenza e I/O per capire se il pool sta reggendo bene o se è arrivato il momento di separare VM, backup e dati freddi.

La RAIDZ expansion è una funzione molto utile, ma il suo valore migliore è strategico: permette di crescere con meno interruzioni. Non deve diventare una scusa per non progettare lo storage. In homelab, come in produzione, la regola resta semplice: prima i backup, poi la capacità.

Fonti

Proxmox, “Proxmox Virtual Environment 9.0 with Debian 13 released”.
Proxmox VE Roadmap e documentazione amministrativa 9.x.
OpenZFS 2.3: supporto RAIDZ expansion e nuove funzionalità ZFS.