Ricostruzione RAID in corso ma gli errori I/O aumentano: cosa fare

Se gli errori di I/O continuano ad aumentare durante una ricostruzione NAS, ridurre le scritture e considerare il membro sopravvissuto o il percorso di connessione instabile. Una percentuale in progresso non rende sicuro ignorare l'aumento dei fallimenti di lettura.

L'obiettivo immediato è preservare i dati leggibili e identificare se gli errori sono guasti del supporto, reset del collegamento o un target difettoso. Salvare i log e i numeri di serie, confermare lo stato del backup ed evitare di riavviare ripetutamente la ricostruzione mentre il set di origine si deteriora.

Gli errori in aumento sovrascrivono la barra di progresso

Una percentuale di ricostruzione indica quanto del target è stato processato. Non indica se ogni lettura dalla sorgente è riuscita. Confrontare i contatori cumulativi di lettura, scrittura, checksum, supporto e timeout dei comandi a intervalli regolari.

Quando la ricostruzione avanza mentre gli errori aumentano, l'array potrebbe ricostruire la maggior parte dei blocchi ma fallire in regioni specifiche. Una singola lettura fallita dalla sorgente può essere più importante di migliaia di letture riuscite quando il livello RAID non ha copie rimanenti per quel blocco.

Identificare quale dispositivo sta producendo gli errori

Mappare ogni identificatore di log a un numero di serie fisico. Determinare se gli errori provengono dal vecchio membro sopravvissuto, dal nuovo obiettivo o da un percorso condiviso del controller. Un errore di scrittura sul target e un errore di lettura sulla sorgente richiedono decisioni diverse.

I dati sullo stato del disco aiutano a dare priorità all'indagine. L'uso operativo di Backblaze di cinque attributi di avviso SMART concentra l'attenzione su indicatori di riallocazione, non correggibili, timeout, in attesa e offline-non correggibili, invece di affidarsi a un'unica etichetta complessiva di salute.

Separare gli errori del supporto dagli errori di collegamento

I settori in attesa o non correggibili indicano un supporto illeggibile. La crescita degli errori UDMA CRC, i reset del trasporto e le disconnessioni ripetute indicano più spesso un problema di cavo, backplane, bridge, alimentazione o percorso del controller. Entrambi possono interrompere la ricostruzione, ma sostituire i dischi non risolverà un problema di collegamento condiviso.

Una spiegazione del conteggio errori UDMA CRC distingue gli errori di trasferimento dell'interfaccia dai danni ai piatti. Salva il conteggio grezzo, correggi una variabile di connessione e verifica se il contatore continua ad aumentare.

Non continuare a riavviare una ricostruzione fallita

Ogni riavvio completo rilegge i membri sopravvissuti e può stressare le stesse aree deboli senza produrre un risultato migliore. Se l'operazione abortisce ripetutamente vicino allo stesso indirizzo o un secondo disco si guasta, interrompi i tentativi di riparazione di routine.

Un blocco della ricostruzione causato da errori di origine dimostra il limite centrale: quando l'unica fonte buona ha una lettura irrecuperabile, l'array non ha altre fonti da cui ottenere i dati mancanti. Le opzioni forzate non possono ricreare contenuti sconosciuti.

Scegli tra continuare, copiare e creare un'immagine

Se i dati sono irrinunciabili e il backup non è verificato, creare un'immagine dei membri leggibili può essere più sicuro che permettere un altro ricostruzione automatica. Un flusso di lavoro orientato al recupero in caso di guasto del secondo disco durante la ricostruzione enfatizza l'interruzione dei tentativi di riparazione intensivi in scrittura quando il set sopravvissuto è instabile.

Riduci il lavoro in primo piano senza nascondere l'incidente

Interrompi backup, indicizzazione media, download, macchine virtuali e altre scritture evitabili. Mantieni solo i servizi necessari per copiare dati critici o monitorare l'array. Ridurre il carico di lavoro può diminuire le code e facilitare l'interpretazione dei tempi degli errori.

Non cancellare i log, resettare i contatori SMART o riavviare ripetutamente prima di acquisire le prove. Un riavvio può cambiare i nomi dei dispositivi ed eliminare la sequenza che mostra quale membro ha fallito per primo.

Cosa Acquisire Prima di Spegnere

• Stato dell'array, livello RAID, ruoli dei membri, obiettivo della ricostruzione e contatori di progresso esatti
• Ogni modello di disco, numero di serie, alloggiamento, porta del controller e identificatore dispositivo attuale
• Eventi del kernel o del controller che coprono dal primo guasto fino all'ultimo errore di I/O
• Valori SMART grezzi del supporto, timeout, temperatura ed errori di interfaccia
• Elenco dei file o intervalli di blocchi illeggibili e lo stato dell'ultimo backup verificato

Questo registro supporta un test controllato del cavo, la sostituzione del disco, la clonazione o il recupero professionale senza indovinare quale membro contenesse i dati più recenti.

Richiedi un Follow-Up Stabile Dopo Qualsiasi Intervento

Dopo aver sostituito un cavo, spostato un disco con numero di serie confermato o ridotto il carico di lavoro, resetta solo la baseline di confronto rilevante e osserva se si ripresentano problemi. Un miglioramento temporaneo non è prova che il guasto sottostante sia stato eliminato.

L'array dovrebbe completare il recupero, tornare a piena appartenenza e superare un controllo di integrità successivo senza nuovi errori di I/O. Finché tutte e tre le condizioni non sono soddisfatte sotto un carico di lavoro rappresentativo normale, mantieni l'incidente aperto in sicurezza e conserva i log acquisiti.

Domande Frequenti

Posso lasciare che la ricostruzione finisca se compaiono solo pochi errori?

Solo quando gli errori sono compresi, stabili e i dati sono stati salvati. L'aumento degli errori di lettura della fonte o i reset ripetuti sono un segnale di escalation anche se la percentuale di completamento continua a salire.

Devo sostituire il disco con il conteggio SMART più alto?

Non automaticamente. Verifica se gli errori seguono il disco con numero di serie specifico o rimangono associati al suo alloggiamento e percorso di connessione. Sostituire il membro sbagliato durante un'operazione degradata può distruggere la fonte valida rimanente.

Una ricostruzione completata può ancora contenere file danneggiati?

Sì. Alcune implementazioni possono completare la ricostruzione segnalando settori o file danneggiati irrecuperabili. Controlla sempre il rapporto finale degli errori ed esegui un controllo di integrità dopo che l'array è tornato a uno stato stabile.

La Condizione di Arresto

Quando gli errori di I/O aumentano durante la ricostruzione, proteggi i dati leggibili prima di completare l'operazione. Continua solo dopo aver verificato che il set di origine e il percorso di connessione siano abbastanza stabili da fornire ogni blocco rimanente.