The most important correction in this source is that the array did not remain a confirmed “one disk failed” RAID. After the user booted with each drive separately, both were individually workable. Reconnecting both drives produced [UU] De belangrijkste correctie in deze bron is dat de array niet aantoonbaar een RAID-array bleef waarin “één schijf defect was”. Nadat de gebruiker met elke schijf afzonderlijk had opgestart, bleken beide afzonderlijk bruikbaar. Het opnieuw aansluiten van beide schijven leverde in/proc/mdstat
, wat betekent dat beide RAID 1-leden op dat moment aanwezig en gesynchroniseerd waren.
De discussie breidde zich daarna uit naar instabiliteit van SATA-verbindingen en voeding, USB-/monitorstoringen, opstarts in de noodmodus, NFS-fouten en het terugvallen van ZimaOS op de andere systeempartitie. De gegevens zijn hersteld, maar de bron bewijst nooit één definitieve oorzaak. Maak er geen eenvoudige tutorial van met als advies “vervang schijf X”.
Klik niet op Onderbreken of Formatteren zolang herstel nog mogelijk is
Het eerste advies vanuit de community was op dit veiligheids punt correct: als de gegevens belangrijk zijn en de werkelijke toestand van de array onbekend is, kunnen destructieve acties in de interface herstel moeilijker maken. Maak eerst een back-up van de leesbare gegevens.
Elke schijf werkte bij afzonderlijk testen
De oorspronkelijke poster koppelde de schijven één voor één los en zei dat elke schijf afzonderlijk een bruikbaar systeem-/datapad opleverde. Daardoor werd de aanname dat één schijf fysiek defect was direct minder waarschijnlijk.
Op de geposte status was te zien dat het opnieuw aansluiten van beide schijven een gezonde [UU] md-array opleverde md0 : active raid1 ... [2/2] [UU]. Op dat moment beschouwde de Linux md-laag beide leden als aanwezig.
Daarom verschoof de latere discussie naar de stabiliteit van kabels, SATA-poorten, controllers, adapters/backplanes en voeding, in plaats van alleen naar RAID-metadata.
SATA-/voedingsinstabiliteit kan zich voordoen als een RAID-storing
De bron meldde later bredere problemen met SATA-, USB- en weergavegedrag. Suggesties vanuit de community waren onder meer SATA-kabels vervangen, andere poorten testen, twijfelachtige splitters/adapters vermijden en stresstests uitvoeren terwijl op I/O-resets werd gelet.
Dit waren diagnoses vanuit de community, geen door IceWhale bevestigde hardwaredefecten.
Latere problemen met de noodmodus/NFS vormden een afzonderlijke laag
Na kabelwijzigingen en herstarts ging het systeem naar de noodmodus en werden NFS/RPC-gerelateerde fouten weergegeven. Pogingen van de community om de NFS-status te wissen of NFS uit te schakelen leverden geen bevestigde reparatie op.
Leid hieruit niet af dat NFS de oorspronkelijke ontoegankelijkheid van de RAID veroorzaakte; het verscheen later in een systeem dat al bredere instabiliteit vertoonde.
Het systeem viel ook terug op de andere ZimaOS-sleuf
De gebruiker meldde dat het systeem opstartte vanaf blok/slot B in plaats van A. Het huidige ZimaOS gebruikt twee systeemslots voor herstel, dus terugvallen kan erop wijzen dat een van de systeemslots niet door de gezondheids- of opstartcontroles kwam, en niet dat de gebruikersgegevens op de RAID verdwenen zijn.
Zie het huidige dual-slot-herstelmodel van ZimaOS.
Huidig ZimaOS heeft een officiële RAID 1-reparatieworkflow
ZimaOS 1.4.4 voegde RAID1-reparatie toe voor gedegradeerde/beschadigde arrays en verhielp het probleem dat eerder gebruikte schijven tijdens herstel niet beschikbaar waren.
Gebruik de officiële RAID1-reparatiefunctie voordat je oude handmatige mdadm-opdrachten uitvoert die wijzigingen aanbrengen.
RAID-metagegevens zijn veerkrachtiger in nieuwere ZimaOS-versies
ZimaOS 1.6.0 voegde een mechanisme toe voor het opslaan van RAID-metagegevens, ontworpen om de oorspronkelijke array automatisch opnieuw te identificeren en te koppelen na een herinstallatie van het besturingssysteem of vervanging van het apparaat. Dat verbetert het herstelpad ten opzichte van de periode van de bron met versie 1.5.x.
Veiligere huidige herstelvolgorde
- Formatteer de array niet en verbreek deze niet.
- Identificeer schijfmodellen/-serienummers en de huidige RAID-status met alleen-lezen-diagnostiek.
- Maak onmiddellijk een back-up van toegankelijke gegevens.
- Controleer kabels, poorten, voeding, SMART- en kernel-I/O-/resetlogboeken.
- Gebruik de huidige RAID-reparatie-interface wanneer de array daadwerkelijk gedegradeerd is.
- Behandel herstel van het besturingssysteemslot afzonderlijk van herstel van RAID-gegevens.
De herstelthread kwam uiteindelijk uit bij de reset-/herstelopties van ZimaOS
Een [UU]-md-status betekent dat beide RAID 1-leden op dat moment aanwezig waren
Nadat beide schijven opnieuw waren aangesloten, gaf de bron aan dat de array actief was met twee leden en [UU]. Dat was sterk bewijs dat de mirror op dat moment zelf succesvol opnieuw was samengesteld.
Het verklaart niet waarom de array eerder ontoegankelijk leek of waarom de latere instabiliteit van SATA/USB/monitor bleef aanhouden.
Alleen-lezen-diagnostiek is veiliger dan handmatige mdadm-reparatieopdrachten
De community vroeg om informatie over de array en de status voordat wijzigingen werden voorgesteld. Dat is de juiste volgorde: bepaal welke apparaten bij de array horen, of deze actief of gedegradeerd is en wat de kernel meldt, voordat je leden toevoegt of verwijdert of metadata opnieuw aanmaakt.
Kopieer geen mdadm --create, een geforceerde assemblage of een opdracht voor het wissen van de superblock uit een andere Linux-case naar een RAID die de enige kopie van je gegevens bevat.
Kopieer belangrijke gegevens zodra de array leesbaar wordt
De gebruiker uit de bron kreeg weer toegang. Op dat moment moet de prioriteit liggen bij het kopiëren van onvervangbare gegevens naar onafhankelijke opslag, voordat je verder experimenteert met kabels, controllers, systeemslots, NFS of een herinstallatie.
RAID 1 biedt redundantie, maar een instabiele host of controller kan beide leden tegelijkertijd onbeschikbaar maken.
Wanneer SATA-, USB- en displayproblemen tegelijk optreden, moet je de diagnose verbreden
De latere symptomen waren niet langer het verhaal van één schijf die eenvoudigweg defect was geraakt. Intermitterende SATA-detectie, USB-problemen en monitor-/opstartproblemen kunnen wijzen op problemen met bekabeling, voeding, controller, moederbordfirmware of andere platforminstabiliteit.
Test betrouwbare voeding en kabels en vereenvoudig de hardwareconfiguratie voordat je de RAID herhaaldelijk opnieuw opbouwt.
Systeemslotherstel en RAID-herstel zijn afzonderlijke processen
ZimaOS kan voor OS-herstel vanaf alternatieve systeemslots opstarten. Terugvallen op Slot B kan een probleem met het OS-slot verhelpen of omzeilen, maar herstelt een gedegradeerde array op zichzelf niet.
Gebruik het huidige systeemherstelmodel van ZimaOS wanneer ook het OS-slot niet goed werkt.
Koppel gegevensschijven los bij het herinstalleren van het besturingssysteem als het herstelplan dat voorschrijft
De community van de bron raadde aan de RAID-schijven los te koppelen tijdens een schone herinstallatie van het besturingssysteem, om de kans te verkleinen dat de verkeerde schijf werd geselecteerd of gewijzigd. Als de huidige IceWhale-ondersteuning een herinstallatieplan verstrekt, label dan elke schijf en maak eerst een back-up van de opslagmetadata en gegevens.
Veelgestelde vragen over RAID 1-herstel
Was één schijf volgens de bron definitief defect?
Nee. Beide schijven werkten later afzonderlijk en de array gaf [UU] wanneer deze opnieuw werd aangesloten.
Heeft de bron één definitieve hoofdoorzaak vastgesteld?
Nee. Problemen met RAID, SATA/voedingsinstabiliteit, het opstarten van NFS en OS-slots liepen door elkaar.
Heeft het huidige ZimaOS RAID 1-herstel?
Ja. IceWhale heeft in 1.4.4 een officiële workflow voor RAID 1-herstel toegevoegd.
