Ta odpowiedź jest połączeniem odpowiedzi @ lechlukasz i @ db48x , a także zawiera pewne uwagi poczynione w komentarzach oraz moje własne przemyślenia.
Prosta ścieżka do przodu to połączenie systemu plików i oddzielnych metadanych.
Korzystając z systemu plików, który dokonuje haszowania i sprawdzania poprawności danych w locie, takiego jak ZFS lub Btrfs (zauważ, że chociaż dokonano wielkich postępów, Btrfs nie jest obecnie uważany za gotowy do użytku produkcyjnego), możesz być rozsądnie upewnij się, że jeśli dane można odczytać z dysku bez błędu systemu operacyjnego, to odczytane dane zostały zapisane na dysku w sposób zamierzony przez system plików. Dzięki okresowym operacjom „szorowania” wszystkie dane są odczytywane i weryfikowane pod kątem tego, co system plików powinien wiedzieć.
Chroni to jednak tylko przed uszkodzeniem na dysku (nieczytelne bloki, bezpośrednie błędy zapisu sprzętu, nieprawidłowe zapisy, które uszkadzają części danych bezpośrednio na urządzeniu blokującym itp.). Nie chroni przed błędem oprogramowania, niewłaściwą obsługą użytkownika lub złośliwym oprogramowaniem, które działa przez zamierzone funkcje systemu operacyjnego do pracy z plikami, przy założeniu, że narzędzia te są wolne od takich błędów.
Aby chronić się przed tym drugim, potrzebujesz kolejnej warstwy ochrony. Sumowanie danych kontrolnych lub mieszanie danych z perspektywy aplikacji użytkownika pomoże zabezpieczyć się przed wieloma wyżej wymienionymi zagrożeniami, ale należy je wykonać osobno (albo jako wbudowane działanie procesu w oprogramowaniu, albo jako całkowicie odrębny proces).
Przy dzisiejszym sprzęcie i praktycznym rozwiązaniu do przechowywania dużych ilości danych (spinningowe dyski twarde w przeciwieństwie do dysków półprzewodnikowych / SSD), nawet złożone algorytmy mieszające, takie jak SHA1, będą w dużej mierze ograniczone do operacji we / wy - to znaczy prędkości przy której dane są mieszane będą raczej funkcją prędkości odczytu systemu pamięci niż zdolności procesora komputera do obliczenia wartości skrótu. Zrobiłem eksperyment z uruchomieniem procesu mieszania MD5 w przestrzeni użytkownika na około 150 GB danych na tym, co w 2012 roku było komputerem klasy średniej, i zakończyło się po ćwiczeniu dysku w zasadzie bez przerwy przez około 40 minut. Skalując te liczby 100-krotnie, uzyskasz skróty MD5 kolekcji 15 TB w około trzy dni na tym samym sprzęcie. Dodając szybkość odczytu odczytu (co można łatwo osiągnąć npNa przykład RAID 0 to striping bez redundancji, powszechnie stosowany w celu uzyskania wyższej wydajności odczytu / zapisu, być może w połączeniu z RAID 1 tworzącym RAID 10 ), czas do ukończenia można skrócić dla tej samej ilości danych.
Łącząc oba, uzyskujesz to, co najlepsze z obu światów: system plików daje pewność, że to, co otrzymałeś podczas czytania pliku, jest tym, co zostało faktycznie zapisane, a osobny proces sprawdzania poprawności może przebiegać w całej kolekcji, zapewniając, że dane przechowywane nadal pasuje do tego, co zostało wprowadzone do archiwum. Każda niespójność między nimi (system plików mówi, że plik jest w porządku, sprawdzanie poprawności mówi, że nie) wskazuje na plik, który został zmodyfikowany poza zamierzonym trybem działania archiwum, ale z poziomu wyposażenia systemu operacyjnego, powodując przywrócenie z pomocniczego kopia (kopia zapasowa). Sprawdzanie poprawności może zatem być uruchamiane w dłuższym przedziale czasu, co staje się niezbędne w przypadku bardzo dużych archiwów, ale wszelkie gwarancje dostępu online nadal nie zostaną uszkodzone na sprzęcie, jeśli odczyt się powiedzie. Zasadniczo, oprogramowanie archiwalne może polegać na systemie plików, aby zgłaszać niespójności jako błędy odczytu, i przeprowadzać osobne sprawdzenie poprawności w tle, gdy użytkownik pracuje z plikiem i wyświetla odpowiedni komunikat, który powinien wskazywać, że plik nie pasuje do tego, co zostało pobrane do archiwum. Korzystając z systemu plików z blokowaniem blokowym, taki schemat miałby minimalny wpływ na postrzeganą wydajność, jednocześnie zapewniając pewność, że treść jest poprawna.