Jak zinterpretować i naprawić błąd wejścia / wyjścia w systemie Linux?


21

Korzystam z codziennej kopii zapasowej za pomocą rsync. Począwszy od kilku dni temu jeden z plików zgłaszał ten błąd podczas tworzenia kopii zapasowej:

rsync: read errors mapping "/home/folder/file.ext": Input/output error (5)
WARNING: /home/folder/file.ext failed verification -- update discarded (will try again).

Jaki jest najlepszy sposób działania? Czy to tylko uszkodzony plik? A może coś jest nie tak z dyskiem twardym w lokalizacji pliku? Czy powinienem go po prostu usunąć i skopiować jedną z kopii zapasowych do lokalizacji pliku? Czy jest coś jeszcze / co powinienem zrobić?

Odpowiedzi:


17

Błąd rsync

 read errors mapping ....: Input/output error (5)

wskazuje niemożność odczytu lub zapisu pliku przez rsync. Najbardziej prawdopodobnymi przyczynami tego błędu są wady dysku, albo w SRC, albo w katalogu TGT. Inne możliwości obejmują jednak niewystarczające uprawnienia, blokadę plików przez programy antywirusowe i maybeinne przyczyny.

Pierwszym krokiem w kierunku diagnozy jest próba ręcznego skopiowania plików. Może to działać, jeśli na przykład źródłem błędu była wada dysku w katalogu TGT; powtarzając operację później, zapiszesz w innej części dysku, a problem mógł wyparować.

Alternatywnie możesz odkryć, że nie możesz uzyskać dostępu do pliku w katalogu SRC. W takim przypadku sugeruję skorzystanie z dowolnego narzędzia do sprawdzania dysku dostępnego dla Twojej dystrybucji.

Niewystarczające uprawnienia antywirusowe są łatwiejsze do zdiagnozowania.

Wreszcie, jeśli masz zły sektor w katalogu SRC, możesz wykluczyć to z przyszłych uruchomień rsync za pomocą

rsync -av --exclude='/home/my_name/directory_with_corrupt_files/*'

Dzięki! Ryzykując, że będzie to kolejne pytanie, w jaki sposób dowiem się, czy jest to katalog SRC czy TGT, jeśli mogę wykluczyć uprawnienia lub program antywirusowy?
— odkrycie

Antywirus blokuje pliki na pewien czas. W takim przypadku ponowna próba wykonania tego samego polecenia później nie powinna powodować wystąpienia tego samego błędu. Kwestia uprawnień jest łatwa: użyj konta root na komputerach SRC i TGT. Jeśli nie możesz tego zrobić, sprawdź, czy pliki, na których nie działa rsync, są dostępne dla Ciebie, tzn. Należą do konta próbującego uzyskać do nich dostęp, a jeśli nie, że masz do nich dostęp do odczytu. Jeśli to rozwiąże twoją sprawę, pamiętaj o przyjęciu mojej odpowiedzi, jest to przydatne dla innych czytelników.
— MariusMatutiae

Źle zrozumiałeś mój komentarz powyżej. Nieważne, zadam nowe pytanie.
— odkrycie

TGT jest tylko celem, prawda? Lepiej więc powiedzieć po prostu cel.
— Jasper

Wygląda na to, że twoja odpowiedź dała początek całemu artykułowi bobcares.com/blog/rsync-input-output-error_5 ( oczywiście bez referencji).
— Yaroslav Nikitenko

3

Miałem podobny problem, miałem urządzenie z bezpiecznikiem zamontowane przez USB, które często się rozłączało, powodując błędy We / Wy. Moja kopia zapasowa nigdy się nie zakończy, ponieważ błędy we / wy zaczną się w połowie drogi do rsync i pomimo wielokrotnego uruchamiania rsync, w pewnym momencie synchronizacja nie przejdzie poza aktualizację istniejących plików.

Moim rozwiązaniem było użyć

--ignore-existing 

opcja. W ten sposób mogłem uruchomić synchronizację w pętli, aż zobaczyłem status wyjścia 0.

Oczywiście w tym przypadku nie dbałem o aktualizacje istniejących plików.


0

Mam 2 dyski zewnętrzne, które synchronizuję i używam rsync. Wykonuję to zadanie regularnie na jednym z dwóch komputerów i często ze względu na wygodę przełączam się między nimi. Mam 4 komputery z systemem Debian 9 i używam tych dysków na każdym z nich.

Dziś rano użyłem następujących:

rsync -ahv --delete drive-x drive-y 

i był zaskoczony, że zgłoszono kilkaset awarii.

głównie: rsync: readlink_stat... failed: Input/output error (5)
także:rsync: rsync: recv_generator: mkdir ... failed: Read-only file system (30)

Aby dowiedzieć się, co się wydarzyło, ponownie zamontowałem dyski dwa razy, uruchomiłem ponownie, uruchomiłem rsyncbez --deletei zasadniczo moje normalne próby naprawienia czegoś, co niezawodnie działało przez długi czas. Nawet pomyślałem o rsyncponownej instalacji . Zanim to zrobiłem, zdecydowałem się rsyncna 2 dyski na drugim komputerze, który uruchamiam offline. rsyncdziałało tak, jak powinno.

Po przeczytaniu zamieszczonego tutaj materiału zainstalowałem clamav, zaktualizowałem podpisy i zeskanowałem mój katalog domowy. Używam tego regularnie na innym komputerze. Znalazłem 1 i tylko 1 PUA i usunąłem go. Zawsze usuwam PUA. Następnie ponownie zamontowałem dwa dyski na tym komputerze i do każdego z nich dodałem różne pliki testowe i foldery.

Pobiegłem rsync -ahv --delete drive_x drive_yi wszystko działało dobrze.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.