Perché un array RAID diventa inattivo dopo un'interruzione di corrente?

Dopo un'interruzione di corrente, un array RAID può rimanere inattivo perché i suoi metadati sono stati rilevati, ma il sistema non è riuscito ad avviarlo in modo sicuro con i membri e lo stato disponibili.

Il termine “inattivo” descrive più direttamente gli array md di Linux, anche se altri stack di archiviazione possono avere errori simili di importazione o attivazione. Controlla il rilevamento dei dispositivi, i metadati dei membri, lo stato sporco o degradato, la configurazione di avvio e i guasti del percorso di alimentazione prima di tentare un avvio forzato.

Comprendere cosa significa Inattivo in Linux RAID

Un array md inattivo può avere dispositivi e una certa configurazione collegati, ma rifiutare le normali operazioni di I/O. Non è lo stesso di un array sano semplicemente smontato, e i comandi di montaggio non possono riparare il passaggio di attivazione mancante.

Uno stato di array inattivo è configurato ma non attivo, con I/O che restituisce errori. Questo stato permette al sistema di continuare a scoprire o riconfigurare i membri senza fingere che l'array sia pronto.

Ispeziona /proc/mdstat, i dettagli dell'array e ogni superblocco dei membri prima di cambiare stato. L'obiettivo è capire perché l'attivazione si è fermata, non trasformare “inattivo” in “attivo” senza confermare il set di membri.

Uno o più membri potrebbero non essere riapparsi

Un'interruzione improvvisa può mettere in evidenza un cavo di alimentazione marginale, un backplane, un cavo SATA, una porta del controller o un disco che non si inizializza al successivo avvio. L'array vede quindi meno membri di quanti i metadati indicano dovrebbero essere presenti.

mdadm normalmente confronta i dispositivi non di riserva disponibili con il conteggio attivo previsto prima di avviare. Un array può rimanere parzialmente assemblato quando mancano dispositivi previsti, anche se esistono metadati sufficienti per creare una voce del dispositivo md.

Spegnere in modo sicuro se è necessaria un'ispezione hardware, quindi controllare connettori, avvio, rilevamento del controller, numeri di serie e dati SMART. Ripristinare la connettività mancante prima di scegliere l'avvio degradato, perché un guasto temporaneo del percorso può essere più facile e sicuro da risolvere rispetto alla ricostruzione dell'array.

Un arresto non pulito può lasciare l'array sporco

La perdita di alimentazione può interrompere le scritture prima che ogni membro e blocco di parità raggiunga uno stato coerente. I metadati dell'array registrano quindi che una risincronizzazione, una riproduzione della bitmap, una riproduzione del journal o un'altra azione di coerenza è richiesta al prossimo avvio.

Linux md supporta diverse politiche di coerenza dopo uno spegnimento imprevisto, inclusi risincronizzazione completa, bitmap di intento di scrittura, journal e log parziale di parità. La politica di coerenza determina quanto lavoro è necessario prima che la ridondanza possa essere nuovamente considerata affidabile.

Un array sporco ma completo può avviarsi e risincronizzarsi normalmente. Un array sporco e anche degradato richiede molta più cautela, perché dati mancanti e parità incerta possono rimuovere le informazioni necessarie per una ricostruzione affidabile.

Parità sporca e degradata può innescare un rifiuto di sicurezza

RAID 5 o RAID 6 possono essere rifiutati all'avvio quando sono sia sporchi che manca un membro. Il rifiuto protegge contro uno stato in cui la parità può essere obsoleta e i dati assenti non possono essere verificati contro un'altra copia.

Esiste una protezione all'avvio degradato sporco perché forzare quella combinazione può creare corruzione non rilevabile. Pertanto, l'avvio degradato forzato è una decisione esplicita dell'amministratore e non un comportamento normale di avvio.

Non bypassare questa protezione finché non si comprendono il membro mancante, lo stato del backup e la cronologia delle scritture. Ripristina prima il percorso del dispositivo o clona i membri guasti; se il recupero deve continuare, minimizza le scritture e verifica i file recuperati in modo indipendente.

La scoperta e configurazione all'avvio possono essere incomplete

I dischi possono essere tutti sani mentre l'avvio non riesce comunque a trovare l'array perché la scoperta dei dispositivi termina dopo il tentativo di assemblaggio, la configurazione manca dell'identità dell'array o l'initramfs contiene impostazioni RAID obsolete.

Un file di configurazione RAID può descrivere dispositivi e array affinché gli strumenti di avvio sappiano cosa scansionare e assemblare. Record di configurazione dell'array accurati sono particolarmente importanti quando la scoperta automatica non può dedurre in modo affidabile il set previsto.

Confronta gli UUID dei membri attivi con la configurazione installata e l'ambiente di avvio. Correggi la configurazione obsoleta solo dopo aver confermato l'identità reale dell'array; generare una nuova configurazione da un set di membri incompleto può rendere l'avvio successivo costantemente errato.

I metadati esterni possono richiedere un gestore in userspace

Alcuni array usano formati di metadati esterni gestiti da userspace anziché interamente dal kernel. Dopo un'interruzione improvvisa, il processo container o monitor potrebbe non aver completato le conferme necessarie per i cambiamenti di stato dei membri.

I metadati gestiti esternamente possono sospendere l'attività finché l'userspace non conferma un evento. Un set di componenti inattivo può quindi riflettere un passaggio di gestione mancante piuttosto che dischi dati guasti.

Identifica il formato dei metadati prima di applicare comandi md generici. I formati assistiti da firmware o container possono richiedere il monitor appropriato, l'utilità del controller o il flusso di lavoro di recupero NAS affinché gli aggiornamenti dei metadati avvengano nell'ordine corretto.

Recupera nell'ordine a minor rischio

Inizia con prove in sola lettura: elenca i dispositivi a blocchi per ID stabile, mappa i numeri di serie agli slot, esamina i metadati dei membri, rivedi i log del boot precedente e verifica se ogni disco previsto è presente. Non creare un nuovo array né azzerare i superblocchi.

Tenta l'assemblaggio normale della piattaforma dopo aver corretto connettività e configurazione. Usa modalità di sola lettura o lettura automatica quando supportate, e riserva le opzioni di esecuzione degradata o forzata per i casi in cui il membro mancante esatto e il rischio di coerenza sono compresi.

Dopo il recupero, completa ogni risincronizzazione o pulizia, conferma i backup e indaga il percorso dell'interruzione. Un UPS, alimentazione e cablaggio affidabili, configurazione RAID aggiornata, ID dispositivo stabili e sistemi di allerta riducono la probabilità che il prossimo evento di alimentazione presenti lo stesso stato inattivo.