Quando un utente contatta uno specialista in recupero dati per un array guasto (recupero dati RAID), la risposta alla domanda “di quale livello RAID si tratta?” determina tutto quanto segue. RAIDZ1 e RAID 5 condividono lo stesso principio fondamentale — distribuire la parità sui dischi in modo che la perdita di una singola unità non comporti perdita di dati — ma si comportano in modo molto diverso sotto stress. Queste differenze diventano particolarmente concrete quando ci si trova di fronte a un array degradato. Questo articolo analizza cosa significano, in termini di probabilità di guasto, difficoltà di recupero e strumenti effettivamente utilizzabili, le differenze architetturali tra RAIDZ1 (ZFS) e RAID 5.
Contenuti
- Come viene effettivamente costruito ogni array
- Write hole e corruzione silente
- Capacità e prestazioni
- Confronto delle modalità di guasto
- Ricostruzione a rischio con dischi di grandi dimensioni
- Recupero dei dati da RAID‑Z1
- Recupero dati da RAID 5
- RS RAID Retrieve: recupero software per entrambe le configurazioni RAID
- Quale scegliere — e quando conta per il recupero
Entrambe le configurazioni tollerano la perdita di un singolo disco. La somiglianza finisce qui — soprattutto nel momento in cui qualcosa va storto.
Come viene effettivamente costruito ogni array
RAID 5 distribuisce dati e parità in stripe a larghezza fissa su tutti i dischi membri — comunemente 64 KB o 128 KB, impostati dal controller e mai modificati. Ogni scrittura che interessa meno di uno stripe completo attiva il classico ciclo read-modify-write (lettura‑modifica‑scrittura): leggere i dati precedenti, leggere la parità precedente, calcolare la nuova parità e riscrivere entrambi.
Questo ciclo è la causa principale del write hole e di altri problemi analizzati più avanti.
RAIDZ1 è un tipo di vdev in ZFS — lo strato pool è inscindibile dal filesystem. ZFS raggruppa i blocchi di ogni record in uno stripe a larghezza variabile che attraversa tutti i dischi contemporaneamente. Non esistono scritture parziali di stripe; ogni scrittura è sempre uno stripe completo. Questo elimina completamente il ciclo read-modify-write e chiude il problema del write hole.
Un vdev RAIDZ1 non può essere espanso dopo la creazione. È possibile aggiungere un nuovo vdev al pool, ma quello originale rimane fisso. RAID 5 permette l’espansione online in molte implementazioni — una flessibilità che occasionalmente può introdurre nuova corruzione.
Write hole e corruzione silente
Il write hole è un problema specifico del RAID 5: se l’alimentazione viene interrotta tra la scrittura dei nuovi dati e l’aggiornamento della parità, i blocchi dati e la parità non sono più coerenti. La maggior parte dei controller accetta silenziosamente questa incoerenza al successivo avvio e segnala l’array come sano — la parità è semplicemente errata per quella stripe (striscia). Nessuno se ne accorge fino a quando, durante una ricostruzione, non si guasta un secondo disco: a quel punto quella stripe non può essere ricostruita e si verifica una perdita di dati senza alcun preavviso.
Nota per il recupero: quando un RAID 5 sembra aver subito il guasto di due dischi ma soltanto un’unità è effettivamente danneggiata, l’incoerenza dovuta al write hole è un probabile responsabile. Effettuare prima un’immagine bit-a-bit di ciascun disco e analizzare la consistenza della parità sulla stripe sospetta prima di presumere che entrambi i dischi siano guasti.
ZFS evita questo problema grazie alla semantica copy-on-write: i dati non vengono mai sovrascritti sui blocchi esistenti. Se l’alimentazione cade a metà scrittura, ZFS scarta la transazione incompleta al successivo montaggio. L’array è sempre consistente nel momento in cui torna online.
Il secondo problema di integrità è la corruzione silente dei dati (bitrot). I dischi a volte restituiscono dati errati senza segnalare errori. RAID 5 non dispone di checksum con cui confrontare i dati e accetta quanto restituito dall’unità. ZFS calcola un checksum per ogni blocco in scrittura e lo verifica in lettura — quando un blocco non supera il controllo, ZFS lo ricostruisce dalla parità e riscrive i dati corretti. In un RAID 5 la stessa corruzione viene invece trasmessa silenziosamente all’applicazione.
La corruzione silente è più comune di quanto si pensi sugli array in esercizio da tre o più anni. Gli array RAID 5 con dischi datati la manifestano spesso solo quando un tentativo di recovery mette in luce discrepanze di parità su decine di stripe — nessuna delle quali aveva mai generato un allarme del controller.
Capacità e prestazioni
Entrambe le configurazioni utilizzano la stessa formula di capacità: (N − 1) × dimensione del disco, con un minimo di tre unità. Cinque dischi da 8 TB forniscono 32 TB di spazio utilizzabile in entrambe le configurazioni. Le differenze riguardano il comportamento in scrittura:
- RAID 5 con cache hardware con batteria gestisce bene workload misti — la cache assorbe i picchi e gestisce il ciclo di lettura-modifica-scrittura fuori dal percorso critico. In assenza di questa cache, la latenza di scrittura aumenta sensibilmente per le scritture casuali di piccole dimensioni.
- RAIDZ1 offre buone prestazioni per workload sequenziali con grandi dimensioni di record — archiviazione multimediale, backup, immagini di macchine virtuali. Le scritture casuali di piccole dimensioni sono il suo punto debole: ogni scrittura genera una stripe completa, perciò carichi con elevato numero di IOPS, come i database, non sono indicati senza L2ARC e SLOG su NVMe ad alte prestazioni.
- Throughput in lettura sequenziale è sostanzialmente paragonabile — ogni array legge in parallelo da più dischi, quindi nessuno dei due presenta un vantaggio significativo in questo ambito.
Confronto delle modalità di guasto
La tabella seguente illustra gli scenari più comunemente riscontrati nelle attività pratiche di recupero dati.
| Scenario di guasto | RAIDZ1 (ZFS) | RAID 5 (tradizionale) |
|---|---|---|
| Guasto di un singolo disco | L’array rimane operativo; resilver dal pool | L’array rimane operativo; ricostruzione su hot spare o su disco sostitutivo |
| Secondo disco si guasta durante la ricostruzione | Perdita di dati — situazione equivalente a RAID 5 | Perdita di dati — parità insufficiente |
| Perdita di alimentazione durante la scrittura | Copy-on-write (CoW) garantisce consistenza; assenza di corruzione | Rischio di write hole — la parità della stripe interessata può risultare incoerente |
| Bitrot silenzioso / settore danneggiato | I checksum lo rilevano; ZFS ripara utilizzando la parità | Passa silenziosamente all’applicazione; non rilevato |
| Guasto del controller | I pool ZFS possono essere importati su qualsiasi sistema con ZFS — nessuna dipendenza dal controller | I controller proprietari possono vincolare l’accesso; il software RAID (mdadm) è più portabile |
| Corruzione dei metadati ZFS/RAID | ZFS mantiene copie multiple dei metadati; generalmente recuperabile | Perdita del superblocco RAID — i parametri dell’array possono richiedere ricostruzione manuale |
| Ordine dei dischi alterato | ZFS identifica i dischi tramite GUID; l’ordine dei dischi è irrilevante | Ordine errato può generare un array apparentemente valido ma corrotto; rischio di peggiorare la situazione |
| Cancellazione accidentale del pool/array | Le etichette ZFS su ciascun disco vengono preservate; zpool import spesso consente il recupero |
La sovrascrittura del superblocco può rendere il recupero software molto più difficile |
| URE durante la ricostruzione (dischi ad alta capacità) | Lo scrub di ZFS rileva i problemi in anticipo; il resilver salta i blocchi vuoti | La ricostruzione completa della stripe legge ogni settore; qualsiasi URE rende la stripe irrimediabilmente danneggiata |
Ricostruzione a rischio con dischi di grandi dimensioni
Su unità di capacità superiore a circa 4–8 TB, la protezione a parità singola diventa un rischio operativo significativo. La procedura di ricostruzione legge ogni settore di tutti i dischi sopravvissuti — su un disco da 16–20 TB ciò richiede molte ore con carico I/O elevato. I dischi enterprise dichiarano un tasso URE di circa 1 errore ogni 1015 bit; i dischi consumer sono circa dieci volte peggiori. Per un array a quattro dischi con unità da 12 TB, una ricostruzione legge circa 36 TB — imbattersi in un URE è plausibile, non raro.
ZFS offre un vantaggio modesto: il resilvering (resincronizzazione) legge solo i blocchi allocati. Un array occupato al 40% ricostruisce approssimativamente il 40% dei dati. Una ricostruzione RAID 5 legge sempre l’intera capacità del disco indipendentemente dalla quantità di dati presenti — una differenza significativa in termini di tempo e rischio per array parzialmente occupati.
Indicazioni pratiche: Per dischi superiori a 8 TB, passare a RAIDZ2 o RAID 6 (parità doppia). Le configurazioni a parità singola restano ragionevoli per array più piccoli in cui il tempo di ricostruzione rimane inferiore a poche ore.
Recupero dei dati da RAID‑Z1
Il recupero da RAID‑Z1 beneficia della natura auto‑descrittiva di ZFS. Ogni disco contiene quattro copie delle etichette che includono il GUID del pool, la configurazione del vdev e il numero del transaction group (TXG). Collegate i dischi a qualsiasi macchina con ZFS e zpool import identifica e monta il pool — non è necessaria alcuna conoscenza del sistema originale. Un guasto al controller che rende inutilizzabile un RAID 5 non ha alcun effetto su un pool ZFS, purché i dischi siano accessibili fisicamente.
Scenario tipici di recupero RAID‑Z1, in ordine di difficoltà:
- Errori di checksum o I/O durante lo scrub — ZFS marca il vdev come degradato e ripara i blocchi interessati usando la parità. Sostituire il disco degradato con
zpool replace, quindi eseguirezpool scrub. Il resilver ricostruisce solo i blocchi coinvolti. - Metadati ZFS corrotti (uberblock, MOS, object directory) — ZFS conserva più copie dei metadati e può ripristinare lo stato a un transaction group precedente. L’utilità
zdbespone lo stato interno del pool ed è il punto di partenza per l’analisi forense del metadata. - Impossibile importare il pool (due o più dischi guasti, o etichette danneggiate su più dischi) — diventano necessari strumenti software di recupero. Serve uno strumento che comprenda i puntatori di blocco ZFS, la compressione e la geometria a strisce a larghezza variabile, non uno che consideri l’array come un dispositivo a strisce a larghezza fissa.
Per una procedura dettagliata di recupero di pool ZFS in ambienti TrueNAS, consultare Come recuperare i dati da un array RAID‑Z in TrueNAS.
Recupero dati da RAID 5
La difficoltà del recupero da RAID 5 varia ampiamente perché i parametri dell’array non sono memorizzati in un formato universalmente leggibile. I controller hardware conservano l’ordine dei dischi, la dimensione della stripe, l’algoritmo di parità e l’offset dei blocchi in metadati proprietari o nella NVRAM a bordo. Se il controller si guasta, è necessario un ricambio identico (talvolta con la stessa revisione firmware) oppure software in grado di ricostruire la configurazione dai dati grezzi dei dischi. Il RAID 5 software tramite mdadm è più portabile: il superblocco su ciascun disco membro contiene i parametri dell’array. Il superblocco, tuttavia, rappresenta un punto debole: se viene sovrascritto, il riassemblaggio diventa un processo interamente manuale.
I passaggi critici per qualsiasi recupero RAID 5, in ordine:
- Creare immagini settore per settore di ogni disco prima di intervenire. Lavorare sulle immagini anziché sui dischi live consente di ripetere eventuali errori partendo dallo stato originale. Questa è la fase più importante.
- Non permettere al controller di avviare automaticamente una ricostruzione. Se durante la ricostruzione un disco superstite incontra un errore di lettura irrimediabile (URE), la stripe viene persa in modo definitivo. Disabilitare la ricostruzione automatica finché non si dispongono delle immagini.
- Ricostruire l’ordine dei dischi — un ordine errato genera un array apparentemente valido ma corrotto. Lo schema di rotazione della parità nello standard RAID 5 left-symmetric consente di verificarne la correttezza senza dover procedere per tentativi.
- Identificare la dimensione della stripe — valori comuni sono 64 KB, 128 KB e 256 KB. Il valore corretto fa emergere firme riconoscibili dei file system agli offset previsti. Il software di recupero automatizza completamente questa fase.
Per un’analisi dettagliata degli scenari di failure, inclusi i casi in cui un controller riconfigura l’array dopo la sostituzione di un disco, consultare Come recuperare i dati da RAID 5.
RS RAID Retrieve: recupero software per entrambe le configurazioni RAID
Quando l’array RAID non può essere riassemblato dal sistema operativo — controller guasto, superblocco danneggiato o dischi spostati da un NAS su un’altra macchina — la ricostruzione software è il passo corretto prima di inviare i dischi a un laboratorio di recupero dati.
Ripristino automatico di qualsiasi tipo di array RAID
RS RAID Retrieve gestisce entrambi i tipi di array senza richiedere all’operatore di conoscere a priori i parametri. Funzionalità chiave rilevanti per il recupero dati:
- Rilevamento automatico dei parametri per RAID 5 — il software testa configurazioni candidate (ordine dei dischi, dimensione dello stripe, algoritmo di parità) e seleziona quella che produce un file system coerente e montabile. Ciò elimina le congetture che possono provocare ulteriori corruzioni quando il recupero viene tentato senza parametri verificati.
- Ricostruzione del pool ZFS per RAIDZ1 — legge le etichette del pool su ciascun disco, identifica il GUID del pool e la configurazione dei vdev e ricostruisce la geometria dell’array. La ricostruzione riesce anche se alcune etichette sono danneggiate, purché sia disponibile un quorum di etichette leggibili.
- Estrazione parziale oltre la soglia di tolleranza ai guasti — per array RAID 5 o RAID 6 con un numero di dischi guasti superiore a quanto previsto dalla parità, il software estrae i blocchi presenti sui dischi superstiti. Nella pratica ciò permette spesso di recuperare la maggior parte dei dati da un’operazione che altrimenti appare come perdita totale.
- Compatibile con immagini disco — una copia forense di ciascun disco elimina il rischio di un secondo guasto durante il tentativo di recupero.
Importante: Non salvare mai i file recuperati su alcun disco membro dell’array oggetto di recupero. Utilizzare un disco di destinazione separato con capacità superiore allo spazio totale utilizzabile dell’array.
Quale scegliere — e quando conta per il recupero
La scelta incide sul recupero dati oltre che sull’architettura. Selezionare in base all’ambiente operativo:
- Optare per RAIDZ1 se si utilizza già ZFS (TrueNAS, Proxmox, distribuzioni Linux personalizzate). I checksum integrati, la consistenza garantita dal copy-on-write e la portabilità indipendente dal controller riducono la probabilità di uno stato irrecuperabile. Il guasto del controller non compromette un pool ZFS — un vantaggio significativo per il ripristino RAID e il recupero dati ZFS.
- Optare per RAID 5 se l’ambiente si basa su un controller RAID hardware e non è prevista un’infrastruttura ZFS. Eseguire controlli di consistenza regolari, verificare i dati SMART di tutti i dischi prima di qualsiasi ricostruzione, e mantenere un backup aggiornato — confermarne l’integrità prima di avviare la ricostruzione dell’array.
In entrambe le configurazioni, il fattore più importante per l’esito del recupero è ciò che si fa nella prima ora. Interrompere immediatamente tutte le operazioni di scrittura. Non inizializzare, non riformattare e non eseguire fsck / chkdsk sui dischi grezzi. Creare prima le immagini disco (imaging forense) — quindi valutare se procedere con strumenti software di recupero o rivolgersi a un laboratorio specializzato in recupero dati, in base al numero di dischi guasti e all’eventuale danno fisico.
RAIDZ1 e RAID 5 condividono lo stesso rischio fondamentale: il guasto di un secondo disco durante la ricostruzione porta a perdita di dati. Per unità oltre gli 8 TB o per dati effettivamente insostituibili, le configurazioni a parità doppia — RAIDZ2 o RAID 6 — offrono un margine di sicurezza che la singola parità non può garantire.
Domande frequenti
zpool import rileverà automaticamente il pool. Non servono l'hardware, il controller o il sistema operativo originali.
