MD5 Checksumfiles

[Verwijderd]

Een vraagje over md5 checksumfiles. Ik ben van plan mijn backuproutine opnieuw aan te pakken en vanaf nu gebruik te gaan maken van bestandsintegriteitscontrole. Mijn backup's gaan er zo uit zien:

DVD met X aantal verschillende mappen met bestanden. Van die bestanden maak ik MD5 hashes aan die als checksum worden opgeslagen: ChecksumMapX.md5

Als ik bijvoorbeeld map 2 terugkopieer naar de harde schijf kan ik met ChecksumMap2.md5 de integriteit van de bestanden controleren.

Nu is mijn vraag.. wat is de beste plaats om die checksumfiles op te slaan? Niet op de desbetreffende dvd lijkt me; stel dat de dvd om de een of andere reden deels corrupte files overbrengt, dan zou de checksum ook corrupt kunnen zijn.

[gertvdijk]

Misschien niet direct een antwoord op je vraag, maar misschien wel iets waar je wat aan hebt. Wat ik altijd een heel goede methode vind is PAR2-files die ook worden gebruikt in nieuwsgroepen (usenet). Met bijvoorbeeeld QuickPar maak je par2 files aan die checksums bevatten en eventueel aangevuld met een percentage herstelblokken in geval een deel van je data corrupt raakt. Het maakt dan niet uit welk deel stuk gegaan is, aangezien het parity blokken zijn.

De .par2 files (checksums) kan je dan gewoon ergens bewaren als je wil en ze geven je gelijk een overzicht van de hele inhoud, dus elke file die hij omvat.

[ Voor 13% gewijzigd door gertvdijk op 10-07-2009 12:24 ]

[Verwijderd]

gertvdijk schreef op vrijdag 10 juli 2009 @ 12:23:
Misschien niet direct een antwoord op je vraag, maar misschien wel iets waar je wat aan hebt. Wat ik altijd een heel goede methode vind is PAR2-files die ook worden gebruikt in nieuwsgroepen (usenet). Met bijvoorbeeeld QuickPar maak je par2 files aan die checksums bevatten en eventueel aangevuld met een percentage herstelblokken in geval een deel van je data corrupt raakt. Het maakt dan niet uit welk deel stuk gegaan is, aangezien het parity blokken zijn.

De .par2 files (checksums) kan je dan gewoon ergens bewaren als je wil en ze geven je gelijk een overzicht van de hele inhoud, dus elke file die hij omvat.

Oke, hiervan was ik nog niet op de hoogte. Ga het eens uitzoeken!

[Verwijderd]

Er ontstaan wel nieuwe vragen.. Als ik het goed begrijp zijn de par2 files ook meteen de integriteitscontrolebestanden... maar gaat dit met een ander algoritme dan md5?

En als ik verder rondkijk op internet zijn er veel mensen die hun data eerst rarren, daarna parren. Stel ik wil jpg's backuppen, is het dan verstandig om eerst een collectie jpg's te 'rarren' en daarna te 'parren'? Mijn mapjes varieren in aantallen jpg's van 10 tot 2000. Of is het beter de jpg's niet te rarren?

Eigenlijk een geniaal programma.. als er een bestand ontbreekt dan maakt het niet uit welk par bestand je gebruikt om het terug te halen, mits voldoende blocks... En over de blockgrootte.. ik heb gekozen voor 'blockgrootte precies 384.000 bytes/377 kb' omdat encoderen imo niet nodig is? (ik post niet in nieuwsgroepen). Maar ik kan fout zijn en in dat geval kan ik beter kiezen voor yEnc, al begrijp ik nog niet waarom

En verder, het schijnt (wat ik vanavond gelezen heb) dat indien de de parity files zelf corrupt zijn, quickpar alleen de delen gebruikt die nog wel goed zijn.. Zo kan je ze dus op dezelfde schijf bewaren als naar waar de backups zijn weggeschreven. Dit is dan meteen een antwoord op mijn eigenlijke vraag, alleen gaat het nu om de par2 files.

Wellicht dat ik er toch voor kies ze op een apart medium te branden.. maar ok

Oja, nog een laatste vraag.... hoe groot zou ik de blockgrootte moeten kiezen? Waar baseer je zoiets op?

Ik zal morgen zelf verder zoeken naar antwoorden

[gertvdijk]

Verwijderd schreef op vrijdag 10 juli 2009 @ 23:10:
Er ontstaan wel nieuwe vragen.. Als ik het goed begrijp zijn de par2 files ook meteen de integriteitscontrolebestanden... maar gaat dit met een ander algoritme dan md5?

Maakt het wat uit welk algoritme gebruikt wordt? Uit ervaring weet ik dat PAR2 gewoon altijd werkt. (Afgezien van sommige bugs in usenet post programma's)

Verwijderd schreef op vrijdag 10 juli 2009 @ 23:10:
En als ik verder rondkijk op internet zijn er veel mensen die hun data eerst rarren, daarna parren. Stel ik wil jpg's backuppen, is het dan verstandig om eerst een collectie jpg's te 'rarren' en daarna te 'parren'? Mijn mapjes varieren in aantallen jpg's van 10 tot 2000. Of is het beter de jpg's niet te rarren?

Rarren is gebruikelijk voor nieuwsgroepen, maar staat helemaal los van het parren. Overigens gebruikt RAR ook weer integriteitscontrole.

Verwijderd schreef op vrijdag 10 juli 2009 @ 23:10:
Eigenlijk een geniaal programma.. als er een bestand ontbreekt dan maakt het niet uit welk par bestand je gebruikt om het terug te halen, mits voldoende blocks...

Dat is exact het geniale inderdaad.

Verwijderd schreef op vrijdag 10 juli 2009 @ 23:10:
En over de blockgrootte.. ik heb gekozen voor 'blockgrootte precies 384.000 bytes/377 kb' omdat encoderen imo niet nodig is? (ik post niet in nieuwsgroepen). Maar ik kan fout zijn en in dat geval kan ik beter kiezen voor yEnc, al begrijp ik nog niet waarom

Blockgrootte kiezen is een afweging tussen de grootte te 'parren' files en het spreiden van het risico op beschadiging. Stel je gaat 2GB parren en je neemt een blocksize van 100kB dan heb je relatief veel overhead als je 10% par2 blokken bijgenereert, maar met 200MB blokken is de kans te groot dat alle blokken beschadigd zijn (ook al zijn er maar 15 beschadigingen over je hele data)...
Encoderen is helemaal niet nodig idd.

Verwijderd schreef op vrijdag 10 juli 2009 @ 23:10:
En verder, het schijnt (wat ik vanavond gelezen heb) dat indien de de parity files zelf corrupt zijn, quickpar alleen de delen gebruikt die nog wel goed zijn.. Zo kan je ze dus op dezelfde schijf bewaren als naar waar de backups zijn weggeschreven.

Jij hebt het begrepen.

Verwijderd schreef op vrijdag 10 juli 2009 @ 23:10:
Wellicht dat ik er toch voor kies ze op een apart medium te branden.. maar ok

Lijkt mij een beetje overbodig en vooral omslachtig. Enige wat je ermee ondervangt is een gevalletje waarbij je net een paar blokken teveel beschadigd aantreft. Maar het blijft jouw keuze natuurlijk.

[Verwijderd]

Oke bedankt voor de info!