Jakie są oznaki ostrzegawcze, że skanowanie RAID wykrywa nowe uszkodzenia?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

What Are the Warning Signs That a RAID Scrub Is Finding New Damage?

Scrub wykrywa nowe uszkodzenia, gdy liczba błędów rośnie między kolejnymi przebiegami, naprawy powtarzają się na tym samym urządzeniu lub wcześniej czyste dane stają się niekorygowalne. Pojedynczy naprawiony blok nie oznacza pogarszającego się wzoru.

Najbezpieczniejszą interpretację uzyskuje się, porównując zakończone raporty scrub, błędy na poziomie dysku oraz dotknięte pliki, zamiast reagować na pojedynczą alarmującą liczbę. Ten przewodnik oddziela normalną korekcję od narastających uszkodzeń i pokazuje, kiedy należy przerwać rutynową konserwację i najpierw chronić dane.

Rosnąca liczba błędów to najczytelniejsze ostrzeżenie

Najważniejsze jest nie to, czy scrub zgłasza jakikolwiek błąd, ale czy kolejny zakończony scrub zgłasza więcej błędów sum kontrolnych, parzystości, nośnika lub niekorygowalnych. Stabilna liczba po naprawie może odzwierciedlać zdarzenie z przeszłości. Rosnąca liczba oznacza, że ścieżka pamięci nadal generuje złe odczyty lub złe dane.

Zapisuj czas rozpoczęcia, czas zakończenia, naprawione bajty, liczbę niekorygowalnych błędów oraz liczniki odczytu, zapisu lub sum kontrolnych dla każdego urządzenia po każdym przebiegu. Praktyczne wyjaśnienia scrubowania i cichej korupcji pokazują, dlaczego pełny odczyt może ujawnić uszkodzenia, których zwykłe obciążenia nie dotknęły przez miesiące.

Powtarzające się naprawy na tym samym dysku wymagają uwagi

Redundantny system plików może naprawić uszkodzony blok z innej kopii i nadal utrzymać pulę online. Ostrzeżenie pojawia się, gdy kolejne scruby naprawiają nowe bloki na tym samym fizycznym dysku, zwłaszcza gdy dysk gromadzi również sektory oczekujące, przealokowane lub niekorygowalne.

Nie czyść liczników i nie zapominaj o zdarzeniu. Najpierw zapisz numer seryjny dysku, migawkę SMART i wynik scrub. Następnie wykonaj długi autotest dysku tylko wtedy, gdy macierz pozostaje redundantna i responsywna. Powtarzające się korekty są dowodem do zbadania członka, kabla, zatoki, ścieżki zasilania i kontrolera, a nie dowodem, że system plików rozwiązał przyczynę.

Niekorygowalne pliki zmieniają priorytet

Wynik niekorygowalny oznacza, że redundancja nie mogła wygenerować zweryfikowanej kopii przynajmniej dla jednego bloku. W takim przypadku kolejny scrub nie jest automatycznie następnym krokiem. Zidentyfikuj nazwane pliki, skopiuj czytelne krytyczne dane w inne miejsce i zachowaj logi przed wprowadzeniem zmian w topologii.

Przykład scrubu z niekorygowalnymi danymi pokazuje różnicę między skorygowanymi metadanymi a plikami, które nadal musiały zostać przywrócone z kopii zapasowej. Użytecznym sygnałem nie jest sama duża suma surowych błędów, lecz to, czy czysty kolejny przebieg może zakończyć się bez nowych błędów.

Powtarzające się błędy w tym samym obszarze logicznym nie są normalne

Błędy powtarzające się w tym samym pasku, zakresie bloków lub pliku mogą wskazywać na trwały nieczytelny obszar lub uszkodzony stan parzystości. Błędy przemieszczające się mogą wskazywać na szersze pogorszenie nośnika, niestabilną pamięć, problem z łączem lub niestabilność zasilania. Zapisuj dokładne przesunięcia, gdy platforma je ujawnia.

Nie wymuszaj wielokrotnie napraw na milionach błędów bez zrozumienia pierwszego dotkniętego zakresu. Duża klaster błędów parzystości może pochodzić z jednego wcześniejszego błędu I/O i następnie zanieczyścić późniejsze porównania, więc pierwsza zła pozycja i zdarzenie, które jej poprzedziło, mają znaczenie.

Nowe błędy łącza lub I/O podczas scrubu mają znaczenie

Scrub generuje ciągłe odczyty i może ujawnić marginalny kabel, płytę tylnią, złącze zasilania, mostek USB lub ścieżkę kontrolera. Obserwuj dziennik systemowy podczas działania scrubu. Resetowanie łącza, przekroczenia czasu poleceń, odłączania urządzeń i błędy CRC są silniejszymi ostrzeżeniami niż samo wolne tempo procentowe.

Jeśli błędy komunikacji rosną, ale wskaźniki sektorów nośnika pozostają stabilne, wstrzymaj się z potępieniem dysku. Przełóż lub wymień jedno połączenie na raz, zachowaj mapę numerów seryjnych do zatok, zresetuj bazę błędów i powtórz kontrolowany odczyt. Usterka pozostająca na ścieżce wymaga innej naprawy niż usterka podążająca za dyskiem.

Scrub, który nie może się zakończyć, to także wynik

Scrub, który wielokrotnie zatrzymuje się, restartuje lub zatrzymuje się w prawie tym samym miejscu, nie oznacza tylko długiego czasu trwania. Najpierw potwierdź, że zaplanowane zadania, wyłączenia lub inny resilver go nie przerywają. Następnie skoreluj punkt zatrzymania z logami urządzenia i opóźnieniami na dysku.

Zaplanowany proces powinien mieć stabilną bazę dla czasu trwania i przepustowości. Wskazówki dotyczące interpretacji wyników scrubu są przydatne, ponieważ postęp, naprawione bajty i ostateczny status muszą być czytane razem; sam upływ czasu nie potwierdza uszkodzeń.

Użyj tabeli trendów przed podjęciem decyzji

Krótka historia zapobiega podejmowaniu ryzykownej wymiany na podstawie jednego głośnego przebiegu. Zachowuj poniższe obserwacje co najmniej od ostatniego czystego przebiegu i każdego przebiegu po pierwszym błędzie.

Obserwacja	Zwykle monitoruj	Natychmiast eskaluj
Naprawione bloki	Jedno zdarzenie, następny scrub czysty	Nowe naprawy w kolejnych scrubach
Dane niekorygowalne	Brak	Jakikolwiek nazwany plik lub trwały błąd
Liczniki urządzeń	Stabilne po resecie	Liczby odczytów/zapisów/sum kontrolnych stale rosną
Dziennik systemowy	Brak resetów lub przekroczeń czasu	Powtarzające się odłączania, resetowania lub błędy I/O
Zakończenie	Zakończenie bliskie normalnej bazie	Wielokrotne zatrzymania w tym samym zakresie

Gdy pojawi się dwa lub więcej sygnałów eskalacji, zmniejsz zapisy, potwierdź kopię zapasową i zdiagnozuj dotkniętą ścieżkę sprzętową przed rozpoczęciem kolejnego pełnego scrubu.

FAQ

Czy powinienem czyścić liczniki błędów po naprawionym scrubie?

Wyczyść je tylko po zapisaniu raportu i zidentyfikowaniu fizycznego dysku. Wyczyść bazę tylko wtedy, gdy chcesz wykryć ponowne wystąpienie, ale wcześniejsze wyczyszczenie niszczy porównanie, które mówi, czy uszkodzenie jest nowe.

Czy jeden błąd sumy kontrolnej oznacza konieczność wymiany dysku?

Samo w sobie nie. Jeden skorygowany błąd może pochodzić z nośnika, pamięci, okablowania lub wcześniejszej przerwy. Wymiana staje się bardziej uzasadniona, gdy po sprawdzeniu ścieżki pojawiają się nowe błędy na tym samym dysku o tym samym numerze seryjnym.

Czy duży ruch aplikacji może powodować uszkodzenia sum kontrolnych?

Duży ruch może spowolnić scrub i ujawnić słaby sprzęt, ale prawidłowe obciążenie nie powinno powodować niezgodności zweryfikowanej zawartości. Traktuj nowe błędy sum kontrolnych jako zdarzenie integralności pamięci, a nie normalny efekt uboczny wydajności.

Granica decyzji

Uznaj wynik scrubu za pogarszające się uszkodzenie, gdy błędy rosną w kolejnych zakończonych przebiegach, naprawy powtarzają się na jednym członku, pojawiają się dane niekorygowalne lub ta sama ścieżka sprzętowa ciągle się resetuje. Chroń dane, zanim powtórzysz obciążenie.