Vilka är varningstecknen på att en RAID-scrub upptäcker ny skada?

En scrub upptäcker ny skada när felräkningen ökar mellan körningar, reparationer upprepas på samma enhet eller tidigare ren data blir okorrigerbar. En isolerad reparerad block är inte samma sak som ett förvärrande mönster.

Den säkraste tolkningen kommer från att jämföra slutförda scrub-rapporter, fel på enhetsnivå och påverkade filer istället för att reagera på ett enskilt alarmerande tal. Denna guide skiljer normal korrigering från ackumulerande skada och visar när man ska sluta med rutinunderhåll och först skydda data.

En ökande felräkning är den tydligaste varningen

Den viktigaste jämförelsen är inte om en scrub rapporterar något fel, utan om nästa slutförda scrub rapporterar fler checksum-, paritets-, media- eller okorrigerbara fel. En stabil räknare efter reparation kan spegla en gammal händelse. En ökande räknare betyder att lagringsvägen fortfarande ger dåliga läsningar eller dåliga data.

Registrera starttid, sluttid, reparerade byte, antal okorrigerbara fel och per-enhets räknare för läsning, skrivning eller checksum efter varje körning. Praktiska förklaringar av scrubbing och tyst korruption visar varför en fullständig läsning kan avslöja skada som vanliga arbetsbelastningar inte har rört på månader.

Upprepade reparationer på samma disk kräver uppmärksamhet

Ett redundant filsystem kan reparera ett skadat block från en annan kopia och ändå hålla poolen online. Varningen uppstår när senare scrubs reparerar nya block på samma fysiska disk, särskilt när disken också samlar på sig väntande, omallokerade eller okorrigerbara sektorer.

Rensa inte räknarna och glöm händelsen. Spara diskens serienummer, SMART-ögonblicksbild och scrub-resultat först. Kör sedan ett långt självtest på disken endast om arrayen förblir redundant och responsiv. Upprepade korrigeringar är bevis för att undersöka medlemmen, kabeln, facket, strömvägen och kontrollern snarare än bevis på att filsystemet har löst orsaken.

Okorrigerbara filer ändrar prioriteten

Ett okorrigerbart resultat betyder att redundans inte kunde producera en verifierad kopia för minst ett block. Vid den punkten är en ny scrub inte automatiskt nästa steg. Identifiera de namngivna filerna, kopiera läsbar kritisk data till annan plats och bevara loggar innan du gör topologiförändringar.

En verklig scrub med okorrigerbara data illustrerar skillnaden mellan korrigerad metadata och filer som fortfarande behövde återställas från backup. Det användbara signalvärdet är inte bara den stora råa felmängden; det är om en ren uppföljningskörning kan slutföras utan nya fel.

Samma logiska område som fallerar igen är inte normalt

Fel som återkommer på samma stripe, blockintervall eller fil kan peka på en bestående oläsbar region eller korrupt paritetsstatus. Fel som flyttar runt kan indikera bredare medieförsämring, instabilt minne, länkproblem eller ströminstabilitet. Spara exakta offset när plattformen visar dem.

Fortsätt inte att tvinga fram reparationer över miljontals fel utan att förstå det första påverkade området. En stor paritetsfelkluster kan ha sitt ursprung i ett tidigare I/O-fel och sedan förorena senare jämförelser, så den första dåliga positionen och händelsen som föregick den är viktiga.

Nya länk- eller I/O-fel under scrubben är viktiga

En scrub skapar kontinuerliga läsningar och kan avslöja en marginal kabel, backplane, strömkontakt, USB-brygga eller kontrollerväg. Övervaka systemloggen medan scrubben körs. Länkrestart, kommandotidsgränser, enhetsbortkopplingar och CRC-fel är starkare varningar än enbart en långsam procentandel.

Om kommunikationsfel ökar men mediesektorsindikatorer förblir stabila, pausa innan du fördömer disken. Sätt tillbaka eller byt ut en anslutning i taget, bevara serienummer-till-fack-kartan, återställ felbaslinjen och upprepa en kontrollerad läsning. Ett fel som följer vägen kräver en annan reparation än ett fel som följer disken.

En scrub som inte kan slutföras är också ett resultat

En scrub som upprepade gånger pausar, startar om eller stannar vid nästan samma punkt tar inte bara lång tid. Bekräfta först att schemalagda jobb, avstängningar eller en annan resilvering inte avbryter den. Korrelera sedan stoppunkten med enhetsloggar och per-disk latens.

En schemalagd process bör ha en stabil baslinje för varaktighet och genomströmning. Vägledning om tolkning av scrub-utdata är användbar eftersom framsteg, reparerade byte och slutstatus måste läsas tillsammans; förfluten tid i sig fastställer inte skada.

Använd en trendtabell innan du bestämmer dig

En kort historik förhindrar att en enstaka bullrig körning leder till en riskfylld ersättning. Behåll observationerna nedan för minst den senaste rena körningen och varje körning efter det första felet.

När två eller fler upptrappningssignaler uppträder samtidigt, minska skrivningar, bekräfta backupen och diagnostisera den påverkade hårdvaruvägen innan du startar en ny fullständig scrub.

FAQ

Ska jag rensa felräknare efter en reparerad scrub?

Rensa dem endast efter att ha sparat rapporten och identifierat den fysiska disken. En rensad baslinje kan hjälpa till att upptäcka återkommande fel, men att rensa först förstör jämförelsen som visar om skadan är ny.

Betyder ett checksumfel att disken måste bytas ut?

Inte i sig. Ett korrigerat fel kan komma från media, minne, kablage eller en tidigare avbrott. Utbyte blir mer motiverat när nya fel följer samma disk med serienummer efter att vägen har kontrollerats.

Kan tung applikationstrafik skapa checksumskada?

Tung trafik kan sakta ner scrubben och avslöja svag hårdvara, men en legitim arbetsbelastning bör inte skapa verifierade innehållsmismatchningar. Behandla nya checksumfel som en lagringsintegritetshändelse, inte som en normal prestandabieffekt.

Beslutsgränsen

Kalla scrub-resultatet för förvärrande skada när fel ökar över slutförda körningar, reparationer återkommer på en medlem, okorrigerbara filer dyker upp eller samma hårdvaruväg fortsätter att återställa sig. Skydda data innan du upprepar belastningen.