Fórum Root.cz

Hlavní témata => Software => Téma založeno: mhi 13. 01. 2022, 17:52:47

Název: Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: mhi 13. 01. 2022, 17:52:47
Mam balik dat, vetsina jsou ruzne PDF, ZIP, JPEG, pripadne ISO soubory. Veci, ktere se daji (slozite) nahradit, je jich nejaka desitka TB. S daty se obcas pracuje, hlavne tak, ze se treba prejmenuji soubory, nebo nejak zabali, rozdeli, apod.

Nechci na to vymyslet nejake slozite archivni reseni, spis jen treba mit 2 kopie tech dat, ktere budu postupne udrzovat aktualni, ale bez naroku na 100% konzistenci. Jsou to data ktera se pouziji stylem "potrebuju se podivat na ..." a pak hledam.

Jak na to? Reseni ze se udela nejaky seznam CRC32/MD5/SHA neni uplne funkcni, takhle jsem to mel doted, rozpadne se to v okamziku kdy se nejak zmeni cesty. Idealni by bylo, kdyby si soubory primo sebou mohly nest informaci o sve integrite, treba CRC32. U ZIPu to je snadne, PDF/ISO/JPEG nebo takove EXE  to uz takhle nemaji. Napadlo me udelat tool, ktery upravi zname typy souboru aby mely nulove nejake CRC32 (ci fixni hodnotu typu 0x55555555), ve spouste formatu souboru je v hlavickach plno hluchych mist, kde se da nejaky dword opravit, aby vysel spravne CRC32.

Touto cestou by sla vetsina souboru overit, ze se vylozene neposkodily nejakou operaci nebo vyhnitim disku. Zajimalo by mne, jestli na tento problem je nejake existujici reseni, abych to nemusel programovat, pripadne nejake jine reseni plnici moji potrebu. Jde mi ciste o overeni, ze data se nejak nahodne neposkodila.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: RDa 13. 01. 2022, 18:14:48
jako byla doba, kdy jsem pouzival k checksumu i indexovani souboru na velkem poli takto vytvorenej soubor:

Kód: [Vybrat]
find . -type f -exec md5sum {} \;
(asi by to slo i lepe, skrze xargs - jen je treba poradne overit zda projdou vsechny podivne jmena souboru, plus taky co s prazdnyma adresarema, ktere find . taky vylistuje a muze se to nekdy hodit)

Pak se to hodi taky na hledani duplicit, kdy potrebujete uvolnit misto, ale kvuli bordelu netusite co presne lze postradat :) Jen bych tam hodil rovnou i velikost, nebo dalsi atributy.

A pokud se index vytvari novej (treba co tyden), tak lze trocha odsledovat jak probihal uklid nebo mazani - nepredpokladam ze je mnoho souboru co by melo kolize v pripade bezneho uzivatele (pokud tedy neexperimentujete primo s cilem vytvorit kolizni pdf a pod)
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: RDa 13. 01. 2022, 18:16:59
Pokud to FS umi, tak by slo pridat k souborum tyto checkumy pres:
https://en.wikipedia.org/wiki/Extended_file_attributes#Linux

(pak se to drzi souboru a presouvani snad nesmaze atributy), Podobne na NTFS jsou ty ADS.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: Filip Jirsák 13. 01. 2022, 18:18:13
Ten postup, co jste vymyslel, je neuvěřitelně komplikovaný a náchylný na chyby.

Jednoduché řešení je ukládat ten kontrolní součet do rozšířených atributů. Na linuxu je nastavíte pomocí setfattr, přečtete pomocí getfattr. Pokud byste to chtěl na Windows (NTFS), tam by se to řešilo spíš pomocí Alternate Data Streams.

Pak už si jen pohlídejte, že nepoužíváte nějaké extrémně staré nástroje, které by třeba při kopírování nebo archivaci souborů rozšířené atributy zahazovaly.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: mhi 13. 01. 2022, 18:22:11
RDa, to neresi muj problem ... ta data si ziji svym zivotem, nejsou az tak dulezita aby stalo za to mit kontrolu naprosto duslednou, ta zabira prilis mnoho casu. Spis jen potrebuju vedet jest se nekde neco nerozbilo a vcas pripadne najit starsi verzi.

To nulove CRC32 mi prislo jako celkem fajn cesta, hlavne kdyz muzu jednoduse prilepit treba do PDFka do poslednich par bajtu pred xref+EOF nejaky "zero-crc32" padding...

viz https://www.nayuki.io/page/forcing-a-files-crc-to-any-value (to samozrejme neresi udrzeni validity formatu).

Koukam ze nez jsem dopsal odpoved prisly navrhy na FS atributy/streamy, to neni uplne spatna metoda, problem je, ze to musi chodit Unix+Win (NTFS) a hlavne aby se napric systemy dalo snadno kopirovat.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: RDa 13. 01. 2022, 18:27:28
Koukam ze nez jsem dopsal odpoved prisly navrhy na FS atributy/streamy, to neni uplne spatna metoda, problem je, ze to musi chodit Unix+Win (NTFS) a hlavne aby se napric systemy dalo snadno kopirovat.

To uz od toho chcete zazraky. Nejbliz k tomu maji dot files z OSX, jen to nesmi nekdo smazat nebo zapomenout presunout :)
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: RDa 13. 01. 2022, 18:30:01
Jeste me napada klasicke oldschool/warez reseni - checksum file v kazdem adresari.
Pro RO uloziste to je akceptovatelny kompromis.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: Filip Jirsák 13. 01. 2022, 18:55:11
Koukam ze nez jsem dopsal odpoved prisly navrhy na FS atributy/streamy, to neni uplne spatna metoda, problem je, ze to musi chodit Unix+Win (NTFS) a hlavne aby se napric systemy dalo snadno kopirovat.
Jak to mezi těmi systémy chcete kopírovat? ADS z NTFS by měly jít přečíst a zapisovat i z linuxu, takže pokud to bude v obou systémech na NTFS, neměl by to být problém. Nebo Windows Subsystem for Linuxu emuluje linuxové rozšířené atributy (myslím, že k tomu používá právě ADS).

Možná bych problém spíš rozdělil na dva – jak ty údaje zachovávat (k čemuž jsou podle mne ideální rozšířené atributy a ADS), a potom jak s nimi pracovat, právě třeba při kopírování napříč systémy.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: mhi 13. 01. 2022, 19:10:50
Idealne to musi prezit kopii pres sit, pres SMB (na obou stranach). Proto byl muj cil CRC32 "nezachovavat nikde" ale fixnout ho do nulove hodnoty...
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: Jakub Štech 13. 01. 2022, 19:15:06
Dejte hash nebo nějakou jeho část do názvu souboru, např.

$ sha512sum "17bd629f8f703109 precious-memories.zip"
17bd629f8f703109b3a494b4cab571069a49cffe7eb6696fa1ab3d034b4efbd59b6f181c82dca123d2ae3a7811123e30270531dbb558c33f6b6fb71344251e76  17bd629f8f703109 precious-memories.zip

Vyberte hashovací funkci, která je na zamýšlením hardwaru nejrychlejší... u mě (Aarch64 NAS) takto vyšel blake2s.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: Filip Jirsák 13. 01. 2022, 19:28:46
Samba má jakousi podporu pro Alternate Data Streams pomocí vfs_streams_xattr. Pro uložení se používají právě rozšířené atributy. Zkuste se na to podívat.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: mhi 13. 01. 2022, 19:29:45
Aha, ok, jeste musim doplnit, ze treba zrovna ty PDF musi mit ve slozkach zachovany nazev souboru. Stejne tak asi i u nejakych ISO souboru by se to mohlo siknout, kdyz jsou setrizene (treba "manuals XYZ DVD 1" ... az do 7).

Zatim se mi nejlepsi hned po mem overengineered zero-crc jevi ten warez-styl nejakych .crc32 souboru v kazde slozce, sice to neni imunni proti zmene nazvu souboru, jinak ale ano a je to univerzalnejsi nez mit zero-crc jen u definovanych formatu souboru.

FilipJirsak: dekuji, mrknu na to.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: RDa 13. 01. 2022, 19:49:05
Kdyztak se drz alespon nejakeho standardu, pak muzes najit tooly co ti pomuzou :)

*.SFV = https://en.wikipedia.org/wiki/Simple_file_verification
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: Ondrej Nemecek 13. 01. 2022, 22:59:22
Řešil bych tak, jak na to jsou všichni zvyklí: https://cs.wikipedia.org/wiki/Md5sum + ekvivalenty sha256sum, sha512sum atd.

Umí zapsat soubor s kontrolními součty i je verifikovat.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: Jan Fikar 14. 01. 2022, 08:05:06
Vyberte hashovací funkci, která je na zamýšlením hardwaru nejrychlejší... u mě (Aarch64 NAS) takto vyšel blake2s.

A co třeba xxh128sum? https://cyan4973.github.io/xxHash/ (https://cyan4973.github.io/xxHash/)

Jenom pozor na verzi, má se na delší dobu používat až verze 0.8.0 a novější. Konkrétně mezi verzemi 0.7.3 a 0.7.4 se ty hashe změnily.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: Filip Jirsák 14. 01. 2022, 08:41:27
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í.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: Filip Jirsák 14. 01. 2022, 08:52:23
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.
Název: Re:Jednoducha kontrola integrity dlouhodobe archivovanych dat
Přispěvatel: Ondrej Nemecek 14. 01. 2022, 14:58:05
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.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: mhi 14. 01. 2022, 15:03:13
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.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: RDa 14. 01. 2022, 15:20:37
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)
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: Filip Jirsák 14. 01. 2022, 16:23:39
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í.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: Ondrej Nemecek 14. 01. 2022, 19:20:43
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...
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: drobek1 15. 01. 2022, 21:51:42
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.

Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: Max Devaine 18. 01. 2022, 08:27:59
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
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: messagebus 18. 01. 2022, 14:37:39
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 :)
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: RDa 18. 01. 2022, 15:04:55
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 :P
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: mhi 18. 01. 2022, 15:17:44
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.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: RDa 18. 01. 2022, 16:44:23
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.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: mhi 18. 01. 2022, 16:48:38
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.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: RDa 18. 01. 2022, 16:54:07
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..
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: messagebus 18. 01. 2022, 17:28:28
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.

Po kopii se sice zacit shanet muzete, ale nebudete vedet, jak ji poznat :) Protoze muze mit jine jmeno a vy nevite, zda byl v archivu poskozen obsah souboru, jeho crc/hash nebo oboji.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: messagebus 18. 01. 2022, 17:36:57
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.

Tohle je hodne brutalni symptom. Takovy server by bylo dobre odstavit a poradne otestovat, a ne na nej kopirovat dalsi data.

Jinak robocopy uz z nejakych duvodu nevyhovuje?
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: mrmh 18. 01. 2022, 18:38:32
Pri kopírovaní zásadne kontrolovať  neporušenosť napr. cez TeraCopy.
Veľa malých súborov zbaliť do RARu s recovery recordom (vhodne zvoliť %).
Pre všetky súbory vygenerovať PAR (s vhodne zvolenými parametrami) napr. cez MultiPAR.
Mať druhú kópiu dát spolu s PAR súbormi.
Pod Windows existujú katalogizačné sofvéry, ktoré si do DB/katalógu ukladajú aj hash katalogizovaných súborov.
Název: Re:Jednoduchá kontrola integrity dlouhodobě archivovaných dat
Přispěvatel: pruzkumbojem 18. 01. 2022, 21:17:53
jak uz tady padlo:
a presne kvuli tomuhle vzniklo ZFS....

ovsem s projektem zfs pro windows je to porad vachrlate. (ale co takhle iSCSI target?)