Czy dd dokonuje jakiejkolwiek weryfikacji?

Używam dddo kopiowania danych ze starego dysku twardego na nowy. Chcę mieć pewność, że integralność danych jest bezpieczna.

Na tę odpowiedź Gilles mówi

Jeśli [dd] zakończyło się pomyślnie, tworzenie kopii zapasowej jest prawidłowe, z wyjątkiem błędu sprzętowego…

Co to dokładnie znaczy? Czy ddma wbudowaną weryfikację?

Gdybym zamiast tego używał rsync, uruchamiam również drugie przejście --checksumw celu weryfikacji. Czy tego rodzaju paranoja jest uzasadniona?

ddlub żadna inna aplikacja nie ma „wbudowanej weryfikacji” w takim sensie, o jakim prawdopodobnie myślisz: nie odczytuje danych z nośnika pamięci w celu porównania z tym, co zostało napisane. To jest zadanie systemu operacyjnego.

Naprawdę nie jest możliwe wykonanie weryfikacji odczytu do sprzętu z aplikacji. To działałoby w niektórych scenariuszach, ale w większości przypadków nic nie osiągnęłoby. Aplikacja mogłaby odczytać to, co właśnie napisała, jeśli zapisuje bezpośrednio na nośniku pamięci , ale zwykle odczytałby z pamięci podręcznej w pamięci, co nie dałoby żadnej użytecznej gwarancji. W przykładzie zacytowanie , ddpisze do rury, a w tym przypadku nie ma żadnej kontroli nad tym, co dzieje się z danymi w dalszej linii. W twoim przykładzie rsync, drugie przejściersync --checksum nie ma sensu: teoretycznie może złapać błąd, ale w praktyce, jeśli błąd się zdarzy, wtedy drugie przejście prawdopodobnie nie zgłosi niczego złego, więc marnujesz wysiłek na coś, co nie daje użytecznej pewności.

Jednak aplikacje nie sprawdza, co dzieje się z danymi, w tym sensie, że ich zweryfikowania, czy system operacyjny przyjął odpowiedzialność za dane. Wszystkie wywołania systemowe zwracają status błędu. Jeśli wywołanie systemowe zwraca status błędu, aplikacja powinna propagować ten błąd do użytkownika, generalnie poprzez wyświetlenie komunikatu o błędzie i zwrócenie niezerowego statusu wyjścia.

Uwaga: ddjest to wyjątek: w zależności od parametrów wiersza poleceń ddmoże zignorować niektóre błędy . Jest to niezwykle niezwykłe: ddjest to jedyne wspólne polecenie z tą właściwością. Używaj catzamiast dd, w ten sposób nie ryzykujesz korupcji i może to być szybsze .

W łańcuchu kopiowania danych mogą wystąpić dwa rodzaje błędów.

• Korupcja: podczas transferu trochę się przewraca. Nie ma sposobu, aby to zweryfikować na poziomie aplikacji, ponieważ jeśli tak się stanie, jest to spowodowane błędem programistycznym lub sprzętowym, który może spowodować takie samo uszkodzenie podczas odczytu. Jedynym przydatnym sposobem sprawdzenia, czy nie doszło do takiego uszkodzenia, jest fizyczne odłączenie nośnika i ponowienie próby, najlepiej na innym komputerze, na wypadek gdyby problem dotyczył pamięci RAM.
• Obcięcie: wszystkie skopiowane dane zostały skopiowane poprawnie, ale niektóre z nich w ogóle nie zostały skopiowane. Ta jedna jest warta sprawdzenia czasami, w zależności od stopnia skomplikowania polecenia. Aby to zrobić, nie musisz czytać danych: po prostu sprawdź rozmiar.

Nie, ddnie dokonuje wyraźnej weryfikacji. Jeśli potrzebujesz / potrzebujesz kopii dysku lub jakiejkolwiek jego części, zweryfikowanej przez sąd, skorzystaj dcflddz ulepszonej wersji ddopracowanej przez Departament Obrony Komputerowej Departamentu Obrony USA.

Jedynym sposobem na „pewność” jest wykonanie dodatkowej operacji odczytu i porównania (po usunięciu pamięci podręcznej).

Poza tym ddwykrywa błędy odczytu i zapisu w taki sam sposób, jak robią to wszystkie inne programy ... działa, jeśli napędy (i inne komponenty) zgłaszają błędy; dla dysków, które akceptują dane w trybie dyskretnym bez ich zapisywania, nie masz szczęścia.

Czy tego rodzaju paranoja jest uzasadniona?

Jeśli nie możesz ufać, że Twój sprzęt jest niezawodny, sprawy się komplikują ...

Tak, wadliwy sprzęt może wstawiać losowe bity błędu w danych z szybkością jednego bitu na liczbę megabajtów, jest to możliwe i czasami ma to miejsce w praktyce.

Zwykle używam skrótu md5 lub sha1, aby sprawdzić, czy dane są nienaruszone, ponownie czytając zarówno źródło, jak i miejsce docelowe, np .:

dd if=/dev/sdb of=~/hd_backup
dd if=/dev/sdb | md5sum
dd if=~/hd_backup | md5sum

Zakłada się, że dane są znacznie większe niż pamięć podręczna systemu plików, w przeciwnym razie może być konieczne ponowne uruchomienie systemu w celu zweryfikowania rzeczywistych danych na nośniku, a nie zawartości pamięci podręcznej, lub użycie innego systemu.

Od man dd:

Po zakończeniu dd wyświetla liczbę pełnych i częściowych bloków wejściowych i wyjściowych, skrócone rekordy wejściowe i bloki wymiany bajtów nieparzystej długości na standardowe wyjście błędów.

Częściowy blok wejściowy to taki, w którym odczytano mniej niż rozmiar bloku wejściowego. Częściowy blok wyjściowy to taki, w którym zapisano mniej niż rozmiar bloku wyjściowego. Częściowe bloki wyjściowe urządzeń taśmowych są uważane za błędy krytyczne. W przeciwnym razie reszta bloku zostanie zapisana. Częściowe bloki wyjściowe do urządzeń znakowych wygenerują komunikat ostrzegawczy.

ddsprawdza, czy rozmiary bloku wejściowego / wyjściowego są dopasowane przy każdym kopiowaniu bloku. Jeśli nie, obsługuje błąd z ostrzeżeniem lub błąd krytyczny (zastąpiony przez noerror). Dlatego dddziała praktycznie przez cały czas.

Mimo to nie zastępuje ręcznego sprawdzania integralności dysku. Jeśli informacja jest dla ciebie cenna, to tak, twoja paranoja jest uzasadniona . Uruchom ręczną weryfikację po ddzakończeniu.