Den viktigaste korrigeringen i denna källa är att arrayen inte förblev ett bekräftat RAID där ”en disk hade gått sönder”. Efter att användaren hade startat systemet med varje disk separat fungerade båda individuellt. När båda diskarna återanslöts skapades [UU] i /proc/mdstat, vilket betyder att båda RAID 1-medlemmarna var närvarande och synkroniserade vid det tillfället.
Tråden utvidgades sedan till instabilitet i SATA/länk/ström, USB-/skärmfel, uppstarter i nödläge, NFS-fel och att ZimaOS föll tillbaka till den andra systemplatsen. Data återställdes, men källan bevisar aldrig en enda slutlig orsak. Gör inte om detta till en enkel guide för att ”byta disk X”.
Klicka inte på Bryt eller Formatera när återställning fortfarande är möjlig
Det första rådet från gemenskapen var korrekt ur säkerhetssynpunkt: om data är viktig och arrayens faktiska tillstånd är okänt kan destruktiva åtgärder i gränssnittet försvåra återställningen. Säkerhetskopiera läsbar data först.
Varje disk fungerade när den testades ensam
Den ursprungliga skribenten kopplade bort enheterna en i taget och uppgav att varje enhet gav en fungerande system-/dataväg. Det försvagade omedelbart antagandet att en disk hade gått sönder fysiskt.
Återanslutning av båda skapade en frisk [UU] md-array
Den publicerade statusen visade md0 : aktiv raid1 ... [2/2] [UU]. Vid den tidpunkten ansåg Linux md-lagret att båda medlemmarna var närvarande.
Därför skiftade den senare diskussionen mot kabel-, SATA-port-, styrenhets-, adapter-/bakplans- och strömstabilitet i stället för enbart RAID-metadata.
SATA-/strömstabilitetsproblem kan misstas för RAID-fel
Källan rapporterade senare mer omfattande fel som påverkade SATA, USB och skärmens funktion. Förslag från gemenskapen omfattade att byta SATA-kablar, testa andra portar, undvika tveksamma splitters/adaptrar och stresstesta samtidigt som man höll utkik efter I/O-återställningar.
Detta var felsökning utförd av gemenskapen, inte ett av IceWhale bekräftat hårdvarufel.
Senare problem med nödläge/NFS var ett separat lager
Efter kabelbyten och omstarter gick systemet in i nödläge och visade NFS-/RPC-relaterade fel. Gemenskapens försök att rensa NFS-tillståndet eller inaktivera NFS ledde inte till någon bekräftad reparation.
Dra inte slutsatsen att NFS orsakade den ursprungliga otillgängligheten för RAID; det uppstod senare i ett system som redan hade drabbats av mer omfattande instabilitet.
Systemet föll även tillbaka till den andra ZimaOS-platsen
Användaren rapporterade att systemet startade från Block/Slot B i stället för A. Aktuella ZimaOS använder dubbla systemplatser för återställning, så reservstarten kan tyda på att en av systemplatserna inte klarade hälso- eller startkontrollerna, snarare än att användardata på RAID-enheten har gått förlorade.
Se den aktuella återställningsmodellen med dubbla ZimaOS-platser.
Aktuella ZimaOS har ett officiellt arbetsflöde för RAID 1-reparation
ZimaOS 1.4.4 lade till RAID1-reparation för degraderade/skadade arrayer och åtgärdade att tidigare använda diskar inte var tillgängliga under återställningen.
Använd den officiella RAID1-reparationsfunktionen innan du använder gamla manuella mdadm-kommandon som ändrar arrayen.
RAID-metadata är mer motståndskraftiga i nyare ZimaOS-versioner
ZimaOS 1.6.0 lade till en mekanism för att spara RAID-metadata, utformad för att automatiskt identifiera och montera den ursprungliga arrayen igen efter ominstallation av operativsystemet eller byte av enhet. Det förbättrar återställningsförloppet jämfört med källans 1.5.x-era.
Säkrare aktuell återställningsordning
- Formatera inte och bryt inte upp arrayen.
- Identifiera diskmodeller/serienummer och RAID-hälsan med skrivskyddad diagnostik.
- Säkerhetskopiera omedelbart alla data som går att komma åt.
- Kontrollera kablar, portar, strömförsörjning, SMART samt kärnans I/O- och återställningsloggar.
- Använd det aktuella RAID-reparationsgränssnittet när arrayen faktiskt är degraderad.
- Hantera återställning av operativsystemets plats separat från återställning av RAID-data.
Återställningstråden nådde så småningom alternativen för återställning/återställning av ZimaOS
En [UU]-md-status betyder att båda RAID 1-medlemmarna fanns på plats vid den tidpunkten
Efter att båda diskarna hade anslutits igen visade källan att arrayen var aktiv med två medlemmar och [UU]. Det var starka bevis för att själva speglingen hade satts ihop igen korrekt vid den tidpunkten.
Det förklarar inte varför arrayen tidigare hade verkat otillgänglig eller varför instabiliteten med SATA/USB/skärm fortsatte senare.
Skrivskyddad diagnostik är säkrare än manuella mdadm-reparationskommandon
Communityn bad om information om arrayen och dess status innan ändringar föreslogs. Det är rätt ordning: identifiera vilka enheter som tillhör arrayen, om den är aktiv eller degraderad och vad kärnan rapporterar innan medlemmar läggs till eller tas bort eller metadata återskapas.
Kopiera inte ett mdadm --create, tvingad montering eller ett kommando för att rensa superblocket från ett annat Linux-fall till en RAID-array som innehåller den enda kopian av dina data.
Kopiera viktiga data så snart arrayen blir läsbar
Källans användare återfick åtkomsten. Då bör prioriteten vara att kopiera oersättliga data till oberoende lagring innan fler experiment med kablar, styrenheter, systemplatser, NFS eller ominstallation fortsätter.
RAID 1 ger redundans, men en instabil värd eller styrenhet kan göra båda medlemmarna otillgängliga samtidigt.
När problem med SATA, USB och bildskärm uppstår samtidigt bör du bredda felsökningen
De senare symtomen var inte längre ett tydligt fall av att en enda disk hade gått sönder. Sporadisk SATA-identifiering, USB-beteende och problem med skärm/start kan tyda på problem med kablage, strömförsörjning, styrenhet, moderkortsfirmware eller annan instabilitet i plattformen.
Testa fungerande strömförsörjning och kablar och förenkla hårdvarukonfigurationen innan du bygger om RAID upprepade gånger.
Återställning av systemplats och RAID-återställning är separata
ZimaOS kan starta från alternativa systemplatser för att återställa operativsystemet. Att falla tillbaka på plats B kan reparera eller kringgå ett problem med systemplatsen, men reparerar inte i sig en degraderad array.
Använd den aktuella systemåterställningsmodellen i ZimaOS när även operativsystemets plats är instabil.
Koppla bort datadiskarna när du installerar om operativsystemet, om återställningsplanen kräver det
Källans community rekommenderade att RAID-diskarna isoleras under en ren ominstallation av operativsystemet för att minska risken att fel enhet väljs eller ändras. Om aktuell support från IceWhale ger en ominstallationsplan ska varje disk märkas och lagringsmetadata samt säkerhetskopior bevaras först.
Vanliga frågor om återställning av RAID 1
Var den ena disken definitivt trasig enligt källan?
Nej. Båda diskarna fungerade senare var för sig och arrayen visade [UU] när den anslöts igen.
Identifierade källan en slutgiltig grundorsak?
Nej. RAID, instabilitet i SATA/strömförsörjningen, NFS-start och problem med systemplatser överlappade varandra.
Har nuvarande ZimaOS stöd för reparation av RAID1?
Ja. IceWhale lade till ett officiellt arbetsflöde för att reparera RAID1 i 1.4.4.
