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

Varför blir en RAID-array inaktiv efter ett strömavbrott?
En inaktiv array betyder ofta att metadata hittades men att systemet inte hade tillräckligt med förtroende eller medlemmar för att starta den säkert efter...

Vilka är riskerna med att tvinga en saknad RAID-medlem att komma online igen?
Tvångsalternativ kan kringgå säkerhetskontroller kring föråldrad metadata, smutsig paritet, saknade skrivningar eller aktiva pooler; undersök och bevara bevis innan du använder dem.

Hur man skiljer en dålig SATA-kabel från en felande NAS-enhet
Spåra om fel följer med disken eller stannar kvar i SATA-vägen, och separera transporträknare från bevis på mediehälsa innan hårdvara byts ut.

