Odstranění duplicit a konsolidace dat

Odstranění duplicit a konsolidace dat
« kdy: 08. 05. 2026, 22:02:05 »
Dobry vecer,


prosim o mensi brainstorming, data mi uz prerustaji pres hlavu :)


1x notas (Windows; 1 TB, vetsina dat je toliko kopie ze SSD NASu, ale zato tyto kopie existuji v ruznych verzich)
1x desktop (Windows; ~5 TB, vychazi opet jako kopie ze SSD NASu, ale nekdy mam u sebe jen notas, kde udelam nejake zmeny, ty si presypu sem a mam to tu vickrat... desktop ma obecne storage jen jako "pracovni disky", samotny uzitecny vystup je vlastne o rozumne velikosti)
1x tichej SSD NAS (Linux; ~5 TB - zere to malo, bezi to furt, je to rychly, tak tam mam takovou "cache" pro velke HDD zalohoviste)
1x hlavni HDD zalohoviste (Linux; ~12 TB - spousta dat je tam proste jen tak pro sichr)
1x HDD cold storage archiviste toho nejdulezitejsiho (Linux; ~6 TB)


Prilezitostne zkousim fusovat do casosberu a mam docela problem si v tech datech udrzet nejakej smysluplnej poradek.

Jsem nekde fuc, SD kartu natroubim do notasu a nazdar, pripadne udelam nejake drobne upravy a odsypu to na SSD storage.
Nekdy za tyden, mesic, objevim SD kartu, chcu si byt jistej, ze ten obsah jako fakt nekde mam, tak to jeste supnu na SSD storage do kouzelne bobtnajici slozky "nove".
Ze SSD storage si to pak presypu do desktopu pro poradne zpracovani, pripadne to ruzne existuje v mnoha verzich.
Jednou za uherak zapnu zalohoviste a presypu jeste tam.


Vysledkem je strasnej gulas, fura duplicit a nakolik storage zdrazuje a misto dochazi, musim uz ty duplicity nejak resit.


Jak z toho nejlip vybruslit?


Docela svizne mi vsechno prechroustal multiplatformni DupeGuru (nazev, datum, a/nebo hash souboru), ale s ohledem na charakter tech dat, co mam, by mi vyhovovalo spis neco, kde si muzu otevrit celej strom filesystemu a vychazet toliko z podobnych slozek, nez to resit v ramci seznamu s duplicitama v radu vyssich desitek tisic...


Nu a dalsi vec je, ze teda bez nejakyho poradnyho syncu a discipliny se uz asi fakt nehnu, veci z karty asi spis presunout, nezli kopirovat...
Udelat si jasno v tom, co ze je "master" (kuriozne to vlastne bude asi spis ona SSD storage, k tomu pristupuju nejvic, pac to bezi furt).
A poresit sync zmen mezi SSD storagem a zalohovistem (pro kazdej file prohledat, jestli tam uz neexistuje... upozornit, pokud chci mit jako master SSD storage a z nej nejakej soubor smaznu, jestli chci tuhle zmenu syncnout i do zalohoviste).


Variantne teda kdyz si vezmu jeste charakter toho, co delam - muze mit smysl si verzi metadat a konfigu k fotkam nacpat do neceho jako SVN, at si muzu prepinat mezi verzema pro lepsi porovnavani, nebo to neni vhodny use case?


Diky za napady.


Re:Odstranění duplicit a konsolidace dat
« Odpověď #1 kdy: 11. 05. 2026, 11:29:55 »
ja by som po upratani urobil asi to, ze na SSD NAS nasadim SVN server, klientov na notas a pocitac.
A potom dajme tomu kazdu noc robit sync z toho SSD NAS na HDD cold storage archiviste - tym zase zabezpecis, ze budes mat zalohu poslednych dat z toho ssd.
Cize cez den sa hrajes na ssd, menis/upravujes a vecer sa ti urobi zaloha na hdd.
To by na nejake udrzanie poriadku a zalohy dolezitych veci mohlo stacit.
kedze asi to budu rozne subory, tak preto radsej svn, ako git.

Re:Odstranění duplicit a konsolidace dat
« Odpověď #2 kdy: 11. 05. 2026, 15:26:17 »
Jak vyřešit už existující "duplicity" (čti: chaos/bordel) takhle zfleku v hlavě úplně nemám ale co se synchronizace týká, striktně se držím modelu "jeden master storage, kde je všechno + soustava strojů obsahující podmnožiny". A bez opravdu dobrého důvodu žádná data nikde jinde. Pak to lze snadno hned, P2P a automaticky synchronizovat přes Syncthing (https://syncthing.net/) a není v tom přesně tenhle binec. Nemuvě o tom, že je to pohodlné a nemusím pořád žonglovat s nějakými transfery odněkud někam.

Samozřejmě mám data i jinde ale to jsou vyloženě specifické domény: cold archiv, kam jde to, o čem vím, že už to potřebovat nejspíš hodně dlouho (roky) nebudu, archiv filmů a médií obecně, archiv fotek.
« Poslední změna: 11. 05. 2026, 15:28:37 od Martin Poljak »

Kit

  • *****
  • 1 004
    • Zobrazit profil
    • E-mail
Re:Odstranění duplicit a konsolidace dat
« Odpověď #3 kdy: 11. 05. 2026, 19:49:49 »
Použil bych Git. Vezmeš nejstarší adresář, dáš git init, git add, git commit. Potom novější soubory přesuneš do tohoto adresáře. Znovu git add, git commit. Přesuneš další a další. Git si už s duplicitami poradí i v případě rozdílných názvů. Starší soubory pak najdeš v historii.

Samozřejmě je nutné soubory rozdělit do projektů, to dá rozum.

a6b

  • ****
  • 250
    • Zobrazit profil
    • E-mail
Re:Odstranění duplicit a konsolidace dat
« Odpověď #4 kdy: 11. 05. 2026, 21:42:50 »
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
udelat deduplikovani relativne malych textaku a zdrojaku a xml asi jde, ale u velkych obrazku a binarnich souboru je to skoro nemozne.
takze ja bych to zkusil jen na nazvech adresaru a nazvech souboru, cesty a nazvy souboru jde zpracovat bud skripty nebo pomoci ai.
az v poslednim kroku zkusit porovnat velikost, hash pro soubory se stejnou cestou a stejnym nazvem.


Kit

  • *****
  • 1 004
    • Zobrazit profil
    • E-mail
Re:Odstranění duplicit a konsolidace dat
« Odpověď #5 kdy: 11. 05. 2026, 22:25:14 »
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
udelat deduplikovani relativne malych textaku a zdrojaku a xml asi jde, ale u velkych obrazku a binarnich souboru je to skoro nemozne.
takze ja bych to zkusil jen na nazvech adresaru a nazvech souboru, cesty a nazvy souboru jde zpracovat bud skripty nebo pomoci ai.
az v poslednim kroku zkusit porovnat velikost, hash pro soubory se stejnou cestou a stejnym nazvem.

Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy. Nevidím v tom žádný overkill, prostě to funguje. Skript asi na 6 řádek - bylo to nečekaně rychlé. Prostě stačí výstup sha256sum seřadit a pustit do filtru, který ty duplicity zobrazí, případně rovnou smaže.

Re:Odstranění duplicit a konsolidace dat
« Odpověď #6 kdy: 11. 05. 2026, 23:08:19 »
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.

Nie celkom, už som to robil niekoľkokrát v rôznych verziách so stovkami tisíc súborov. Zvlášť keď sa jedná iba o deduplikáciu, ktorá je oveľa menej náročná ako sa zdá. Vidím tam Windows, používam na takéto veci PowerShell je na to ako stvorený, má prístup aj do .Net aj do Windows API, dajú sa v ňom písať aj testy aj tam funguje TDD. A to isté by malo fungovať aj na Linuxe, v rámci .Net Core, tuším. Prípadne python alebo C# alebo čokoľvek.

Postup v skratke pre PowerShell: získať položky súborov v daných zložkách, to sú objekty, asi typ FileInfo alebo niečo také, zoskupiť podľa veľkosti, iba súbory s rovnakou veľkosťou (celkovo alebo veľkosť prúdu audio/video dát, ak ignorujem popisky) môžu byť duplikáty; pre každú skupinu veľkosti (cyklus alebo ForEach-Objekt) ktorá má viac ako jedného člena pridať objektom FileInfo v aktuálnej skupine cez Add-Member ako vlastnosť prúd na čítanie bloku dát, pridať aj objekt .Net na inkrementálný hash, zistiť si vopred z úložiska minimálnu veľkosť bloku, ktorú má zmysel načítať z disku (lebo keď aj zadám iba 1 bajt, OS aj tak načíta napríklad 4kb), pre danú veľkosť vypočítať koľko blokov zistenej veľkosti potrebujem na danú veľkosť súboru. Počet blokov určí počet iterácii inkrementálneho hashovania, pre každú iteráciu poslať položky aktuálnej skupiny veľkosti súborov do ForEach-Objekt, pre každú položku v bloku toho ForEach-Objekt načítať pre danú iteráciu i-ty blok podľa čísla iterácie, z prúdu, ktorý bol pridaný do položky v predchádzajúcich krokoch, pridať načítané dáta do kontrolného súčtu cez objekt z .Net, ktorý bol tiež pridaný do položky a vrátiť položku ako výsledok. Plus mínus niečo na tento spôsob.

Pokiaľ takto spracované položky chcem zhromaždené v jednom poli, tak ich normálne priradím do premennej, ak nie, tak ich zreťazím v kolóne s ďalším krokom, tým ten ForEach-Objekt nie je blokujúci, ale je ako generátorová korutina, ktorá posiela položky ďalej do ďalšieho kroku, takže keď napríklad v prvom kroku kolóny je piata položka, prvá položka je už v piatom kroku kolóny, ak ani jeden z krokov nie je blokujúci. (+-1, nerozmýšľam, nepočítam to...)

Ďalším krokom tu ale je zoskupenie podľa aktuálnej hodnoty inkrementálneho kontrolného súčtu. To sa asi dá urobiť iba blokujúco, lebo sú nutné všetky položky.

Tým vzniknú skupiny podľa aktuálnej hodnoty inkrementálneho kontrolného súčtu, tie ktoré po prvej iterácii majú iba jedného člena nemajú rovnaký prvý blok, nie sú to teda duplikáty, tým treba iba zatvoriť prúd, prípadne odobrať a aj ten objekt .Net, ktorý inkrementálne hashuje a zabudnúť na ne.

Súbory v skupinách, ktoré majú viac ako jedného člena sú kandidáti na duplikáty a tie je treba v ďalšej iterácii poslať opäť do toho ForEach-Objekt, kde sa načíta druhý blok dát, pridá sa do inkrementálneho kontrolného súčtu a výsledok sa zas zoskupí podľa aktuálnej hodnoty kontrolného súčtu z prvých dvoch blokov.

Takto postupne vypadnú súbory, ktoré nie sú duplikáty, veľa z nich hneď v prvých iteráciách, pre veľa z nich sa teda kontrolný súčet počíta iba z blokov na začiatku, dovtedy, kým nevypadnú z hry a úplný kontrolný súčet sa vypočíta iba z tých súborov, ktoré naozaj duplikátmi sú.

Takže pre deduplikáciu nie je nutné počítať celé kontrolné súčty zo všetkých súborov.

ForEach-Objekt má aj paralelnú verziu, ale je to zložitejšie, lebo je nutné obmedziť podľa typu úložiska počet paralelne bežiacich úloh (NVME zvládne viac, SATA SSD menej, rotačný disk ešte menej, možno iba 1, sieťové som neskúšal), pokiaľ máte všetko z NVME, je to jednoduché, ak nie, tak sa to dá zoskupiť podľa druhu úložiska a jednotlivé skupiny podľa druhu hardvéru riešite oddelene s rôznym obmedzením súbežnosti a pred zoskupením podľa výsledku aktuálnej iterácie kontrolného súčtu to zlúčite do jedného poľa. V PowerShelli je to iba jedna ďalšia úroveň cyklu a to zlúčenie je vzhľadom na vlastnosti kolóny automatické.

Potom sú tam ešte také veci ako odkazy na súbory, pevné alebo symbolické, to je nutné vedieť rozlíšiť, získať cieľový súbor odkazu, nechať v sade iba jeden výskyt, nemá zmysel deduplikovať 10 súborov, keď všetky ukazujú na tie isté dáta, to zistíte aj z Windows API, že sú to fyzicky tie isté dáta prístupné pod viacerými názvami a je lepšie prefiltrovať to vopred.

Robil som aj presúvanie súborov v jednej stromovej štruktúre podľa vzoru ich umiestnenia v inej stromovej štruktúre, a podobné veci, to ale vyžaduje buď úplné kontrolné súčty pre všetko, alebo podľa typu dát, napríklad audio/video súbory sa dá tipnúť si, že keď sú dáta v strede rôzne, celý súbor je rôzny, tak stačí kontrolný súčet z kúsku dát.

a6b

  • ****
  • 250
    • Zobrazit profil
    • E-mail
Re:Odstranění duplicit a konsolidace dat
« Odpověď #7 kdy: 11. 05. 2026, 23:11:56 »
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
udelat deduplikovani relativne malych textaku a zdrojaku a xml asi jde, ale u velkych obrazku a binarnich souboru je to skoro nemozne.
takze ja bych to zkusil jen na nazvech adresaru a nazvech souboru, cesty a nazvy souboru jde zpracovat bud skripty nebo pomoci ai.
az v poslednim kroku zkusit porovnat velikost, hash pro soubory se stejnou cestou a stejnym nazvem.

Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy. Nevidím v tom žádný overkill, prostě to funguje. Skript asi na 6 řádek - bylo to nečekaně rychlé. Prostě stačí výstup sha256sum seřadit a pustit do filtru, který ty duplicity zobrazí, případně rovnou smaže.

no u nekolika gigoveho filmu mi ten hash trval i 10s, tak to se mi nechtelo zase tak cekat, takze jsem nejprve porovnaval jen nazvy adresaru a souboru.

Kit

  • *****
  • 1 004
    • Zobrazit profil
    • E-mail
Re:Odstranění duplicit a konsolidace dat
« Odpověď #8 kdy: 12. 05. 2026, 00:12:23 »
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
udelat deduplikovani relativne malych textaku a zdrojaku a xml asi jde, ale u velkych obrazku a binarnich souboru je to skoro nemozne.
takze ja bych to zkusil jen na nazvech adresaru a nazvech souboru, cesty a nazvy souboru jde zpracovat bud skripty nebo pomoci ai.
az v poslednim kroku zkusit porovnat velikost, hash pro soubory se stejnou cestou a stejnym nazvem.

Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy. Nevidím v tom žádný overkill, prostě to funguje. Skript asi na 6 řádek - bylo to nečekaně rychlé. Prostě stačí výstup sha256sum seřadit a pustit do filtru, který ty duplicity zobrazí, případně rovnou smaže.

no u nekolika gigoveho filmu mi ten hash trval i 10s, tak to se mi nechtelo zase tak cekat, takze jsem nejprve porovnaval jen nazvy adresaru a souboru.

Potřeboval jsem deduplikovat shodné soubory s potenciálně různými názvy v různých adresářích. Přes sha256 jsem měl napsán skript asi za 5 minut. Než jsem si uvařil kafe, bylo deduplikováno. Nedělám to každý den, optimalizace tedy nedává smysl.

Kit

  • *****
  • 1 004
    • Zobrazit profil
    • E-mail
Re:Odstranění duplicit a konsolidace dat
« Odpověď #9 kdy: 12. 05. 2026, 00:15:52 »
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
.
Postup v skratke pre PowerShell: ...

Ve Windows je to tak komplikované? No jo, nemají roury...

Zopper

  • *****
  • 1 010
    • Zobrazit profil
Re:Odstranění duplicit a konsolidace dat
« Odpověď #10 kdy: 12. 05. 2026, 07:35:34 »
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.
Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...), a rozdělil bych to tedy na "spočítej hash pro všechno a ulož do sqlite" a pak dál pracoval už jen s tou sqlite (protože dělat random seek v txt, co má pár MB, taky není nejrychlejší, když to děláš milionkrát).

Kit

  • *****
  • 1 004
    • Zobrazit profil
    • E-mail
Re:Odstranění duplicit a konsolidace dat
« Odpověď #11 kdy: 12. 05. 2026, 10:01:32 »
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.
Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...), a rozdělil bych to tedy na "spočítej hash pro všechno a ulož do sqlite" a pak dál pracoval už jen s tou sqlite (protože dělat random seek v txt, co má pár MB, taky není nejrychlejší, když to děláš milionkrát).

Jaký random seek? Proženu to sortem a projdu sekvenčně

Re:Odstranění duplicit a konsolidace dat
« Odpověď #12 kdy: 12. 05. 2026, 10:32:11 »
Sám jsem deduplikaci pomocí hash úspěšně udělal v Bashi na své sbírce filmů. Najde shodu i když mají různé názvy.
Pokud tě zajímají jen přesné duplicity, tak je to v pohodě, i když to na velkém úložišti bude prostě trvat (přečíst celý disk a prohnat ty TB skrz CPU...)

Práveže ak chcete iba nájsť presné duplicity, tak všetky tie TB dát cez CPU prehnať nemusíte, stačia iba tie, ktoré sú bezpodmienečne nutné.

Dúfal som, že to bude z mojej odpovede jasné. Súbory, ktoré majú rovnakú veľkosť a nemajú rovnaký inkrementálny hash z prvých n blokov nie sú duplikátmi a nie je teda pre ne nutné počítať hash od bloku n+1. Vlastne možno ani nemusí byť počítaný inkrementálny hash, ale stačí prostý hash z daného bloku, ale to je v podstate jedno, lebo vypočítať hash je lacné v porovnaní so získaním dát z úložiska.

Kit

  • *****
  • 1 004
    • Zobrazit profil
    • E-mail
Re:Odstranění duplicit a konsolidace dat
« Odpověď #13 kdy: 12. 05. 2026, 10:48:58 »
Súbory, ktoré majú rovnakú veľkosť a nemajú rovnaký inkrementálny hash z prvých n blokov nie sú duplikátmi a nie je teda pre ne nutné počítať hash od bloku n+1. Vlastne možno ani nemusí byť počítaný inkrementálny hash, ale stačí prostý hash z daného bloku, ale to je v podstate jedno, lebo vypočítať hash je lacné v porovnaní so získaním dát z úložiska.

Takže když v bloku n+1 změním písmenko, tak jsou soubory stále shodné?

Re:Odstranění duplicit a konsolidace dat
« Odpověď #14 kdy: 12. 05. 2026, 11:53:14 »
sam mam zkusenost, ze delat hash jednotlivych souboru a porovnavat je overkill.
.
Postup v skratke pre PowerShell: ...

Ve Windows je to tak komplikované? No jo, nemají roury...

Njn, ešte stále sa stáva, že tu niekto "trollí", ale to že sa nájde niekto, kto má problém s chápaním písaného textu, porovnáva neporovnateľné a vyjadruje sa tak ako vy, ma už v tejto dobe naozaj trochu prekvapuje.

PowerShell pochopiteľne "roury" má, a asi vás zmiatlo, že nepíšem o primitíve spájajúcom dve fázy spacovania, čo je menej dôležitý koncept, ale o celom mechanizme kolóny, označenom tak sme sa to kedysi dávno učili.

To máte ako s vláknom, mne sa tiež slovo vlákno nepáči, ale akceptujem, že ho niekto kedysi dávno z nejakých dôvodov zaviedol.

Tu máte článok, kde je to slovo použité, myslím, že médium, kde je ten článok publikovaný je v odbornej komunite celkom rešpektované:  https://www.root.cz/clanky/terminaly-tajemstvi-zbavene-procesy-a-signaly/

Je k tomu aj celkom výživná diskusia, kde sú uvedené dôvody prečo toto slovo a prečo ho niektorí nechápu.

Pokiaľ ale máte pocit, že som niečo mohol napísať inak a že je chyba na mojej strane, čo sa mohlo stať, písal som to v noci, rád sa dozviem čo, nech sú moje príspevky v budúcnosti jednoduchšie na pochopenie.

Súbory, ktoré majú rovnakú veľkosť a nemajú rovnaký inkrementálny hash z prvých n blokov nie sú duplikátmi a nie je teda pre ne nutné počítať hash od bloku n+1. Vlastne možno ani nemusí byť počítaný inkrementálny hash, ale stačí prostý hash z daného bloku, ale to je v podstate jedno, lebo vypočítať hash je lacné v porovnaní so získaním dát z úložiska.

Takže když v bloku n+1 změním písmenko, tak jsou soubory stále shodné?

V akom prípade? keď je kontrolný súčet za prvých n blokov rovnaký alebo rôzny?

- ak je kontrolný súčet za prvých n blokov rôzny, tak vás blok n+1 nezaujíma, lebo tie súbory na základe prvých n blokov nemôžu na byť duplikátmi a v iterácii n ste ich z vyradili, takže v iterácii n+1 vôbec nie sú, pretože kontrolný súčet z nich nepočítate, lebo nemusíte, keďže viete z predchádzajúcej iterácie, že tie súbory nie sú duplikátmi.

- ak je ale kontrolný súčet za prvých n blokov rovnaký, tak ten rozdiel v jednom bajte zistíte v iterácii n+1, do iterácie n sú súbory kandidátmi na duplikáty, ale v iterácii n+1 nimi byť prestanú a tiež ich vyradíte z ďalšieho spracovania

Inak, mohol som asi použiť i na označenie čísla iterácie, ale to už je teraz jedno.