Stijging foutmelding HDD NAS

[Jewie]

Hi all,

In mijn Ugreen NAS heb ik een tweetal (tweedehands) schijven geplaatst. Deze werken in Raid1 opstelling met elkaar samen. Nu krijg ik van 1 HDD wekelijks een melding dat de foutieve sectoren toenemen:

- Unstable sectors: wekelijks een stijging van 200

- Niet corrigeerbare sectors: wekelijk een stijging van 100

De NAS geeft aan om de groeitrend in de gaten te houden. Maar wat is nu het moment om de betreffende schijf (8TB) te vervangen? Of zijn er wellicht zaken die ik kan doen om vervanging te voorkomen? De schijf heeft inmiddels 35k draaiuren.

[The Eagle]

Dat ligt er aan hoe zuinig je op je data bent

Maar die disk is duidelijk aan het sterven, zou hem niet meer vertrouwen. Moment om de schijf te vervangen is al geweest, dat was toen ie nog goed was

[WargamingPlayer]

Op het moment dat je groei in bad sectors kan waarnemen in een periode van minder dan pak weg een jaar. En dan praat ik over minder dan 10 uncorrectable per jaar dan ben je eigenlijk al te laat.

Zoals al gesteld is, als je data je lief is, direct vervangen. Het gedrag duid op een fysieke beschadiging in de disk, bijvoorbeeld door lekkage en vocht of misschien erger, een beschadigde kop, of een stofdeeltje van een paar micron groot in de disk.

[Jewie]

Duidelijke uitspraken. Opvallend is dat de SMART testen nog allemaal positief zijn.

[_JGC_]

Heb je rauwe SMART data van je schijven? Evt screenshots?

[Jewie]

Hierbij de details van de betreffende HDD:

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 016 Pre-fail Always - 0
2 Throughput_Performance 0x0004 128 128 054 Old_age Offline - 108
3 Spin_Up_Time 0x0007 249 249 024 Pre-fail Always - 228 (Average 426)
4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 542
5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 3
7 Seek_Error_Rate 0x000a 100 100 067 Old_age Always - 0
8 Seek_Time_Performance 0x0004 124 124 020 Old_age Offline - 19
9 Power_On_Hours 0x0012 095 095 000 Old_age Always - 35198
10 Spin_Retry_Count 0x0012 100 100 060 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 23
192 Power-Off_Retract_Count 0x0032 099 099 000 Old_age Always - 2054
193 Load_Cycle_Count 0x0012 099 099 000 Old_age Always - 2054
194 Temperature_Celsius 0x0002 135 135 000 Old_age Always - 48 (Min/Max 16/51)
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 3
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 912
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 333
199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 50% 35170 -
# 2 Short offline Completed: read failure 90% 35153 -
# 3 Extended offline Completed: read failure 90% 35126 -
# 4 Short offline Completed: read failure 90% 34985 -
# 5 Short offline Completed: read failure 90% 34817 -
# 6 Short offline Completed: read failure 90% 34605 -
# 7 Extended offline Completed: read failure 90% 34602 -
# 8 Short offline Completed: read failure 90% 34437 -
# 9 Short offline Completed: read failure 90% 34269 -
#10 Short offline Completed without error 00% 34146 -
#11 Short offline Completed without error 00% 33980 -
#12 Extended offline Completed without error 00% 30739 -
#13 Short offline Completed without error 00% 30374 -
#14 Extended offline Completed without error 00% 29995 -
#15 Short offline Completed without error 00% 29630 -
#16 Extended offline Completed without error 00% 29251 -
#17 Short offline Completed without error 00% 28886 -
#18 Extended offline Completed without error 00% 28531 -
#19 Short offline Completed without error 00% 28166 -
#20 Extended offline Completed without error 00% 27786 -
#21 Short offline Completed without error 00% 27421 -

[ Voor 198% gewijzigd door Jewie op 03-09-2026 23:56 ]

[Mijzelf]

Ik vraag me af waar die NAS zijn waarschuwingen vandaan haalt. Voor zover ik weet zijn de zaken die er in deze context toe doen deze:

code:

5 Reallocated_Sector_Ct 0x0033 100 100 005 Pre-fail Always - 3
197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 912
198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 333

Hierbij is Reallocated_Sector_Ct het aantal daadwerkelijk defecte sectors, die zijn vervangen door spares. Bij jou dus 3. Als dit getal (snel) stijgt, is de disk aan het sterven.

Dan heb je Current_Pending_Sector, dat zijn sectoren waarvan de checksum niet meer klopt, doordat er bitjes zijn omgevallen, maar die in principe fysiek nog prima in orde zouden moeten zijn. Het wachten is tot ze een keer worden overschreven.

Offline_Uncorrectable is bij mijn weten iets soortgelijks, alleen wat ernstiger. Waar bij een Current_Pending_Sector nog een gok kan worden gedaan wat er zou moeten staan, is dat bij Offline_Uncorrectable niet mogelijk.

Dus ik neem aan dat jouw UGreen Current_Pending_Sector 'unstable' noemt, en Offline_Uncorrectable 'Niet corrigeerbaar'. In beide gevallen kan het gaan om sectoren die al sinds de productie niet meer zijn beschreven, en nu last hebben van bitrot, zonder dat het iets zegt over de kwaliteit van de disk.

[_JGC_]

Offline uncorrectable wordt opgehoogd als de firmware bij een achtergrondscan een sector niet kan lezen. Die hoeft niet erg te zijn, want mogelijk staat er geen data op die sector.
Pending sectors zijn sectoren die niet gelezen konden worden toen het OS erom vroeg. Dan heb je dus wel datacorruptie of mis je data.

Wat je kunt doen is de hele disk van voor tot achter overschrijven, dan zouden beide counters weer naar 0 moeten gaan en de sectoren die echt slecht zijn worden reallocated sectors. Als vervolgens de counters weer gaan oplopen weet je 100% zeker dat je afscheid mag gaan nemen van deze disk.

[MAX3400]

Wees er in ieder geval zeker van dat je een backup hebt van jouw (belangrijkste) data. En dat is niet je andere disk in de pool.

Zeker in RAID1 waarvan 1 disk al kuren lijkt te vertonen, zou ik me zeker vergewissen dat al mijn backups in orde zijn...

[WargamingPlayer]

Daarnaast worden sectoren welke bad zijn maar niet rein een RAID-1 als het goed is op de andere disk als onbeschikbaar gemarkeerd. Dus je verliest ook nog eens disk ruimte.

Daarnaast kan het gebeuren dat bij een lees actie er op de disk een timeout optreed en de NAS de disk offline gooit.

[Jewie]

_JGC_ schreef op vrijdag 4 september 2026 @ 09:13:
Wat je kunt doen is de hele disk van voor tot achter overschrijven, dan zouden beide counters weer naar 0 moeten gaan en de sectoren die echt slecht zijn worden reallocated sectors. Als vervolgens de counters weer gaan oplopen weet je 100% zeker dat je afscheid mag gaan nemen van deze disk.

Dit is wellicht wel een leuke controle. Ik heb het plan om de betreffende HDD aan mijn PC te hangen en deze door middel van "formatteren" te overschrijven. Of kan ik hiervoor beter een specifiek programma gebruiken?

[_Arthur]

Jewie schreef op vrijdag 4 september 2026 @ 14:35:
[...]


Dit is wellicht wel een leuke controle. Ik heb het plan om de betreffende HDD aan mijn PC te hangen en deze door middel van "formatteren" te overschrijven. Of kan ik hiervoor beter een specifiek programma gebruiken?

Als er geen data op de disks staat, kan je dat altijd doen. Let wel als je 1 disk uit je Raid1 set haalt, de data op disk nummer 2 ook niet meer benaderbaar zal zijn.

Raid = geen backup.

[_JGC_]

WargamingPlayer schreef op vrijdag 4 september 2026 @ 11:47:
Daarnaast worden sectoren welke bad zijn maar niet rein een RAID-1 als het goed is op de andere disk als onbeschikbaar gemarkeerd. Dus je verliest ook nog eens disk ruimte.

Daarnaast kan het gebeuren dat bij een lees actie er op de disk een timeout optreed en de NAS de disk offline gooit.

Zo werkte dat vroeger met FAT en diskettes, dan markeerde je een kapotte sector in de FAT tabel en werd die niet meer gebruikt. Moderne harddisks lossen dat in de firmware op door sectoren te remappen naar andere fysieke sectoren.

Maar afhankelijk van hoe de NAS werkt en welke RAID implementatie er gebruikt wordt kan idd de hele disk offline gaan of uit het array geschopt worden.

@Jewie Als je de disk formatteert in windows en dan geen quick format gebruikt overschrijft Windows idd de hele disk.

[Jewie]

_Arthur schreef op vrijdag 4 september 2026 @ 14:37:
[...]

Als er geen data op de disks staat, kan je dat altijd doen. Let wel als je 1 disk uit je Raid1 set haalt, de data op disk nummer 2 ook niet meer benaderbaar zal zijn.

Raid = geen backup.

Deze moet je me even uitleggen. Als ik de HDD met gebreken uit mijn NAS haal, deze formatteer en vervolgens terugplaats in mijn NAS dan verwacht ik dat de NAS hem als een nieuwe HDD herkent en vervolgens de data vanuit de werkende HDD weer mirrored.

Maak ik hier een denkfout?

[vassago]

Ik zou niet eens aan die exercitie beginnen, behalve een goed gevoel lost het verder niets op.
Persoonlijk zou ik die disk vervangen, bij voorkeur voor een (refurbished) enterprise disk.

Wat zit er nu in voor disk? 4 jaar 24/7 draaien hoeft geen probleem te zijn, afhankelijk van het type disk.

Als de andere disk nog goed is kan je ook wachten tot 1 v/d 2 het echt begeeft, zolang je maar een goede backup hebt van je data.
Raid 1 zou je moeten zou je moeten beschermen tegen de uitval van 1 disk maar garantie tot aan d e deur.

[ Voor 8% gewijzigd door vassago op 04-09-2026 14:49 ]

[SpamLame]

RAID1 = mirroring.
Je set bestaat uit 2 disks waarvan 1 problemen lijkt te hebben.
Theoretisch zou je de set kunnen blijven gebruiken zelfs nadat er een disk stuk gaat.

Wanneer er een disk stuk gaat in R1 behoor je geen data te verliezen, HW redundantie ben je wel kwijt.
Je verliest geen capaciteit (in GB) vanuit een logisch aspect (zijnde whatever bovenop de R1 leeft, volume/share bv).

Je opties;
-koop een zelfde of groter schijf en vervang de falende
-niks doen en zien wat er gaat gebeuren
-R1 set breken en doorgaan op de single drive

Backup had je uiteraard al gemaakt en maak je regelmatig zodat je iets achter de hand hebt.

[MAX3400]

vassago schreef op vrijdag 4 september 2026 @ 14:48:
Raid 1 zou je moeten zou je moeten beschermen tegen de uitval van 1 disk maar garantie tot aan d e deur.

RAID1 beschermt inderdaad tegen "niets"; hoogstens inderdaad de uitval van 1 disk.

Voor de rest: het is een mirror. Dat houdt in dat alle data die niet correct weggeschreven wordt op disk A ook niet correct op disk B terecht komt. Dat geldt zowel voor corruptie door hardware-failure (zoals bad sectors of een dode kop) maar ook corruptie in je datastream (data die je schrijft naar een NAS) of zaken zoals een virus of malware.

[_JGC_]

@MAX3400 Dat van die corruptie op beide schijven is niet waar. De corruptie zit on-disk, dus disk1 en disk2 hebben dan verschillende data.
Hoe het daarmee omgaat... zonder integriteitscontroles ben je overgeleverd aan de eerlijkheid van de disk firmware.

Dat laatste is dus waarom ik ZFS gebruik ipv klassiek RAID met een los filtersystem eroverheen. ZFS kan de data valideren met checksums en dan kiezen om de corrupte data van disk1 weg te gooien en de juiste data van disk2 te gebruiken.

Maargoed, RAID1 met 8TB... de kans dat je bij het terugzetten van alle data naar een nieuwe disk tegen een leesfout van je nog werkende schijf aanloopt is aanwezig. Tijdens de recovery heb je geen redundantie.

[WargamingPlayer]

Jewie schreef op vrijdag 4 september 2026 @ 14:35:
[...]


Dit is wellicht wel een leuke controle. Ik heb het plan om de betreffende HDD aan mijn PC te hangen en deze door middel van "formatteren" te overschrijven. Of kan ik hiervoor beter een specifiek programma gebruiken?

HDSentinel. De gratis versie doet het redelijk, voor weinig koop je een licentie voor meerdere PC’s.

[WargamingPlayer]

_JGC_ schreef op vrijdag 4 september 2026 @ 16:32:
@MAX3400 Dat van die corruptie op beide schijven is niet waar. De corruptie zit on-disk, dus disk1 en disk2 hebben dan verschillende data.
Hoe het daarmee omgaat... zonder integriteitscontroles ben je overgeleverd aan de eerlijkheid van de disk firmware.

Dat laatste is dus waarom ik ZFS gebruik ipv klassiek RAID met een los filtersystem eroverheen. ZFS kan de data valideren met checksums en dan kiezen om de corrupte data van disk1 weg te gooien en de juiste data van disk2 te gebruiken.

Maargoed, RAID1 met 8TB... de kans dat je bij het terugzetten van alle data naar een nieuwe disk tegen een leesfout van je nog werkende schijf aanloopt is aanwezig. Tijdens de recovery heb je geen redundantie.

Je vergelijkt met ZFS. Klassieke raid 1 schrijft gewoon naar head, track, sector op beide disks binnen de stripe. Het lezen gaat identiek. Afhankelijk van de controller en software zal of de sector in de stripe als bad worden gemarkeerd in de boekhouding of zelfs de hele stripe. Dus als head 0, track 5, sector 3 op disk 2 defect is, dan zal de zelfde sector op disk 1 door de controller/software/os ook als bad worden aangemerkt.

ZFS doet dit anders, maar we hebben het hier over klassiek dom RAID 1. Het probleem met RAID-1 is dat systemen zonder checksum in de stripe niet eens weten welke disk van de 2 de correcte data heeft. Daarom is ouderwets Dom RAID-1 af te raden.

[_JGC_]

@WargamingPlayer Dat als slecht markeren in de stripe gebeurt alleen als de disk het zelf niet oplost. Elke IDE, SATA, SAS en SCSI harddisk van de afgelopen 20 jaar doet aan defect mapping. Dat wordt bijgehouden in de reallocated_sector_count smart waarde. Bad sectors markeren is iets uit het verleden wat je deed met diskettes, die hebben geen reallocated sectors. Verder werken moderne disks met LBA ipv C/H/S, de firmware bepaalt welke C/H/S bij een LBA hoort.

Wat de checksum betreft die RAID1 niet heeft, als je geluk hebt geeft de firmware een foutmelding naar het OS of blijft de disk hangen in de retries ipv corrupte data teruggeven. Krijg je wel corrupte data... succes ermee.

[WargamingPlayer]

_JGC_ schreef op vrijdag 4 september 2026 @ 20:43:
@WargamingPlayer Dat als slecht markeren in de stripe gebeurt alleen als de disk het zelf niet oplost. Elke IDE, SATA, SAS en SCSI harddisk van de afgelopen 20 jaar doet aan defect mapping. Dat wordt bijgehouden in de reallocated_sector_count smart waarde. Bad sectors markeren is iets uit het verleden wat je deed met diskettes, die hebben geen reallocated sectors. Verder werken moderne disks met LBA ipv C/H/S, de firmware bepaalt welke C/H/S bij een LBA hoort.

Wat de checksum betreft die RAID1 niet heeft, als je geluk hebt geeft de firmware een foutmelding naar het OS of blijft de disk hangen in de retries ipv corrupte data teruggeven. Krijg je wel corrupte data... succes ermee.

Het aantal sectoren waarvoor relocatie gedaan kan worden is ook beperkt.

[_JGC_]

WargamingPlayer schreef op vrijdag 4 september 2026 @ 21:00:
[...]

Het aantal sectoren waarvoor relocatie gedaan kan worden is ook beperkt.

En jij denkt dat de SMART status nog steeds OK is als dat zo ver is?

[WargamingPlayer]

_JGC_ schreef op vrijdag 4 september 2026 @ 21:06:
[...]

En jij denkt dat de SMART status nog steeds OK is als dat zo ver is?

Nope

[SMSfreakie]

tot het ineens heel snel gaat... en hoe vaak je ook je smart checkt natuurlijk..

[Renault]

Dus zijn op dit moment accurate backups heel belangrijk, onanks "RAID1".