Algemene vraag mbt Bitrot / data corruptie

[Zakkenwasser]

Ik maak structureel vaak backups en gebruik daarbij een NAS: raid1 met 3 hdd’s, en nog eens drie externe hdd’s

Ik exporteer eerst mijn foto’s en video’s naar een map op de computer, die ik vervolgens weeg en noteer ik het “gewicht in bytes” en sorteer.

Als die map rond de 20gb is gaat die naar mijn NAS en externe hdd’s.

Vervolgens weeg en noteer ik het totaal aantal bestanden van al mijn media.

Vandaag zit ik op 4.136.988.463.669 bytes / 405.273 bestanden.

Kan ik met deze methode makkelijker bit-rot / bit flips en overige data degradatie detecteren?

Een corrupt bestand weegt toch anders dan zijn niet corrupte tweeling?

[Juup]

Zakkenwasser schreef op zaterdag 1 februari 2025 @ 13:51:
Een corrupt bestand weegt toch anders dan zijn niet corrupte tweeling?

Ehh... wat bedoel je met "weegt"?
Als je bestandsgrootte bedoelt: nee die is bij bitflips hetzelfde (tenzij het in de FAT gebeurt).

[Zakkenwasser]

Juup schreef op zaterdag 1 februari 2025 @ 14:08:
[...]

Ehh... wat bedoel je met "weegt"?
Als je bestandsgrootte bedoelt: nee die is bij bitflips hetzelfde (tenzij het in de FAT gebeurt).

Ik bedoel inderdaad de eigenschappen.
Zijn er betere methoden/programma’s hiervoor om een unieke hash te maken van alle bestanden?

[Juup]

Zakkenwasser schreef op zaterdag 1 februari 2025 @ 15:18:
Zijn er betere methoden/programma’s hiervoor om een unieke hash te maken van alle bestanden?

Beter dan wat?

[F_J_K]

Vroegah gebruikte ik wel eens quickpar voor zoiets.

Incidenteel checksums draaien op beide plaatsen. Niet te vaak. Beter: gebruik een filesystem dat zelf aan checksums doet.

Edit: ik had over het Raid0 heen gelezen Raid0 en zorgen over data gaat niet samen: Raid0 gebruik je alleen als het geen pijn doet als de data foetsie is.

[ Voor 31% gewijzigd door F_J_K op 01-02-2025 16:16 ]

[canonball]

Zakkenwasser schreef op zaterdag 1 februari 2025 @ 13:51:
Ik maak structureel vaak backups en gebruik daarbij een NAS: raid0 met 3 hdd’s, en nog eens drie externe hdd’s

Bedoel je echt raid0 of raid1 (maar dan heeft 3 disken weinig zin)?? als je dat hebt zou kun je beter eerst dat aanpakken voordat je zorgen maakt over bitrot.

tav bitrot, je kunt het beste een bestandssysteem nemen dat dat detecteert, en evt oplost.
ZFS of btrf zijn dan de lociche opties. En dan bv btrf met raid1, of zfs met een zpool (lijkt op raid, maar is net anders)

[CodeCaster]

Juup schreef op zaterdag 1 februari 2025 @ 15:52:
[...]

Beter dan wat?

020.

[Zakkenwasser]

canonball schreef op zaterdag 1 februari 2025 @ 16:00:
[...]

Bedoel je echt raid0 of raid1 (maar dan heeft 3 disken weinig zin)?? als je dat hebt zou kun je beter eerst dat aanpakken voordat je zorgen maakt over bitrot.

tav bitrot, je kunt het beste een bestandssysteem nemen dat dat detecteert, en evt oplost.
ZFS of btrf zijn dan de lociche opties. En dan bv btrf met raid1, of zfs met een zpool (lijkt op raid, maar is net anders)

RAID1 (mirrored) op mijn NAS staat ook btrfs aan.
Alleen hoe controleer je hdd’s buiten je NAS?

[F_J_K]

Ook btrfs? Of zoals gezegd zelf checksums maken en af en toe (scriptmatig) langslopen.

[Ben(V)]

Als je drie disken hebt kun je beter Raid 5 (als je Synology heb SHR) gebruiken en dan regelmatig een data schrub doen.
Met Raid 1 kan dat niet.

Die datascrub zal je vertellen of er ergens bitrot heeft plaatsgevonden en als je geluk hebt kan hij het ook nog repareren.

PS
Wegen doe je met een weegschaal en levert iets in grammen op, wat jij doet is data bits bij elkaar optellen.

[sypie]

Ben(V) schreef op zondag 2 februari 2025 @ 14:05:
Wegen doe je met een weegschaal en levert iets in grammen op, wat jij doet is data bits bij elkaar optellen.

Data kun je ook wegen, heb je alleen wel iets nauwkeurigere weegschaal voor nodig. Een artikel wat hier over gaat is hier te vinden: https://www.progress.com/...-why-digital-mass-matters

[Ben(V)]

Als je het echt gelezen had wist je dat de schrijver denk dat data hetzelfde is als electrons wat niet het geval is.
Data op een disk is magnetisme en geen lading electrons.

En niemand heeft nog een methode (zelfs niet theoretisch) kunnen vinden om magnetisme te wegen.

[Renault]

De meest gemaakte fout op dit gebied is dat "checksums" (parity) kunnen bewijzen dat data nog intact is.
Een checksum/parity is een statistisch gegeven over de data, het zegt niets over de data zelf.

Een niet kloppende checksum/parity geeft alleen een statistisch " alarmsignaal" dat er daadwerkelijk iets mis is gegaan, meer niet.

[F_J_K]

Renault schreef op zondag 2 februari 2025 @ 22:01:
De meest gemaakte fout op dit gebied is dat "checksums" (parity) kunnen bewijzen dat data nog intact is.
Een checksum/parity is een statistisch gegeven over de data, het zegt niets over de data zelf.

Een niet kloppende checksum/parity geeft alleen een statistisch " alarmsignaal" dat er daadwerkelijk iets mis is gegaan, meer niet.

Kan je een paar voorbeelden geven van waar de hash collision niet klopt?

Klopt, het geeft geen 100 procent zekerheid. Maar 99% is meer dan niet…

[ Voor 6% gewijzigd door F_J_K op 02-02-2025 22:09 ]

[Ben(V)]

Renault schreef op zondag 2 februari 2025 @ 22:01:
De meest gemaakte fout op dit gebied is dat "checksums" (parity) kunnen bewijzen dat data nog intact is.
Een checksum/parity is een statistisch gegeven over de data, het zegt niets over de data zelf.

Een niet kloppende checksum/parity geeft alleen een statistisch " alarmsignaal" dat er daadwerkelijk iets mis is gegaan, meer niet.

Een checksum geeft aan of de data corrupt is of niet, niet wat er corrupt is.

[ Voor 4% gewijzigd door Ben(V) op 03-02-2025 08:07 ]

[dcm360]

Checksums en parity zijn vooral compleet andere zaken, en moet je niet op 1 hoop gooien.
Met parity kan je x delen data opdelen in x+y delen, en zo lang er x delen van de x+y correct beschikbaar zijn heb je de beschikking over de originele data. Dit is ook de reden waarom klassiek RAID niet geschikt is voor het bewaken van de integriteit van de data, want het kan bij een 'fout' in het terugberekenen niet vaststellen welk van de x+y delen de fout is. Toen ik hier jaren geleden wat op heb getest bleek md de keuze te maken om de eerste x delen als waar aan te nemen, en de volgende y delen opnieuw weg te schrijven.
Over checksums is al terecht opgemerkt dat je er de kans mee vast kan stellen of data gewijzigd is. Met tegenwoordig 'ouderwetse' checksums met 32 bits heb je een kans van 1 op 4 miljard dat de checksum geen wijziging vindt die er wel was. Willekeurige wijzigingen leveren daarmee (zeker met nieuwere checksums) bijna gegarandeerd een andere hash op.

Het leukste is dan wel als je deze 2 combineert. Met checksums (of een mismatch in pariteit) kan je vaststellen dat er iets fout gegaan is, maar je kan ook vaststellen welke x delen van de x+y delen na reconstructie overeenkomen met de hash. Ook hier heb je een minimale kans (van 1 op 4 miljard of kleiner met modernere hashes) dat het mis gaat, maar dat is al beter dan aannemen dat de eerste x delen altijd correct zijn.

En dit is overigens allemaal statistiek. Foutdetectie en foutcorrectie bestaat bij gratie van algoritmes waarmee je de kans op correcte data zo dicht mogelijk bij de 100% probeert te krijgen.

[ Voor 6% gewijzigd door dcm360 op 02-02-2025 22:49 ]

[Renault]

Mijn punt hierboven is dat alle statistische indicatoren op "kloppend" kunnen staan, maar dat tóch de data "niet origineel" is, oftewel niet de destijds opgeslagen versie maar een aangetaste versie ervan.

Dit is een kwestie van toeval en gelukkig zélden voorkomend, maar écht vertrouwen op een intacte checksum / pariteit is een verkeerd uitgangspunt als het je kostbare data betreft.
Meer niet.

[dcm360]

@Renault Ik noemde dus een kans van 1 op 4 miljard, dat vindt je blijkbaar een risico? Op welke manier zou jij voorstellen om het beter te doen dan dat?

[Renault]

Geen idee, ik weet niet hoe groot het risico in werkelijkheid is.
In het geval van alléén van parity is dat véél groter.

Mijn punt is dat datazekerheid primair in procedures en redundancy's moet zitten en niet in periodieke controle van bestanden op één (of te weinig) medium/media.

Maar laten we aub hier deze discussie stoppen, het gaat bezijden de kern van dit topic.

[SPee]

Je zou dan per directory een bestand kunnen aanmaken met een checksum per bestand. Dan kun je over je schijven heen controleren of dat bestand niet meer correct is.
Je kunt daar bv de linux tool 'shasum' (of sha256sum, sha512sum) of windows powershell 'Get-FileHash' voor gebruiken. Corrigeren zou je dan moeten doen door de corrupte te vervangen door een correcte.
Per stukje van een bestand (data block) is mogelijk, maar daar zijn geen algemene tools voor.

Overigens hoeft niet elke bitrot een probleem te zijn. Veel mediaformaten hebben ook een mate van error handling.

[vanaalten]

Renault schreef op maandag 3 februari 2025 @ 15:19:
Geen idee, ik weet niet hoe groot het risico in werkelijkheid is.
In het geval van alléén van parity is dat véél groter.

Mijn punt is dat datazekerheid primair in procedures en redundancy's moet zitten en niet in periodieke controle van bestanden op één (of te weinig) medium/media.

Maar laten we aub hier deze discussie stoppen, het gaat bezijden de kern van dit topic.

@Renault Maar... dit is toch juist exact de kern van het topic?
TS wil weten hoe corruptie te detecteren en daar zijn diverse methodes voor te bedenken:

• filesize, zoals TS mee begon. Het is een klein beetje bruikbaar, als een bestand door corruptie groter of kleiner wordt, maar niet bruikbaar als het bestand door corruptie anders wordt.
• parity - bijvoorbeeld het aantal enen in een binaire file tellen dus. Werkt goed voor een enkele bitflip, maar meer corruptie heb je dus 50% kans dat het gezien wordt.
• hash, checksum berekenen. Afhankelijk van het algoritme een goede tot zeer goede dekking om corruptie te detecteren. Ik zit er niet zo in, maar wat @dcm360 zegt is een kans van 1 op 4 miljard dat corruptie van een bestand exact dezelfde hashwaarde geeft (en dus niet gedetecteerd wordt).
• Tja, als je dat niet voldoende vindt, kan je verschillende hashes berekenen met verschillende algoritmes. Dan ga je van 1 op 4 miljard naar, ik noem maar wat, 1 op 40 miljard of meer. Al zal de daadwerkelijke dekking best een ingewikkelde rekensom kunnen zijn, maar je gaat er hoe dan ook op vooruit.
• Zou je natuurlijk ook nog hetzelfde bestand vier keer kunnen kopieeren. Als 1 van de 5 anders is dan de andere 4, dan zal die wel corrupt zijn (of de andere 4 hebben exact dezelfde corruptie...)
• En zo kun je doorgaan met de detectiekans verhogen door bovenstaande uit te breiden of te combineren. En dan is het aan de eigenaar van de data om te bepalen wat hij/zij nodig heeft. Voor een filmcollectie vind ik zelf een opslag op ZFS-filesystem met extra hash per bestand en een reservekopie op externe harddisk goed genoeg. Of eigenlijk zwaar overkill, maar omdat het kon gewoon gedaan. Maar enkel de data-eigenaar kan bepalen wat er nodig is.

En los van dit alles, het kunnen detecteren van corruptie, is het natuurlijk ook zinnig om de juiste procedures en redundantie te hebben: als je geen procedure hebt om regelmatig de checksums te controleren, heb je er ook weinig aan. En als je geen backups hebt, dan kan je enkel corruptie vaststellen maar niet herstellen.

Het gaat om het totaalplaatje - maar de methode van data integriteitscontrole met hash, parity, wat dan ook, is onderdeel van het totaalplaatje.

[dcm360]

vanaalten schreef op dinsdag 4 februari 2025 @ 08:31:
[...]

• hash, checksum berekenen. Afhankelijk van het algoritme een goede tot zeer goede dekking om corruptie te detecteren. Ik zit er niet zo in, maar wat @dcm360 zegt is een kans van 1 op 4 miljard dat corruptie van een bestand exact dezelfde hashwaarde geeft (en dus niet gedetecteerd wordt).
• Tja, als je dat niet voldoende vindt, kan je verschillende hashes berekenen met verschillende algoritmes. Dan ga je van 1 op 4 miljard naar, ik noem maar wat, 1 op 40 miljard of meer. Al zal de daadwerkelijke dekking best een ingewikkelde rekensom kunnen zijn, maar je gaat er hoe dan ook op vooruit.

Bij het gebruik van verschillende (32 bit) hashes zou je dat getal in theorie mogen vermenigvuldigen, en uitkomen op een kans van 1 op 18 triljoen (voor zover dat nog een bevatbaar getal is). Een andere logische keuze zou het gebruiken van een 256-bit hash zijn, dan zit je in theorie op een kans van 1 op 116 duodeciljard (zeg maar een 1 met 77 nullen erachter) voor een collision. Ik zou er net als de rest van de wereld van uit gaan dat dit praktisch geen problemen meer gaat opleveren...

Dus, de 'makkelijke' optie is een bestandssysteem gebruiken dat de bestanden hasht, en regelmatig een scrub uitvoeren om te verifiëren dat de bestanden ongewijzigd zijn. Als je datzelfde ook doet met de backups (al zou je die ook prima in een archiefbestand met checksums kunnen stoppen), kan je bij beschadigingen een nog wel correcte kopie terughalen.

[Zakkenwasser]

Ik was iets te snel met het plaatsen van mijn startpost. Omdat ik hier pas geleden een topic las over een ZFS setup met corruptie werd ik een beetje angstig.

Even een paar dingen rechtzetten:

- NAS met Raid 1 (3 mirror) met btfrs en map ingesteld op geavenceerde data intergriteit.
- Drie losse externe schijven 2x NTFS, 1x extract via de NAS zelf (ext4)

Ik draai nog geen Linux op mijn Laptop, maar zou het mogelijk zijn om via mijn NAS mijn drie externe schijven als btfrs in te stellen?

[jan99999]

-Zorg dat je nas scrubben doet, dan kun je bij een foutmelding daar actie op doen, als hd of file defect gaat.
-Zorg dat je bijv via backup software een kopie maakt(2x dus in totaal 3 kopieen) van al je data, dus niet gewoon kopieren, dus backup software gebruiken die de file content(inhoud van de file) vergelijkt van bron en backup.
-Met freefilesync kun je backup maken, maar ook 2 externe hd's kontroleren/vergelijken op fouten, dus of ze nog hetzelfde zijn.
-Backup maken met file content duurt zeer lang, maar dan weet je wel dat de data aangekomen is.
-Netwerk testen, ssd, harde schijf testen, maak een par2 test files, zet een groep iso files bij elkaar, maak een par2, stuur de map met iso's naar netwerk of naar ssd, of naar hd, daarna laat par2 lopen en je kunt zien of alles werkt. Van de hd's natuurlijk voor en na deze actie de smart uitlezen, dit ook bij nieuwe harde schijven/ssd.(dit zou je ook met freefilesync kunnen doen).
-1 backup extern van je huis maken, dit ivm brand diefstal.

Bij mij tegenover , een telefoon opladen, brand, alles weg in het huis, en ook bij de buurman.

[ Voor 32% gewijzigd door jan99999 op 06-02-2025 07:24 ]

[jan99999]

ExactFile-Setup deze heb ik gebruikt om een usb stick de files te kunnen testen op bitrot, dus of er niks is veranderd.

[Ben(V)]

Raid 1 heeft geen mogelijkheid tot scrubben, daar heb je minimaal Raid 5 voor nodig.
Raid 5 kan ook gewoon met 3 disken.

[dcm360]

Ben(V) schreef op donderdag 6 februari 2025 @ 09:22:
Raid 1 heeft geen mogelijkheid tot scrubben, daar heb je minimaal Raid 5 voor nodig.
Raid 5 kan ook gewoon met 3 disken.

Alles met enige vorm van redundantie (dus ook raid 1) kan je een scrub op uitvoeren om te kijken of de data op de schijven overeenkomt. Zit je er alleen nog mee dat raid (zonder extra informatie) niet geweldig is met een correctie de correcte kant uit uitvoeren.

[Ben(V)]

Je kunt wel controleren of de data tussen de mirror(s) verschillend is, maar je kunt niks herstellen.
Dat kan met Raid 5 wel.