''basishandvatten'' over schijven beoordelen

[dennis_rsb]

Ik dacht, ik post het maar niet in het grote SMART-topic, ik denk dat hier een los topic beter op zijn plaats is.

Laat ik vooropstellen dat ik op meerdere externe harde schijven backups maak. (nja copy/pasten via verkenner) Verder controleer ik regelmatig met crystaldiskinfo de SMART status.

Ik schets hieronder een scenario zoals ik denk dat het zit. Dit op basis van ervaringen, van het smart-topic, van tomshardware, van reddit, etc, ect.

Bij reallocated sectors is je data nog compleet veilig omdat de bad sectors (current pending) zijn omgewisseld met reservesectoren. Ondanks dat bij reallocated sectors je data nog veilig is, controleer regelmatig of de reallocated sectors niet blijft oplopen. Anders zit je door de reservesectoren heen en is je hdd dood (als ie door de spare sectors heenzit, krijg je dan ook current pending sectors?) Hoeveel reserve sectoren heeft een gemiddelde hdd? Ik lees soms het getal 50 (raw value)

Bij current pending sectors is er een groot probleem. Zelfs al heb je maar 1 current pending sectors, hij zou maar net op een deel van je data zitten. Dan heb je dataverlies of datacorruptie. Je kan bij current pending sectors eventueel afwachten of hij hem onschadelijk maakt (reallocated sector) maar wil je dat risico lopen? Je kan de hdd ook slow formatten en kijken of de current pending sector weer 0 is, maar het risico dat het later gaat oplopen heb je. Ik neig dus bij current pending sectors om meteen de hele hdd te vervangen.

Backups maken kan nog veilig zolang het reallocated sectors zijn. Ga je een backup maken als je current pending sector(s) hebt, dan heb je risico dat je corrupte data (op de pending sectors) meekopieert.

Klopt dit beeld hoe ik het schets? Ik vraag dit niet alleen voor mezelf, maar ik wil ook duidelijke instructies kunnen geven als mijn broer iets heeft met zijn schijven. Ik heb hem ingeseind dat als hij reallocated sectors (raw) en/of current pending sectors (raw) ziet dat hij mij moet waarschuwen. Ik en mijn broer hebben een ssd als bootschijf (hij een 120 gb ssd, ik een 1 tb) en een data hdd (ik een 4 tb hdd, hij een 1 tb hdd) Dus de ssd is minder belangrijk, zolang de max tbw niet overschreven is beschouw ik een ssd nog als goed (klopt dit?)

Ik hoop dat het een beetje duidelijk omschreven is. Ik vind het moeilijk om het gestructureerd uit te leggen. Maar ik heb mijn best gedaan. p.s. ik hoef geen discussies over backups maken, dat weet ik allemaal wel dat dat goed is (en dat doe ik dus ook) maar het gaat mij puur om kritische smart waardes beoordelen. En uiteraard hou ik ook in gedachten dat een schijf ook pats boem kan stoppen zonder voortekenen. En daarnaast check je ook niet dagelijks je smart.

[Cpt.Morgan]

dennis_rsb schreef op dinsdag 4 januari 2022 @ 22:01:
Backups maken kan nog veilig zolang het reallocated sectors zijn. Ga je een backup maken als je current pending sector(s) hebt, dan heb je risico dat je corrupte data (op de pending sectors) meekopieert.

Klopt dit beeld hoe ik het schets?

Om deze maar vast in te koppen. Nee. Een backup maak je continue, of met duidelijke regelmaat, zodat die klaarligt om te gebruiken als er iets misgaat met een schijf / data. Op het moment dat je dat gaat kopiëren omdat er een probleem is, dan is het data recovery geworden, geen backup.

Maar, ik snap wel wat je bedoelt en je hebt in principe gelijk voor wat betreft hoe een schijf werkt. Het realloceren van sectoren behoort (tot op zekere hoogte) bij het normaal functioneren van een schijf. En als dat niet meer goed gaat, of het er heel veel worden, dan is dat een sterk signaal dat de schijf op overlijden staat.

[ Voor 29% gewijzigd door Cpt.Morgan op 04-01-2022 22:50 ]

[dennis_rsb]

@Cpt.Morgan Ik maak vaak backups (met name als ik flink wat bestanden heb gewijzigd en/of bijgeplaats) Maar ik weet dat mijn ene broer er wat lakser mee is. Maar om het even bij de feiten te houden, als je reallocated sectors hebt (dus bad sectors die al onschadelijk gemaakt zijn) dan kun je toch nog prima een backup maken omdat alle bestanden nog ´heel´ zijn? Als je current pending sectors hebt, dan nog een bakcup maken is een risico denk ik, omdat je dan mogelijk corrupte/missende bestanden MEEkopieert (dus de fouten/missende files ook meekopieert.)

[Ben(V)]

Als een disk constateert dat bepaalde sectoren onbetrouwbaar zijn geworden zullen die bij de current pending sector count opgeteld worden.
De disk gaat dan proberen deze sectoren te lezen, op reserve sectoren weg te schrijven en dan de desbetreffende sector te deactiveren, ook wordt de sector reallocation counter opgehoogd en de current pending sector weer verlaagt.
Normaal gesproken niets aan de hand.

Maar als die current pending sector count niet terug loopt, dan kan de disk die sector niet meer lezen en dus ook niet realloceren en ben je per definitie data kwijt.
Als dat een video file is, zie je misschien een hikup, maar verder heb je daar geen last van, is het echter een database dan heb je een corrupte database gekregen.

Dus het oplopen van de reallocation count is een waarschuwing dat er dingen mis dreigen te gaan, maar de disk het nog kan fixen.
Als de pending sector count blijft staan, dan is de disk al corrupt.

[ Voor 11% gewijzigd door Ben(V) op 05-01-2022 17:28 ]

[Renault]

Ah, eindelijk iemand die zich dat óók afvraagt!

Mijn ervaring is als volgt:
- een backup maak je voor het geval je problemen krijgt met de data op de disk, dus altijd vóórdat de SMART data gaan afwijken. Een backup alsnog gaan maken terwijl je al problemen hebt is (alhoewel mogelijk behoorlijk effectief) not done.
- een disk functioneert prima.
Maar zodra de pariteit van uitgelezen data niet klopt, wordt die sector voorlopig direct gemarkeerd als "Pending sector".
- Daarop start de firmware op de disk automatisch een serie uitleespogingen (honderden?) op de gemarkeerde sector met steeds een iets anders gepositioneerde kop, totdat het max aantal geprogrammeerde pogingen is bereikt.
- is de uitgelezen data op die sector daarna consistent bevonden dan wordt die data in veiligheid gebracht op een andere sector op de disk. Daarna wordt de als Pending gemarkeerde sector uitgetest met lees/schrijfpogingen. Als dat leidt tot consistent als goed bevonden resultaten verdwijnt de markering "Pending" op die sector, zonder oplopen van het aantal Reallocated sectoren. Als de sector als defect wordt beoordeeld wordt de sector gemarkeerd als onbruikbaar en wordt de disk aangevuld met één daarvoor gereserveerde reservesectoren. Op dat moment loopt het aantal "Reallocated sectoren" met 1 opgehoogd.
Een disk zonder Pending sectoren en met diverse Reallocated sectoren is (zolang het er niet teveel zijn) in mijn optiek nog steeds betrouwbaar, zolang die geen deel uitmaakt van een RAIDset hoger dan 1 (zie onderstaand).

Volgens mij is dit een andere interpretatie dan TS geeft.
Het verschil:
- een Pending sector is wel een zorgwekkend signaal, maar niet erg zolang het uitlezen en beoordelen van de als Pending gemarkeerde sector nog loopt. Zolang de harddisk stroom heeft, zal dit uitlezen en beoordelen voortschrijden op momenten dat de disk niet met iets anders wordt belast. Zolang is de data op de als Pending gemarkeerde sector ontoegankelijk.
- na enige tijd vermindert het aantal als "Pending" gemarkeerde sectoren met als resultaat wel of niet Reallocated sectoren. Mijn interpretatie is dat afhankelijk van het uitleesresultaat de data op de voorheen als "Pending" gemarkeerde sector wel of niet verloren is gegaan zonder dat dat in de SMART-data tot uiting komt.
"Je weet dus niet wat je mist".
- zodra het aantal "Pending sectoren" op 0 staat, is de disk op dat moment stabiel.
Elders op de disk kunnen dan nog steeds andere sectoren slecht zijn, wat nog niet werd opgemerkt omdat die sectoren (dus de data erop) nog niet is geraadpleegd sinds het achteruitgaan van de sector. Dit is m.i. ook de oorzaak van het vaak mislukken van rebuilden van data in een RAID hoger dan 1 (als 1 disk uit de set vliegt), omdat bij het reconstrueren van alle data alle sectoren op de overgebleven disks in de RAID volledig goed moeten zijn. Bij de eerste de beste als "Pending" beoordeelde sector is dan al je data in de RAIDset weg omdat de rebuild dan afbreekt. Daarom moet je bij een RAID0 en RAID hoger dan 1 óók altijd een zo volledig mogelijke offline databackup hebben.

Ik hoor graag waar mijn redenatie fout gaat, omdat hij afwijkt van wat hierboven staat.

[dennis_rsb]

@Ben(V) Maar jij bevestigd mijn verhaal toch dan als ik het goed lees? Bij reallocated sectors is de schijf nog prima bruikbaar, en is je data veilig én kan je zelfs nog een bruikbare backup maken. Wel is het zaak om in de gaten te houden of reallocated sectors niet steeds verder oploopt, als dat wel is, dan is het vaak wachten op het moment dat de schijf er mee op houdt en/of current pending sectors krijgt.

Bij current pendings sectors kun je het beste schijf niet meer gebruiken voor belangrijke bestanden. Je kan eventueel de schijf low level wipen en kijken of de current pending sectors weg zijn (én blijven). Ook kun je wachten totdat de current pending sectors zijn omgewisseld met reallocated sectors (maar zoals je al zei, als dat niet gebeurd, dan heb je alsnog een probleem en is je data niet veilig)

@Renault In principe kun je zover ik weet wel wachten als je current pending sectors hebt, kijken of ze na een poosje worden ingewisseld voor reallocated sectors. Als dat inderdaad gebeurd dan is het prima. Maar als ze niet worden ingewisseld en de current pending sectors blijven, dan is je data niet safe.

Tenzij iemand aanpassingen heeft houd ik het volgende aan:

-Bij reallocated sectors is je data safe (maar houd in de gaten of het reallocated cijfer niet steeds verder oploopt, dan is meestal wachten tot de schijf naar eeuwige jachtvelden gaat)

-Bij current pending sectors (als het er niet zoveel zijn) hoef je niks te doen, je kan wachten of ze ´verdwijnen´ en dus ingeruild worden voor reallocated sectors. Mocht dit niet gebeuren, dan kun je de schijf beter weggooien. (of low level formatten en dan nog eens kijken hoe het gaat)

-Ondanks dat je altijd je backups op orde moet hebben kun je nog steeds een backup maken als je reallocated sectors hebt. Maar je moet geen backups maken als je current pending sectors hebt, omdat je dan mogelijk de fouten meekopieert.

[Ben(V)]

Als de pending sector count naar nul terugloopt ben je geen data kwijtgeraakt.

Maar als je ziet dat je reallocated count niet op nul staat is dat een teken dat je disk achteruit gaat.
Hij kon het nog fixen door te re-alloceren, maar dat is meestal wel een teken aan de wand.

Als je pending sectors ziet staan ben je te laat, tenzij die weer verdwijnen.

[dennis_rsb]

@Ben(V) Dat bedoel ik ook. alleen dat over die reallocated sectors niet per definitie. Ik heb schijven gezien waar ze jarenlang stabiel bleven (én zonder current pendings) maar ik heb ook schijven gezien waar de reallocated bleef oplopen tot ie door zijn reserve sectors heen zat en dan is het einde verhaal met de schijf.

[Ben(V)]

Uiteraard is dat mogelijk, maar het is ook een risico.
Alles is afhankelijk hoe belangrijk je data voor je is.

[dennis_rsb]

@Ben(V) De data is voor mij belangrijk ja. Het is ook geen probleem van nu, maar het gaat om een situatie die een keer bij mij of bij mijn broers voor kan komen.

Maar we hebben net toch al besproken dat je data veilig is zolang het reallocated sectors zijn? Ik bedoel ze de bad sectors zijn dan al onschadelijk gemaakt. Bij current pending sectors (actieve bad sectors) vertrouwen op je data (als ze niet worden gewisseld door reallocated) is een ander verhaal.

Uiteraard is het wel zo dat je in de gaten moet houden of de reallocated sectors niet blijven oplopen, want als dat is, dan zit hij binnen de kortste keren door zijn reservesectoren heen. En als dat gebeurd krijg je fysieke current pending sectors en/of de schijf stopt met functioneren. Maar zolang het reallocated sectors zijn is de data veilig, maar backups maken is dan extra van belang.

Het kan zijn dat we langs elkaar heen praten, maar volgens mij begrijpen we elkaar

[Ben(V)]

Klopt en het is allemaal statistiek.
Maar voor mij is het verschijnen van reallocated sectoren voldoende om de disk te vervangen.

[dennis_rsb]

@Ben(V) Snap ik, dan hoef je ook niet heel de tijd te "monitoren" of de reallocated sectors blijven oplopen (tot zn spare sectors op zijn)

[ Voor 12% gewijzigd door dennis_rsb op 05-01-2022 21:41 ]

[sdk1985]

Data integriteit is niet beperkt tot het al dan niet vaststellen van SMART data. Ben je daar in geïnteresseerd dan zou ik eerder eens kijken naar data integrity checks. Oplossingen zoals snapraid kun je bovenop bestaande data draaien. Valt er een bitje om dan kun je dit opmerken en afhankelijk van de hoeveelheid parity oplossen.

[dennis_rsb]

@sdk1985 Dat snap ik, maar de kans op dataverlies en datacorruptie is wel groot als je current pending sectors hebt.

Waar jij op doelt is bitrot en dergelijke. Voor de eenvoud gebruik ik externe schijven als backups, via copy/paste. Heerlijk simpel, niet afhankelijk van backupsoftware. Natuurlijk kun je een NAS kopen en dan RAID 1 draaien. Dan is de kans op fouten al klein vóórdat je backupt naar de cloud of naar ext hdd’s.

Echter heb ik, en eigenlijk ook niemand die ik ken, ooit last gehad van bitrot. Sowieso is ntfs al een stuk robuuster dan vroeger met fat16 en dergelijke.

Maar mij gaat het in dit topic echt om de SMART, zoals ik uitlegde. Over backups heb ik geen vragen, dan had ik wel een ander topic geopend

[sdk1985]

dennis_rsb schreef op donderdag 6 januari 2022 @ 14:37:
@sdk1985 Dat snap ik, maar de kans op dataverlies en datacorruptie is wel groot als je current pending sectors hebt.

Waar jij op doelt is bitrot en dergelijke. Voor de eenvoud gebruik ik externe schijven als backups, via copy/paste. Heerlijk simpel, niet afhankelijk van backupsoftware. Natuurlijk kun je een NAS kopen en dan RAID 1 draaien. Dan is de kans op fouten al klein vóórdat je backupt naar de cloud of naar ext hdd’s.

Echter heb ik, en eigenlijk ook niemand die ik ken, ooit last gehad van bitrot. Sowieso is ntfs al een stuk robuuster dan vroeger met fat16 en dergelijke.

Maar mij gaat het in dit topic echt om de SMART, zoals ik uitlegde. Over backups heb ik geen vragen, dan had ik wel een ander topic geopend

Juist tijdens copy operaties valt er weleens een bitje om. De twee keer dat ik de afgelopen 5 jaar 'bitrot' heb vastgesteld via een parity jaar was twee keer bij het verplaatsen van circa 1 TB aan data van disk A naar B. Hier merk je zelf overigens niks van. Als er in één bestand één bitje fout staat dan krijg je daar vanuit Windows geen melding van.

[ Voor 7% gewijzigd door sdk1985 op 06-01-2022 14:45 ]

[dennis_rsb]

@sdk1985 Ik snap dat je daar zonder parity checks geen melding van krijgt, maar je merkt het wel bij het openene van bestanden. Dan opent je bestand niet meer, of je mp3tje krijg ruis, je foto is lelijk etc.

Natuurlijk is parity via RAID1 of via ZFS beter, alleen vrijwel geen enkele consument doet dit. De meeste problemen komen als mensen überhaupt de data maar op 1 plek hebben. En dan is het een kwestie van tijd tot er iets gebeurd en je data weg is.

edit; heb voor de lol eens gekeken op de site naar snapraid, klinkt vrij ingewikkeld. Ook volledig command line, daar hou ik ook niet zo van. Ik gebruik de terminal wel eens in Linux, maar command line only vind ik verschrikkelijk.

[ Voor 20% gewijzigd door dennis_rsb op 06-01-2022 14:59 ]

[sdk1985]

dennis_rsb schreef op donderdag 6 januari 2022 @ 14:49:
@sdk1985 Ik snap dat je daar zonder parity checks geen melding van krijgt, maar je merkt het wel bij het openene van bestanden. Dan opent je bestand niet meer, of je mp3tje krijg ruis, je foto is lelijk etc.

Maar daar zit dus het gevaar. Jij hebt je 'backup' gemaakt vervolgens valt je primaire schijf uit. Daarna ga je op je externe harde schijf opent het bestand dat je nodig hebt en dan pas blijkt dat hij beschadigd is. Daarom wil je zo nu en dan een hash check op je (backup) data draaien.

dennis_rsb schreef op donderdag 6 januari 2022 @ 14:49:
@sdk1985
Natuurlijk is parity via RAID1 of via ZFS beter, alleen vrijwel geen enkele consument doet dit. De meeste problemen komen als mensen überhaupt de data maar op 1 plek hebben. En dan is het een kwestie van tijd tot er iets gebeurd en je data weg is.

Maar dat is niet de insteek van je topic. In de ts vraag je je af of je logica klopt. Die logica klopt dus niet want je richt je heel specifiek op één risico, de verloren sector, terwijl met de huidige bestand groottes het risico op bitrot vele malen groter is. Zie https://www.zdnet.com/art...-5-stops-working-in-2009/ . Het advies om met regelmaat bestanden te kopiëren maakt dit op systemen zonder ECC eigenlijk vanuit die invalshoek alleen maar erger. Niet dat ik daarmee dan adviseer om helemaal geen backups te maken dat is ook niet het punt .

Heb nog wel een relevant voorbeeld. Ik had met macrium reflect een image gemaakt van een laptop vóór formateren. Op die laptop stond belangrijke bedrijfsinformatie waar verder geen kopie van bestond. De image is gemaakt met Macrium reflect naar een USB 3.1 Icydock met daarin een gloed nieuwe Samsung 860 SSD. Vervolgens blijkt 3 maanden later het image corrupt en krijgt ook de support van Macrium het niet meer aan de praat. Er is letterlijk geen byte data te recoveren uit het image ondanks de 400GB filesize. (Gelukkig had ik ook een image gemaakt via LAN naar mijn NAS die dus bitrot bescherming heeft en waar het image wel uit te lezen was.). De fout hier is het niet verifiëren van de gemaakte backup.

Als je vraagstelling wordt aangepast naar wat zou een gemiddelde consument moeten doen dan ga ik je advies eigenlijk ook niet volgen. Die raad ik een Office 365 dienst aan waar 1000GB Onedrive bij is inbegrepen. Daarin past voor de gemiddelde consument al zijn of haar belangrijke data. Los van dat je data dan fysiek ergens anders is opgeslagen zijn er nog wat andere voordelen. Waaronder dat dit volautomatisch gebeurd en dat je 30 dagen revision history op al je data hebt. Gooi je per ongeluk die excel spreadsheet weg die je nog niet had meegenomen in je normale backups dan heb je alsnog 30 dagen de tijd om hem terug te halen.

[sdk1985]

Ik zie je trouwens ook een opmerking over SSD's maken. Een SSD zonder stroom kan al zijn data verliezen.
Een SSD die je met 30 graden uitschakelt en bij 25 graden bewaard kan zijn data 65 weken bewaren aldus dat onderzoek. Hoe kouder je SSD bij uitschakelen des te sneller hij zijn data verliest. Reken normaal op 1 jaar, dat is wat volgens JEDEC zou moeten lukken. In tegenstelling tot de harde schijf is het geen product dat je jaren als backup in je kast kunt laten liggen.

(Overigens had MLC binnen de TBW vroeger een data retentie van 10 jaar, de vraag is even wat dat nu is voor QLC, helaas lijkt men daar niet heel transparant over te zijn).

[ Voor 14% gewijzigd door sdk1985 op 06-01-2022 15:29 ]

[dennis_rsb]

sdk1985 schreef op donderdag 6 januari 2022 @ 15:18:
[...]

Maar daar zit dus het gevaar. Jij hebt je 'backup' gemaakt vervolgens valt je primaire schijf uit. Daarna ga je op je externe harde schijf opent het bestand dat je nodig hebt en dan pas blijkt dat hij beschadigd is. Daarom wil je zo nu en dan een hash check op je (backup) data draaien.

Dat snap ik, maar dat is dus het (zeer kleine) risico wat ik neem. Ik denk echt dat je te veel theoretisch denkt. Er zijn alleen al miljoenen mensen in NL die of géén backup maken óf het via de verkenner doen of via de backupfunctie in Windows.

Hoevaak lees jij dat er datacorruptie is? 99/100 keer lees je dat iemand getroffen is door ransomware, hdd kapot is dat soort dingen.

sdk1985 schreef op donderdag 6 januari 2022 @ 15:18:
Maar dat is niet de insteek van je topic. In de ts vraag je je af of je logica klopt. Die logica klopt dus niet want je richt je heel specifiek op één risico, de verloren sector, terwijl met de huidige bestand groottes het risico op bitrot vele malen groter is. Zie https://www.zdnet.com/art...-5-stops-working-in-2009/ . Het advies om met regelmaat bestanden te kopiëren maakt dit op systemen zonder ECC eigenlijk vanuit die invalshoek alleen maar erger. Niet dat ik daarmee dan adviseer om helemaal geen backups te maken dat is ook niet het punt .

Heb nog wel een relevant voorbeeld. Ik had met macrium reflect een image gemaakt van een laptop vóór formateren. Op die laptop stond belangrijke bedrijfsinformatie waar verder geen kopie van bestond. De image is gemaakt met Macrium reflect naar een USB 3.1 Icydock met daarin een gloed nieuwe Samsung 860 SSD. Vervolgens blijkt 3 maanden later het image corrupt en krijgt ook de support van Macrium het niet meer aan de praat. Er is letterlijk geen byte data te recoveren uit het image ondanks de 400GB filesize. (Gelukkig had ik ook een image gemaakt via LAN naar mijn NAS die dus bitrot bescherming heeft en waar het image wel uit te lezen was.). De fout hier is het niet verifiëren van de gemaakte backup.

Als je vraagstelling wordt aangepast naar wat zou een gemiddelde consument moeten doen dan ga ik je advies eigenlijk ook niet volgen. Die raad ik een Office 365 dienst aan waar 1000GB Onedrive bij is inbegrepen. Daarin past voor de gemiddelde consument al zijn of haar belangrijke data. Los van dat je data dan fysiek ergens anders is opgeslagen zijn er nog wat andere voordelen. Waaronder dat dit volautomatisch gebeurd en dat je 30 dagen revision history op al je data hebt. Gooi je per ongeluk die excel spreadsheet weg die je nog niet had meegenomen in je normale backups dan heb je alsnog 30 dagen de tijd om hem terug te halen.

Maar als jij consumenten 1 TB onedrive aanraad, dan heb je nog steeds geen offsite backup. Ik gebruik overigens zelf LibreOffice. Maar goed, ik vind het niet erg om een optie te onderzoeken hoe je bitrot en dergelijke kan detecteren. Makkelijkste lijkt me dan een willekeurige RAID 1 configuratie (op bv een NAS) en vanuit daar kun je nog offsite een backup maken naar externe schijven. Maar ja nogmaals, ik heb niet de indruk dat bitrot nou echt zo heel vaak voorkomt met NTFS.

sdk1985 schreef op donderdag 6 januari 2022 @ 15:24:
Ik zie je trouwens ook een opmerking over SSD's maken. Een SSD zonder stroom kan al zijn data verliezen. [Afbeelding]
Een SSD die je met 30 graden uitschakelt en bij 25 graden bewaard kan zijn data 65 weken bewaren aldus dat onderzoek. Hoe kouder je SSD bij uitschakelen des te sneller hij zijn data verliest. Reken normaal op 1 jaar, dat is wat volgens JEDEC zou moeten lukken. In tegenstelling tot de harde schijf is het geen product dat je jaren als backup in je kast kunt laten liggen.

Klopt, ik had het vooral over de wanneer een SSD ''op'' is. Sommige mensen kijken bij ssd's naar reallocated sectors en current pending sectors. Maar dat is geen goede indicatie, omdat hdd's anders werken dan ssd's . Max TBW en max power on hours geven een beter indicatie.

Waar jij op doelt dat data wegvloeit bij stilstaande ssd's ben ik van op de hoogte, zelfde geld bij usb sticks. Hoewel ik ook daar niet zo snel iets van gemerkt heb, maar het is hoe dan ook sneller dan bij een hdd. Als je een hdd een paar jaar niet gebruik maakt niet uit, data is magnetisch opgeslagen en dus hoogstwaarschijnlijk zelfs na vele jaren nog leesbaar. ook al heb je hem jaren niet aangekoppeld gehad.

[sdk1985]

dennis_rsb schreef op donderdag 6 januari 2022 @ 15:32:
[...]

Dat snap ik, maar dat is dus het (zeer kleine) risico wat ik neem. Ik denk echt dat je te veel theoretisch denkt. Er zijn alleen al miljoenen mensen in NL die of géén backup maken óf het via de verkenner doen of via de backupfunctie in Windows.

Hoevaak lees jij dat er datacorruptie is? 99/100 keer lees je dat iemand getroffen is door ransomware, hdd kapot is dat soort dingen.

Klopt de impact van echte bitrot is vaak extreem beperkt. Dat gaat dan over 1 file op 3TB aan data. Overigens kun je als consument voor je koude data (lees vakantie foto's) dat relatief eenvoudig oplossen. Als je je data met winrar in een .rar gooit dan kun je een vinkje aanzetten 'add recovery record'. Dan kan hij zichzelf healen.

De impact van een probleem zoals mijn Icydock is natuurlijk wel groot. Dan is alles beschadigd. Daarom blijft mijn advies aan ieder die dit handmatig doet om je backups in ieder geval steekproefsgewijs te controleren.

[...]

Maar als jij consumenten 1 TB onedrive aanraad, dan heb je nog steeds geen offsite backup. Ik gebruik overigens zelf LibreOffice

Waarom is Onedrive geen offsite backup? Je data staat dan toch op een server van Azure? Ik heb zelf mijn volledige data schijf onder Onedrive geplaatst (350K bestanden). Veel veiliger dan een losse hdd/ssd die je in de kast hebt liggen.

Maar goed, ik vind het niet erg om een optie te onderzoeken hoe je bitrot en dergelijke kan detecteren. Makkelijkste lijkt me dan een willekeurige RAID 1 configuratie (op bv een NAS) en vanuit daar kun je nog offsite een backup maken naar externe schijven. Maar ja nogmaals, ik heb niet de indruk dat bitrot nou echt zo heel vaak voorkomt met NTFS.

Makkelijkste is snapraid, daar kun je ook één map mee beschermen. Snapraid maakt een index en slaat die op in een .content bestand. Daarnaast maakt hij een .parity (ongeveer even groot als de hoeveelheid data die je beschermd). Dat kan gewoon op je bestaande nfts partities worden opgeslagen.

Klopt, ik had het vooral over de wanneer een SSD ''op'' is. Sommige mensen kijken bij ssd's naar reallocated sectors en current pending sectors. Maar dat is geen goede indicatie, omdat hdd's anders werken dan ssd's . Max TBW en max power on hours geven een beter indicatie.

Waar jij op doelt dat data wegvloeit bij stilstaande ssd's ben ik van op de hoogte, zelfde geld bij usb sticks. Hoewel ik ook daar niet zo snel iets van gemerkt heb, maar het is hoe dan ook sneller dan bij een hdd. Als je een hdd een paar jaar niet gebruik maakt niet uit, data is magnetisch opgeslagen en dus hoogstwaarschijnlijk zelfs na vele jaren nog leesbaar. ook al heb je hem jaren niet aangekoppeld gehad.

Klopt ik heb nog hdd's van 10 jaar oud liggen waar nog data leesbbaar is. USB is even de vraag, vroeger was alles natuurlijk SLC en MLC en dan had je er niet zo'n last van.

Van reddit (slechte bron I know)

quote: https://www.reddit.com/r/...data_loss_after_extended/

If you look at the major NAND technologies, a good rule-of-thumb for how long they can stay powered-off is probably something like:

SLC: effectively forever
MLC: a few years
TLC: a few months to a year
QLC: a month or so

[dennis_rsb]

sdk1985 schreef op donderdag 6 januari 2022 @ 15:47:
[...]

Klopt de impact van echte bitrot is vaak extreem beperkt. Dat gaat dan over 1 file op 3TB aan data. Overigens kun je als consument voor je koude data (lees vakantie foto's) dat relatief eenvoudig oplossen. Als je je data met winrar in een .rar gooit dan kun je een vinkje aanzetten 'add recovery record'. Dan kan hij zichzelf healen.

De impact van een probleem zoals mijn Icydock is natuurlijk wel groot. Dan is alles beschadigd. Daarom blijft mijn advies aan ieder die dit handmatig doet om je backups in ieder geval steekproefsgewijs te controleren.

Dat van WINRAR ga ik eens proberen, klinkt als een simpel iets wat voor mij easy is, en ook voor minder computeraangelegde mensen (zoals mijn broer) ook prima te doen is.
[...]

Waarom is Onedrive geen offsite backup? Je data staat dan toch op een server van Azure? Ik heb zelf mijn volledige data schijf onder Onedrive geplaatst (350K bestanden). Veel veiliger dan een losse hdd/ssd die je in de kast hebt liggen.

Omdat ransomware dan nog steeds de kans krijgt. En als je automatische sync aanzet met onedrive kun je ook perongeluk je bestanden verwijderen (hoewel onedrive waarschijnlijk wel een recovery functie heeft?) Voor mij voelen meerdere losse afgekoppelde schijven veiliger in elk geval. Heb 3 backup hdd's: 2 heb ik er 2 bij mijn broer liggen, en 1 thuis.
[...]

Makkelijkste is snapraid, daar kun je ook één map mee beschermen. Snapraid maakt een index en slaat die op in een .content bestand. Daarnaast maakt hij een .parity (ongeveer even groot als de hoeveelheid data die je beschermd). Dat kan gewoon op je bestaande nfts partities worden opgeslagen.

Ik vind snapraid nou niet bepaald simpel klinken, ik heb op de site gekeken en in de faq. Een hoop gedoe, dus dat is voor mij al lastig, laat staan voor huis-tuin-keuken gebruikers. Dat is mijn punt ook, 99% van de consumenten gebruikt de verkenner, timemachine (apple) of ingebouwde backupfunctie Windows. En ook daar heb ik nog nooit gehoord over bitrot. Zeg ik dat bitrot niet kan? Het kan wel, maar het is zover ik weet extreem zeldzaam. Ik heb sommige bestanden al meer dan 10 jaar, ook regelmatig gebackuped, en backup teruggezet. Werkt allemaal nog. Zelfde geld bij mijn broers.

[...]

Klopt ik heb nog hdd's van 10 jaar oud liggen waar nog data leesbbaar is. USB is even de vraag, vroeger was alles natuurlijk SLC en MLC en dan had je er niet zo'n last van.

Van reddit (slechte bron I know)

Je zei hdd's (je bedoeld neem ik aan ssd's )
Ja tegenwoordig zijn bijna alle SSD's QLC, en soms TLC. Ik moet bekennen dat ik ook een aantal QLC ssd's gebruik (want goedkoop) maar ik zou die bijv niet voor backups gebruiken. Die ext hdd bij mijn broer wissel ik 1,2 of 3 keer per jaar. Bij ssd's zou ik me zelf dan teveel zorgen maken of de data nog leesbaar is.

[...]

antwoorden dikgedrukt Is makkelijker bij wat meer antwoorden.

[dennis_rsb]

Om nog even terug te komen.. Ik zei in dit topic dat raid 1 parity doet. Maar schijnbaar niet. Raid 1 is eigenlijk dus 1 op 1 kopie van een schijf, dus eventuele bitrot of corruptie kopieert ie mee.

Nu heb ik al gezegd dat ik me in de praktijk geen zorgen maak om bitrot en dergelijke, maar het is goed om te weten dat raid 1 überhaupt niet beschermd tegen bitrot. Weer wat geleerd.

[Ben(V)]

Geen enkele raid beschermt tegen bitrot.
Maar een raidset kan wel constateren dat er bitrot is ontstaan.
Een raid 5 set kan het zelfs repareren, een raid 1 set niet want die weet niet welke disk de juiste data heeft.

Als je een raidset gaat scrubben (bij een raid 1 set is dat de mirrors vergelijken) dan kan er geconstateerd worden dat er een verschil is en dat je dus corrupte data hebt.
Op zich heb je daar bij een raid 1 set niets aan om de boel te repareren, maar het is wel een waarschuwing dat er iets mis is en kun je de backup terugzetten en er over gaan denken de disk te vervangen.

[GioStyle]

Ben(V) schreef op zondag 9 januari 2022 @ 11:23:
Geen enkele raid beschermt tegen bitrot.
Maar een raidset kan wel constateren dat er bitrot is ontstaan.
Een raid 5 set kan het zelfs repareren, een raid 1 set niet want die weet niet welke disk de juiste data heeft.

Weleens gehoord van ZFS?

[Ben(V)]

Natuurlijk, maar wat heeft het stellen van zo'n vraag voor zin?
Als je een punt wilt maken moet je het uitleggen.

En misschien moet je dit artikel eens lezen, voor je ZFS (en BTFRS) heilig gaat verklaren.
https://www.jodybruchon.c...about-bit-rot-and-raid-5/

[Thralas]

Renault schreef op woensdag 5 januari 2022 @ 18:44:
Zolang de harddisk stroom heeft, zal dit uitlezen en beoordelen voortschrijden op momenten dat de disk niet met iets anders wordt belast.

Ik geloof niet dat dit klopt.

Elders op de disk kunnen dan nog steeds andere sectoren slecht zijn, wat nog niet werd opgemerkt omdat die sectoren (dus de data erop) nog niet is geraadpleegd sinds het achteruitgaan van de sector.

Dit is volgens mij de reden waarom men vaak te snel concludeert dat het aantal bad sectors 'groeit'. Als je één (of een aantal) pending sectors opmerkt moet je de hele disk scannen om een goed beeld te krijgen van de staat van de disk.

Één keer van A-Z uitlezen en overschrijven waar nodig (of direct zerofillen) en de kans is aannemelijk dat de schijf gewoon weer werkt. Zonde om meteen weg te gooien (als je consument bent en geen garantie hebt).

[Ben(V)]

Je verward zaken die je van buiten kunt doen met dingen die de diskcontroller in de disk zelf doet.

En pending sectoren is iets waar je van buiten geen invloed op hebt.
Als die niet door de diskcontroller opgelost worden door ze te realloceren dan ben je die data gewoon kwijt, want de diskcontroller kan ze niet lezen dus van buiten al helemaal niet.
En wat @Renault schrijft klopt wel degelijk, dat zijn gewoon dingen die de diskcontroller zelf doet als hij niet met iets anders bezig is.

Als je alle dat opnieuw laat schrijven dan zal uiteraard die pending sector verdwijnen, want de diskcontroller zal bij overschrijven die data op een andere sector zetten en die pending sector als bad markeren en niet meer gebruiken.
Jij denk dan de boel opgelost te hebben maar je verstopt het alleen maar.

Pending sectoren is altijd een probleem en in mijn ogen niet verstandig te negeren, maar ieder moet daar zijn eigen afweging in maken.

[GioStyle]

Ben(V) schreef op dinsdag 11 januari 2022 @ 09:32:
Natuurlijk, maar wat heeft het stellen van zo'n vraag voor zin?
Als je een punt wilt maken moet je het uitleggen.

En misschien moet je dit artikel eens lezen, voor je ZFS (en BTFRS) heilig gaat verklaren.
https://www.jodybruchon.c...about-bit-rot-and-raid-5/

Nee, ben gewoon benieuwd. Ik was altijd in de veronderstelling dat ZFS prima mee helpt tegen bitrot.

[dennis_rsb]

@GioStyle Ik ben verre van expert, maar volgens mij is ZFS filesystem in combinatie met RAID5 het meest ideale. En dan ook ECC ram lijkt een must (moet je wel een geschikt moederbord hebben)

[GioStyle]

dennis_rsb schreef op dinsdag 11 januari 2022 @ 17:41:
@GioStyle Ik ben verre van expert, maar volgens mij is ZFS filesystem in combinatie met RAID5 het meest ideale. En dan ook ECC ram lijkt een must (moet je wel een geschikt moederbord hebben)

Dat klopt. ZFS leunt voornamelijk op ARC. Als je bijvoorbeeld een defect geheugenmodule hebt zonder ECC, dan kan je geheugen je data corrumperen zonder dat je het door hebt. Daarom wordt bij ZFS altijd ECC geheugen aangeraden. Bij ZFS heb je geen raid5, maar raidz1. Komt op hetzelfde neer, maar wordt anders genoemd.

[Thralas]

GioStyle schreef op dinsdag 11 januari 2022 @ 12:49:
Nee, ben gewoon benieuwd. Ik was altijd in de veronderstelling dat ZFS prima mee helpt tegen bitrot.

Natuurlijk.

Het punt dat het gelinkte artikel echter vooral lijkt te gebruiken is dat bitrot niet bestaat omdat het altijd hele sectors zijn die stukgaan. Ben ik het helemaal mee eens.

Maar dat is geen argument om ZFS af te schrijven, of het punt proberen te maken dat RAID 5 net zo goed werkt (in brede zin, dus inclusief de features en drawbacks van het filesystem erbonveop). Verder is heel Hacker News er kennelijk al overheen gegaan, dus dat lijkt me de moeite van het discussiëren niet echt waard. Laat staan om het hier te droppen zonder uit te leggen waarom je het zo'n goed stuk vindt.

dennis_rsb schreef op dinsdag 11 januari 2022 @ 17:41:
@GioStyle Ik ben verre van expert, maar volgens mij is ZFS filesystem in combinatie met RAID5 het meest ideale. En dan ook ECC ram lijkt een must (moet je wel een geschikt moederbord hebben)

Dat van ECC is ook een misvatting en overhyped. Zie hier een (bekende?) quote van Matthew Ahrens, die wel het één en ander weet van ZFS en het keurig samenvat:

quote: https://arstechnica.com/c...5679&p=26303271#p26303271

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Als je de kans hebt om goedkoop ECC te gebruiken (dat gaat soms met AMD tegenwoordig) dan is dat leuk om te hebben, ook voor thuis, maar verder wordt de impact enorm overschat door de thuisgebruiker.

Het risico dat een thuisgebruiker data kwijtraakt door een gebrek aan ECC is erg klein. Waar het wel heel erg prettig voor kan zijn: defect ram opsporen zonder de ellende van crashende applicaties en memtests die het toevallig net niet laten zien.

[aawe mwan]

Wat hierboven ter sprake gekomen is, is de populaire urban myth dat een (elke) harddisk automagisch onderhoud pleegt op bad sectors. De praktijk blijkt anders te zijn dan de theorie. Misschien dat dure enterprise schijven dit kunnen, maar het spul dat een gewone consument koopt doet dit niet.

Bij een leesfout zal een harddisk sowieso nooit uit zichzelf de foutief gelezen sector realloceren. Dat is by design om je dan meer dan 1 kans te geven de data alsnog te lezen.
Sommige schijven realloceren een sector automatisch na het schrijven, maar dat is dan als die schrijfactie mislukt is. (Het is best mogelijk dat je een bad sector succesvol kunt overschrijven met andere data.)
Bij sommige schijven moet je een commando naar de drive sturen, om eenmalig bad sectors te realloceren.