Disclosure: Geekworm ha fornito l'X1011, SUNLU i filamenti del case stampato in 3D e Plugable l'adattatore di rete 2.5G, in collaborazione con homelabz.cc; sono tutti sponsor del blog. Il giudizio resta indipendente.
Il Geekworm X1011 aggiunge quattro slot M.2 NVMe a un Raspberry Pi 5 e lo trasforma in un NAS reale. Nel mio homelab regge da settimane i backup di un cluster Proxmox, con quattro SSD organizzati in un pool ZFS RAIDZ2. Ecco com'è fatto, i numeri veri misurati sul campo e come dimensionarlo per farci la cosa giusta.
Quattro NVMe su un Raspberry Pi 5: cos'è il Geekworm X1011
Il Geekworm X1011 è un HAT che si monta sopra il Raspberry Pi 5 e mette a disposizione quattro slot M.2 Key-M nei formati 2230, 2242, 2260 e 2280, collegati tramite uno switch PCIe ASMedia ASM1184e. Accetta SSD NVMe: niente M.2 SATA, niente AHCI. La scheda misura 109x87,2mm e, nella variante V1.1, il prezzo ufficiale è di 45 dollari, scontato da un listino di 52. La capacità dichiarata arriva fino a 16TB con quattro SSD da 4TB ciascuno.
Il supporto a quattro formati fisici diversi non è un dettaglio da scheda tecnica: significa poter rimettere in gioco SSD di taglie diverse recuperati da altre macchine, invece di comprare quattro drive identici solo per riempire gli slot. Nel mio caso il taglio è volutamente modesto — quattro NVMe da 256GB recuperati da configurazioni precedenti, con livelli di usura diversi tra loro, tra lo 0% e il 24%. È esattamente lo spirito con cui questa board dà il meglio: dare una seconda vita a drive che altrimenti resterebbero in un cassetto.
"The hidden NAS maker": così Tom's Hardware ha intitolato la sua recensione del Geekworm X1011 — la board che ti permette di costruirti un NAS senza dare nell'occhio, buona quando cerchi capacità e ridondanza più che i numeri di un NAS enterprise.
Il NAS in produzione: pool ZFS RAIDZ2 e backup del cluster Proxmox
Il mio Geekworm X1011 gira su un Raspberry Pi 5 da 8GB, hostname NAS-PI, in produzione dal 30 maggio 2026: non un banco di prova, ma un pezzo reale dell'infrastruttura homelab, con un ruolo preciso — assorbire i backup del cluster Proxmox. I quattro NVMe da 256GB sono organizzati in un pool ZFS chiamato tank in configurazione RAIDZ2 (952GB raw, circa 447GB utili), che tollera fino a due guasti simultanei. Con dischi di seconda mano e usure diverse è il margine giusto, ed è la ragione precisa per cui ho scelto RAIDZ2 invece di RAIDZ1 nonostante la capacità utile più bassa: la ridondanza vale più dei gigabyte.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Hardware
Thermal Grizzly M.2 SSD Cooler: -6°C sul NVMe del mio homelab server
Da 39°C a 33°C sotto stress: il Thermal Grizzly M.2 SSD Cooler testato sul Crucial P3 del nodo failover Proxmox. Benchmark before/after con foto e dati reali.
Compressione lz4, ashift=12, atime=off, scrub mensile automatico, snapshot gestiti da sanoid con retention 24h/14d/4w/3m: rollback rapido sull'ultimo giorno, un cuscinetto settimanale, una memoria più lunga per i mesi. Sopra il pool gira uno stack ordinato da homelab: Cockpit per la gestione via web sulla porta 9090, con il plugin file-sharing di 45Drives per configurare SMB e NFS senza toccare la riga di comando; Docker e Dockge con il data-root spostato sullo ZFS; Scrutiny per tenere d'occhio lo SMART dei quattro NVMe, prezioso proprio con drive di seconda mano dalle usure diverse; Filebrowser e una share Samba per l'accesso quotidiano. log2ram tiene la microSD al riparo dalla scrittura continua dei log.
La prova più concreta che il NAS regge il suo compito è arrivata per caso, non per test: quando il container LXC che fa da server GPU per Ollama si è corrotto per un thin pool Proxmox pieno, il restore è partito proprio dal backup conservato sul NAS Pi. Un NAS di backup lo giudichi lì — nel momento in cui ti serve davvero — e questo ha risposto presente.
Rete: una 2.5G dedicata che dimezza le finestre di backup
L'eth0 1GbE del Pi 5 tappa intorno ai 110 MB/s, prevedibile. Per i backup ho aggiunto un adattatore USB 2.5G dedicato — un Plugable USBC-E2500, il 2-in-1 USB-C/USB-A basato su chip Realtek RTL8156 — con policy-routing separato dal traffico normale. I numeri reali, misurati via NFS: 258 MB/s in scrittura, 294 MB/s in lettura, con iperf3 che segna circa 2,3 Gbit/s — praticamente il line-rate della 2.5GbE. Tradotto in pratica: finestre di backup più corte, senza dover aspettare che l'unica interfaccia da 1GbE saturi mentre il cluster Proxmox scarica i vzdump. Il pool tank è montato come storage NFS su Proxmox (nas-backup, NFSv4.2) ed è il target dei backup vzdump del cluster. È qui che la board mostra il suo valore reale: non un numero da vetrina, ma un backup che finisce in metà tempo.
Come dimensionarlo bene: la banda PCIe condivisa
C'è una cosa da sapere prima di comprarlo, e conoscerla in anticipo fa la differenza tra un acquisto azzeccato e uno deluso. Lo switch ASM1184e collega tutti e quattro gli slot al Raspberry Pi 5 attraverso un unico canale PCIe 2.0 x1: fino a 5 Gbps teorici, condivisi tra i quattro slot, non 5 Gbps per ciascun drive. È un tetto strutturale della scheda.
Il calcolo indipendente di Jeff Geerling stima un throughput aggregato reale nell'ordine di 430 MB/s; con tutti e quattro i drive attivi contemporaneamente, CNX Software riporta che ciascuno scende attorno ai 100 MB/s. Combacia bene con il tetto che ho misurato io stesso, intorno ai 450 MB/s aggregati — una convergenza tra una fonte esterna indipendente e l'esperienza diretta che vale più di qualunque numero sul datasheet.
Ma ecco il punto che rende questo limite quasi teorico nell'uso reale: come nota un commento sul forum ufficiale Raspberry Pi, in un NAS il collo di bottiglia percepito è quasi sempre la rete, non lo storage. Con un 1GbE onboard che tappa già a circa 110 MB/s, la banda condivisa dello switch PCIe raramente diventa il primo limite che incontri — a meno di aggiungere, come ho fatto io, una rete più veloce dedicata. In altre parole: per un NAS di backup o file-sharing questo è esattamente il target giusto. Se invece l'obiettivo fosse storage primario ad alte prestazioni per carichi 10G, il posto da guardare è un box x86, non un Pi — e vale per qualunque HAT, non per l'X1011 in particolare.
Un'ultima verifica utile per chi vuole fare boot direttamente da un NVMe dietro lo switch: le fonti non collimano (alcune indicano supporto dai bootloader Pi recenti, il database PCIe di Jeff Geerling e una issue GitHub segnalano invece una limitazione firmware ancora aperta sul boot dietro switch/bridge). Meglio provarlo sul proprio setup prima di darlo per scontato; per un NAS con l'OS su microSD, come il mio, la questione non si pone.
Alimentazione: falla giusta e non ci pensi più
Il Geekworm X1011 si alimenta in due modi alternativi, mai insieme: i pogo pin collegati alla USB-C del Raspberry Pi 5 (5V, almeno 5A, sufficiente per 1-2 SSD), oppure il jack barrel DC5521 da 5,5x2,1mm sulla board stessa (5V, con almeno 5A o 10A a seconda del carico, necessario quando si montano 3 o 4 SSD). Il produttore lo scrive chiaro: mai collegare contemporaneamente il jack DC del X1011 e la USB-C del Pi. Il convertitore DC/DC di bordo eroga fino a 10A complessivi verso i quattro SSD, a 3,3V.
Una issue aperta sul repository GitHub di Jeff Geerling segnala che, collegando entrambe le alimentazioni insieme contro l'avviso del produttore, non sembra esserci una protezione hardware che eviti danni. Vale come promemoria pratico: la sequenza di collegamento va rispettata alla lettera. Fatto una volta bene, è una cosa a cui non pensi mai più.
Un accorgimento per la stabilità 24/7: il power-management NVMe
Vale la pena metterlo in conto se costruisci un NAS h24, e non riguarda l'X1011 in sé ma il rapporto tra certi SSD NVMe e il Raspberry Pi. Alcuni drive OEM (nel mio caso due SK hynix) tendono a entrare in stati di risparmio energetico molto profondi (APST) e, con uno switch PCIe di mezzo, possono non risvegliarsi in tempo. La soluzione, da applicare una volta sola via kernel cmdline, è disattivare quel risparmio:
Da lì il pool gira liscio in continuo. Non è un difetto della board: è un comportamento noto degli NVMe consumer su Pi con switch PCIe, confermato anche da altri — un utente con quattro Crucial P3 ha risolto lo stesso sintomo passando da PCIe Gen2 a Gen3 con dtparam=pciex1_gen3. Buono a sapersi prima, così parti già stabile invece di inseguire un fantasma.
Il case: stampato in 3D su misura con filamento SUNLU
L'X1011 lascia il Raspberry Pi 5 e i quattro NVMe completamente scoperti, e per un pezzo acceso h24 su uno scaffale un enclosure non è un vezzo estetico: protegge da polvere, cavi che passano e mani distratte. Per chiudere il progetto ne ho stampato uno in 3D su misura per l'intero stack — Pi 5, HAT, i quattro drive e l'adattatore di rete 2.5G — con filamento SUNLU, anche loro tra gli sponsor di homelabz.cc.
È il bello di avere una stampante in casa: invece di adattare il NAS a una scatola generica, la scatola la disegni attorno al NAS. L'apertura per il barrel jack dal lato giusto, le feritoie dove servono per far respirare i quattro NVMe, lo spazio per la scheda di rete USB che sporge dal Pi. Nessuna riga del datasheet dell'X1011 ne parla, eppure è la differenza tra un mucchietto di schede su un ripiano e un oggetto che sembra finito.
Per chi ha senso questo NAS
Il Geekworm X1011 ha senso se l'obiettivo è aggiungere storage ridondante e capiente a un homelab basato su Raspberry Pi — backup, media, file-sharing. Con quattro formati M.2 supportati recuperi SSD eterogenei, con RAIDZ2 dormi tranquillo su dischi di seconda mano, e con una 2.5G dedicata ci fai passare i backup di un intero cluster in tempi comodi. Nel mio caso ha fatto esattamente questo, in produzione, e nel momento della verità — un restore vero — ha risposto.
Non è un NAS 10G, e non ha mai finto di esserlo. È un ottimo posto dove far vivere backup e SSD recuperati, in modo ordinato e ridondante, a patto di alimentarlo dal jack giusto e di sistemare una volta il power-management dei dischi. Fatte quelle due cose, sparisce sullo sfondo e lavora — che è esattamente ciò che chiedi a un NAS.
