Advies over bit rot protection en 2-bay NAS (QNAP TS-251D)

[JeroenTheStig]

Ik ben op zoek naar een manier om data, waaronder een aardige fotocollectie, veilig op te slaan. Tot voor kort had ik hiervoor een externe HDD aangesloten op een servertje dat ik hier binnen mijn netwerk heb draaien. Deze werd o.a. gebruikt voor timemachine backups en als locatie waarnaar backupsoftware die op de laptops hier in huis is geinstalleerd hun backup naartoe schreven. Deze zelfde informatie (behalve time machine) werd tevens gebackupped naar een offsite backup location.

Echter heb ik nooit rekening gehouden met z.g.n. bit rot, of silent data corruption. Data integriteit werd m.i. dus niet bewaakt. Nadat ook mijn externe schijf regelmatig uitviel, was dat voor mij reden om de setup te vervangen door een NAS-opstelling die mij tevens zou moeten beschermen tegen bit rot.

Ik heb sinds enkele dagen een 2-bay QNAP nas in mijn bezit (TS-251D), waarvan ik had gelezen dat deze beschermt tegen bit rot. Dit zou worden opgelost met RAID scrubbing.

Nadat ik de NAS heb geinstalleerd in RAID-1 configuratiie, kwam ik er achter dat RAID scrubbing alleen toegepast kan worden bij RAID5/RAID6 configuraties. Tevens is het met de QNAP turbo stations / QTS besturingssysteem niet mogelijk om een filesystem te gebruiken die mij beschermt tegen dat rot (zoals ZFS).

Ik heb daarom een aantal vragen om te bepalen of ik veilig (genoeg) zit met mijn huidige setup, ook omdat in de handleiding van de QNAP met geen woord wordt gerept over data integriteit en silent data corruption.

1. In welke mate beschermt deze QNAP mij tegen bit rot, of is deze bescherming uberhaupt niet aanwezig?

2. HDD's hebben ECC aan boord. In welke mate kan ik hierop vertrouwen in een RAID-1 config? Bijv., als bij het lezen van een bestand een ECC failure optreedt in één van de schijven, valt de RAID-1 controller in dat geval terug op de andere schijf?

3. Moet ik mij uberhaupt zorgen maken over bit rot in een huis/tuin/keuken opstelling?

[Ben(V)]

Bitrot is in een twee bay Nas altijd een probleem.
Je kan maximaal daarmee een mirror maken en als er door bitrot dan ergens een bit omvalt kan de Nas maximaal constateren dat er een bestand corrupt is maar kan nooit uitvinden welke helft van de mirror juist is.

Alleen een Raid5 systeem (dus minimaal 3 disken) can via de opgeslagen CRC uitvinden op welke disk de bitrot is opgetreden en dan corrigeren.

Als je een twee bay Nas hebt zul je om je daar tegen te beschermen voor een backup moeten zorgen.

En of je zorgen moet maken is een afweging tussen de kans dat het optreed en het belang dat je aan je data toekent.

[Mijzelf]

Ben(V) schreef op zondag 12 juli 2020 @ 11:58:
Alleen een Raid5 systeem (dus minimaal 3 disken) can via de opgeslagen CRC uitvinden op welke disk de bitrot is opgetreden en dan corrigeren.

Hoe dan? Bij mijn weten is de parity bij raid5 een XOR van de data blokken op de andere schijven. Als er een bitje omvalt zie je dat de XOR niet meer klopt, maar je kunt onmogelijk zien welk bitje is omgevallen, die op een van de data blokken of die op het parity blok.

@JeroenTheStig Heb je een linkje waar dat beschermingsmechanisme wordt beschreven? Bij mijn weten kun je bitrot alleen waarnemen/voorkomen op systemen met een geschikt filesysteem (ZFS of BTRFS) in combinatie met redundantie in de opslag.
Om het alleen waar te nemen volstaat het om een hash van al je bestanden bij te houden, en regelmatig te controleren.

[Ben(V)]

Je hebt gelijk

[ Voor 89% gewijzigd door Ben(V) op 12-07-2020 13:05 ]

[Wim-Bart]

Raid 5 en 6 zijn geen bescherming tegen bitrot. Stel je hebt een raid met 5 disks. Op disk 4 valt een bit om maar disk valt niet uit. Dan ziet raid dat er iets niet klopt, maar kan niet bepalen wat er niet klopt. Is de parity kapot, is het disk 1, disk 2 of misschien zelfs alle disks. Enige mogelijkheid is dat disk zelf aangeeft dat sector kapot is. En de vraag is, doet disk dat?

Bitrot is eigenlijk heel moeilijk op te vangen zonder te werken met CRC data. Zelfs ZFS is niet onfeilbaar. De enige juiste methode is drie kopieën van de data met ieder eigen CRC waarbij twee identieke versies van de data winnen.

[CurlyMo]

Wim-Bart schreef op zondag 12 juli 2020 @ 13:28:
Zelfs ZFS is niet onfeilbaar.

Leg uit

[Borromini]

Ik dacht dat ZFS net controlesommen van bestanden bijhield? Zelfs met één bitflip zonder mirror weet ZFS dan welk bestand corrupt is. Al kan je zonder mirror natuurlijk wel niks fiksen, maar dan weet je wel waar het zit .

[Wim-Bart]

CurlyMo schreef op zondag 12 juli 2020 @ 13:31:
[...]

Leg uit

Heel simpel, slaat ZFS alle data 3 maal op om dan de twee gelijken te laten winnen?

Niks mis met ZFS maar vanuit integriteit voldoet geen enkel systeem ook al heeft het parity en andere methoden. ZFS gaat heel ver, zelfs met ECC geheugen, maar ook dat is niet voldoende.

Wanneer ik 1 kopie van de data heb en ik kan een om vallend bit detecteren. Dan heb ik daar alleen maar aan dat ik weet dat de data niet goed is. Nu kan ik stap verder gaan, ik kan het bit herstellen. De vraag is nu was dit het bit of waren er andere bits. Als ik herstel, is dat dan de originele data? Er is geen referentie punt, zou je kunnen oplossen met row en column parity, maar ook dat is niet onfeilbaar.

Dus uiteindelijk is het misschien goed hersteld, maar zonder referentie weet je dat niet. Nu kan je er een tweede kopie tegen aan houden, maar wie zegt mij dat die tweede kopie goed is wanneer de zelfde techniek wordt gebruikt als kopie 1. Daarom kan je bijna 100% zeggen dat wanneer twee kopieën van drie gelijk zijn, dat dat de waarheid is. Maar uiteindelijk zal de waarschijnlijkheid bij 5 kopieën waarvan een majority wint de waarheid zijn.

[ Voor 0% gewijzigd door Wim-Bart op 12-07-2020 13:45 . Reden: Autocorrectie opgelost ]

[CurlyMo]

Wim-Bart schreef op zondag 12 juli 2020 @ 13:43:
[...]
De vraag is nu was dit het bit of waren er andere bits.

Dat weet je door te vergelijken met de CRC die is opgeslagen in de metadata.

Je hebt de som 1 (bit 1) + 3 (bit 2) = 4 (data). Van die 4 maak ik een CRC (voor het gemak in MD5) en die sla ik ook redundant op.

4 = A87FF679A2F3E71D9181A67B7542122C

Nu valt bit 1 om op HDD 2 waardoor de som opeens als volgt wordt:

2 (bit 1) + 3 (bit 2) = 5 (data)

5 = E4DA3B7FBBCE2345D7772B0674A318D5

CRC klopt dus niet meer met de data van schijf 1. Doordat de CRC ook staat opgeslagen als metadata weet ZFS welke van de twee versies juist was.

Als ZFS voor 1 + 3 zou kiezen als waarheid, dan blijkt dat de data weer overeenkomt met de opgeslagen CRC. Als er gekozen wordt voor 2 + 3 dan klopt de data niet met de opgeslagen CRC, waardoor ZFS weet welke van de twe versies juist was.

Borromini schreef op zondag 12 juli 2020 @ 13:35:
Ik dacht dat ZFS net controlesommen van bestanden bijhield? Zelfs met één bitflip zonder mirror weet ZFS dan welk bestand corrupt is. Al kan je zonder mirror natuurlijk wel niks fiksen, maar dan weet je wel waar het zit .

Mits je je data met meer dan één kopie laat opslaan.

[CurlyMo]

Oeps

[ Voor 99% gewijzigd door CurlyMo op 12-07-2020 13:58 ]

[Wim-Bart]

CurlyMo schreef op zondag 12 juli 2020 @ 13:57:
[...]

Dat weet je door te vergelijken met de CRC die is opgeslagen in de metadata.

Je hebt de som 1 (bit 1) + 3 (bit 2) = 4 (data). Van die 4 maak ik een CRC (voor het gemak in MD5) en die sla ik ook redundant op.

4 = A87FF679A2F3E71D9181A67B7542122C

Nu valt bit 1 om op HDD 2 waardoor de som opeens als volgt wordt:

2 (bit 1) + 3 (bit 2) = 5 (data)

5 = E4DA3B7FBBCE2345D7772B0674A318D5

CRC klopt dus niet meer met de data van schijf 1. Doordat de CRC ook staat opgeslagen als metadata weet ZFS welke van de twee versies juist was.

Als ZFS voor 1 + 3 zou kiezen als waarheid, dan blijkt dat de data weer overeenkomt met de opgeslagen CRC. Als er gekozen wordt voor 2 + 3 dan klopt de data niet met de opgeslagen CRC, waardoor ZFS weet welke van de twe versies juist was.


[...]

Mits je je data met meer dan één kopie laat opslaan.

Je weet dat twee verschillende bronnen identieke CRC kunnen opleveren. Hoe kleiner de CRC hoe groter die kans.

[CurlyMo]

Wim-Bart schreef op zondag 12 juli 2020 @ 14:03:
[...]

Je weet dat twee verschillende bronnen identieke CRC kunnen opleveren. Hoe kleiner de CRC hoe groter die kans.

Als je wil betogen dat hash collissions kunnen voorkomen en dus geen systeem feilbaar is dan heb je natuurlijk gelijk. Maar laten we realistisch blijven:

When using a secure hash like SHA256, the probability of a hash collision is about 2\^-256 = 10\^-77 or, in more familiar notation:
0.00000000000000000000000000000000000000000000000000000000000000000000000000001.

De door ZFS gebruikte Fletcher4 presteert vergelijkbaar. Ik noem dat risico dus verwaarloosbaar.

[Erik Jan]

Ik gebruik hier PAR2 bestanden voor. Dat kan fouten herstellen, is lekker flexibel, is backupbaar en werkt onafhankelijk van bestandssysteem/OS/hardware, en ook nog wel over 20 jaar.

Nadeel is dat je een beetje moet scripten om bv. elke nacht de nieuwe bestanden te verwerken.

[unezra]

Borromini schreef op zondag 12 juli 2020 @ 13:35:
Ik dacht dat ZFS net controlesommen van bestanden bijhield? Zelfs met één bitflip zonder mirror weet ZFS dan welk bestand corrupt is. Al kan je zonder mirror natuurlijk wel niks fiksen, maar dan weet je wel waar het zit .

ZFS fixt het juist wel.
ZFS is een van dé filesystems die actief beschermt tegen bitrot, ook wanneer je het op een enkele disk gebruikt.

Bij het lezen van de topictitel was ZFS het eerste dat in me op kwam.

[rdfeij]

Iets wat complexer is een CEPH cluster bouwen, of simpeler een Synology nas met een Synology Hybrid Raid oplossing.
Met wat linux kennis kom je met ZFS ook een eind.

[JeroenTheStig]

Bedankt voor de vele reacties. Ik zal op een aantal even snel reageren. Ik kom later nog even terug op de overige reacties.

Ben(V) schreef op zondag 12 juli 2020 @ 11:58:

Als je een twee bay Nas hebt zul je om je daar tegen te beschermen voor een backup moeten zorgen.

Het punt is dat de NAS juist dient als backup. Het vervelende met silent data corruption / bit rot is dat je er pas achter komt als je de data nodig hebt. Op het moment dat mijn laptop crasht en ik terug moet vallen op mijn backup, dan wil ik natuurlijk niet te maken krijgen met bit rot. Dat had ik dan namelijk al op een eerder moment willen weten zodat ik op dat moment maatregelen kon nemen. Bijv. door de data te herstellen op basis van de informatie van mijn laptop of offside backup.

Mijzelf schreef op zondag 12 juli 2020 @ 12:53:
[...]

@JeroenTheStig Heb je een linkje waar dat beschermingsmechanisme wordt beschreven? Bij mijn weten kun je bitrot alleen waarnemen/voorkomen op systemen met een geschikt filesysteem (ZFS of BTRFS) in combinatie met redundantie in de opslag.
Om het alleen waar te nemen volstaat het om een hash van al je bestanden bij te houden, en regelmatig te controleren.

In de documentatie van QTS 4.4.2 is het volgende te lezen over RAID scrubbing:

RAID scrubbing helps maintain the consistency of data on the NAS. QTS scans the sectors of a RAID 5 or RAID 6 group and automatically attempts to repair any detected errors. You can run RAID scrubbing manually, or on a schedule.
QNAP recommends performing RAID scrubbing at least once a month to maintain system health and prevent data loss.

Helaas gaan ze niet verder in op de werking ervan.

Verder geef ik nogmaals even aan dat de QNAP geen ander bestandsformaat ondersteunt dan EXT-4. ZFS is met de huidige hardware dus geen optie.

[unezra]

JeroenTheStig schreef op zondag 12 juli 2020 @ 15:51:
Verder geef ik nogmaals even aan dat de QNAP geen ander bestandsformaat ondersteunt dan EXT-4. ZFS is met de huidige hardware dus geen optie.

NAS vervangen door een FreeNAS exemplaar?
Dan heb je wél bitrot protectie, snapshots, offsite replicatie, de hele rimram.

[Borromini]

@unezra Spreekt dat wat CurlyMo zegt niet tegen? ALs je maar één versie hebt van het bestand, dus geen kopieën?

CurlyMo schreef op zondag 12 juli 2020 @ 13:57:
[...]

Mits je je data met meer dan één kopie laat opslaan.

[unezra]

Borromini schreef op zondag 12 juli 2020 @ 18:00:
@unezra Spreekt dat wat CurlyMo zegt niet tegen? ALs je maar één versie hebt van het bestand, dus geen kopieën?
[...]

Nee.
De ZFS bitrot protectie werkt ook bij één versie van het bestand, zonder snapshots.

Wil niet zeggen dat het per-sé verstandig is alleen daarop te vertrouwen. Met ZFS zou ik evengoed nog gebruik maken van snapshots, RAID én offsite replicatie.

Maar de basis is nog steeds dat het zelf actief bitrot herkent en in-line herstelt. Je merkt het letterlijk alleen aan de scrubs. (Ik heb een keer een HBA met rotte firmware gehad, dankzij ZFS is er geen data verloren gegaan / corrupt geraakt.)

[JeroenTheStig]

unezra schreef op zondag 12 juli 2020 @ 16:54:
[...]


NAS vervangen door een FreeNAS exemplaar?
Dan heb je wél bitrot protectie, snapshots, offsite replicatie, de hele rimram.

Ik heb juist voor een kant-en-klare optie gekozen omdat ik geen zin heb om met allerlei randzaken bezig te zijn. Ik het verleden vaker mijn vingers aan gebrand met zelfbouw-spulletjes, en bovendien heb ik daar nu ook geen tijd voor (over). Wat mij betreft is freeNAS daarom geen optie voor mij.

Al met al lijkt de conclusie dus te zijn dat bit rot alleen gedetecteerd kan worden met een daarvoor geschikt filesystem. Dan vraag ik mij af waarom QNAP dan allerlei oplossingen op de markt zet die dat dus eigenlijk niet kunnen. Zie ik een probleem die er in de praktijk niet is?

Verder, heeft Synology betere oplossingen om bitrot tegen te gaan? Is Btrfs een goed alternatief voor zfs?

Waar ik vooral naar op zoek ben is puur detectie dat er iets niet in de haak is. Dat het vervolgens hersteld kan worden vind ik minder interessant, daar kan ik op dat moment het origineel of de offsite backup voor inschakelen. Helaas kan de QNAP niet periodiek gescheduled een file system check uitvoeren. Die moet ik expliciet uitvoeren of schedulen. Dat kan dus niet maandelijks geautomatiseerd uitgevoerd worden.

Als laatst vraag ik mij nog steeds af hoe en of de ECC check die in de HDD's is ingebouwd kan bijdragen in dit verhaal. Met mijn boerenverstand zou ik zeggen dat het mogelijk moet zijn om in een RAID-1 configuratie i.c.m. de HDD ECC check te voorkomen dat ik corrupte data krijg wanneer ik die inlees (even los van fouten op bus/memory-niveau). Immers, als een block, die gemirrord is, ingelezen wordt van disk1, en daarbij treedt een ECC failure op op HDD-niveau, dan zou je zeggen dat de RAID-controller vervolgens diezelfde block van disk2 op zou kunnen halen. Tuurlijk kan op disk2 heel toevallig diezelfde block ook corrupt zijn, maar die kans lijkt mij extreem klein dat ik daar geen rekening mee wil houden. Foutherstelling zou de HDD dan uitvoeren d.m.v. sector reallocation of iets dergelijks.

Ik heb wel een blog gevonden waar e.e.a. wordt uitgelegd over ECC op HDD niveau en dat dit voor een groot deel silent data corruption kan voorkomen (https://louwrentius.com/w...lent-data-corruption.html), maar meer info kan ik ook niet vinden hoe RAID-controllers hier mee om gaan. Bovendien is het ook nog maar de vraag of iedere vendor eenzelfde foutafhandeling heeft geimplementeerd. Voor wat betreft de QNAP kan ik daar ook 0,0 informatie over vinden.

[Borromini]

Btrfs komt niet in de buurt van ZFS. Het idee is hetzelfde, maar bij Sun waren ze ZFS al aan het ontwikkelen toen btrfs nog niet eens bedacht was.

[ Voor 60% gewijzigd door Borromini op 12-07-2020 21:44 ]

[CurlyMo]

Borromini schreef op zondag 12 juli 2020 @ 18:00:
@unezra Spreekt dat wat CurlyMo zegt niet tegen? ALs je maar één versie hebt van het bestand, dus geen kopieën?


[...]

Dan valt er vanaf een enkele schijf niks te herstellen als er echt bitrot is en geen andere reden voor de waargenomen fouten, zoals kabels, rot geheugen e.d.

In ZFS kan je wel copies=X instellen waarbij je aangeeft hoeveel kopieën er van je data worden gemaakt, dan is er wel herstel mogelijk bij een enkele schijf.

[Ben(V)]

Volgens mij is de enige echte protectie een goede backup met een zorgvuldig backup schema.
Zonder zo'n schema loop je de kans de bitrot in je backup te vinden.

[Q]

JeroenTheStig schreef op zondag 12 juli 2020 @ 19:57:
[...]

Ik heb juist voor een kant-en-klare optie gekozen omdat ik geen zin heb om met allerlei randzaken bezig te zijn. Ik het verleden vaker mijn vingers aan gebrand met zelfbouw-spulletjes, en bovendien heb ik daar nu ook geen tijd voor (over). Wat mij betreft is freeNAS daarom geen optie voor mij.

Al met al lijkt de conclusie dus te zijn dat bit rot alleen gedetecteerd kan worden met een daarvoor geschikt filesystem. Dan vraag ik mij af waarom QNAP dan allerlei oplossingen op de markt zet die dat dus eigenlijk niet kunnen. Zie ik een probleem die er in de praktijk niet is?

Verder, heeft Synology betere oplossingen om bitrot tegen te gaan? Is Btrfs een goed alternatief voor zfs?

Waar ik vooral naar op zoek ben is puur detectie dat er iets niet in de haak is. Dat het vervolgens hersteld kan worden vind ik minder interessant, daar kan ik op dat moment het origineel of de offsite backup voor inschakelen. Helaas kan de QNAP niet periodiek gescheduled een file system check uitvoeren. Die moet ik expliciet uitvoeren of schedulen. Dat kan dus niet maandelijks geautomatiseerd uitgevoerd worden.

Als laatst vraag ik mij nog steeds af hoe en of de ECC check die in de HDD's is ingebouwd kan bijdragen in dit verhaal. Met mijn boerenverstand zou ik zeggen dat het mogelijk moet zijn om in een RAID-1 configuratie i.c.m. de HDD ECC check te voorkomen dat ik corrupte data krijg wanneer ik die inlees (even los van fouten op bus/memory-niveau). Immers, als een block, die gemirrord is, ingelezen wordt van disk1, en daarbij treedt een ECC failure op op HDD-niveau, dan zou je zeggen dat de RAID-controller vervolgens diezelfde block van disk2 op zou kunnen halen. Tuurlijk kan op disk2 heel toevallig diezelfde block ook corrupt zijn, maar die kans lijkt mij extreem klein dat ik daar geen rekening mee wil houden. Foutherstelling zou de HDD dan uitvoeren d.m.v. sector reallocation of iets dergelijks.

Ik heb wel een blog gevonden waar e.e.a. wordt uitgelegd over ECC op HDD niveau en dat dit voor een groot deel silent data corruption kan voorkomen (https://louwrentius.com/w...lent-data-corruption.html), maar meer info kan ik ook niet vinden hoe RAID-controllers hier mee om gaan. Bovendien is het ook nog maar de vraag of iedere vendor eenzelfde foutafhandeling heeft geimplementeerd. Voor wat betreft de QNAP kan ik daar ook 0,0 informatie over vinden.

Ik denk dat thuisgebruikers zich niet druk hoeven te maken over het risico van silent data corruptie. Dat is misschien niet altijd een populaire visie bij mensen, maar ik denk dat dit wel het eerlijke antwoord is.

Je eigen intuïtie is hier denk ik juist. Als silent data corruptie zo'n issue is: waarom zijn de consumenten Synologies en QNAPs nog een ding dan? Waarschijnlijk omdat het risico niet zo groot is.

Zie hier ook een blogpost over dit onderwerp (mening):

https://louwrentius.com/w...lent-data-corruption.html

Edit: ik had je post niet helemaal gelezen, je had 'm dus al gevonden

RAID (software of hardware maakt niet uit) zal niet of nooit om kunnen gaan met silent data corruption dat wordt aangeleverd door een harde schijf. Dat is hierboven door mensen al uitgelegd. ZFS is de enige optie beschikbaar voor consumenten die wel bescherming biedt tegen silent data corruption. Maar dat heeft ook zo zijn prijs.

Voor wat HDDs betreft en hun interne ECC: een harde schijf levert ofwel de data die juist is, of geeft een lees-error. Als een schijf een lees-error geeft, zal een RAID controller de data van een andere schijf lezen of reconstrueren via parity.

Als een harde schrijf intern geen issues ziet en de ECC ziet geen problemen, dan wordt de data gewoon verstuurd naar de controller. De kans dat je ondanks al die lagen en vormen van ECC een silent data corruption bitje binnen krijgt: alleen een issue op datacenter-scale. Als thuisgebruiker ben je dan gewoon fucked. Je hebt een rot bestand en dat rotte bestand komt in je backup terecht. Hoe erg is 1 rotte foto?

Als jij je toch echt zorgen maakt om silent data corruption, ook al is die kans klein, dan zul je echt aan de zelfbouw moeten en voor ZFS + ECC geheugen moeten gaan. Maar zelfbouw is denk ik misschien voor sommige mensen gevaarlijker (een groter risico voor hun data) dan silent data corruption ooit zou kunnen zijn.

Het alternatief is om met bijvoorbeeld tripwire of een equivalent zelf checksums van files bij te gaan houden in een lijstje (geautomatiseerd) en die periodiek te controleren. Hoe ver wil je gaan?

[ Voor 15% gewijzigd door Q op 13-07-2020 01:58 ]

[unezra]

JeroenTheStig schreef op zondag 12 juli 2020 @ 19:57:
[...]
Ik heb juist voor een kant-en-klare optie gekozen omdat ik geen zin heb om met allerlei randzaken bezig te zijn. Ik het verleden vaker mijn vingers aan gebrand met zelfbouw-spulletjes, en bovendien heb ik daar nu ook geen tijd voor (over). Wat mij betreft is freeNAS daarom geen optie voor mij.

IX-Systems verkoopt ook kant- en klare NASsen met FreeNAS...
https://www.freenas.org/for-business/

Qua zelfbouw, je kunt het gewoon op een kant- en klare server installeren. De installatie is niet het ingewikkelde deel. Da's de inrichting en die heb je met QNAP of iets anders net zo goed.

Al met al lijkt de conclusie dus te zijn dat bit rot alleen gedetecteerd kan worden met een daarvoor geschikt filesystem. Dan vraag ik mij af waarom QNAP dan allerlei oplossingen op de markt zet die dat dus eigenlijk niet kunnen. Zie ik een probleem die er in de praktijk niet is?

Verder, heeft Synology betere oplossingen om bitrot tegen te gaan? Is Btrfs een goed alternatief voor zfs?

Waar ik vooral naar op zoek ben is puur detectie dat er iets niet in de haak is. Dat het vervolgens hersteld kan worden vind ik minder interessant, daar kan ik op dat moment het origineel of de offsite backup voor inschakelen. Helaas kan de QNAP niet periodiek gescheduled een file system check uitvoeren. Die moet ik expliciet uitvoeren of schedulen. Dat kan dus niet maandelijks geautomatiseerd uitgevoerd worden.

Die snap ik niet.
Waarom zou je je beperken tot detectie, als er ook systemen zijn die het voorkomen?

[JeroenTheStig]

unezra schreef op maandag 13 juli 2020 @ 07:12:
[...]

Die snap ik niet.
Waarom zou je je beperken tot detectie, als er ook systemen zijn die het voorkomen?

Omdat 'silent data corruption' pas aan het licht komt op het moment dat je de data leest. Dus als ik bijvoorbeeld moet terugvallen op mijn backup (waar ik mijn nas voor ga inzetten) als mijn laptop de geest heeft gegeven. Op dat moment wil ik niet tegen silent data corruption aanlopen, wat mogelijk al tijden aanwezig is. Als ik dat al op voorhand kan detecteren, dan kan me dat een hoop ellende besparen, door mijn backup te herstellen op basis van het origineel of offside backup.

[ Voor 5% gewijzigd door JeroenTheStig op 13-07-2020 07:22 ]

[MainframeX]

Als je er geen gedoe van wilt zou je de foto's op een clouddienst van een paar euro per maand zetten.

[Q]

JeroenTheStig schreef op zondag 12 juli 2020 @ 09:06:
1. In welke mate beschermt deze QNAP mij tegen bit rot, of is deze bescherming uberhaupt niet aanwezig?

De QNAP kan niet tegen bitrot beschermen. Alleen de duurdere modellen hebben ECC geheugen, dat tegen bitrot via 'rot' geheugen beschermt, het enige component in een reguliere computer dat niet door allerlei ECC-achtige constructies wordt beschermd.

2. HDD's hebben ECC aan boord. In welke mate kan ik hierop vertrouwen in een RAID-1 config? Bijv., als bij het lezen van een bestand een ECC failure optreedt in één van de schijven, valt de RAID-1 controller in dat geval terug op de andere schijf?

Als een HDD dus een ECC failure detecteert geeft deze een read-error. Dit is GEEN silent data corruptie. De RAID oplossing (maakt niet uit welke) kan hier prima mee overweg.

3. Moet ik mij uberhaupt zorgen maken over bit rot in een huis/tuin/keuken opstelling?

Ik denk dat dit niet hoeft. Het is een leuke extra, maar niet essentieel.

De kans dat een HDD silent corrupte data terugstuurt is zeer zeer klein.

Ik denk zelf ook dat het risico op silent data corruptie eerder zit in het risico van non-ECC geheugen dan dat de schijven 'rotte' data terugspuwen.

Als ik dus mij zo'n zorgen zou maken over silent data corruptie, dan zou dat stap 1 zijn.

Het is mijn stokpaardje dat ik liever met ECC geheugen en zonder ZFS draai dan zonder ECC geheugen maar met ZFS. Mijn mening is dat ZFS zonder ECC geheugen gewoon vreemd is: alsof je de achterdeur opslot doet maar de voordeur open laat staan.

https://louwrentius.com/please-use-zfs-with-ecc-memory.html

MainframeX schreef op maandag 13 juli 2020 @ 07:58:
Als je er geen gedoe van wilt zou je de foto's op een clouddienst van een paar euro per maand zetten.

Dat biedt geen bescherming tegen het risico dat bitrot in een bestand doorsijpelt in je backups.

---

Ben je commercieel bezig of particulier? Betekent commercieel misschien dat je bereid bent om ook wat pegels te investeren in dit risico? Hoe erg is (de hele kleine kans) op een rotte foto voor jou?

En zijn er niet grotere risico's waar jij je misschien beter druk over kunt maken (mocht je die niet afgedicht hebben) zoals externe backup (buitenshuis tegen brand/diefstal e.d.). Is dat misschien interessanter qua investering?

[ Voor 45% gewijzigd door Q op 13-07-2020 09:31 ]

[rikadoo]

Eind dit jaar komt er ook een OS van qnap uit, Qnap Hero deze heeft ondersteuning voor ZFS, wellicht kan je daar ook nog naar kijken. Deze versie komt naar een bepaald aantal NAS modellen uit hun lijn.

oa deze:

TS-x53B/Be/BT3/BU (4-8GB Upgrade needed)
TS-x77X
TVS-x82
TVS-x82T3
TVS-x72XT
TVS-x72N
TS-x83XU
TVS-x71
TVS-x71T
TS-x85

[MainframeX]

Q schreef op maandag 13 juli 2020 @ 09:19:

Dat biedt geen bescherming tegen het risico dat bitrot in een bestand doorsijpelt in je backups.

Dat is niet wat ik bedoel. Hij kan z'n foto data bijvoorbeeld op Google photo's, icloud, flickr etc zetten. Die slaan dat vast wel redundante hardware op met ecc geheugen.

Omdat hij eerder in het topic aangaf eigenlijk geen gedoe en uitzoeken wilde hebben leek me dat wel een goed idee.

[JeroenTheStig]

Mooi dat er nog steeds gereageerd wordt. Bedankt daarvoor! Ik ben ondertussen nog steeds veel blogposts en informatie her en der op internet aan het lezen om meer te begrijpen over de werking van raid, scrubbing, bit rot, etc.

Mijzelf schreef op zondag 12 juli 2020 @ 12:53:
[...]

Hoe dan? Bij mijn weten is de parity bij raid5 een XOR van de data blokken op de andere schijven. Als er een bitje omvalt zie je dat de XOR niet meer klopt, maar je kunt onmogelijk zien welk bitje is omgevallen, die op een van de data blokken of die op het parity blok.

@JeroenTheStig Heb je een linkje waar dat beschermingsmechanisme wordt beschreven? Bij mijn weten kun je bitrot alleen waarnemen/voorkomen op systemen met een geschikt filesysteem (ZFS of BTRFS) in combinatie met redundantie in de opslag.
Om het alleen waar te nemen volstaat het om een hash van al je bestanden bij te houden, en regelmatig te controleren.

Ik denk dat ik inmiddels begrijp waarom QNAP alleen raid scrubbing uitvoert op RAID5 en RAID6 configuraties. De belangrijkste informatie hierover heb ik hier gevonden:

Drawback of raid5: https://forum.qnap.com/viewtopic.php?f=45&t=140758
Scrubbing mismatch repair: https://unix.stackexchang...scrubbing-mismatch-repair

Wat ik uit de eerste link haal, is dat wanneer in een raid5 cluster een block wordt weggeschreven, dat de parity block niet wordt herberekend op basis van de volledige stripe, maar enkel op basis van de oude informatie uit de block die overschreven gaat worden, de nieuwe informatie die weggeschreven gaat worden en de huidige parity block. Dus bij een RAID5 cluster van 4 schijven, wordt het volgende gedaan:
Parity(new) = BlockX(old) ^ BlockX(new) ^ Parity(old).
Aangezien het schrijven van de nieuwe block en de parity block niet in één 'transactie' verloopt, kan vanwege een stroomstoring, crash of andere fout de schrijfactie naar de data block succesvol zijn, maar die van de parity block mislukken. Vanaf dat moment is de parity block dus invalid. Bij verdere lees- of schrijfacties op deze stripe blijft dit onopgemerkt, omdat dan geen validatie plaatsvindt. De scrubbing zorgt er echter voor om parity fouten te herstellen (zie de tweede link): Wanneer een invalid parity block wordt gevonden, dan wordt deze opnieuw berekend op basis van de datablocks in de stripe en wordt vervolgens weggeschreven in de parity block

Kortom, de scrubbing is voor zover ik begrijp bedoeld puur om parity block fouten te herstellen, maar niet om bit rot te detecteren of herstellen. En aangezien RAID1 geen parity heeft, is het daar dus niet nodig om te scrubben.


Op dit moment neig ik naar het behoud van mijn 2-bay nas, waarbij ik het risico op bit rot voor lief neem. Die kans lijkt mij zeer klein. Waar ik nog wel naar op zoek ben is een scheduled disk scan om tijdig unrecoverable read errors op te sporen, voordat ik mijn backup daadwerkelijk nodig heb. Die zou ik dan tijdig kunnen herstellen.
<edit>
Inmiddels gevonden om maandelijks een complete test uit te voeren. Ik denk dat ik er dan ben

[JeroenTheStig]

Q schreef op maandag 13 juli 2020 @ 09:19:
[...]


Ben je commercieel bezig of particulier? Betekent commercieel misschien dat je bereid bent om ook wat pegels te investeren in dit risico? Hoe erg is (de hele kleine kans) op een rotte foto voor jou?

En zijn er niet grotere risico's waar jij je misschien beter druk over kunt maken (mocht je die niet afgedicht hebben) zoals externe backup (buitenshuis tegen brand/diefstal e.d.). Is dat misschien interessanter qua investering?

Het is puur particulier. Dus in mijn geval backup van foto's, video's en documenten. De investering die ik nu heb gedaan is wat mij betreft meer dan genoeg voor deze use case.
Qua backup heb ik het volgens mij redelijk voor elkaar: Ik heb de data hier binnenshuis gebackupped, maar ook offsite in een idrive account. Maar er valt zeker het nodige te verbeteren.

In ieder geval allemaal bedankt voor de hulp, ik heb weer veel bijgeleerd en mijn conclusie is dat de installatie zoals die nu staat voldoende veilig is voor wat ik nodig heb.