Perché la ricostruzione di un RAID ricomincia dopo la disconnessione di un disco

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Una ricostruzione può ricominciare dopo che un altro disco si disconnette perché l'insieme di membri fidati dell'array è cambiato di nuovo. Il controller può scartare i progressi parziali e rigenerare la ridondanza da un nuovo punto di coerenza.

Una disconnessione breve non è innocua durante un funzionamento degradato. La risposta corretta è identificare quale membro con numero di serie è caduto, preservare i log, confermare che l'array abbia ancora copie valide sufficienti e smettere di sperimentare con cavi o alloggiamenti finché lo stato attuale di recupero non è compreso.

La seconda disconnessione crea un nuovo evento di recupero

Una ricostruzione si basa su un insieme specifico di membri sorgente e un disco di destinazione. Se un altro membro sorgente scompare, anche brevemente, l'array non può più assumere che ogni blocco già scritto sul disco di destinazione corrisponda all'insieme attivo corrente. Le scritture potrebbero anche essere continuate mentre quel membro era assente.

I controller gestiscono questa situazione in modo diverso. Alcuni riprendono da una bitmap o checkpoint; altri ricominciano una ricostruzione completa. La discussione sulla ricostruzione dopo il ricollegamento di un disco mostra perché rimuovere un membro cambia lo stato di tolleranza ai guasti anche quando il disco contiene ancora la maggior parte dei dati vecchi.

Metadati sporchi possono far sembrare un vecchio membro obsoleto

I membri RAID normalmente memorizzano metadati dell'array che identificano il loro ruolo e la cronologia degli eventi. Quando un disco scompare mentre le scritture continuano, il suo contenuto diventa più vecchio rispetto all'array attivo. Ricollegarlo non fa sparire quelle scritture perse, quindi il controller deve riconciliare o sovrascrivere le aree obsolete.

Un membro RAID temporaneamente rimosso può essere riconosciuto dai suoi metadati, ma l'implementazione decide comunque se può rientrare direttamente o necessita di sincronizzazione. Non dare per scontato che rimetterlo nello stesso alloggiamento mantenga la fiducia.

Perché il progresso può tornare a zero

La percentuale spesso descrive la passata di recupero corrente, non un registro permanente di tutti i blocchi mai copiati. Se uno membro sorgente cambia stato, la destinazione viene riassegnata o il controller riassembla l'array, l'operazione visualizzata può ricominciare da zero anche se alcuni blocchi di destinazione corrispondono già.

Su RAID software, un nuovo evento di degrado può richiedere una risincronizzazione completa. Una seconda ricostruzione completa RAID1 documentata dimostra che una volta che un array md entra in stato degradato, può sincronizzare l'intero membro invece di fidarsi di uno stato parziale precedente.

Non rimuovere un altro disco per testare la teoria

Durante una ricostruzione, ogni sorgente rimanente fa parte dell'unico percorso per ricostruire i dati mancanti. Rimuovere un altro membro per identificazione può superare la tolleranza ai guasti del livello RAID o creare versioni concorrenti dei dati. Individua i dischi tramite numero seriale e indicatori dell'involucro, non tramite rimozione a tentativi.

Interrompi gli esperimenti di hot-swap finché l'array non è sano o copiato in un archivio sicuro. Se si sospetta un cavo o uno slot, raccogli prima il registro eventi e pianifica una singola modifica controllata con il sistema in quiete quando l'hardware non supporta esplicitamente il servizio online.

Verifica se la ricostruzione è realmente ricominciata

Confronta più della percentuale. Registra il nome dell'operazione, il seriale di destinazione, il numero di membri sorgente, il numero dell'evento o della generazione, i blocchi elaborati, la velocità attuale e il tempo stimato di completamento. Un controller può passare dalla ricostruzione all'inizializzazione della parità, alla verifica o al controllo di coerenza in background.

Campo Stessa operazione Nuovo evento di recupero
Seriale di destinazione Invariato Diverso o riclassificato
Blocchi elaborati Continua verso l'alto Torna all'inizio
Set di membri Stabile Un altro disco assente o reinserito
Messaggio di log Riprendi o continua Annulla, riavvia, riassembla, nuova ricostruzione
Stato dell'array Degradato/ricostruzione in corso Più degradato, esterno o in recupero

Se il set di membri è cambiato, considera la nuova percentuale come un evento nuovo. Se si è solo resettata l'interfaccia mentre i contatori continuano, potrebbe essere un problema di visualizzazione piuttosto che una perdita di progresso.

Quando un riavvio è meno importante di una rimozione del disco

Un riavvio pianificato non invalida necessariamente una ricostruzione gestita dal controller. Molti controller mantengono abbastanza stato per riprendere in sicurezza. L'evento più grave è perdere un altro disco di origine o introdurre una configurazione esterna durante o dopo il riavvio.

Un riavvio durante una ricostruzione può essere recuperabile, ma la conclusione sicura dipende dallo stato del controller dopo l'avvio. Non inizializzare né importare mai una configurazione esterna solo perché la percentuale si è azzerata.

Cosa fare immediatamente

  1. Pausa le scritture non essenziali e acquisisci i log dell'array, dell'involucro e del sistema operativo.
  2. Mappa ogni membro attivo, mancante, in ricostruzione e di riserva a un numero di serie fisico.
  3. Conferma che il livello RAID abbia ancora abbastanza membri di origine validi per ricostruire i dati.
  4. Controlla i contatori SMART e degli errori di collegamento sul disco che si è disconnesso e sul suo percorso di connessione.
  5. Lascia che una ricostruzione stabile venga eseguita senza ulteriori esperimenti con cavi, bay, riavvii o carichi di lavoro.

Se un'altra sorgente segnala settori illeggibili o disconnessioni ripetute, dai priorità alla copia dei dati irrinunciabili o all'imaging dei membri piuttosto che forzare ripetutamente una ricostruzione.

FAQ

Ricollegare lo stesso disco riavvierà sempre la ricostruzione?

No. Alcuni controller possono ricollegarlo o riprendere da una bitmap. Altri considerano il membro obsoleto e iniziano nuovamente la sincronizzazione. Il registro eventi e i dati di generazione del membro decidono quale caso si è verificato.

Una percentuale di reset significa che il nuovo disco è stato cancellato di nuovo?

Non necessariamente. Può significare che il controller ha iniziato un nuovo passaggio o ha cambiato tipo di operazione. Non dedurre la perdita di dati solo dalla percentuale; controlla l'identità del target e i messaggi degli eventi.

Posso continuare a usare le app durante la ricostruzione riavviata?

Un uso leggero può essere supportato, ma riduci le scritture evitabili e i lavori sensibili alla latenza. L'array ha già mostrato un secondo evento di connettività, quindi la stabilità e la protezione dei dati hanno la priorità rispetto al normale throughput.

La risposta pratica

Una ricostruzione si riavvia perché le ipotesi di coerenza sono cambiate quando un altro membro si è disconnesso. Stabilizza il percorso hardware, verifica il set di origine e consenti un recupero ininterrotto invece di testare l'array mentre è degradato.

Supporto e consigli

Altro da leggere

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.