Synology DSM: data scrubbing vs disk replacement

[Tomby]

Mijn Synology gaf al een maand of zo af en toe een warning ivm een read error die dan wel gerecovered wordt adhv retries. Heb dan ook wel al een replacement disk gekocht die vandaag toegekomen is. Dacht vandaag ook nog effen rap een Extended SMART test te doen, en die faalde uiteindelijk (een maand geleden liep dat nog goed). Ik zie wel geen kritische SMART parameters. Hoedanook betekent het wel duidelijk dat ik nu direct die schijf moet vervangen.

Ik lees nu dat Synology aanraadt van je RAID eerst te scrubben vooraleer je een disk upgradet. Geldt dat ook voor het vervangen van falende disks ? Hoe ik data scrubbing begrijp, is dat eigenlijk je hele RAID ingelezen wordt en de parity gecheckt wordt, om dus te garanderen dat je nog op 100% van je data redundancy hebt. Wat me niet duidelijk is, is wat er gebeurt als er effectief errors gevonden worden. Is het op dat moment dat er sectors heralloceerd worden en dan adhv de redundancy/parity de onleesbare data terug hersteld wordt op de nieuwe sector ? In dat geval lijkt het me dan essentieel dat ik eerst data scrubbing doe ? Want als ik de schijf nu al vervang, en dan blijken er read errors ergens op een van mijn andere 3 schijven te zitten, betekent dat onherroepelijk data loss op de desbetreffende sectoren.

Klopt mijn redenering ?

EDIT: van wat ik lees is het een mes dat aan 2 kanten snijdt:
Pro = scrubbing kan effectief data issues op een van de andere 3 schijven recoveren door ze op andere blocks weg te schrijven. Dit zorgt er voor dat na replacement van 1 disk je in elk voorkomt dat op dat moment de rebuild ineens faalt omwille van read errors elders.
Con = scrubbing zet extra load op alle disks, wat het juist terug meer waarschijnlijk maakt dat er failures op een andere disk gaan zijn. Anderzijds is dat sowieso al het geval voor de RAID rebuild, en als het dan voorkomt ben je sowieso screwed.

[Tomby]

Raar dat een diepvries-topic direct reacties krijgt maar een Synology topic niets .

Anyway, ik heb toch maar de gok gewaagd en Scrubbing laten lopen. Heeft uiteindelijk een uur of 12 geduurd, met een succesvolle consistency check als resultaat ('No abnormality has been found'). Onderweg wel terug een paar warnings over I/O errors op die verdachte schijf, die met retries wel verholpen waren.
Nu nog fingers crossed dat ook de rebuild met nieuwe schijf (ben voor Ironwolf gegaan) zonder probleem verloopt.

[sky]

Heb ook een syno nas, maar dit zegt me helemaal niets.
Heb deze week mijn NAS vanaf nul terug geinstalleerd en een backup teruggezet. Is iets minder risico vol dan te laten rebuilden

[Tomby]

Heb ook een syno nas, maar dit zegt me helemaal niets.
Heb deze week mijn NAS vanaf nul terug geinstalleerd en een backup teruggezet. Is iets minder risico vol dan te laten rebuilden

Hoezo ? Terug vanaf nul installeren en een backup terugzetten is wel meer werk dan een RAID rebuild, en in tussentijd zijn je files ook totaal niet beschikbaar. Dan kan je even goed geen RAID gebruiken (waar ook iets voor te zeggen valt natuurlijk). Een RAID rebuild kan maar zo gemakkelijk zijn: kapotte schijf eruit, nieuwe erin en de rebuild laten lopen, terwijl je ondertussen nog gewoon al je files beschikbaar hebt. Als je al een backup hebt (wat ook zo is) is daar helemaal niet méér risico aan dan jouw manier. Immers normaliter heb je de backup dan zelfs niet nodig, maar als de rebuild faalt, kan ik nog altijd de NAS compleet resetten en backup terug halen. In jouw geval moet je 100% vertrouwen op je backup, in mijn geval is het maar een vangnet voor als de rebuild zou falen.

Mijn vraag ging eerder of je nog moet scrubben (ook weer iets typisch RAID) als je al weet dat je een slechte schijf hebt. Het scenario dat ik me kon inbeelden was dus simpelweg: Stel, HDD1 is defect want de NAS komt fouten melden. Omdat het RAID is, ben je echter nog geen data kwijt. Wat je niet weet, is dat HDD2 ook slechte sectoren blijkt te hebben maar op files die je al een tijdje niet meer gelezen hebt. Als je dan gewoon HDD1 vervangt door een nieuwe schijf, heb je het wel vlaggen, want een rebuild vereist dat al je andere schijven perfect leesbaar zijn. Door HDD1 eruit te halen, neem je echter juist ook de goeie bits weg die je nodig had om de slechte sectoren van HDD2 te compenseren.
Voor zover ik weet gaat Scrubbing ook slechte sectoren disablen en de goeie info elders wegschrijven zodat je terug volledige redundancy hebt. Dus in het voorbeeld hierboven zouden de slechte sectoren van HDD2 dan gemarkeerd worden en de data dan elders terug gereconstrueerd kunnen worden (aangezien HDD1 met de goeie bits, er nog in zit). Idem trouwens voor de slechte sectoren van HDD1 dan. Dus na het scrubben kan je dan veilig een hele schijf eruit nemen.

EDIT: begrijp trouwens niet helemaal goed wat er misgelopen is met die ene HDD. Ik kreeg dus regelmatig al recoverable read errors. Op nieuwjaar is er nog een Extended S.M.A.R.T. test goed verlopen, maar gisteren liep die dus verkeerd en werd onderbroken ('failed') zonder duidelijk aangeven wat er mis is. Het bizarre is immers dat de Scrubbing erna terug enkel enkele (recoverable) read errors gegeven heeft, en dus meldde dat mijn Storage Pool ok was. De schijf is er ondertussen uit, en ga eens met SeaTools een extended test doen. Sowieso zijn die read errors wel al een indicatie dat de schijf niet echt betrouwbaar meer was, dus vervangen was sowieso een must.