RAID-Z2 può mantenere disponibile un vdev ZFS quando si guastano due dei suoi dischi. Non protegge da ogni perdita di dati e non diventa più tollerante aggiungendo semplicemente un sesto disco. Per un NAS affidabile servono anche copie recuperabili, controllo dello stato e una procedura di ripristino.
Uso TrueNAS nel mio ambiente e considero lo storage una parte del sistema da progettare, non un accessorio a cui collegare dischi. Qui spiego come ragionare su RAID-Z2 e sulle alternative. Gli esempi di capacità sono calcoli illustrativi, non benchmark o descrizioni di uno specifico NAS Romiltec.
Pool, vdev e dischi: dove vale la ridondanza
Un pool ZFS contiene uno o più vdev. Un vdev può essere un mirror o usare una topologia RAID-Z. È a quel livello che va ragionata la tolleranza ai guasti: perdere un vdev dati può rendere inutilizzabile l’intero pool.
La documentazione OpenZFS sulle topologie distingue RAID-Z1, RAID-Z2 e RAID-Z3 secondo il livello di parità. Per un singolo vdev RAID-Z2 il margine è di due dischi guasti, anche se il vdev ne contiene cinque, sei o più. Non pianificherei mai un recupero contando di sopravvivere alla perdita di un terzo disco.
Capacità: una stima utile, con i suoi limiti
Con dischi uguali, una prima approssimazione per RAID-Z2 è (numero dischi − 2) × capacità del disco. Cinque unità da 1 TB danno circa 3 TB prima di overhead, riserve e differenze tra TB e TiB. Sei unità aumentano la capacità approssimata a 4 TB; la tolleranza resta di due guasti.
Con unità di dimensioni diverse il disco più piccolo limita la capacità utilizzabile nella configurazione ordinaria del vdev. È un aspetto importante se recuperi SSD da macchine diverse: sommare le etichette dei dischi produce una previsione sbagliata.
| Configurazione illustrativa | Capacità grezza disponibile per i dati, approssimata | Guasti tollerati |
|---|---|---|
| Mirror di due dischi da 1 TB | 1 TB | Uno nel mirror |
| RAID-Z1, cinque dischi da 1 TB | 4 TB | Uno nel vdev |
| RAID-Z2, cinque dischi da 1 TB | 3 TB | Due nel vdev |
| RAID-Z2, sei dischi da 1 TB | 4 TB | Due nel vdev |
Dimensionerei il pool lasciando spazio per crescita, snapshot e manutenzione. La capacità nominale non è un obiettivo di riempimento.
SSD recuperati: cosa guardare prima di usarli
Un disco che viene riconosciuto dal sistema non è automaticamente adatto a custodire l’unica copia di un progetto. Controllerei stato SMART, errori registrati, usura dichiarata dal dispositivo, interfaccia e temperature sotto carico. Verificherei anche alimentazione, cavi e controller: più dischi possono diventare irraggiungibili per un guasto comune.
Dischi provenienti dallo stesso lotto o dallo stesso ambiente possono avere usura simile. La ridondanza aiuta contro alcuni guasti, ma non rende indipendenti componenti che condividono storia e alimentatore. Per gli esperimenti il recupero di hardware è sensato; per dati importanti serve una copia altrove.
Snapshot, scrub e backup coprono problemi diversi
Uno snapshot conserva una vista precedente del dataset. È rapido da creare, ma i blocchi che deve trattenere occupano spazio quando i dati cambiano o vengono cancellati. Con file grandi riscritti spesso, il consumo può essere rilevante.
Lo scrub legge e verifica i dati, consentendo a ZFS di usare la ridondanza disponibile per correggere gli errori recuperabili. Il checksum non deve essere descritto come “sempre SHA-256”: algoritmo e proprietà dipendono dalla configurazione, documentata nelle proprietà ZFS.
Un backup conserva una copia recuperabile con un grado di indipendenza dal sistema originale. Uno snapshot nello stesso pool non salva da furto o perdita del pool. Una replica può propagare modifiche indesiderate; la sua utilità dipende da retention, permessi e possibilità di recuperare uno stato precedente. Le funzioni di protezione dati TrueNAS vanno combinate in base a questi rischi.
Quando la rete limita il valore degli NVMe
Una rete da 1 Gbit/s ha un limite teorico di 125 MB/s prima degli overhead: il calcolo è un miliardo di bit diviso otto. Se trasferisci un singolo file sequenziale su quella rete, aumentare molto la velocità dei dischi può non cambiare il tempo percepito.
Questo non rende gli SSD inutili. Accessi casuali, più utenti, applicazioni locali, rumorosità e consumi sono altri criteri. Misurerei separatamente il disco e il trasferimento SMB o NFS dal dispositivo che uso davvero, senza dedurre l’uno dall’altro.
La prova che farei prima di fidarmi del NAS
Creerei un insieme di dati di prova, lo copierei nella destinazione di backup e lo ripristinerei in una directory separata, confrontando file e contenuto. Proverei anche il recupero di un file cancellato da uno snapshot, senza un rollback indiscriminato dell’intero dataset.
Se il NAS ospita backup Proxmox, aggiungerei una prova di restore della VM e dell’applicazione. È quel passaggio a chiudere il progetto: sapere quante unità possono guastarsi è utile, sapere come recuperare il servizio lo rende operativo.