Jak odróżnić uszkodzony kabel SATA od awarii dysku NAS

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.

How to Tell a Bad SATA Cable From a Failing NAS Drive - Zima Store Online

Nie decyduj, że dysk NAS uległ awarii po jednym rozłączeniu, ostrzeżeniu I/O lub linii SMART. Uszkodzony kabel SATA, luźne złącze, niestabilne zasilanie, uszkodzony port, problem z kontrolerem i uszkodzony dysk mogą powodować nakładające się objawy. Pewną metodą jest zachowanie oryginalnych dowodów, oddzielenie błędów łącza od błędów nośnika, zmiana jednej zmiennej na raz i sprawdzenie, czy nowe błędy podążają za ścieżką kabla czy numerem seryjnym dysku.

Chroń macierz i zachowaj pierwsze dowody

Jeśli NAS jest zdegradowany lub wielokrotnie rozłącza członka, ogranicz niepotrzebne zapisy i potwierdź, że nieodzowne dane istnieją na osobnej, czytelnej kopii zapasowej. Zapisz stan macierzy przed ponownym podłączaniem czegokolwiek. Test kabla jest tani, ale przypadkowe usunięcie drugiego dysku lub odbudowa przez niestabilne połączenie może spowodować znacznie poważniejszy problem z odzyskiwaniem danych.

Zapisz model, numer seryjny, zatokę, nazwę urządzenia, raport SMART, historię autotestów, zdarzenia kontrolera oraz dokładny czas każdego resetu lub błędu I/O uszkodzonego dysku. Przewodnik ZimaSpace dotyczący rozróżniania odłączonego dysku RAID od uszkodzonej zatoki opiera się na tej samej zasadzie: najpierw zidentyfikuj fizyczne urządzenie, a potem śledź, za którym elementem podąża błąd.

Nie czyść atrybutów SMART, liczników kontrolera ani dzienników systemowych przed zapisaniem punktu odniesienia. Wiele liczników to sumy całkowite z całego okresu użytkowania i nie wrócą do zera po wymianie kabla. Ważne jest, czy surowa wartość wzrasta po kontrolowanej zmianie. Fotografowanie okablowania i oznaczanie obu końców zapobiega późniejszym niejasnościom, która ścieżka była faktycznie testowana.

Zbuduj dwie konkurencyjne hipotezy przed testowaniem

Hipoteza A to awaria ścieżki połączenia: kabel danych SATA, złącze, port, ścieżka na backplane, kanał kontrolera, złącze zasilania lub niestabilne zasilanie. Ta ścieżka częściej powoduje resetowanie połączenia, błędy CRC, obniżanie prędkości, przekroczenia czasu poleceń, nagłe zniknięcia lub te same objawy na różnych dyskach podłączonych przez ten sam sprzętowy tor.

Hipoteza B to awaria dysku: nośnik nieczytelny, rosnąca liczba sektorów przeniesionych lub oczekujących, nieudane autotesty, awaria elektroniki wewnętrznej, nietypowe dźwięki lub błędy pojawiające się na tym samym dysku o tym samym numerze seryjnym, nawet przy użyciu znanych, sprawnych kabli i portów. Dyskusja na BleepingComputer wyjaśnia, dlaczego błędy transferu związane z kablem nie powinny być automatycznie traktowane jako fizyczne uszkodzone sektory.

Zachowaj obie hipotezy do momentu, aż dowody je rozdzielą. Jeden błąd CRC nie dowodzi, że kabel jest obecnie uszkodzony, a jeden błąd odczytu nie oznacza, że dysk należy natychmiast wyrzucić. Model testowy powinien pytać, które liczniki rosną, za którym komponentem podąża objaw oraz czy dysk może ukończyć długi test na stabilnej ścieżce.

Oddziel błędy łącza od błędów nośnika w danych SMART

Liczba błędów UDMA CRC, często oznaczana jako atrybut SMART C7 lub 199, to głównie wskazówka dotycząca ścieżki komunikacji. Level1Techs wyjaśnia, że błąd UDMA CRC rejestruje wykrytą korupcję między dyskiem a kontrolerem hosta. Kabel jest częstą przyczyną, ale odpowiedzialne mogą być także złącze, port, backplane, kontroler, niestabilność zasilania lub elektronika interfejsu dysku.

Atrybuty związane z nośnikiem wskazują na inny kierunek. Liczba przekierowanych sektorów, liczba oczekujących sektorów, błędy offline niekorygowalne, zgłaszane błędy niekorygowalne oraz długi test zakończony niepowodzeniem odczytu to silniejsze dowody problemu z dyskiem. Nazwy atrybutów i formaty surowe różnią się u producentów, więc porównuj trendy i wyniki testów zamiast stosować uniwersalny próg dla każdego modelu.

Suma CRC zapisana w pamięci sama w sobie nie wystarcza. Wyjaśnienie HardForum dotyczące obserwowania, czy surowa wartość CRC nadal rośnie oddaje kluczową różnicę. Jeśli liczba pozostaje niezmieniona po wymianie kabla, może to opisywać zdarzenie z przeszłości. Jeśli rośnie podczas nowych transferów, aktywna ścieżka łącza jest nadal niestabilna.

Dowody	Bardziej zgodne z kablem, portem lub ścieżką zasilania	Bardziej zgodne z uszkodzonym dyskiem	Wciąż niejednoznaczne
Liczba błędów UDMA CRC / interfejsu CRC	Nowe przyrosty zatrzymują się po zmianie kabla lub portu	Nowe przyrosty pojawiają się na tym samym dysku przez znane, dobre ścieżki	Stara, niezerowa wartość całkowita, która nie rośnie
Przekierowane lub oczekujące sektory	Zazwyczaj nie jest spowodowany samym kablem danych	Wartości rosną lub pozostają nierozwiązane po testach stabilnej ścieżki	Jeden historyczny parametr bez trendu lub wyniku testu
Długi test SMART	Powtarzalnie działa po naprawie łącza	Błąd powtarza się na określonym LBA lub etapie odczytu na innym systemie	Przerwano, ponieważ dysk został odłączony
Dzienniki systemowe	Reset łącza, błąd PHY, obniżenie prędkości, ponowne połączenie urządzenia	Niepoprawny odczyt nośnika, błąd sensora, powtarzający się zły LBA	Ogólny timeout I/O bez szczegółów niższego poziomu
Błąd następuje po	Ta sama zatoka, kabel, port, backplane lub gałąź zasilania	Ten sam dysk o tym samym numerze seryjnym	Kilka zmiennych zmienionych jednocześnie

Zmieniać jedną zmienną sprzętową na raz

Wyłącz NAS, gdy obudowa lub kontroler nie są zaprojektowane do dokładnie takiej operacji hot-swap, jaką planujesz wykonać. Oznacz dysk i kabel, a następnie wymień tylko kabel danych SATA na krótki, znany, dobry kabel, który pewnie się blokuje i nie jest ostro zgięty. Zachowaj ten sam dysk, port, złącze zasilania i zatokę do pierwszego porównania.

Uruchom system, zapisz nową bazę odniesienia i wykonaj ograniczone, reprezentatywne obciążenie, obserwując nowe błędy CRC, resetowania lub rozłączenia. Społeczność Unraid zauważa, że błędy CRC często wskazują na połączenie SATA, ale mogą też dotyczyć zasilania. Jeśli błąd się utrzymuje, przejdź do znanego, dobrego portu lub gałęzi zasilania, pozostawiając dysk bez zmian.

Nie wymieniaj kabla, nie przesuwaj dysku, nie zmieniaj portu ani nie zamieniaj przewodu zasilającego w jednym kroku. Może to spowodować zniknięcie objawu, ale zniszczy dowody potrzebne do identyfikacji uszkodzonego komponentu. Po każdej zmianie zanotuj upływ czasu, obciążenie, temperaturę, zmiany SMART i zdarzenia w logu, aby wynik można było porównać, a nie tylko zapamiętać.

Decyduj na podstawie tego, co następuje po nowym błędzie

Główną przyczyną jest kabel, gdy atrybuty nośnika dysku pozostają stabilne, długie testy przechodzą pomyślnie, a nowe błędy CRC lub zdarzenia resetu ustają po wymianie kabla danych. Wycofaj podejrzany kabel zamiast instalować go gdzie indziej. Jeśli problem powraca tylko na jednym porcie płyty głównej lub jednym slocie backplane, uszkodzony komponent znajduje się dalej w łańcuchu niż kabel.

Główną przyczyną jest dysk, gdy nieczytelne sektory, sektory oczekujące, zdarzenia realokacji lub awarie autotestu utrzymują się na znanym, dobrym kablu i porcie, zwłaszcza gdy dotyczy to tego samego LBA lub dysku o tym samym numerze seryjnym. Tom's Hardware również zauważa, że same błędy CRC wskazują na problem z ścieżką transferu, a nie automatycznie na uszkodzony dysk; wymiana dysku wymaga silniejszych dowodów z testów zdrowia nośnika lub śledzenia błędów.

Wspólna ścieżka jest główną przyczyną, gdy różne dyski zawodzą w tej samej zatoczce, na tym samym porcie kontrolera lub tym samym rozdzielaczu zasilania. Jeśli kilka dysków rozłącza się jednocześnie, sprawdź zasilacz, wspólny backplane, HBA i złącza, zanim potępisz wiele dysków. Przyczyną źródłową jest komponent wspólny dla awarii, niekoniecznie pierwsze urządzenie wymienione w ostrzeżeniu.

Napraw potwierdzoną przyczynę przed odbudową

W przypadku potwierdzonego problemu z kablem wymień go na stałe, zabezpiecz oba złącza, popraw ostre zagięcia lub napięcie i ustal nową bazę odniesienia liczników. Zweryfikuj zwykłe odczyty i zapisy, a następnie uruchom obsługiwany przez platformę skan lub kontrolę spójności. Zdrowy dysk może wrócić do pracy, gdy atrybuty nośnika pozostaną stabilne, a na naprawionej ścieżce nie pojawią się nowe błędy łącza.

W przypadku potwierdzonego problemu z dyskiem najpierw skopiuj czytelne, krytyczne dane, wymień dysk zgodnie z procedurą macierzy i monitoruj odbudowę. Zatrzymaj się i oceń sytuację ponownie, jeśli inny członek zacznie wykazywać błędy lub wymieniany dysk będzie się powtarzalnie rozłączał. Wyjaśnienie ZimaSpace dotyczące redundancji RAID a odzyskiwania z kopii zapasowej jest tu kluczowe: odbudowa przywraca redundancję, a nie wcześniejszą czystą kopię uszkodzonych danych.

Przekaż do diagnostyki kontrolera, backplane’u lub zasilania, gdy ta sama ścieżka wpływa na wiele znanych, dobrych dysków. Nie rozpoczynaj powtarzających się odbudów, by „zobaczyć, co się stanie”. Diagnoza jest zakończona dopiero, gdy podejrzany komponent zostanie wyizolowany, ścieżka zastępcza jest stabilna, liczniki przestają rosnąć, dysk lub macierz przejdzie weryfikację, a ważne dane pozostaną możliwe do odzyskania poza NAS.

FAQ

Czy niezerowa liczba błędów UDMA CRC oznacza, że dysk się psuje?

Nie. Rejestruje błędy komunikacji wykryte na ścieżce między dyskiem a hostem. Zapisz aktualną wartość i obserwuj, czy wzrasta po wymianie kabla i przetestowaniu na znanym, dobrym porcie.

Czy uszkodzony kabel SATA może powodować sektory oczekujące?

Uszkodzony kabel częściej powoduje błędy transferu lub łącza. Sektory oczekujące lub przeniesione są silniejszymi wskazówkami dotyczącymi stanu nośnika, ale przerwane polecenia i niejednoznaczne logi mogą się nakładać. Przetestuj dysk ponownie na stabilnej ścieżce przed podjęciem decyzji.

Czy powinienem przeprowadzić długi test SMART na zdegradowanej macierzy RAID?

Najpierw zabezpiecz czytelne dane i uwzględnij obciążenie pozostałych członków. Przeprowadzaj testy zgodnie z wytycznymi platformy NAS, unikaj nakładania się ciężkich zadań i zatrzymaj się, jeśli pojawią się rozłączenia lub dodatkowe błędy.