Jednoduchá kontrola integrity dlouhodobě archivovaných dat

[Filip Jirsák]

Umí zapsat soubor s kontrolními součty i je verifikovat.

Což ovšem nesplňuje to, proč se na to tazatel vůbec ptá – začátek třetího odstavce zadání.

[Reklama]

[Filip Jirsák]

Ještě mne napadá – jak přesně chcete s těmi soubory pracovat, jestli je opravdu nutné mít u souborů ty kontrolní součty i při kopírování na Windows.

Já si pod dlouhodobě archivovanými daty představuju to, že mám soubory uložené na nějakém disku připojeném (ideálně ne trvale) k nějakému linuxovému systému. Občas tam nahraju nějaká data, občas odsud nějaká data chci stáhnout, a hlavně se tam pravidelně provádí kontrola kontrolních součtů. Při takovémhle použití mi nedává smysl tahat kontrolní součty někam mimo tenhle systém. Prostě by se měly přepočítat, když tam nahraju nějaký nový soubor, a pak pravidelně kontrolovat. Přepisovat soubory by se tam neměly, to je nejlepší cesta, jak o archivní data přijít. Mazání souborů by mělo být výjimečné, pokud už nějaká data opravdu nejsou potřeba – opět, jakmile tam běžně umožníte mazání, je to největší riziko ztráty dat.

[Ondrej Nemecek]

Umí zapsat soubor s kontrolními součty i je verifikovat.

Což ovšem nesplňuje to, proč se na to tazatel vůbec ptá – začátek třetího odstavce zadání.

Tak musí zachovat název souboru, ale pořád mi toto tradiční superjednoduché řešení přijde OK.

Další možnost, která tu asi nepadla, je použít na to nějaké repositářové řešení. Pro řadu případů to bude také OK, existují nástroje i na správu velkých multimediálních dat.

[mhi]

Nejsou to uplne archivni data, jen velke mnozstvi dat, ktera jsou potrebna pomerne zridka. Muzu tady rozepsat detaily, ale podle meho nazoru do toho jen zabredneme. Spousta dat je i na externich discich (NTFS).

Napadlo mne jeste jedno reseni, mit ty cksumy centralne a hledat podle hashe (md5?) stejne soubory a pripadne identifikovat zmeny slozek/nazvu souboru. Jenze to je spis takova magie, tezko rict jestli to poslouzi k ucelu.

Ondrej Nemecek: Jste hodny ze odpovidate, ale prijde mi, ze kazdy jsme v nejake uplne odlisne paralelni realite. Mozna by stalo za to si precist prvni post v threadu, treba se ty reality pak sejdou.

[RDa]

Nahraj to na centralni uloziste nad RAID-6 a provadej scrubbing. Jakekoliv permamentni chyby se tim objevi.
Chyby, ktere nastanou pri vyjimecnem pouziti dat jsou opravdu zanedbatelne (1 chyba na x TB dat vs. par MB soubory).

Alternativa pak bude ZFS nebo jiny system, kterou rovnou u cteni overuje checksumy.

S NTFS to je marny boj (leda ze by napr. tamni komprese FS podporovala checkumy a online indikaci poskozeni)

[Reklama]

[Filip Jirsák]

Napadlo mne jeste jedno reseni, mit ty cksumy centralne a hledat podle hashe (md5?) stejne soubory a pripadne identifikovat zmeny slozek/nazvu souboru. Jenze to je spis takova magie, tezko rict jestli to poslouzi k ucelu.

To mne také napadlo, ale to dost záleží na objemu dat. Protože když budete hledat nějaký soubor podle hashe, znamená to spočítat otisky všech souborů, které v tom úložišti máte (resp. tak dlouho, dokud ten soubor nenajdete, což v nejhorším případě znamená všech). A vlastně by se tím těžko hledaly chyby – spočítal byste hashe všech souborů, porovnal se známými hashi a zjistil byste, že je tam nějaký nový hash. A teď byste musel zjišťovat, zda jste tam nahrál nový soubor, nebo jestli je ten soubor poškozen.

MD5 bych určitě nepoužíval, je děravé a nemá žádné výhody. Vám asi děravost nevadí, ale mohu z toho vzniknout akorát problémy, nic vám to nepřinese. Použil bych BLAKE3 (utilita b3sum), pokud nemáte nějaký obskurní hardware, na kterém by se počítala pomalu. Výpočet je podstatně rychlejší než MD5 a není děravá.

Každopádně mi pořád jako nejlepší řešení vychází mít hashe uložené v samostatných souborech (buď jeden soubor na adresář, nebo jeden soubor pro vše), a přejmenované soubory holt řešit tak, že vám zmizí starý soubor a objeví se nový, který ale má stejný hash, jako soubor, který zmizel – takže víte, že je to přejmenování.

[Ondrej Nemecek]

Ondrej Nemecek: Jste hodny ze odpovidate, ale prijde mi, ze kazdy jsme v nejake uplne odlisne paralelni realite. Mozna by stalo za to si precist prvni post v threadu, treba se ty reality pak sejdou.

Já to četl Možná to je tím, že neznám účel. Nicméně berte to jako brain storming, kdy jsem hodil do placu dvě obvyklá řešení.

Spolu s variantou mít data a případně i kontrolu checksumů přímo v rámci souborového systému (btrfs nebo rozšířené atributy jak navrhoval p Jirsák toho už asi stejně moc dalšího nevymyslíte (a nic nesplňuje 100% všechny požadavky). A než vymýšlet kolo...

[drobek1]

To co popisujete mi připadá jako klasická úloha pro NAS.
Jak už psal kolega použít filesystém který hlídá integritu souborů tj. např. ZFS.

[Max Devaine]

Pokud s daty potřebuji pracovat a měnit je, tak se nejedná o archivaci.
Každopádně pokud je potřeba s daty pracovat a měnit je, tak prostě je mít na NAS, které podporuje FS, co umí checksummy a je odolné vůči chybám v integritách dat.
Bavíme se tedy o Synology + BTRFS (nutný je minimálně RAID1, aby bylo možné případné chyby i opravit) nebo QNAP se ZFS. Nebo vlastní server s BTRFS nebo ZFS storagem.
Je to plně transparentní a člověk nemusí sám proaktivně nic kontrolovat, stačí pravidelné scruby.
Zdar Max

[messagebus]

Presne tak, nejedna se o archivaci. Tudiz mit filesystem, ktery kontroluje integritu dat je jiste super, ale pokud v celem retezci prenosu a zpracovani dat nejsou taky dusledne implementovany kontroly integrity, tak je to nedostacujici. Napriklad pokud mate lehce shnilou non-ECC pamet v PC, ktere vybaluje soubory z archivu (nebo nedejboze primo v NAS), tak vam klidne nastane presne ta situace, ktere se tazatel obava i na super-duper filesystemu.

Plus pokud by se vyskytla nejaka chyba v aplikaci zpracovavajici data (treba zip-unzip), tak k tehle nezadouci situaci muze dojit i na totalne zdravem zeleze s kontrolami integrity vseho a vsude.

Takze vzhledem k tomu, ze mezi pozadavky tazatele je i prejmenovani souboru, bude treba k obsahu archivu pristupovat vyhradne pred aplikaci, ktera ke kazdemu souboru bude mit nekde ulozeny id a hash. V obsahu archivu budou taky dost prekazet baliky zipu, protoze neobsahuji id a hashe k souborum uvnitr. No, bude to hezka prace na dlouhe zimni vecery

PS Moc nechapu tu dnesni posedlost kontrolou integrity dat zrovna u disku, kde mezi dnes bezne dostupnymi modely v normalni distribuci neni ani jeden, ktery by neobsahoval kontrolu integrity interne. Jiste, filesystem umi "lepsi" kontrolu, ktera by mela odhalit i "divotvorny" kablik, proc to nevyuzit, ale jsem v oboru uz peknou radku let a nevidel jsem ani jeden disk, ktery by ze sebe vyndaval jina data nez byla zapsana bez chybove hlasky, jeden jediny "divotvorny" kablik, ale spoustu vadnych pameti RAM. Ergo kladivko poridte si predvsim zarucene fungujici ECC zelezo a poradny switch s kabelazi, pak teprve filesystem. Protoze nesedite pred digitalnim pocitacem. Sedite pred analogovym emulatorem digitalniho pocitace

[RDa]

Presne tak, nejedna se o archivaci. Tudiz mit filesystem, ktery kontroluje integritu dat je jiste super, ale pokud v celem retezci prenosu a zpracovani dat nejsou taky dusledne implementovany kontroly integrity, tak je to nedostacujici. Napriklad pokud mate lehce shnilou non-ECC pamet v PC, ktere vybaluje soubory z archivu (nebo nedejboze primo v NAS), tak vam klidne nastane presne ta situace, ktere se tazatel obava i na super-duper filesystemu.

Archivy maji vlastni CRC rozbalovanych souboru, takze jestli tazatel nema FS s podporou checksumu, postaci data zabalit. Pri rozbalovani pak bude upozornen na vadny soubor a muze se shanet po kopii z alternativni lokace.

PS Moc nechapu tu dnesni posedlost kontrolou integrity dat zrovna u disku, kde mezi dnes bezne dostupnymi modely v normalni distribuci neni ani jeden, ktery by neobsahoval kontrolu integrity interne.

PI (T10-PI) u profi ulozist taky neni overovana diskem, je to jenom extra rezervovany prostor. Lze to v linuxu take emulovat stylem 9:8, kdy PI z 8 sektoru padnou do devateho. Ale podle me neexistuje zadny spotrebni FS, ktery by vyuzival diskove-nativni PI regiony pro ukladani checksumu. Navic zadny spotrebni PC hw nepodporuje fyzicky nativni PI (aka 528 byte sektory).

Ale to jsme se dostali nekam jinam :-) Pan chce jen draka na snure a my vymyslime pristani na mesici

[mhi]

Jak pise messagebus, ty FS samy o sobe to neresi, neresi to bohuzel vhodne ani NAS, to by byla jinak volba #1 a nemusel bych se patlat s nejakymi NTFS apod .

Aktualne kopiruju asi 4 TB v obrovskem mnozstvi souboru ve Windows, aby byly zachovany permissions. Prvni naivni pokus o ctrl+C a ctrl+V na novy disk skoncil na tom, ze Windows se na nejakem malem souboru zastavily . Takze po castech, nicmene po kopii jsem se dostal do stavu kdy bylo par souboru se samymi nulami misto obsahu (nasel to prave md5sum). To je priklad prusvihu, ktery chci resit.

Dale jsem zazil, ze se nekde na disku rozpadly metadata (ne nutne chybou disku, spis nejakou kombinaci chyba cteni disku + chyba v SW/filesystemu nad tim), a pak cele slozky byly s nesmysly, poznat to ale neslo bez otevreni slozky.

A pak samozrejme chyby pameti.

Zazil jsem taky disk, ktery vracel "jine sektory" nez byly vyzadovany, kdyz se to netrefi do metadat, nepoznate to do doby nez data potrebujete ..

atd atd atd.

[RDa]

Aktualne kopiruju asi 4 TB v obrovskem mnozstvi souboru ve Windows, aby byly zachovany permissions. Prvni naivni pokus o ctrl+C a ctrl+V na novy disk skoncil na tom, ze Windows se na nejakem malem souboru zastavily

Ano, byla chyba to delat na Win, protoze omezena delka cesty takze neni jedno co/kam kopirujes. Nekdy tomu pomuze presunout nad-adresar jeste vejs.

[mhi]

Aktualne kopiruju asi 4 TB v obrovskem mnozstvi souboru ve Windows, aby byly zachovany permissions. Prvni naivni pokus o ctrl+C a ctrl+V na novy disk skoncil na tom, ze Windows se na nejakem malem souboru zastavily

Ano, byla chyba to delat na Win, protoze omezena delka cesty takze neni jedno co/kam kopirujes. Nekdy tomu pomuze presunout nad-adresar jeste vejs.

Ne, to neni ten problem, cesta je kratka. Ale to jsme dost offtopic, spis mne zaujalo ze tam vznikly ty soubory s temi nulami. Evidentne se neco hodne pokazilo, protoze chyby byly koncentrovane do par slozek a jak jsou soubory v adresari setrizeny uz abecedne i na disku, tak bylo zjevne ze to delalo chyby "po sobe" treba ve 20ti souborech a pak se to nejak cele ozivilo a zbytek sady se dokopiroval uz spravne. A chyba se projevila vzdy od zacatku do konce souboru, nebyly tam zadne "polonulove" soubory.

[RDa]

Ne, to neni ten problem, cesta je kratka. Ale to jsme dost offtopic, spis mne zaujalo ze tam vznikly ty soubory s temi nulami. Evidentne se neco hodne pokazilo, protoze chyby byly koncentrovane do par slozek a jak jsou soubory v adresari setrizeny uz abecedne i na disku, tak bylo zjevne ze to delalo chyby "po sobe" treba ve 20ti souborech a pak se to nejak cele ozivilo a zbytek sady se dokopiroval uz spravne. A chyba se projevila vzdy od zacatku do konce souboru, nebyly tam zadne "polonulove" soubory.

Asi chyba FS, treba se prepsal nejaky neprimy blok s indexama na datove bloky. Na tohle bych sel nejakym NTFS explorerem a podival se jak to je na nizsi urovni..