La correzione più importante contenuta in questa fonte è che l’array non è rimasto un RAID confermato con «un disco guasto». Dopo che l’utente ha avviato il sistema con ciascuna unità separatamente, entrambe risultavano utilizzabili singolarmente. Ricollegando entrambe le unità si è ottenuto [UU] in /proc/mdstat, il che significa che in quel momento entrambi i membri del RAID 1 erano presenti e sincronizzati.
La discussione si è poi ampliata fino a comprendere instabilità SATA/di collegamento/dell’alimentazione, guasti di USB/monitor, avvii in modalità di emergenza, errori NFS e il passaggio di ZimaOS all’altro slot di sistema. I dati sono stati recuperati, ma la fonte non dimostra mai una causa finale univoca. Non trasformare il caso in una semplice guida del tipo «sostituisci il disco X».
Non fare clic su Interrompi o Formatta finché il recupero è ancora possibile
Il primo consiglio della community era corretto sotto questo aspetto di sicurezza: se i dati sono importanti e lo stato reale dell’array è sconosciuto, le azioni distruttive nell’interfaccia possono rendere più difficile il recupero. Esegui prima il backup dei dati leggibili.
Ogni disco funzionava quando veniva testato da solo
L’autore del post originale ha scollegato le unità una alla volta e ha affermato che ciascuna consentiva un percorso funzionante per il sistema e i dati. Ciò ha immediatamente indebolito l’ipotesi che un disco fosse guasto fisicamente.
Ricollegare entrambe le unità ha prodotto un array md [UU] integro
Lo stato pubblicato mostrava md0 : active raid1 ... [2/2] [UU]. A quel punto il livello md di Linux considerava presenti entrambi i membri.
Per questo la discussione successiva si è spostata sulla stabilità di cavi, porte SATA, controller, adattatori/backplane e alimentazione, anziché concentrarsi solo sui metadati RAID.
L’instabilità di SATA/alimentazione può simulare un guasto del RAID
In seguito la fonte ha riportato problemi più ampi che interessavano il comportamento di SATA, USB e del display. Tra i suggerimenti della community c’erano la sostituzione dei cavi SATA, la prova di porte diverse, l’evitare splitter/adattatori al limite delle specifiche e l’esecuzione di test di carico monitorando eventuali reset di I/O.
Si trattava di diagnostica della community, non di un difetto hardware confermato da IceWhale.
I successivi problemi della modalità di emergenza/NFS erano un livello separato
Dopo aver cambiato i cavi e riavviato il sistema, questo è entrato in modalità di emergenza e ha mostrato errori relativi a NFS/RPC. I tentativi della community di cancellare lo stato di NFS o disabilitare NFS non hanno prodotto una riparazione confermata.
Non si deve dedurre che NFS abbia causato l’inaccessibilità iniziale del RAID; il problema è comparso successivamente, in un sistema che stava già mostrando un’instabilità più ampia.
Anche il sistema è passato all’altro slot ZimaOS
L'utente ha riferito di aver avviato il sistema dal Blocco/Slot B anziché da A. L'attuale ZimaOS usa due slot di sistema per il ripristino, quindi il fallback può indicare che uno degli slot di sistema non ha superato i controlli di integrità o avvio, non che i dati utente sul RAID siano andati persi.
Consulta il modello attuale di ripristino a doppio slot di ZimaOS.
Le versioni attuali di ZimaOS dispongono di un flusso di lavoro ufficiale per la riparazione RAID 1
ZimaOS 1.4.4 ha aggiunto la riparazione RAID1 per gli array degradati o danneggiati e ha risolto il problema dei dischi precedentemente utilizzati che risultavano non disponibili durante il ripristino.
Usa la funzione ufficiale di riparazione RAID1 prima di applicare i vecchi comandi manuali di modifica di mdadm.
I metadati RAID sono più resilienti nelle versioni più recenti di ZimaOS
ZimaOS 1.6.0 ha aggiunto un meccanismo di salvataggio dei metadati RAID progettato per reidentificare e montare automaticamente l'array originale dopo la reinstallazione del sistema operativo o la sostituzione del dispositivo. Questo migliora il percorso di ripristino rispetto alla versione 1.5.x a cui risale la fonte.
Ordine attuale di ripristino più sicuro
- Non formattare né alterare l'array.
- Identifica i modelli e i numeri di serie dei dischi e lo stato attuale del RAID con diagnostica di sola lettura.
- Esegui immediatamente il backup dei dati accessibili.
- Controlla cavi, porte, alimentazione, SMART e i log I/O/reset del kernel.
- Usa l'attuale interfaccia di riparazione RAID quando l'array è effettivamente degradato.
- Gestisci separatamente il ripristino dello slot del sistema e il ripristino dei dati RAID.
La discussione sul ripristino è infine arrivata alle opzioni di reimpostazione/ripristino di ZimaOS
Uno stato md [UU] indica che entrambi i membri RAID 1 erano presenti in quel momento
Dopo aver ricollegato entrambi i dischi, la sorgente mostrava l'array attivo con due membri e [UU]. Questa era una prova evidente che, in quel momento, il mirror era stato riassemblato correttamente.
Non spiega perché l'array fosse apparso in precedenza inaccessibile né perché l'instabilità successiva di SATA/USB/monitor continuasse.
La diagnostica di sola lettura è più sicura dei comandi manuali di riparazione di mdadm
La community ha chiesto informazioni sull'array e sul suo stato prima di suggerire modifiche. È l'ordine corretto: identifica quali dispositivi appartengono all'array, se è attivo o degradato e cosa segnala il kernel prima di aggiungere o rimuovere membri o ricreare i metadati.
Non copiare un mdadm --create, l'assemblaggio forzato o un comando per cancellare il superblocco proveniente da un altro caso Linux in un RAID che contiene l'unica copia dei tuoi dati.
Copia i dati importanti non appena l'array diventa leggibile
L'utente della fonte ha recuperato l'accesso. A quel punto, la priorità dovrebbe essere copiare i dati non sostituibili su uno storage indipendente prima di continuare gli esperimenti con cavi, controller, slot di sistema, NFS o reinstallazioni.
RAID 1 offre ridondanza, ma un host o un controller instabile può rendere indisponibili contemporaneamente entrambi i membri.
Quando compaiono insieme problemi SATA, USB e di visualizzazione, amplia la diagnosi
I sintomi successivi non corrispondevano più a un caso chiaro di guasto di un solo disco. Il rilevamento intermittente SATA, i problemi USB e le difficoltà con monitor/avvio possono indicare problemi di cablaggio, alimentazione, controller, firmware della scheda madre o altra instabilità della piattaforma.
Testa alimentazione e cavi sicuramente funzionanti e semplifica la configurazione hardware prima di ricostruire ripetutamente il RAID.
Il ripristino dello slot di sistema e il ripristino RAID sono separati
ZimaOS può avviarsi da slot di sistema alternativi per il ripristino del sistema operativo. Passare allo Slot B può riparare o aggirare un problema dello slot del sistema operativo, ma non ripara automaticamente un array degradato.
Usa l'attuale modello di ripristino del sistema ZimaOS quando anche lo slot del sistema operativo è instabile.
Scollega i dischi dati durante la reinstallazione del sistema operativo, se previsto dal piano di ripristino
La community della fonte ha consigliato di isolare i dischi RAID durante una reinstallazione pulita del sistema operativo, per ridurre il rischio di selezionare o modificare l'unità sbagliata. Se l'assistenza IceWhale attuale fornisce un piano di reinstallazione, etichetta ogni disco e preserva prima i metadati dello storage e i backup.
FAQ sul ripristino di RAID 1
Nella fonte, un disco era definitivamente guasto?
No. In seguito, entrambi i dischi hanno funzionato indipendentemente e l'array risultava [UU] quando è stato ricollegato.
La fonte ha identificato un'unica causa principale definitiva?
No. I problemi relativi a RAID, instabilità SATA/alimentazione, avvio NFS e slot del sistema operativo si sono sovrapposti.
ZimaOS attuale supporta la riparazione di RAID1?
Sì. IceWhale ha aggiunto un flusso ufficiale per la riparazione di RAID1 nella versione 1.4.4.
