RAID-återuppbyggnad pågår men I/O-felen ökar: Vad du ska göra

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Om I/O-fel fortsätter att öka under en NAS-återuppbyggnad, minska skrivningarna och behandla den överlevande enheten eller anslutningsvägen som instabil. En pågående procent gör inte ökande läsfel säkra att ignorera.

Det omedelbara målet är att bevara läsbar data och identifiera om felen är mediafel, länksåterställningar eller ett dåligt mål. Spara loggar och serienummer, bekräfta backupstatus och undvik att upprepade gånger starta om återuppbyggnaden medan källuppsättningen försämras.

Ökande fel går före framstegsmätaren

En återuppbyggnadsprocent visar hur mycket av målet som har bearbetats. Den svarar inte på om varje läsning från källan lyckades. Jämför kumulativa räknare för läsning, skrivning, kontrollsumma, media och kommandotimeout med jämna mellanrum.

När återuppbyggnaden fortskrider samtidigt som felen ökar kan arrayen rekonstruera de flesta block men misslyckas i specifika områden. Ett misslyckat läsning från källan kan vara viktigare än tusentals lyckade när RAID-nivån inte har någon kvarvarande kopia för det blocket.

Identifiera vilken enhet som orsakar felen

Koppla varje loggidentifierare till ett fysiskt serienummer. Avgör om felen kommer från den gamla överlevande enheten, det nya målet eller en delad styrenhetsväg. Ett skrivfel på målet och ett läsfel på källan kräver olika beslut.

Drivhälsodata hjälper till att prioritera undersökningen. Backblazes operativa användning av fem SMART-varningsattribut fokuserar på omallokerade, okorrigerbara, timeout, väntande och offline-okorrigerbara indikatorer istället för att förlita sig på en enda övergripande hälsomärkning.

Separera mediafel från länksfel

Väntande eller okorrigerbara sektorer tyder på oläsbar media. Ökning av UDMA CRC, transportåterställningar och upprepade frånkopplingar indikerar oftare en kabel, backplane, brygga, strömförsörjning eller styrenhetsväg. Båda kan avbryta återuppbyggnaden, men att byta diskar löser inte ett problem med en delad länk.

En UDMA CRC-felförklaring skiljer gränssnittets överföringsfel från skador på skivytan. Spara det råa antalet, korrigera en anslutningsvariabel och kontrollera om räknaren fortsätter att öka.

Fortsätt inte att starta om en misslyckad återuppbyggnad

Varje fullständig omstart läser om de överlevande medlemmarna och kan belasta samma svaga områden utan att ge ett bättre resultat. Om operationen upprepade gånger avbryts nära samma adress eller en andra enhet faller bort, stoppa rutinmässiga reparationsförsök.

En återuppbyggnad blockerad av källfel visar den centrala begränsningen: när den enda bra källan har en oåterkallelig läsfel har arrayen ingen annan plats att hämta den saknade datan från. Tvångsalternativ kan inte återskapa okänt innehåll.

Välj mellan att fortsätta, kopiera och avbilda

Tillstånd Föredragen riktning Varför
Fel stabila, återuppbyggnad pågår Övervaka med reducerad belastning Återställning kan slutföras normalt
Länkfelen ökar, media stabilt Stabilisera kabel-/plats-/kontrollväg Felet kan vara utanför enheten
Fel på källmedia ökar Kopiera kritisk läsbar data först Återstående redundans försvagas
Upprepad avbrytning vid samma område Stoppa blinda återuppbyggnadsförsök Bestående oläsbart område
Andra medlemmen kopplas bort eller går sönder Överväg avbildnings-/återställningsarbetsflöde Arrayen kan överskrida fel tolerans

Om data är oersättlig och säkerhetskopian inte är verifierad kan avbildning av läsbara medlemmar vara säkrare än att tillåta en automatisk återuppbyggnad till. Ett återställningsorienterat andra enhetsfel under återuppbyggnad-arbetsflöde betonar att stoppa skrivintensiva reparationsförsök när den överlevande uppsättningen är instabil.

Minska arbetsbelastningen i förgrunden utan att dölja incidenten

Stoppa säkerhetskopiering, medieindexering, nedladdningar, virtuella maskiner och andra onödiga skrivningar. Behåll endast tjänster som behövs för att kopiera kritisk data eller övervaka arrayen. Att minska arbetsbelastningen kan reducera köbildning och göra felens tidpunkt lättare att tolka.

Rensa inte loggar, återställ inte SMART-räknare eller starta om upprepade gånger innan bevis har fångats. En omstart kan ändra enhetsnamn och radera sekvensen som visar vilken medlem som först gick sönder.

Vad som ska fångas innan avstängning

  • Arraystatus, RAID-nivå, medlemsroller, återuppbyggnadsmål och exakta framstegsräknare
  • Varje diskmodell, serienummer, plats, kontrollerport och aktuell enhetsidentifierare
  • Kärn- eller kontrollerhändelser som täcker det första felet till det senaste I/O-felet
  • SMART råmedia, timeout, temperatur och gränssnitts-felvärden
  • Lista över oläsbara filer eller blockintervall och status för den senaste verifierade säkerhetskopian

Denna dokumentation stödjer ett kontrollerat kabeltest, diskbyte, kloning eller professionell återställning utan att gissa vilken medlem som innehöll den färskaste datan.

Kräv en stabil uppföljning efter varje åtgärd

Efter att ha bytt en kabel, flyttat en bekräftad serienummermärkt disk eller minskat arbetsbelastningen, återställ endast den relevanta jämförelsebaslinjen och övervaka för återkommande fel. En tillfällig förbättring är inget bevis på att det underliggande felet är borta.

Arrayen bör slutföra återställningen, återgå till full medlemskap och klara en senare integritetskontroll utan nya I/O-fel. Tills alla tre villkor uppfylls under en normal representativ arbetsbelastning, håll incidenten öppen och behåll de inspelade loggarna.

Vanliga frågor

Kan jag låta återuppbyggnaden slutföras om bara några få fel uppstår?

Endast när felen är förstådda, stabila och datan är säkerhetskopierad. Ökande källavläsningsfel eller upprepade återställningar är en eskaleringssignal även när målprocenten fortsätter att stiga.

Bör jag byta ut disken med högst SMART-räkning?

Inte automatiskt. Bekräfta om felen följer den serienummermärkta disken eller stannar kvar med dess plats och anslutningsväg. Att byta ut fel medlem under degraderad drift kan förstöra den återstående giltiga källan.

Kan en slutförd återuppbyggnad fortfarande innehålla skadade filer?

Ja. Vissa implementationer kan slutföras samtidigt som de rapporterar oåterkalleliga sektorer eller påverkade filer. Granska alltid den slutgiltiga felrapporten och kör en integritetskontroll efter att arrayen återgått till ett stabilt tillstånd.

Stopvillkoret

När I/O-fel ökar under rekonstruktion, skydda läsbar data innan du försöker slutföra. Fortsätt endast efter att ha bevisat att källuppsättningen och anslutningsvägen är tillräckligt stabila för att leverera varje återstående block.

Support och tips

Mer att läsa

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.