[linux] "Library" voor losse / offline harde schijven?

[iGadget]

Al jaren lang zit ik in een soort 'loopje' waarbij het volgende gebeurt:
1. Ik werk met meerder computers en creëer / verzamel content.
2. Hier maak ik backups van
3. Er gebeurt iets waardoor ik moet migreren naar ofwel een nieuwe machine danwel een nieuwe harde schijf (of herinstallatie / upgrade van OS)
4. Geen tijd om alles uit te zoeken, dus maak maar weer snel een extra kopie van alle data
5. Resultaat: meerdere kopieën van data verpreid over meerdere fysieke (offline) schijven, uitzoeken kost tijd, druk druk druk.
6. Terug naar 1.

Inmiddels gaat het om tientallen terabytes aan data verspreid over tientallen (vaak offline) schijven. Uitzoeken kost nog steeds teveel tijd maar rücksichtlos deleten durf ik niet. Dit probleem gaat zich natuurlijk niet vanzelf oplossen, sterker nog - het wordt alleen maar groter/erger.
Elke keer maar weer nieuwe, grotere schijven kopen maakt het probleem op termijn alleen maar erger, dus er moet iets fundamenteel anders.

Bestaat er een softwarematige (bijv. database) oplossing die met verwisselbare/offline media (zoals losse harde schijven) om kan gaan?

Het doel zou zijn om:
a) Te inventariseren welke fysieke media ik allemaal heb
b) Wat er op die verschillende datadragers staat (en dat op één plek bij te houden)
c) Redundante bestanden / duplicaten te localiseren en te verwijderen.

Voor MacOS is er NeoFinder wat lijkt te kunnen wat ik zoek, maar ik werk voornamelijk op Ubuntu 18.04 en KDE Neon en heb geen Mac.

Een full-scale Digital Asset Manager oplossing is mss wat overkill voor mijn situatie, als ik bijv. dit lees:
https://www.razuna.org/whatisrazuna/features
https://www.phraseanet.com/en/

Bovendien is het maar de vraag hoe goed deze systemen omgaan met offline disks.

Maar mss zit ik er helemaal naast? Graag jullie mening / advies

[jurri@n]

Een kant en klare tool zou ik zo niet weten, maar volgens mij kun je je doel ook vrij eenvoudig bereiken met een scriptje wat de naam/id van de disk, het path en de MD5sum van het bestand opslaat in een CSV/database/whatever. Als bestanden gelijk zijn, hebben ze immers dezelfde MD5sum.

Daarna zou je alle dubbele MD5sum's kunnen opzoeken en opschonen tot je er maar 1 over hebt.

Voor MD5sum mag je natuurlijk ook een moderner algoritme dan MD5 lezen

[iGadget]

jurri@n schreef op woensdag 1 mei 2019 @ 15:54:
Een kant en klare tool zou ik zo niet weten, maar volgens mij kun je je doel ook vrij eenvoudig bereiken met een scriptje wat de naam/id van de disk, het path en de MD5sum van het bestand opslaat in een CSV/database/whatever. Als bestanden gelijk zijn, hebben ze immers dezelfde MD5sum.

Daarna zou je alle dubbele MD5sum's kunnen opzoeken en opschonen tot je er maar 1 over hebt.

Voor MD5sum mag je natuurlijk ook een moderner algoritme dan MD5 lezen

Dan mag ik wel serieus gaan werken aan mijn script-fu. En voor ik dat op niveau heb EN het heb ingezet om iets werkends te bakken zijn we weer vele maanden verder vrees ik

[ThomVis]

Dat schuitje zat ik jaren geleden ook. En het werkt totdat een van de schijfjes het niet meer doet. Of de database corrupt raakt.
NASje kopen (met redundant schijven) en daar je data centraal op zetten. Al jouw schijven 1 keer uitzoeken, kopiëren, vernietigen. Doe het samen met een vriend (op een ander adres) en laat de NASsen over internet een backup naar elkaar maken. En weggooien wat niet belangrijk is.

[iGadget]

ThomVis schreef op woensdag 1 mei 2019 @ 16:56:
Dat schuitje zat ik jaren geleden ook. En het werkt totdat een van de schijfjes het niet meer doet. Of de database corrupt raakt.
NASje kopen (met redundant schijven) en daar je data centraal op zetten. Al jouw schijven 1 keer uitzoeken, kopiëren, vernietigen. Doe het samen met een vriend (op een ander adres) en laat de NASsen over internet een backup naar elkaar maken. En weggooien wat niet belangrijk is.

NASje heb ik. Zit vol. Met veel redundante data uiteraard. Op termijn wil ik wel alsnog naar zo'n oplossing (met een grotere NAS), maar dan moet ik daar eerst geld voor hebben EN mijn data uitgezocht hebben. En juist voor dat laatste zoek ik nu een oplossing zonder dat het me weken kost om alles uit te zoeken.

En wat betreft kapotte schijfjes of corrupte DB - als alles uitgezocht is kan ik eindelijk een definitieve backup-oplossing implementeren zonder wéér een extra redundante laag te erbij te krijgen.

[Ultraman]

Kijk eens naar git-annex.

Ik gebruik het al jaren. Inmiddels minder nodig, maar in mijn studietijd had ik meerdere computers en USB disks waar ik vanalles op bewaarde en tot zekere hoogte in sync wilde hebben. Met git annex kon ik op elke PC dezelfde grote fileboom hebben, maar niet de data altijd bij me hebben. Bij mij zijn mijn Pictures, Music en Video directories annexen waarvan mijn fileserver alles bevat, en op mijn andere devices heb ik wel de fileboom maar niet de data.

Jouw doeleinde lijkt op de case 'Archivist' op de website van git-annex. Je hebt een grote overzichtelijke fileboom, verspreid over verschillende disken. Voeg een disk toe aan git-annex en het houd bij welke data er op staat. Heb je dan ooit wat nodig dan kan het je vertellen op welke disk het staat. En er is ook de mogelijkheid om minimaal 2 of meer kopieën te bewaren. Integrity krijg je ook, want guess what, de fileboom wijst naar een file met z'n hashwaarde als filename

De command line client vind ik zelf het prettigst. Het helpt wel om wat kennis te hebben van de CLI en een beetje git in je vingers kan ook geen kwaad. Oefening baart kunst zou ik zeggen.
Je fileboom wordt opgebouwd uit symlinks die wijzen naar echte files er achter als de file op het systeem aanwezig is (of de juiste disk gemount).
Wil je ooit terug naar normale files? Geen probleem. Je kunt in principe gewoon een copy trekken (cp -L dereferenced symlinks en je krijgt weer files er voor terug).

Wellicht is het wat voor je

[ Voor 3% gewijzigd door Ultraman op 01-05-2019 22:54 ]

[iGadget]

Ultraman schreef op woensdag 1 mei 2019 @ 22:52:
Kijk eens naar git-annex.

*KNIP*

Wellicht is het wat voor je

Dat ziet er veelbelovend uit, ga ik naar kijken. Dank!

Voor het de-dupliceren ben ik nu bezig met dupeGuru. Nog steeds een flink arbeidsintensief klusje, maar vele malen minder werk dan alles met de hand.

Of zit er ook zoiets in git-annex?

[ Voor 29% gewijzigd door iGadget op 02-05-2019 11:57 . Reden: de-dup gedeelte vergeten. ]

[Ultraman]

Ja, dat zit er in. En daar hoef je niets voor te doen.

Wanneer jij een file toevoegd aan git annex neemt hij er een hash van. Add je nogmaals dezelfde file in de annex, dan heeft die file dezelfde hash en legt git annex een tweede(3e/4e/..) symlink richting de al bestaande file (die als filename onder de motorkap de hash heeft).

[ Voor 13% gewijzigd door Ultraman op 03-05-2019 07:54 ]

[iGadget]

Ultraman schreef op vrijdag 3 mei 2019 @ 07:53:
Ja, dat zit er in. En daar hoef je niets voor te doen.

Wanneer jij een file toevoegd aan git annex neemt hij er een hash van. Add je nogmaals dezelfde file in de annex, dan heeft die file dezelfde hash en legt git annex een tweede(3e/4e/..) symlink richting de al bestaande file (die als filename onder de motorkap de hash heeft).

Een symlink... geen hardlink? Wat als dan de 'originele' file gewist wordt?

Hoe dan ook, dit gaat dus wel ruimte besparen, maar mij niet helpen om mijn zelf gecreëerde puinhoop op te ruimen. De bedoeling is ook echt dat ik al die redundante backups van backups van backups (waar mss hier en daar nog wel iets tussen zit wat ik wèl nog wil bewaren) nou eindelijk eens opschoon.

[DJMaze]

Mijn Synology NAS heeft een find duplicates functie.
Daarmee heb ik alle dubbele/trippel/etc. zo gevonden en verwijderd.

Zo nu uit mijn hoofd alleen geen idee hoe het heet enzo, en of het voor alle bestanden is.

[Ultraman]

iGadget schreef op vrijdag 3 mei 2019 @ 22:56:
[...]

Een symlink... geen hardlink? Wat als dan de 'originele' file gewist wordt?

Symlink ja. Maar ik denk dat je er maar eens mee moet spelen, want dan begrijp je waarschijnlijk beter waar ik op doel.

Als jij een rm mijnfile zou doen dan verwijder je een symlink, niet je file.
Maar wat zou je moeten verwijderen eigenlijk? Want ik gebruik git annex voor spul wat ik eigenlijk nooit wil verwijderen. Niet dat het niet kan, maar je wilde toch juist je data gestructureerd gaan bewaren?

Zodra jij een file toevoegd aan git annex wordt de file hernoemd naar een hashwaarde en opgeslagen onder de .git/annex/..... De oorspronkelijke plek wordt vervangen door een symlink met de oorspronkelijk naam, wijsend naar die file onder de .git/annex/.../hash_van_mijn_file.extensie.

Check jij nu nogmaals dezelfde file in git annex, dan krijg je een file met dezelfde hash onder de .git/annex/... En dan is het: "Oh die heb ik al. Verwijder deze en vervang voor symlink richting de file in de store die ik al heb."
Het zijn nog steeds gewoon files en je kunt er nog steeds alles mee wat je normaal kon, alleen staan ze als file ergens anders en maakt git annex symlinks voor je. Ook beschermd het de boel tegen aanpassing en ook verwijderen, tenzij jij zegt dat je de file unlocked of weg wilt hebben.

Mee spelen is denk ik het beste middel om het een beetje door te krijgen.

Hoe dan ook, dit gaat dus wel ruimte besparen, maar mij niet helpen om mijn zelf gecreëerde puinhoop op te ruimen. De bedoeling is ook echt dat ik al die redundante backups van backups van backups (waar mss hier en daar nog wel iets tussen zit wat ik wèl nog wil bewaren) nou eindelijk eens opschoon.

Het gaat de directorystructuur niet voor je fixen idd. Maar kan inderdaad wel ruimte besparen.
Maar wellicht is het handig om dezelfde binary file of video of presentatie op meerdere plekken in je boom te hebben staan. Ik kan mij best voorstellen dat meerdere iteraties eenzelfde file bevatten. Die kan er dan prima staan, maar neemt niet dubbel de ruimte in.

[SadisticPanda]

Ze allemaal gelijk aan een linux back hangen. Met mergerfs combineren tot een grote pool en dan de bijhoren dedup tool draaien.

[iGadget]

SadisticPanda schreef op zaterdag 11 mei 2019 @ 21:44:
Ze allemaal gelijk aan een linux back hangen. Met mergerfs combineren tot een grote pool en dan de bijhoren dedup tool draaien.

Mergerfs... die kende ik nog niet. Mss niet eens zo'n gek idee, alleen heb ik geen enkele machine waar zoveel poorten op zitten dat ik alle schijven in 1x kan aansluiten. Zelfs al draaien ze stuk voor stuk Linux ;-)

[SadisticPanda]

iGadget schreef op zondag 12 mei 2019 @ 20:27:
[...]


Mergerfs... die kende ik nog niet. Mss niet eens zo'n gek idee, alleen heb ik geen enkele machine waar zoveel poorten op zitten dat ik alle schijven in 1x kan aansluiten. Zelfs al draaien ze stuk voor stuk Linux ;-)

Schijven hoeven niet rechstreeks aangesloten te zijn, ik heb ook 1 pool draaien met schijven die zoweel lokaal eraan hangen als schijven die in het nnetwerk hangen als google drive!