Krótko: zapisz skrót przy zapisie pliku i porównaj go później. Jeśli skróty się różnią, a nic nie edytowało pliku, bajty zmieniły się bez Twojej wiedzy.
Nic innego tego nie wykryje. Dysk z cichym uszkodzeniem przechodzi Pierwszą pomoc, ma zdrowy SMART i montuje się bez zarzutu.
Przechowywanie danych jest fizyczne. Domeny magnetyczne na wirującym dysku słabną. Ładunek ucieka z komórek pamięci flash, szybciej, gdy jest ciepło, i jeszcze szybciej, gdy dysk długo leży bez zasilania. Kabel może zgubić bit w transmisji. Firmware ma błędy.
Dyski same poprawiają większość z tego, kodami korekcji błędów i przemapowywaniem sektorów, które zaczynają się psuć. Liczy się uszkodzenie, które się przez to prześlizgnie: odczyt, który zwraca inne bajty niż zapisane i zgłasza sukces.
Nazwa, o którą ludzie się kłócą. Jedni mówią bit rot, inni ciche uszkodzenie danych, jeszcze inni degradacja danych. Dla nas to to samo: plik jest inny i nic tego nie powiedziało.
Tę część warto zrozumieć, bo wyjaśnia, dlaczego każde narzędzie, po które sięgniesz, jest niewłaściwe.
cp i Finder czytają bajty i zapisują bajty.
Jeśli odczyt zwrócił złe bajty, wiernie zapiszą złe bajty.Uczciwie trzeba więc powiedzieć: Twój Mac nie ma mechanizmu, który by Ci to powiedział. Pierwszym objawem jest zdjęcie z pasem śmieci w poprzek, archiwum, które się nie otwiera, albo film, który zatrzymuje się w połowie.
Rzadkie w przeliczeniu na plik, ale nie rzadkie w dużej kolekcji przez długi czas, a właśnie do tego jest kopia zapasowa. Dwie rzeczy wyraźnie zwiększają szanse:
W kopii zapasowej ma to większe znaczenie niż na dysku roboczym, bo plik roboczy się otwiera, a otwarty uszkodzony plik to uszkodzenie, które odkryłeś. Kopia jest zapisywana raz i nigdy nie czytana, co znaczy, że uszkodzenie w kopii odkrywasz w dniu, w którym jej potrzebujesz.
Zapisz, co zapisałeś:
cd /Volumes/Backup
find . -type f -exec shasum -a 256 {} \; > ~/backup-hashes.txt
A potem, po miesiącach, zapytaj, czy wciąż jest taki sam:
cd /Volumes/Backup
shasum -a 256 -c ~/backup-hashes.txt | grep -v ': OK$'
Wszystko, co zostanie wypisane, to plik, którego bajty się zmieniły. Jeśli go nie edytowałeś, masz odpowiedź.
Dwie praktyczne uwagi. Trzymaj plik ze skrótami gdzieś poza dyskiem, który opisuje, bo inaczej stracisz oba naraz. I trwa to tyle, co odczyt całego dysku, więc zaplanuj to na noc.
Wszystko powyżej to powód, dla którego aplikacja wygląda tak, jak wygląda. Przechowuje każdy fragment kopii pod skrótem jego zawartości, a potem regularnie odczytuje kopię i sprawdza każdy fragment względem skrótu, pod którym go zapisano.
Niezgodność jest więc dowodem: bajty nie są tymi bajtami, które zapisano, i nie ma interpretacji, w której to jest w porządku. Fragment usunięty pod spodem kopii jest zgłaszany jako brakujący. A wynik na ekranie głównym liczy tylko to, co niedawno zweryfikowano, i dlatego jest niższy, niż ludzie się spodziewają, i właśnie o to chodzi.
Drugie miejsce ma tu większe znaczenie niż gdziekolwiek indziej na tej stronie. Uszkodzenie w jednej kopii to niedogodność, gdy są dwie, i koniec pliku, gdy jest jedna.
Nie. Pierwsza pomoc sprawdza strukturę systemu plików, a nie zawartość plików. Dysk z po cichu uszkodzonymi plikami przechodzi ją bez problemu, i właśnie to czyni ten problem tym, czym jest.
Nie w tym przypadku. SMART zgłasza błędy, które dysk zauważył i poprawił lub przeniósł. Ciche uszkodzenie to właśnie te, których nie zauważył. Mimo to warto sprawdzić dysk, który zaczyna się psuć, ale to inny i bardziej widoczny problem.
Liczy sumy kontrolne własnych metadanych, a nie danych Twoich plików. ZFS i Btrfs liczą sumy kontrolne zawartości plików i mogą naprawiać z nadmiarowej kopii, a żaden z nich nie jest dostępny jako zwykły wolumin startowy lub zewnętrzny w macOS. Ta luka to powód, dla którego warto mieć sprawdzanie na poziomie aplikacji.
Na tyle często, żeby złą kopię znaleźć, póki jeszcze istnieje dobra. Raz na kwartał to rozsądnie dla archiwum; co miesiąc, jeśli to jedyna kopia czegoś niezastąpionego. Właściwa odpowiedź to taka częstotliwość, której naprawdę nie pominiesz, a to przemawia za automatyzacją.
Nie. Weryfikacja mówi Ci, że kopia się zepsuła. Nie może oddać pliku. Wykrywanie przydaje się tylko wtedy, gdy jest druga kopia, z której można przywrócić, i to cały argument za zasadą 3-2-1.
Powiązane: jak sprawdzić, czy kopię da się odczytać, format repozytorium i zasada 3-2-1.