Il disco è fisicamente presente, SMART non segnala errori e l’array Unraid è stato avviato senza problemi — tuttavia una condivisione è scomparsa e la WebGUI mostra il disco come Unmountable. Si tratta di un evento di corruzione del filesystem, una categoria diversa da un guasto hardware.
La parity non può intervenire in questi casi. Il disco di parity contiene una copia bit-a-bit dei settori dati, non una registrazione dell’integrità della metadata del filesystem. Se il journal o il superblock di un disco dati sono corrotti, la parity preserva fedelmente quella corruzione. Il ripristino richiede l’uso diretto degli strumenti di riparazione del filesystem — xfs_repair per volumi XFS e btrfs check per BTRFS — eseguiti dal terminale di Unraid.
| Situazione | Filesystem | Azione | Esito previsto |
|---|---|---|---|
| Disco non montabile, SMART pulito | XFS | Modalità manutenzione → xfs_repair /dev/sdXp1 → riavvio |
✅ Disco si monta, dati integri |
xfs_repair fallisce: errore dirty log |
XFS |
xfs_repair -L /dev/sdXp1 (azzeramento del journal) |
⚠️ Disco si monta; i file aperti al momento del crash possono essere parziali o vuoti |
| Disco non montabile, SMART pulito | BTRFS |
btrfs scrub (filesystem montato) → btrfs check /dev/sdXp1 (solo lettura) → valutare gli errori |
✅ Errori minori: il disco si monta dopo il controllo |
btrfs check segnala errori su alberi extent o chunk |
BTRFS | Non usare --repair → utilizzare RS RAID Retrieve per il recupero a livello di file prima di qualsiasi riparazione strutturale |
⚠️ Recupero parziale; la riparazione strutturale può causare ulteriori perdite |
| Disco non montabile, SMART segnala settori danneggiati | XFS / BTRFS | RS RAID Retrieve → Analisi completa → recupero su disco separato → pianificare la sostituzione del disco | ⚠️ File recuperabili; hardware in fase di degrado — la riparazione non sarà stabile |
| Strumenti da terminale non riescono a montare il disco; file mancanti dopo la riparazione | XFS / BTRFS | Collegare i dischi a un PC Windows → RS RAID Retrieve → Scansione rapida o Analisi completa | ✅ Recupero a livello di file senza montare il filesystem |
| È stato avviato il format su un disco non montabile | Qualsiasi | Nessuna possibilità di recupero — la parity ora riflette un disco vuoto | ❌ Dati persi in modo permanente |
Come Unraid utilizza file system indipendenti per disco
In uno scenario di guasto logico, l’architettura di Unraid è il fattore determinante per capire quali componenti risultano danneggiati e quali conservano l’integrità dei dati.
A differenza di RAID 5 o RAID 6, in cui una stripe si estende su più dischi fisici, Unraid scrive i file per intero su singoli dischi. Ogni disco dati è un volume autonomo — formattato come XFS o BTRFS — montato in modo indipendente dal sistema operativo. Lo strato array di Unraid sovrastante gestisce l’aggregazione delle condivisioni e gli aggiornamenti della parità, mentre lo strato del file system sottostante è il tradizionale stack Linux.
XFS
Predefinito in UnraidCaratteristiche rilevanti per la riparazione del filesystem XFS:
- Recupero dei metadati basato su journal
- La riparazione richiede che il disco sia smontato
- In Unraid: richiede la Modalità manutenzione
- Strumento principale:
xfs_repair - La corruzione del log richiede il flag
-L(operazione distruttiva)
BTRFS
Opzionale in UnraidCaratteristiche rilevanti per la riparazione:
- Copy-on-write; checksum integrati per dati e metadati
- La verifica può essere eseguita su un volume montato
- La modalità di riparazione (
--repair) è aggressiva — usarla con cautela - Strumenti principali:
btrfs check,btrfs scrub - Recupero dei sotto‑volumi possibile anche in caso di corruzione parziale
Conseguenza pratica di questa architettura: la corruzione del filesystem sul Disco 3 non influisce sui filesystem del Disco 1, Disco 2 o di altri dischi. I dati di ciascun disco sono isolati. Si interviene su un singolo volume, non sull’intero array. L’eccezione è il disco di parità: non contiene un filesystem e non deve mai essere sottoposto a strumenti di riparazione del filesystem.
Il disco di parità non contiene un filesystem — non eseguire mai xfs_repair o btrfs check su di esso.
Il disco di parità memorizza dati XOR su offset di settore fissi. Non dispone di una tabella delle partizioni visibile agli strumenti per filesystem: tentare di ripararlo come se fosse un filesystem corromperà i dati di parità e lascerà l’intero array senza protezione. Identificare il disco di parità nell’interfaccia Web (WebGUI) prima di aprire qualsiasi terminale.
Cause della corruzione del filesystem in Unraid
La corruzione del filesystem in Unraid è quasi sempre ricondotta a una delle tre cause principali. Comprendere quale si applica influisce sull’approccio di ripristino e sulle procedure per il controllo del filesystem e la tutela dell’integrità dei dati.
Spegnimento improprio
Una perdita di alimentazione o un riavvio forzato mentre l’array è attivo lascia operazioni di scrittura in corso non confermate. Il journal del filesystem contiene transazioni incomplete, con possibile corruzione del filesystem. Al successivo montaggio il filesystem rileva l’incoerenza e impedisce il montaggio. Questa è la causa più comune.
RAM difettosa
La memoria ECC non è presente di default nella maggior parte delle installazioni di Unraid. Un singolo flip di bit in un buffer di scrittura può corrompere i metadati del filesystem — voci di directory, tabelle inode o il superblocco — in modi che possono apparire identici a un’interruzione dell’alimentazione, ma sono più difficili da prevenire e possono compromettere l’integrità dei dati.
Errori dei settori del disco
I settori riallocati o in attesa nei dati SMART di un’unità indicano aree del disco che non possono essere lette o scritte in modo affidabile. Se le strutture di metadati finiscono su questi settori, il filesystem si corrompe anche in assenza di interruzioni di alimentazione. Un disco che mostra corruzione del filesystem con conteggi SMART diversi da zero indica probabilmente un guasto hardware sottostante.
Prima di eseguire qualsiasi strumento di riparazione — controllare prima i dati SMART:
- Aprire la WebGUI di Unraid → scheda Main → fare clic sul disco interessato → rapporto SMART.
- Se
Reallocated_Sector_Ct,Current_Pending_SectoroOffline_Uncorrectablesono diversi da zero, la riparazione del filesystem può riuscire temporaneamente ma l’hardware sottostante è in guasto. Pianificare la sostituzione del disco indipendentemente dall’esito della riparazione. - Se i dati SMART risultano puliti, la corruzione è probabilmente un evento isolato dovuto a un’interruzione di alimentazione o a un problema software e la riparazione ha maggiori probabilità di mantenersi a lungo termine.
Il pulsante Format: cosa fa realmente e perché non premerlo
Quando un disco assume lo stato “Unmountable” (impossibile da montare), l’interfaccia web di Unraid (WebGUI) visualizza un’opzione “Format” accanto ai pulsanti diagnostici. Per gli utenti che non conoscono il funzionamento della parità in Unraid, questo può indurre in errore: si può erroneamente ritenere che premendo “Format” il disco venga ripristinato e che la parità ricostruisca automaticamente i file persi, generando il rischio di perdita dati e compromissione dell’array.
Format non recupera i dati. Li distrugge in modo permanente.
Premere il pulsante “Format” su un disco non montabile cancella completamente il filesystem e crea un nuovo volume vuoto. La parità viene quindi ricalcolata rispetto a questo disco ora vuoto. I dati originali sono perduti — non corrotti, non recuperabili, definitivamente cancellati. La parità rifletterà correttamente il disco vuoto, rendendo qualsiasi tentativo successivo di recupero inutile.
Questo è lo scenario di perdita dati più comune in Unraid, dopo i guasti hardware, ed è interamente causato dall’utente. I dati presenti sul disco prima della formattazione erano, nella maggior parte dei casi, recuperabili con gli strumenti di recupero dati per Unraid descritti in questo articolo.
La sequenza corretta quando un disco non è montabile: diagnosticare prima, riparare poi, formattare solo come estremo ultimo ricorso — e soltanto dopo che tutti i dati siano stati già recuperati in un’altra posizione.
Riparazione di un disco XFS non montabile in Unraid: xfs_repair passo per passo
xfs_repair richiede che il filesystem di destinazione sia completamente smontato prima dell’esecuzione. In un array Unraid in esecuzione, tutti i dischi dati sono montati. Per smontare un disco specifico per la riparazione senza interrompere tutte le condivisioni, è necessario porre Unraid in Modalità manutenzione — una modalità di avvio che attiva l’array senza montare le condivisioni e senza mettere i dischi in uso.
Passo 1: Avviare l’array in Modalità manutenzione
Dal WebGUI di Unraid, aprire la sezione Main. Prima di fare clic su Start, selezionare la casella Maintenance Mode (Modalità manutenzione) che appare sotto i comandi di avvio dell’array. Fare clic su Start. L’array si avvia, ma i dischi non vengono montati nelle condivisioni. Questo è lo stato richiesto per l’esecuzione di xfs_repair e per la riparazione del filesystem XFS.
Unraid 7.0 e versioni successive: utilizzare prima i pulsanti di riparazione della WebGUI.
A partire da Unraid 7.0, la WebGUI espone i pulsanti CHECK e FIX direttamente nella vista dei dischi. Questi eseguono automaticamente xfs_repair con i flag appropriati. Se la tua versione li supporta, provare prima la procedura tramite interfaccia web prima di aprire un terminale — il risultato è identico, ma l’interfaccia si occupa per te della Modalità manutenzione e della selezione del percorso del dispositivo.
Fase 2: Identificare il percorso dispositivo corretto
Questa fase evita un errore comune e potenzialmente grave. In Unraid, ogni disco dati dispone di due percorsi dispositivo:
-
/dev/mdXp1— il dispositivo MD (array), gestito dal livello array di Unraid. Non utilizzare questo percorso per xfs_repair. -
/dev/sdXp1— la partizione del disco grezzo, percorso diretto all’hardware. Usare questo percorso.
Per individuare quale /dev/sdX corrisponde al disco da riparare, aprire un terminale (dalla WebGUI: Tools → Terminal, o tramite SSH) ed eseguire:
# Elenca i dischi con le corrispondenti assegnazioni di slot in Unraid ls -la /dev/disk/by-id/
Confrontare il numero di serie indicato nel report SMART della WebGUI con il collegamento simbolico in /dev/disk/by-id/ per confermare il percorso dispositivo prima di procedere.
Fase 3: eseguire xfs_repair — passata standard
# Sostituire sdX con l'identificativo del dispositivo reale (es. sdb, sdc) xfs_repair /dev/sdXp1
xfs_repair eseguirà diverse fasi, verificando inode, directory e la mappa dello spazio libero del file system. Su un journal integro, applicherà le transazioni non confermate presenti nel journal e terminerà con un riepilogo. Se xfs_repair completa senza errori fatali, provare a montare la partizione riavviando il sistema fuori dalla modalità di manutenzione.
Passo 4: se xfs_repair fallisce a causa di un journal sporco — opzione -L
Se la riparazione termina con un messaggio come “ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed” e si rifiuta di proseguire, il journal XFS è illeggibile. L’unica opzione a questo punto è azzerare il journal usando l’opzione -L.
L’opzione -L cancella il journal — cosa significa
L’azzeramento del journal obbliga xfs_repair ad abbandonare eventuali transazioni di metadati in sospeso non ancora registrate su disco. In pratica, i file che erano in fase di scrittura al momento del crash possono andare persi parzialmente o risultare con dimensione zero. I file completati prima dell’evento di corruzione del filesystem XFS non vengono interessati.
Utilizzare -L solo dopo che un tentativo di riparazione standard con xfs_repair si è rivelato inefficace. Non impiegare questa opzione come primo intervento.
# Force repair by zeroing the dirty log # Use only after standard xfs_repair has failed xfs_repair -L /dev/sdXp1
Passo 5: Verificare la riparazione
Dopo una riparazione riuscita, eseguire nuovamente xfs_repair in modalità sola verifica (opzione -n) per accertarsi che non siano rimaste incoerenze nel filesystem XFS:
# Controllo simulato — non apporta modifiche, segnala eventuali problemi residui xfs_repair -n /dev/sdXp1
Se il controllo simulato risulta pulito, riavviare normalmente (senza modalità di manutenzione). Il disco dovrebbe montarsi e la relativa condivisione dovrebbe riapparire. Eseguire successivamente un controllo della parità non correttivo per confermare la validità della parità.
✓ Output previsto dopo una riparazione riuscita
xfs_repair stamperà le righe di completamento delle fasi (Phase 1–7) e terminerà con: «done». Non devono comparire errori nelle fasi 3–7. Eventuali file spostati in /lost+found durante la riparazione saranno accessibili lì dopo che il disco è stato montato — possono essere riposizionati nelle loro cartelle originali se se ne conosce la destinazione.
Riparazione di un volume BTRFS corrotto in Unraid
La corruzione del filesystem BTRFS in Unraid è meno comune rispetto a XFS, in parte perché BTRFS adotta la semantica copy-on-write (COW): non sovrascrive mai i dati esistenti, ma scrive nuove versioni dei blocchi in aree libere. Questo lo rende più resistente alle scritture incomplete. Tuttavia la corruzione dei metadati può comunque verificarsi e la procedura di ripristino per un volume BTRFS differisce da quella di XFS sotto diversi aspetti rilevanti.
Passo 1: Iniziare con btrfs scrub — non con btrfs check
Prima di eseguire qualsiasi riparazione, avviare uno scrub sul volume montato. A differenza di xfs_repair, lo scrub di Btrfs può essere eseguito mentre il file system è montato. Lo scrub verifica i checksum di tutti i blocchi di dati e metadati e segnala eventuali discrepanze. Su un volume Unraid a disco singolo senza RAID Btrfs, lo scrub non può correggere automaticamente gli errori — non esistono copie ridondanti — ma individua con precisione i blocchi danneggiati, informazione utile per decidere la strategia di riparazione del file system. Avviare l’array normalmente (non in modalità di manutenzione) e aprire un terminale:
# Replace /mnt/diskX with the actual Unraid disk mount path btrfs scrub start /mnt/diskX # Monitor progress btrfs scrub status /mnt/diskX
Se lo scrub termina senza errori, il disco è integro e lo stato “Unmountable” potrebbe essere stato un episodio transitorio. Riavviare il sistema e verificare se il disco viene montato normalmente.
Passo 2: Eseguire btrfs check in modalità di sola lettura
Se lo scrub (btrfs scrub) segnala errori o il disco rimane non smontabile dopo un tentativo di scrub, procedere con btrfs check. Prima di tutto arrestare l’array per poter smontare il disco, quindi eseguire il controllo in modalità di sola lettura per valutare l’entità del danneggiamento prima di tentare qualsiasi riparazione:
# Stop array first, then check without making changes btrfs check /dev/sdXp1
Esaminare attentamente l’output. btrfs check elencherà errori specifici sugli alberi del filesystem e oggetti orfani. Incoerenze di entità limitata — inode orfani, riferimenti inversi errati alla root — possono essere riparate in sicurezza. Errori nell’albero degli extent o nell’albero dei chunk indicano danni strutturali più profondi e il recupero tramite la modalità di riparazione potrebbe risultare incompleto.
Passaggio 3: Modalità di riparazione — usare con cautela
btrfs check –repair può causare ulteriore perdita di dati
A differenza di xfs_repair, progettato per essere eseguito routinariamente, gli sviluppatori di BTRFS sconsigliano esplicitamente l’uso dell’opzione --repair senza il supporto di uno sviluppatore o senza aver prima creato un’immagine del disco. In caso di corruzione grave dell’albero degli extent, la modalità di riparazione potrebbe cancellare file che ritiene orfani anziché recuperarli.
Se il controllo in sola lettura segnala errori nell’albero degli extent e sul disco sono presenti dati insostituibili, evita la modalità --repair e procedi direttamente con RS RAID Retrieve per il recupero a livello di file (recupero dati BTRFS) prima di tentare qualsiasi riparazione strutturale.
Per corruzioni lievi e ben circoscritte — errori nella cache dello spazio libero (free-space cache), inode orfani, riferimenti di root errati — la modalità --repair è generalmente considerata sicura:
# Only for minor, well-scoped corruption # Image the disk first if data is critical btrfs check --repair /dev/sdXp1
Passo 4: Recupero dei singoli sottovolumi
Se l’albero principale Btrfs è danneggiato ma i sottovolumi contenenti i dati sono integri, può essere possibile montare direttamente un singolo sottovolume (ad es. usando l’opzione subvolid) e copiarne i dati senza riparare l’intero albero:
# Elenca i sottovolumi su un volume parzialmente leggibile btrfs subvolume list /mnt/diskX # Monta un sottovolume specifico per ID se il mount predefinito fallisce mount -o subvolid=256 /dev/sdXp1 /mnt/recovery_point
Se un sottovolume viene montato con successo, copiare immediatamente i dati su un disco sano prima di procedere con ulteriori operazioni di riparazione sul volume danneggiato.
Quando gli strumenti da terminale falliscono: recuperare file da un disco Unraid corrotto con RS RAID Retrieve
Sia xfs_repair che btrfs check agiscono a livello della struttura del filesystem: tentano di rendere nuovamente montabile il volume. Quando ciò non è possibile a causa di una grave corruzione dei metadati, oppure quando la riparazione termina ma i file risultano ancora mancanti o vuoti, il passo successivo è il recupero a livello di file dai dati grezzi del disco (raw data).
È qui che interviene RS RAID Retrieve. Il programma legge direttamente i dati dei settori, aggira le strutture di filesystem danneggiate e ricostruisce alberi di directory e contenuti dei file a partire dalle tabelle di allocazione sottostanti. Supporta sia XFS che BTRFS — filesystem che Windows non può montare nativamente — ed è quindi uno strumento adatto per il recupero dati RAID e il recupero file da dischi Unraid corrotti, tipicamente eseguito collegando il disco a un PC Windows per l’analisi e l’estrazione.
Cosa fa RS RAID Retrieve con un disco Unraid corrotto
Il programma individua la struttura dell’array Unraid a partire dai metadati del disco, ricostruisce il volume logico e quindi esegue la scansione del file system XFS a livello di settore. Anche quando xfs_repair ha spostato file in /lost+found o i metadati sono troppo danneggiati per consentire il montaggio, il software può spesso recuperare il contenuto dei file e i percorsi originali delle directory leggendo direttamente i dati di allocazione. Questo approccio di recupero dati a basso livello è particolarmente utile per il recupero RAID e il ripristino di file da dischi corrotti.
Ripristino automatico di qualsiasi tipo di array RAID
Arrestare il server Unraid e rimuovere il disco interessato
Arrestare il sistema in modo pulito se è ancora accessibile. Collegare il disco corrotto a un PC Windows — utilizzare, ove possibile, una connessione SATA diretta. Collegare inoltre i restanti dischi dell’array e il disco di parità; RS RAID Retrieve li impiega per ricostruire la configurazione completa dell’array e identificare correttamente il ruolo di ciascun disco nella struttura di Unraid, operazione essenziale per il recupero dati RAID.
Avvio di RS RAID Retrieve — rilevamento automatico dell’array
All’avvio, il programma esegue la scansione di tutti i dischi collegati, legge i metadati Unraid da ciascuno e ricostruisce automaticamente la configurazione dell’array. Il disco corrotto viene visualizzato nell’elenco delle unità insieme ai membri integri. Windows non assegna lettere di unità ai volumi XFS o BTRFS; ciò è previsto e non indica un problema di connessione.
Selezionare il tipo di scansione in base all’entità della corruzione
Fare clic con il tasto destro sull’array ricostruito o sul singolo disco nel Gestore unità per avviare il recupero dati e selezionare Apri. Per una corruzione del filesystem in cui la tabella delle partizioni e il superblocco sono integri, una Scansione rapida è sufficiente: mostrerà l’albero delle directory con i file recuperabili evidenziati. Se il superblocco è danneggiato o la Scansione rapida restituisce un albero file vuoto, eseguire una Analisi completa — questa esegue una scansione settore per settore basata su firme (scansione per firme) e può recuperare file anche quando i metadati delle directory sono assenti, sebbene nomi e percorsi dei file potrebbero non essere preservati.
Anteprima dei file prima di procedere al recupero
RS RAID Retrieve permette di visualizzare in anteprima il contenuto dei file prima di scrivere qualsiasi dato su disco, funzione utile nel recupero RAID e nel recupero dati. Utilizzare questa funzionalità per verificare l’integrità dei file da recuperare: aprire un campione di documenti, immagini e archivi direttamente nel riquadro di anteprima. I file che vengono visualizzati correttamente in anteprima si ripristineranno correttamente; i file che appaiono vuoti o corrotti in anteprima difficilmente consentono il recupero di contenuti utilizzabili, indipendentemente dallo strumento impiegato.
Copiare i file recuperati in una destinazione integra
Selezionare i file e le directory da recuperare (recupero dati), fare clic su Recovery e specificare un percorso di output su un’unità separata e integra. Non ripristinare i file sul disco di origine né su alcuna unità attualmente presente nell’array Unraid. Dopo la copia, verificare un campione dei file recuperati prima di considerare il recupero completato.
Esiti del recupero per tipo di corruzione dei dati
Corruzione del journal / arresto non pulito
Si tratta dello scenario più recuperabile in caso di corruzione del journal o di arresto non pulito. Le strutture di allocazione dei file risultano in genere intatte. RS RAID Retrieve è in grado di ricostruire l’intero albero delle directory e recuperare i file con i nomi e i percorsi originali. In genere è sufficiente Fast Scan (scansione rapida).
Corruzione parziale dei metadati
Gli alberi delle directory potrebbero essere incompleti. Alcuni file possono comparire senza nome nella vista di recupero. Il contenuto dei file è spesso integro anche quando i metadati risultano danneggiati. L’Analisi completa recupera un maggior numero di file a scapito della perdita della struttura originale delle directory nelle aree interessate.
Superblocco e albero degli extent distrutti
Se il disco è stato formattato dopo essere diventato non montabile, oppure se il danneggiamento dei settori fisici ha distrutto il superblocco primario e quello di backup, il recupero dei dati a livello di file non è possibile. Questo risultato è raro in scenari di guasto puramente logico, ma comune quando è stato premuto il pulsante Format o quando il disco presentava un degrado hardware avanzato.
La corruzione del filesystem in Unraid è recuperabile nella maggior parte dei casi — a condizione che venga seguita la sequenza corretta e che il pulsante Format non venga premuto prima di mettere i dati in sicurezza. Il percorso decisionale è semplice:
Un guasto logico non implica automaticamente che la parità sia invalida — tuttavia non va considerata affidabile senza verifiche.
Dopo una riparazione del filesystem, il disco di parità continuerà a contenere l’XOR dei settori del disco — inclusi i settori che erano corrotti prima della riparazione. Una volta che il disco è stato ripristinato e si monta correttamente, eseguite un controllo parità non correttivo per individuare eventuali incongruenze. Se vengono rilevati errori, eseguite un controllo parità correttivo per riallineare la parità allo stato corrente del disco. Effettuate queste operazioni prima che l’array torni in uso produttivo.
Domande frequenti
ddrescue -d -r3 /dev/sdXp1 /path/to/image.img /path/to/map.log. Una volta ottenuta l'immagine, esegui xfs_repair sul file immagine invece che sul disco attivo — xfs_repair /path/to/image.img. Se la riparazione produce un risultato peggiore di quello atteso, avrai comunque la copia originale a livello di settori da cui ripartire. Un vincolo: la destinazione per l'immagine deve essere un disco sufficientemente grande da contenere l'intera dimensione raw della partizione di origine, non solo lo spazio effettivamente utilizzato.
/lost+found e li rinomina con il numero di inode. Se ricordi la dimensione approssimativa dei file, le date di creazione o il tipo di contenuto, puoi restringere i candidati usando stat per controllare i metadati dell'inode e file per identificare il tipo in base all'intestazione binaria — per esempio file /mnt/diskX/lost+found/123456789 ti dirà se un inode contiene un JPEG, un container video, un archivio compresso, ecc. Per i file multimediali la maggior parte può essere identificata e rinominata in base al contenuto; per database o dati di applicazioni privi di un'intestazione leggibile l'identificazione è più complicata e può richiedere il confronto delle dimensioni con backup integri di riferimento o l'analisi dei log dell'applicazione che registravano i nomi originali dei file.
