Maggio 2026, sabato pomeriggio, finestre aperte. Apro il pannello del NAS NVMe di casa e guardo il prezzo storico dei dischi che ho dentro: cinque NVMe gen4 da 1 TB presi nove mesi fa a 70 euro l’uno. Stamattina lo stesso modello è a 200 euro su Amazon. La RAM ha fatto la stessa parabola: il modulo da 32 GB che avevo comprato per il server di casa a fine 2025 lo rivendono oggi a quasi il doppio. Negli ultimi sei mesi i prezzi della memoria sono esplosi e nessuno sa fino a quando salgono. Il punto del post non è speculare sui prezzi: è raccontare come ho costruito uno storage resiliente in casa con ferro che oggi costerebbe il triplo, e perché ZFS in RAID-Z2 è ancora la scelta giusta anche su SSD recuperati. Vedi anche gli altri post di questa rubrica: Production.
Perché TrueNAS bare-metal e non un NAS commerciale
Domanda che mi fanno sempre, anche al WP Meetup di Pisa di marzo. Risposta breve: con un Synology o un QNAP da 800 euro hai una scatola elegante con un’interfaccia educata, ma sotto il cofano gira un kernel chiuso, hardware proprietario, e una matrice di prezzi/feature dove ogni cosa che vuoi davvero (VM, container decenti, snapshot avanzati, replica) finisce sul modello più caro. Per un home lab che vuole imparare e replicare la produzione il rapporto qualità/prezzo non c’è.
TrueNAS è un sistema operativo completo, basato su FreeBSD per la versione storica (Core) e su Debian per la versione corrente (Scale). Si installa bare-metal su qualunque PC, riconosce i dischi, gestisce ZFS nativo, ha un’interfaccia web fatta bene, ed espone i volumi via NFS, SMB, iSCSI, S3 compatibile. Sopra ci si gira un marketplace di applicazioni containerizzate.
Vantaggi pratici per il mio caso:
- Hardware libero. Posso recuperare un PC vecchio di quindici anni con 5 SSD SATA usati e farne un NAS che fa il suo dovere. Posso anche prendere un mini-PC da 280 euro su AliExpress con 5 slot NVMe e farne un NAS che servirebbe una piccola redazione.
- ZFS nativo. Tutto il filesystem è ZFS, che porta con sé snapshot atomici, deduplica opzionale, RAID software integrato, checksum end-to-end. Su Synology/QNAP lo ZFS arriva solo nei modelli enterprise, sui consumer è ext4 o btrfs limitato.
- Apps marketplace. TrueNAS Scale ha un catalogo di applicazioni containerizzate. Negli ultimi rilasci sono passati da un’orchestrazione Kubernetes (pesante, complessa, che molti utenti non capivano) a un Docker registry più diretto. Install one-click di Nextcloud, Home Assistant, Vaultwarden, Plex, Jellyfin, e tutto quello che serve in un home lab.
- Replica nativa tra NAS TrueNAS. Se ho due NAS in casa, posso replicare snapshot ZFS dal primo al secondo con un click, incrementale a livello di blocco.
Il prezzo che paghi è in cura. TrueNAS non è “metti il disco e accendi”. Devi ragionare sul layout dei pool, sul tipo di RAID, sul refresh degli snapshot, sulle policy di scrub mensile. È esattamente il punto: imparare cosa c’è sotto.
ZFS in tre punti
ZFS è il filesystem inventato da Sun a metà anni 2000, oggi mantenuto dalla comunità OpenZFS. Le tre cose che lo rendono diverso da ext4 o NTFS, in due righe ciascuna:
Snapshot atomici a costo zero. Uno snapshot ZFS non è una copia, è un puntatore al filesystem in un dato momento. Si crea in millisecondi, occupa zero spazio finché qualcuno non modifica i dati referenziati. Significa che posso tenere snapshot orari, giornalieri, settimanali per mesi, e occupano solo il delta delle modifiche.
Checksum end-to-end. Ogni blocco scritto ha un checksum SHA-256 calcolato sulla CPU, verificato a ogni lettura. Se un settore del disco si corrompe silenziosamente (bit rot), ZFS se ne accorge, e se hai ridondanza recupera dal mirror o dal parity. Su ext4 il bit rot è invisibile finché non vai a leggere il file e ti accorgi che è cambiato.
RAID software integrato. Niente controller hardware separato. Il RAID è gestito dal filesystem, che sa esattamente quali blocchi sono dati e quali sono parity, e in caso di failure ricostruisce solo i blocchi effettivamente usati (resilver veloce su pool poco pieni).
C’è una quarta proprietà di nicchia, la deduplica, che disattivo sempre. Costa RAM (1 GB ogni TB di pool) e in casi reali risparmia poco rispetto alla compressione standard di ZFS (LZ4, attiva di default, gratis in CPU).
RAID-Z1 vs RAID-Z2 vs mirror: la matematica della resilienza
ZFS ha tre topologie principali:
Mirror (RAID-1). Due dischi che contengono gli stessi dati. Tolleri la perdita di 1 disco. Capacità utile = capacità di un disco. Performance: lettura sommata, scrittura come singolo disco.
RAID-Z1 (paragonabile a RAID-5). N dischi, dati distribuiti, 1 disco di parity. Tolleri la perdita di 1 disco qualsiasi. Capacità utile = (N-1) dischi.
RAID-Z2 (paragonabile a RAID-6). N dischi, dati distribuiti, 2 dischi di parity. Tolleri la perdita di 2 dischi qualsiasi. Capacità utile = (N-2) dischi.
Esiste anche RAID-Z3 (3 parity) per pool molto grandi e long-running, qui non lo uso.
La domanda chiave: perché RAID-Z2 e non RAID-Z1, sacrificando un disco di capacità utile?
Risposta tecnica: il rebuild time dei pool moderni. Quando un disco si rompe in RAID-Z1, sostituisco il disco e parte il resilver (la ricostruzione del disco mancante leggendo gli altri N-1). Su pool grandi (sopra i 2 TB di dati) il resilver può durare ore o giorni. In quel periodo il pool è in degraded mode: se in quelle ore si rompe un secondo disco, perdo tutti i dati. Su SSD/NVMe il rischio è minore (resilver rapido, no testine meccaniche), ma su SSD recuperati la probabilità che un secondo disco abbia un’anomalia mentre il primo si sta sostituendo è tutt’altro che teorica.
Con RAID-Z2 questa finestra non esiste. Posso perdere due dischi in qualsiasi momento, e i dati restano integri. Sostituisco entrambi con calma.
La citazione che uso quando spiego questa scelta a casa: posso perderne due, se ne perdo tre sono un genio. Non scherzo: con RAID-Z2 a 5 dischi servono tre failure simultanei o consecutivi (dentro la finestra del resilver) per perdere il pool. Statisticamente, con dischi sani, è un evento raro. Con dischi recuperati e SSD usati, voglio quel margine.
Lo svantaggio di RAID-Z2: perdo 2 dischi su 5 di capacità utile (40%). Sui pool di backup, dove la priorità è non perdere mai i dati, è un trade-off che firmo subito.
Caso 1: il NAS legacy con 5 SSD SATA recuperati
Il primo NAS è un PC desktop di quindici anni, ATX classico, alimentatore generico, 16 GB di RAM, 5 SSD SATA da 256/512 GB recuperati da vecchi laboratori e workstation in dismissione. Tutti SSD consumer, tutti con qualche ora di scrittura sopra le spalle, alcuni con SMART che segnala blocchi riallocati. Non sono dischi che metterei in produzione enterprise. Sono dischi che fanno benissimo il loro lavoro come storage di casa per documenti, foto, backup secondari.
Layout: pool ZFS da 5 dischi in RAID-Z2. Capacità utile = 3 dischi (~750 GB usabili dopo overhead ZFS). Tolleranza al failure = 2 dischi simultanei.
Sul vecchio PC ho dovuto disabilitare il RAID hardware del controller SATA in BIOS. È un punto che spesso confonde chi parte da PC vecchi: i controller SATA degli anni 2010 spesso espongono una modalità “fakeRAID” o RAID hardware integrato. Se la lascio attiva, ZFS non vede i dischi singoli ma dei volumi aggregati gestiti dal controller, e perdo il controllo che voglio. Soluzione: BIOS, controller SATA in modalità AHCI, RAID disabilitato, ZFS vede tutto.
Configurazione finale dal pannello TrueNAS:
- Pool name:
legacy-pool - Topology: RAID-Z2, 5 drives
- Compression: LZ4 (default, gratis)
- Encryption: nativa ZFS, passphrase salvata fuori dal NAS
- Snapshot policy: ogni ora con retention 24 ore, ogni giorno con retention 30 giorni, ogni settimana con retention 12 settimane
- Scrub mensile (verifica integrità di tutto il pool, raccomandato)
Performance: lettura ~400 MB/s, scrittura ~200 MB/s. Per casa è abbondante. Il limite reale lo vediamo subito.
Caso 2: il NAS NVMe nuovo
Il secondo NAS è un mini-PC consumer cinese con 5 slot NVMe gen4, 32 GB RAM DDR5, CPU Intel N305 a basso consumo. Costo del cabinet: 280 euro. NVMe: 5 unità da 1 TB consumer gen4, comprate a 70 euro l’uno nove mesi fa. Oggi gli stessi NVMe stanno a 200 euro l’uno per via dell’esplosione dei prezzi della memoria. Sono contento di averli presi quando li ho presi.
Layout identico: 5 NVMe in RAID-Z2. Capacità utile = 3 TB. Stessa logica del NAS legacy: i dati sono backup di produzione (snapshot di VM Proxmox, backup di server WordPress, archivio di progetti chiusi), non posso permettermi di perderli. RAID-Z2 anche qui.
Differenze rispetto al legacy:
- Niente RAID hardware da disabilitare. I mini-PC moderni non hanno controller RAID, gli NVMe sono attaccati al PCIe direttamente.
- Performance reali. Lettura sopra i 6 GB/s nelle scritture sequenziali grandi, scrittura intorno a 3 GB/s con ashift=12 e record size 1 MB. Numeri che farebbero invidia a un server enterprise di 5 anni fa.
- Consumi. Il mini-PC con 5 NVMe sotto carico medio sta sotto i 25 W. Sempre acceso, costa 30-40 euro all’anno di corrente.
Sotto un certo profilo di carico domestico (snapshot notturni, sincronizzazione foto, accesso saltuario) il mini-PC NVMe è quasi sempre in idle, sotto i 10 W. È un pezzo di casa che non si sente.
Il limite reale: la rete gigabit
E qui arriva il punto che sposta la prospettiva. Con il NAS NVMe nuovo ho a disposizione, sui dischi, oltre 6 GB/s di lettura sequenziale. Sei. Gigabyte. Al secondo. La rete di casa è gigabit, cioè 1 Gbps = 125 MB/s teorici, 110-120 MB/s reali con overhead TCP. Faccio i conti: sui dischi posso leggere 50 volte più veloce di quanto la rete possa portarmi i dati.
In pratica, qualunque accesso al NAS dal mio laptop o dal media center di casa è limitato dalla rete, non dai dischi. Streaming di un film 4K? La rete porta 25 Mbps di bitrate, serve l’1% della banda gigabit. Backup di una VM da 50 GB? La rete porta 110 MB/s, ci mette circa 8 minuti, e i dischi NVMe sono in attesa per il 99% del tempo.
Conclusione pragmatica: in un home lab con rete gigabit, i dischi meccanici da 7200 rpm sarebbero più che sufficienti per la maggior parte dei casi. Un HDD da 4 TB fa 200 MB/s in lettura sequenziale, supera il limite di rete. Gli NVMe gen4 e gen5 sono uno spreco di banda potenziale a meno che il NAS non serva un cluster locale 10 GbE o non venga usato come storage diretto per VM/LXC su un host che gli sta accanto.
Perché allora ho preso NVMe e non HDD?
- Silenzio. NVMe non hanno parti in movimento. In casa è una dote. Il NAS legacy con 5 SSD SATA è anche lui silenzioso, era un altro motivo della scelta.
- Consumi. 5 NVMe in idle stanno sotto 1 W ciascuno. 5 HDD da 7200 rpm stanno a 5-7 W ciascuno, sempre.
- Latenza. Anche se la banda è limitata dalla rete, la latenza di accesso casuale di un NVMe (sotto 100 microsecondi) è 100 volte migliore di un HDD (10 ms). Sulla quantità di file piccoli (snapshot incrementali, backup di repository git) questo si sente.
- Affidabilità su urti. NVMe in mini-PC consumer sopporta bene urti casuali, un HDD no.
Resta vero il principio: se domani volessi trasformare il NAS NVMe in un server di sviluppo (LXC su Proxmox direttamente sul mini-PC), il senso degli NVMe gen4 esploderebbe. Per ora, sulla rete gigabit, il valore reale che mi danno è silenzio, consumo, latenza.
TrueNAS apps marketplace: Nextcloud in cinque minuti
Il marketplace di TrueNAS Scale è uno dei motivi per cui consiglio TrueNAS a chi parte. Pre-2024 era basato su Kubernetes (pesante, lento da avviare, complesso da debuggare per chi non viene dal mondo K8s). Da fine 2024 i nuovi rilasci sono migrati a un Docker registry più diretto, dove ogni app è un container con configurazione persistente. Install one-click, parametri minimi (porta esposta, dataset di storage, password admin), il container parte e l’app è raggiungibile.
Esempio concreto: Nextcloud sul NAS legacy. Cinque minuti tra il click su “Install” e l’interfaccia di Nextcloud raggiungibile su http://nas-legacy.lan:9000. Storage che punta a un dataset ZFS dedicato (legacy-pool/nextcloud-data), così gli snapshot ZFS automatici proteggono anche i dati Nextcloud senza configurazione aggiuntiva. Database Postgres separato, anche lui in container con storage su dataset proprio.
Le app che uso in casa, in ordine di utilità:
- Nextcloud: foto, video, documenti famiglia, sostituisce iCloud/Google Drive. Sync app su iPhone, accesso da remoto via Tailscale.
- Vaultwarden: password manager Bitwarden-compatibile, leggero (Rust, 50 MB di RAM). Le password stanno cifrate sui device, il server fa solo sync.
- Jellyfin: media center per film e musica, sostituisce Plex (che nelle ultime release è diventato troppo cloud-dipendente).
- Syncthing: sincronizzazione peer-to-peer di cartelle tra device. Lo uso per la cartella di lavoro tra laptop e NAS.
Tutte queste app girano in container Docker su TrueNAS Scale, configurate via interfaccia, con storage persistente su dataset ZFS che gli snapshot automatici proteggono.
Snapshot policy: la rete di sicurezza vera
ZFS senza una policy di snapshot è un’occasione persa. Quella che giro su entrambi i NAS:
- Hourly: ogni ora, retention 24 (un giorno di storia oraria)
- Daily: ogni notte alle 02:00, retention 30 (un mese di storia giornaliera)
- Weekly: ogni domenica alle 03:00, retention 12 (tre mesi di storia settimanale)
- Monthly: il primo del mese alle 04:00, retention 12 (un anno di storia mensile)
Costo in spazio: trascurabile. Gli snapshot occupano solo il delta delle modifiche, e in un home lab con pattern di scrittura tipici (qualche centinaio di MB al giorno di nuovi file) un anno di snapshot occupa una frazione del pool.
Beneficio: in qualunque momento posso navigare lo stato del filesystem in qualunque punto dell’ultima ora, dell’ultimo giorno, dell’ultimo mese, dell’ultimo anno. Se cancello un file per sbaglio, faccio rollback dello snapshot. Se un ransomware cifra il NAS (caso teorico ma possibile), gli snapshot ZFS sono read-only dal lato applicativo, e posso ripristinare uno snapshot precedente. Lo scenario “il bambino di 4 anni cancella tutta la cartella foto matrimonio” è coperto.
Combinato con la replica ZFS verso il secondo NAS (snapshot replicati incrementalmente ogni notte), la rete di sicurezza è doppia: snapshot locali sul primo NAS, replica completa sul secondo.
Cosa non rifarei
Una cosa, secca: avrei preso 6 NVMe invece di 5.
Con 6 NVMe in RAID-Z2 avrei capacità utile = 4 dischi (4 TB) invece di 3, e tolleranza al failure resta 2 dischi. Il costo marginale di un sesto NVMe a 70 euro nove mesi fa era nulla rispetto al beneficio di avere più capacità utile. E il margine “se ne perdo tre sono un genio” sarebbe diventato “se ne perdo tre, capacità utile resta 1 disco”. Non resa, ma sopravvivenza estrema.
Lo stesso ragionamento vale sul NAS legacy: sei dischi invece di cinque sarebbe stata la configurazione giusta, ma erano gli SSD che avevo recuperati e non volevo comprarne un sesto solo per la simmetria.
Il principio che porto a casa: quando dimensioni un pool RAID-Z2, parti dal numero di failure simultanei che vuoi tollerare, e aggiungi sempre un disco oltre il minimo. Il costo marginale è basso, il margine in caso di emergenza è enorme.
I numeri di esercizio
| Metrica | NAS legacy | NAS NVMe |
|---|---|---|
| Hardware | PC desktop ~15 anni | Mini-PC consumer 280 euro |
| Dischi | 5 SSD SATA recuperati | 5 NVMe gen4 1 TB |
| Costo dischi | 0 (recuperati) | 350 euro (70 euro x 5) |
| Topology ZFS | RAID-Z2 | RAID-Z2 |
| Capacità utile | ~750 GB | ~3 TB |
| Tolleranza failure | 2 dischi | 2 dischi |
| Lettura sequenziale | ~400 MB/s | ~6 GB/s |
| Limite di rete | 120 MB/s | 120 MB/s |
| Consumo medio | ~50 W | ~15 W |
Lo storage di casa lo abbiamo iniziato con quello che c’era (cinque SSD recuperati) e ci abbiamo costruito sopra una rete di sicurezza vera: ZFS con snapshot orari, RAID-Z2 che tollera due failure, replica notturna sul secondo NAS. Il NAS NVMe è arrivato dopo, quando il volume di dati e la criticità dei backup hanno giustificato l’investimento. La lezione che mi porto avanti, dopo nove mesi che il sistema gira: in casa il collo di bottiglia è la rete, non i dischi. Se lo sapevo prima, avrei preso HDD da 4 TB a metà del prezzo. Però gli NVMe in idle sotto 1 W sono silenzio puro, e quello, in casa, vale la differenza.