Jak zidentyfikować i naprawić pliki z uszkodzonymi / niedostępnymi blokami dysku

9

Mam MacBooka Pro z 2011 roku z systemem Mavericks 10.9.2. Jego jedynym dyskiem twardym jest dysk o pojemności 750 GB sformatowany za pomocą Bootcamp. Nadal działa dość dobrze, ale podczas uruchamiania przepustki defragmentacji zauważyłem, że istnieje grupa plików, które odmawiają przeniesienia przez defragmentator (iDefrag).

iDefrag zgłasza kod błędu POSIX o wartości 5 podczas uzyskiwania dostępu do plików. Wybieranie jednego losowo i próba skopiowania pliku do innej lokalizacji w powłoce również zgłasza błąd, co sprawia, że myślę, że problem jest prawdziwy i dotyczy dysku / FS. Wyjście cp wynosi:

cp: unity_nophysx.nexe: Input/output error

O ile mi wiadomo, kod błędu 5 to „odmowa dostępu”, ale proces defragmentacji jest uruchamiany jako administrator i cp przy użyciu sudo na podejrzanym pliku nie ma znaczenia.

Disk Utility, fsck i Apple Hardware Test wszystkie twierdzą, że dysk jest w porządku. Nie zgłoszono żadnych błędów SMART, a chociaż były pewne błędy uprawnień, nie były to pliki, na które narzeka iDefrag, a Narzędzie dyskowe twierdzi, że je naprawiło bez skargi.

Istnieje może sto lub więcej uszkodzonych plików, ale wciąż bardzo niewielka część dysku. O ile wiem, nie ma to wpływu na pliki systemowe ani ważne dane. Chociaż byłoby miło odzyskać dane, nie mam nic przeciwko ponownemu instalowaniu lub tworzeniu kopii zapasowych. W tym momencie nie wiem, czy to naprawdę umiera dysk, tylko niektóre złe sektory z powodu przeniesienia dysku podczas pisania, czy jakieś inne drobne uszkodzenia, które można obejść. Przyjmuję najgorszy przypadek i najprawdopodobniej będę musiał uzyskać nieco większy dysk twardy i sklonować istniejący dysk, aby uniknąć konieczności przebudowy systemu.

Moje pytanie dotyczy naprawdę tego, jak zabrać się za oznaczanie tych uszkodzonych plików jako odpowiednio uszkodzonych oraz ich naprawianie lub usuwanie , aby klon dysku odniósł sukces i nie zawiesił się na plikach / blokach, do których nie ma dostępu. Narzędzie dyskowe nie widzi problemu i nie znam żadnego wiersza polecenia ani narzędzi innych firm, które wykonałyby to zadanie. Nie chcę odpisywać całego dysku i zaczynać od zera, ponieważ dysk wydaje się w inny sposób zdrowy, dlatego szukam narzędzi naprawczych / diagnostycznych.

— MrCranky
źródło

Radzę przeczytać tę dość szczegółową podobną dyskusję na SuperUser: superuser.com/q/148227 .

— dn

Testowałem niestety na zdrowym dysku :), volitans-software.com/smart_utility.php . Wygląda jak dość proste i poważne narzędzie. Możesz spróbować i przede wszystkim sprawdzić licznik „realokacji sektorów”.

— dn

9

Jeśli masz do czynienia ze zdrowym systemem plików na poziomie jego struktury i chcesz znaleźć pliki z uszkodzonymi blokami dysku, oto jak postąpiłbym:

Wykonaj pełną kopię zapasową dysku za pomocą Time Machinelub Carbon Copy Cloner

Sprawdź tę kopię zapasową.
Uruchom następującą ciężką i ryzykowną (na wypadek, gdy masz złe bloki poza strukturą systemu plików) (upewnij się, że podano {}, aby nazwy plików zawierające spacje działały):
```
find / -type f -print -exec dd if="{}" of=/dev/null bs=1m \;
```

To ciężkie findpolecenie wypisze dla każdego zwykłego pliku jego nazwę (a więc nie czyta go, ale tylko pozycję katalogu), a następnie kontynuuje pełny i szybki odczyt wszystkich swoich bloków danych.

Po hiting pierwszy plik zawierający uszkodzonych bloków, to findspowoduje, że jądro do logowania read errorna /var/log/system.logi będzie albo spowolnić lub przynieść swój system do całkowitego zatrzymania. Będzie to zależeć głównie od pojemności dysku twardego w celu przeniesienia uszkodzonych bloków znajdujących się w jego wewnętrznej puli przeznaczonej do tego zwykłego zadania naprawy. Ten plik zawierający uszkodzone bloki będzie nazwiskiem wydrukowanym przez find.

Zapisz nazwę tego pliku na kartce papieru! Powiedzmy, że ta nazwa pliku to:

/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9

W tym momencie możesz mieć możliwość findszybkiego zabicia , naciskając ctrl+ C. Jeśli ładne zabicie go nie powiedzie się, po prostu rozbij komputer Mac.

Po ponownym uruchomieniu komputera Mac bezpośrednio sprawdź plik zawierający uszkodzone bloki:

dd if='/.DocumentRevisions-V100/.cs/ChunkStorage/0/0/0/9' of=/dev/null bs=1m

Jeśli polecenie zakończy się poprawnie, błąd był wystarczająco lekki, aby dysk mógł odczytać ten plik i ponownie przydzielić uszkodzone bloki.

Jeśli polecenie nie zostanie zakończone, nie będziesz w stanie zabić go normalnie, twoje dane zostaną całkowicie utracone i będziesz musiał ponownie zawiesić komputer Mac.

W tym ostatnim przypadku musisz rozważyć wymianę dysku i pracę z ostatnimi kopiami zapasowymi. Niektóre inne pliki mogą również zawierać uszkodzone bloki i mogły pozostać niewykryte od dłuższego czasu, dopóki ich nie przeczytałeś.

Jądro nie uruchomi błędu odczytu w bloku, którego nigdy nie czytałeś.

— dan
źródło

Aha, to jest absolutnie taka sztuczka, na jaką liczyłem. Pierwsze przejście ze skryptem find / dd dotyka wszystkich plików / bloków na dysku, i na pewno znajduję kilka plików, które dają „Błąd wejścia / wyjścia”, i mogę po prostu wyprowadzić dziennik polecenia do pliku i następnie grep, aby dowiedzieć się, które pliki są kopiowane. Wygląda na to, że sama komenda dd nie wystarcza do uruchomienia jakiegokolwiek automatycznego naprawiania (nawet nie wiedziałam, że OS X to zrobił), ale przynajmniej daje mi niezawodny sposób na identyfikację plików.

— MrCranky

Na plus, gdy system operacyjny próbuje odczytać z plików z tymi uszkodzonymi blokami, nie zawiesza się ani nie kończy się strasznie. Widzę May 10 20:42:15 ICE kernel[0]: disk0s2: I/O error.okienko wyskakujące w dziennikach, ale nie mam pojęcia, który plik go wywołał. Ale potem polecenie działa całkiem szczęśliwie.

— MrCranky

Jądro nie zawiesza się z BBFH, ponieważ dysk wciąż ma wystarczającą liczbę bloków w puli, aby naprawić uszkodzone bloki. ddnic nie naprawia, to polecenie służy do kopiowania danych i konwertowania ich tak szybko, jak to możliwe. Dysk nadal może naprawić lekkie błędy. Bądź czujny, cena dysku nie ma wpływu na twoją pracę.

— dan

Mmm, tak, założyłem, że: dd jest po prostu głupim narzędziem do rozwiercania wszystkich danych z jednego pliku i umieszczania ich gdzie indziej (w naszym przypadku w powietrzu). Tak naprawdę liczy się to, że każdy blok związany z plikiem jest odczytywany. Nie dostaję tego, czego oczekujesz od OS X w tym przypadku. Oczywiście jądro nie może odczytać tych złych bloków, ale czy uważasz, że sam dysk może i może je naprawić? Jeśli nie może pobrać danych z oryginalnego uszkodzonego bloku, jak zamierza przenieść je gdzie indziej?

— MrCranky

Doskonałe pytanie. Dysk automatycznie wykona ponowną próbę odczytu bloków. Za każdym razem pozycja głowy jest mechanicznie w innej pozycji. Jeśli jedna z tych prób zakończy się powodzeniem, dane zostaną skopiowane do jednego z bloków dostępnych do naprawy uszkodzonych bloków. Zły blok jest oznaczony jako zły i nigdy nie będzie ponownie używany. Z drugiej strony, jeśli wszystkie próby zakończą się niepowodzeniem, dane nie zostaną zapisane, a po bardzo długim czasie dysk oznaczy blok jako zły i przypisze nowy pusty do widocznego dysku. Jądro zgłosi nieodwracalny błąd dysku.

— dan

5

Uruchom ponownie w trybie pojedynczego użytkownika, przytrzymując Command+ Spodczas rozruchu. Gdy zobaczysz monit (powinien wyglądać root #lub podobny), wpisz fsck -fi naciśnij Return. Jest to wbudowane narzędzie do sprawdzania spójności systemu plików Mac i umożliwia znajdowanie i naprawianie błędów w systemie plików uruchamiania. Uruchom to polecenie, dopóki nie zobaczysz **The volume [volume name] was modified.**lub narzędzie nie zawiedzie trzy razy z rzędu.

Jeśli narzędzie zawiedzie, może to wskazywać na większy problem (ale nie mogłem ci powiedzieć bez obejrzenia wyniku działania narzędzia). W każdym razie upewnij się, że wykonałeś kopię zapasową wszystkiego, co możesz, przed uruchomieniem dowolnego narzędzia dyskowego. Po zakończeniu wpisz rebootznak zachęty i naciśnij klawisz Enter, aby (zgadłeś!) Zrestartować komputer.

Aby uzyskać dodatkowe informacje, można znaleźć strony podręcznika fsck tutaj .

— Matt
źródło

Ciekawe, ale wygląda bardzo podobnie do fsck, nawet z opcją -f iw trybie pojedynczego użytkownika robi dokładnie to, co zrobił Narzędzie dyskowe. Podobnie jak Narzędzie dyskowe, nic nie znajduje i uważa, że dysk jest w porządku. Zakładam, że skanuje on rekordy systemu plików, ale myślę, że mój problem jest na poziomie bloku - tzn. System plików jest dobrze skonstruowany, ale rzeczywistych danych w plikach nie można uzyskać, jeśli chodzi o odczyt / kopiowanie / defragmentowanie ich.

— MrCranky

1

→ MrCranky: racja! fscki Disk Utilitysprawdzamy integralność struktury systemu plików. Odczytują bloki dyskowe przypisane do struktury systemu plików. Nie mają na celu weryfikacji integralności bloków danych. W związku z tym mogą działać na dysku z uszkodzonymi blokami bez powodowania żadnego błędu odczytu. Jeśli chcesz sprawdzić dysk, nawet bloki, które mogą być wadliwe, ale w rzeczywistości są nieużywane, po prostu użyj podstawowego narzędzia dd if=/dev/disk0 of=/dev/null ibs=1kw trakcie innego uruchomienia okna powłoki tail -f /var/log/system.log. Jest to bezpłatne, ekstremalne i nie ukryje żadnego błędu.

— dan

2

Zdecydowanie poleciłbym DiskWarrior do odbudowywania katalogów dysków i skanowania w poszukiwaniu potencjalnie uszkodzonych plików .

Podczas przebudowywania katalogu może również informować o opóźnieniach spowodowanych wadliwym działaniem dysku.

— Adam
źródło

Nie jestem przeciwny kupowaniu narzędzia, które pomoże, ale bez okresu próbnego i bez gwarancji, że jest ono nawet przeznaczone do wyszukiwania błędów, których potrzebuję, potrzebuję o wiele więcej zaleceń, aby wykonać kopię zapasową twojego, zanim będę przygotowany na zrzucenie 100 $ na narzędzie.

— MrCranky

-1 Nie tylko odpowiedź, ale mieszanka komentarza i odpowiedzi.

— bot47

2

Opierając się na odpowiedzi Buscara, możesz to zrobić automatycznie, używając dość ciężkiego wiersza poleceń foo.

sudo find / -type f -print0  | xargs -0 -I{} dd if='{}' of=/dev/null bs=1m 2>&1 | grep 'error' >>badfiles.txt  &

sudo: tryb administratora
znajdź -print0: ścieżka bezwzględna
xargs -0 -I {}: podstaw {} w następnym poleceniu
dd 2> i 1: przekieruj błąd std na standardowe wyjście
potok stdout do grep szuka błędu ciągu
Dołącz wyniki do pliku listy. ( Uwaga : powinien znajdować się na zewnętrznym nośniku, jeśli uważasz, że twój dysk wewnętrzny jest wadliwy)

— awiebe
źródło

1

Jak mówisz, nie jest nawet jasne, czy te pliki są uszkodzone, przynajmniej komputer Mac tak nie uważa.

Każdy system operacyjny tworzy nieprzenośne pliki potrzebne do jego działania (punkty przywracania, obecnie aktywne pliki itp.). Niektóre defragry pokażą je, inne nie.

Fakt, że nie możesz uzyskać do nich dostępu ani ich przenieść, nie oznacza, że są uszkodzone.

Zwykle komputery Mac bardzo dobrze dbają o siebie.

Korzystanie z konserwacji Apple odbywa się przez: otwórz Terminal i wpisz:

sudo periodic daily weekly monthly

następnie Return, wprowadź hasło administratora, a OS X zajmie się Tobą.

Jeśli jesteś zainteresowany, poszukaj raportów w konsoli.

Podczas szukania w konsoli (wyszukiwania) błędów we / wy, które mogłyby wskazywać na problemy z dyskiem, należy uzupełnić Narzędzie dyskowe i wyniki fsck.

Czasami używam bezpłatnego narzędzia o nazwie OnyX do dodatkowego zadania konserwacyjnego. Jest wytwarzany przez Francuzów, a ponieważ jedzą, jest po prostu świetny :)

_{OnyX to wielofunkcyjne narzędzie dla OS X, które pozwala zweryfikować dysk startowy i strukturę jego plików systemowych, uruchomić różne zadania związane z konserwacją systemu, skonfigurować niektóre ukryte parametry Findera, Docka, QuickTime, Safari, Mail, iTunes , okno logowania, Spotlight i wiele aplikacji Apple, aby usunąć pamięci podręczne, usunąć pewną liczbę plików i folderów, które mogą stać się kłopotliwe, i wiele więcej.}

Biorąc to wszystko pod uwagę, nie kwestionuję twojej decyzji o użyciu defragmentatora (iDefrag), ponieważ nie wiem, ale raczej oferuję alternatywne rozwiązania.

— Ruskes
źródło

Użycie defragmentatora nie jest problemem, jestem całkowicie świadomy tego, co OS X robi i czego nie robi w tym zakresie. Pliki zdecydowanie nie były w użyciu, były to pliki danych dla aplikacji, która nie była aktywna i rzeczywiście aplikacji nie można teraz przenieść.

— MrCranky

W przypadku Onyx - znowu robi niewiele więcej niż Narzędzie dyskowe - sprawdza status SMART dysku, a następnie uruchamia diagnostykę stylu fsck (która, jak ustaliliśmy, uważa, że nie ma nic złego)

— MrCranky

Dla jasności, dla każdego, kto czyta tę odpowiedź, pliki z pewnością zostały uszkodzone, a Mac wiedział o tym, ponieważ nie mogłem od nich czytać (kopiować, cokolwiek). Nie dlatego, że były to pliki systemowe, albo były w użyciu w tym czasie, tak było nawet w przypadku plików danych użytkownika. Okresowa konserwacja nie pomogła w rozwiązaniu tego problemu, ponieważ fsckwydaje się, że dba się tylko o problemy z systemem plików, a nie blokuje problemy z dostępnością. Konsola pokazywała błędy tylko wtedy, gdy ręcznie próbowałem skopiować / odczytać dane z jednego z tych uszkodzonych plików, nie pomogłem w ich znalezieniu.

— MrCranky

0

Choć wydaje się to nierozsądne, przed zrobieniem czegokolwiek powinieneś zduplikować wszystkie swoje dane na znany dobry dysk. Jeśli uruchamianie z instalatora i kopiowanie danych nie powiedzie się, istnieje narzędzie wiersza polecenia o nazwie „dd”, które może powielać na niskim poziomie w znacznie bardziej bezkompromisowy sposób.

 man dd

aby uzyskać więcej informacji o dd, w tym o użyciu i właściwej składni.

Kolejny głos na post Matta, uruchom tryb pojedynczego użytkownika i uruchom

 fsck -fy

w kółko, aż fsck przestanie zgłaszać błędy.

DiskWarrior to głosowanie na stanowisko Adama. Jest to prosta w użyciu, ale bardzo wydajna aplikacja, która będzie raportować awarie dysku twardego, sprawdzać poszczególne pliki pod kątem błędów i naprawiać je, jeśli to możliwe, a także odbudowywać i optymalizować struktury katalogów.

Innym możliwym rozwiązaniem, które może wydawać się nieracjonalne, ale często jest ostatnią próbą odzyskania danych z dużą ilością niedokończonych dowodów na powodzenie, jest wyciągnięcie dysku, ochrona go przed wilgocią za pomocą kilku warstw worków zamrażarki i umieszczenie go w zamrażarce na 30-45 minut. Następnie, gdy dysk jest zimny, zamontuj dysk w zewnętrznej stacji dokującej USB i użyj innego systemu tymczasowego, aby ponownie spróbować skopiować uszkodzone dane na inny dysk. Zasadniczo jest to stosowane, jeśli występuje problem sprzętowy i dysk jest uszkodzony. Jeśli możesz zduplikować cały dysk z nienaruszonymi danymi, jest to idealne rozwiązanie, ponieważ często partycjonowanie i formatowanie daje dyskowi nową żywotność.

— wyluzowana
źródło

Jak już powiedziałem, fsck nie zgłasza żadnych błędów. Dysk nie ma jeszcze temperamentu ani nie zgłasza przypadkowych błędów, a lista uszkodzonych plików nie wydaje się powiększać, więc nie sądzę, żebym był w pobliżu etapu „zamrożenia dla ostatniego awaryjnego ściągnięcia”. Kopie zapasowe mam już bardzo dobrze na poziomie plików / folderów i nie martwię się o utratę danych, jak powiedziałem w pytaniu. Dobrze jednak usłyszeć kolejny głos na DiskWarrior.

— MrCranky

@MrCranky: Uważam, że odwołujesz się do czegoś opublikowanego przed aktualizacją pytania; Wzmacniałem pomysł fsck dla wszystkich, którzy znajdują tę stronę w poszukiwaniu rozwiązania podobnych objawów. W odniesieniu do wszystkiego, co opublikowałem na temat awarii dysku twardego, nigdy nie boli to, że jest kompleksowy dla innych i niekoniecznie dla ciebie osobiście. Widziałem mój uczciwy odsetek awarii dysków twardych. Często nie ma oznak awarii, nawet w przypadku technologii SMART, dopóki nie będzie można uzyskać dostępu do danych w jakikolwiek sposób. Jeśli zależy Ci na danych, zdecydowanie zaleciłem zakup nowego dysku i wykonanie kopii zapasowej danych.

— chillin

Z pewnością nie zgadzam się z zaleceniem dotyczącym tworzenia kopii zapasowych, ale duchem formatu pytań i odpowiedzi jest odpowiedź na postawione pytanie, a nie ogólne pytanie „jak naprawić uszkodzony dysk” (których jest wiele). Na długo przed jego edycją dodałem fsckdo listy „rzeczy, które uważają, że dysk jest w porządku”, odpowiedziałem na wzmiankę o odpowiedzi pomijając fsckjego przydatność. fsckNarzędzie dyskowe wykonuje tę samą funkcję, a mianowicie działa na strukturach systemu plików, a nie na poziomie bloku. Próbowałem sprecyzować, że jest to problem z blokiem, a nie problem z systemem plików.

— MrCranky

0

W przypadku pojedynczego pliku, którego nie można odczytać w całości z powodu błędu odczytu dysku, można użyć ddnarzędzia do zduplikowania pliku do woluminu zewnętrznego, zastępując bajty NUL blokami, których nie można odczytać. Zdecydowanie zaleca się powielenie na innym woluminie (np. „Dysk USB” w poniższym przykładzie).

Przykład:

dd if=/path/to/damaged/file of=/Volumes/USB\ Disk/file bs=512 conv=noerror,sync

Dzięki zastosowaniu bloków 512-bajtowych odzyskana zostanie maksymalna liczba czytelnych bloków.

Odzyskiwanie może zająć dużo czasu, ponieważ jądro będzie blokować się przez pewien czas przy każdym nieudanym czytaniu.

— bleater
źródło