QNAP volume inaccessibile dopo rebuild raid

L'accensione del led "rosso" su un QNAP corrisponde al fallimento di una unità disco. Tale fallimento nella maggior parte dei casi corrisponde alla rilevazione di blocchi danneggiati o ad errore del drive. Il sistema RAID 5 o 6 automaticamente aggiorna i propri medatati e esclude il drive dal sistema posizionandosi nella modalità "degraded".

Durante l'esercizio in modalità degradata, è anche possibile che il volume venga montato in sola lettura, impedendo modifiche ai dati contenuti nella partizione.

L'esercizio in modalità "degradata" prevede che i blocchi contenuti nel disco danneggiati vengano recuperati dai blocchi di parità presenti negli altri dischi. In una modalità degradata il raid è perfettamente operativo in termini funzionali ma è imperativo eseguire il rebuild sostituendo il drive danneggiato in quanto in caso di rottura il sistema subirebbe un blocco definitivo.

Tipico fermo operativo di un RAID5

Lo scenario più comune tra i danni subiti dai sistemi raid è la mancata sostituzione del disco danneggiato ed una prolungata attività dell'array in modalità degradata.
La semplice rilevazione di un blocco danneggiato in questi casi blocca completamente l'attività del sistema imponendo una procedura di recovery offline dei dischi.
In questi casi, il recovery risulta complesso e rischioso in quanto l'ultimo drive che ha subito il degrado è indispensabile per il recupero dei dati e il centro specializzato che deve intervenire sull'array ha pochissime alternative per ottenere un risultato di qualità. 

Sostituzione del drive danneggiato e procedura di ricostruzione dell'array

La sostituzione del drive danneggiato e la ricostruzione dell'array deve essere condotta con molta attenzione.
E' importante utilizzare un disco nuovo o ricertificato da inserire nello slot del disco danneggiato e prima di iniziare la procedura di rebuild, valutare se nell'array ci sono file importanti di cui fare un backup preliminare.

Principi di rebuild: Discovery delle aree zombie e blocco dell'array

Durante un rebuild tutti i blocchi contenuti in tutti i dischi dell'array vengono letti, ne viene generato uno xor ed il risultato viene posizionato sul nuovo disco appena sostituito.
La particolarità del rebuild è che tutte le zone vengono lette, anche zone in cui sono posizionati vecchi dati di backup inutilizzati da molto tempo, che potrebbero essere interessati da errori non rilevati precedentemente.

E' comune che il discovery delle zone danneggiate avvenga in un contesto di lettura/scrittura. E' possibile che aree dei dischi accedute con poca frequenza siano danneggiate e l'errore non venga rilevato fino alla procedura di rebuild.
In questi casi il rebuild fallirebbe e verrebbero esposti altri dischi danneggiati bloccando la procedura di ricostruzione e la funzionalità del raid.
In questi casi è necessario spegnere il QNAP ed estrarre i dischi singoli che dovranno essere sottoposti ad una procedura di recovery necessariamente off-line.

Rebuild Fallito e blocco dell'array : Un caso reale di danneggiamento QNAP

Eseguire la ricostruzione di un volume degradato, sebbene possa sembrare una procedura comune, comporta dei rischi.
Il rebuild di un blocco raid è basato su un vettore matematico XOR ^.

Per calcolare il contenuto del disco 3 danneggiato viene usata la seguente formula logica:

DISCO 1 ^ DISCO 2 = DISCO 3

E' importante ricordare che il calcolo xor è puramente matematico è non ha alcun legame con i dati contenuti.
Se Durante la ricostruzione di un blocco xor viene inserito un vettore contenente garbage o un buffer sporco il risultato saranno dati danneggiati con una parità corretta.

In un caso reale un QNAP TOWER TS-464 segnalava un errore disco ed il proprietario lo ha correttamente sostituito.
Al termine della procedura di rebuild, i dati risultavano essere inaccessibili.

Analisi delle parità della configurazione iniziale

L'analisi condotta in laboratorio sulla device danneggiata ha dimostrato che il drive del QNAP danneggiato, in realtà non avesse alcun problema e che non ci fossero settori danneggiati.

S.M.A.R.T. drive status................. : GOOD
-----+------------------------------+-------+-------
  ID | Attribute                    | State | Value 
-----+------------------------------+-------+-------
   5 | Reallocated Sector Count     | Ok    |     0 
 196 | Reallocation Events Count    | Ok    |     0 
 197 | Current Pending Sector Count | Ok    |     0 
 198 | Uncorrectable Sector Count   | Ok    |     0 
-----+------------------------------+-------+-------
S.M.A.R.T............................... : Ok
 
Look ahead.............................. : Granted
Write cache............................. : Granted
Error recovery control.................. : Supported

L'analisi delle parità condotte sui dischi online e quello danneggiato ha inoltre dimostrato che le parità fossero perfettamente allineate. Il drive ricostruito al termine della procedura di rebuild risultava essere perfettamente speculare a quello sostituito.

Analisi dei metadati di file system

L'analisi del file system su qnap ha evidenziato la corruzione del superblock principale del file system ext4 che risultava essere sostituito da binary garbage.

E' dunque possibile che un "buffer sporco" abbia compromesso il file system probabilmente in fase di smontaggio del file system.
L'array in modalità degradata e quello ricostruito presentano lo stesso contenuto. E' possibile quindi che tale scrittura fallita fosse precedente lo stop operativo ed il rebuild.

La ricostruzione del file system è stata prodotta utilizzando elementi di backup del superblock principale in sostituzione degli elementi corrotti. La procedura di fixing del superblock è fondamentale per garantire le mappature corrette e gli offset dei Block Groups.

Conclusioni e valutazioni Finali

Il rebuild di un Raid degradato in seguito ad un fallimento di una unità puo' essere rischioso in quanto durante la ricostruzione dell'array zone danneggiate di cui non si era verificato il discovery possono essere esposte e bloccare definitivamente il processo di riparazione.
Se l'array è ancora operativo e' sempre opportuno eseguire un backup dei file fondamentali prima di eseguire la ricostruzione di un array, in quanto i risultati del rebuild possono essere imprevedibili.
Nel caso riportato, l'utente non solo non aveva commesso alcun errore, ma i drive risultavano essere completamente operativi.
Nonostante questo, il rebuild ha determinato un arresto totale ed una completa inaccessibilità dei dati.