Schijf nog te redden met ddrescue?

[3raser]

De schijf in mijn thuisserver (Proxmox) gaf al een tijdje een waarschuwing:

Device: /dev/sdb [SAT], 17 Currently unreadable (pending) sectors

Dit aantal steeg al maanden niet, dus ik hoopte stiekem nog niet zo erg in de problemen te zitten. Tot gisteren dan, want toen kreeg ik deze melding:

Device: /dev/sdb [SAT], ATA error count increased from 0 to 132

Dit leek mij geen goed teken en ik heb direct een nieuwe schijf besteld. Ondertussen lijkt de schijf niet meer te benaderen via de oorspronkelijke manier en pogingen daartoe resulteerden in een nieuwe melding:

Device: /dev/sdb [SAT], ATA error count increased from 57920 to 58064

Ik heb nu ddrescue aangezet om de defecte schijf te clonen naar de nieuwe schijf. Ik heb daar totaal geen ervaring mee en het was tot vanmiddag dat ik nog nooit van deze tool gehoord had. Ik heb deze opgestart met de volgende parameters:

code:

ddrescue -f -n -N /dev/sdb /dev/sdd /root/recovery.log

De status is veelbelovend, behalve dan de voortgang. Gemiddeld nog zo'n 55 dagen totdat hij klaar is.

De huidige status is als volgt:

code:

     ipos:    3420 MB, non-trimmed:        0 B,  current rate:   1507 kB/s
     opos:    3420 MB, non-scraped:        0 B,  average rate:    699 kB/s
non-tried:    3997 GB,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:    3420 MB,   bad areas:        0,        run time:     44m 55s
pct rescued:    0.08%, read errors:        0,  remaining time: 55d 14h  5m
                              time since last successful read:          0s

Mijn vraag is nu dus wat ik kan verwachten van de uitkomst. Tot nu toe lees ik in deze status dat de 3,4GB die hij verwerkt heeft allemaal leesbaar was en dat er geen bad sectors gevonden zijn. Als dat zo is, waarom is de gemiddelde verwerkingssnelheid dan maar 699 kB/s? Kan het zijn dat dit deel van de schijf moeilijk leesbaar is en dat het straks sneller gaat? Ik heb al wat parameters als Direct Disk Access geprobeerd maar dat kwam de snelheid niet ten goede. En is die 3,4GB echt volledig hersteld? Want dan is dat het wachten misschien wel waard.

[Will_M]

Je hebt dus feitelijk gezien gewoon maandenlang alle errors genegeerd om nu tot de conclusie te moeten gaan komen dat je je data kwijt bent of dat die data in ieder geval op z'n minst gezegd niet meer te vertrouwen (lees: consistent) is.

Goed bezig

Er is een hele goede rede dat hardware fabrikanten de disks al onder RMA vervangen op het moment dat er 'Predictive Error's' zichtbaar zijn.

[ Voor 28% gewijzigd door Will_M op 13-06-2024 23:33 ]

[Stanton]

Welk merk en welk model schijf is dit? Is het een WD?

[3raser]

Will_M schreef op donderdag 13 juni 2024 @ 23:19:
Je hebt dus feitelijk gezien gewoon maandenlang alle errors genegeerd om nu tot de conclusie te moeten gaan komen dat je je data kwijt bent of dat die data in ieder geval op z'n minst gezegd niet meer te vertrouwen (lees: consistent) is.

Goed bezig

Er is een hele goede rede dat hardware fabrikanten de disks al onder RMA vervangen op het moment dat er 'Predictive Error's' zichtbaar zijn.

Bedankt voor je nuttige bijdrage. Ik zeg toch ook nergens dat ik dit niet beter op had kunnen pakken? Ik stel vragen over een eventuele recovery en berichten over "hoe stom ik wel niet ben" mogen achterwege blijven. Dat weet ik namelijk zelf ook wel.

[3raser]

Stanton schreef op vrijdag 14 juni 2024 @ 02:07:
Welk merk en welk model schijf is dit? Is het een WD?

Ja, het is een WD Red. Betreft dit model: uitvoering: WD Red Plus, 4TB (64MB cache)

[Mijzelf]

Een 'Currently unreadable (pending) sector' is een sector die fysiek in orde is, maar waarvan om de een of andere reden de checksum/error correction code niet klopt. De huidige inhoud is dus niet meer te verifiëren. Vandaar dus 'currently unreadable', de fout verdwijnt als de de sector overschrijft met nieuwe data, en een nieuwe checksum/ecc. Dit zijn geen ernstige fouten, behalve dan dat je data kwijt bent.
Het probleem waar je uiteindelijk tegenaan bent gelopen is van andere aard, of de schijf heeft zelf de ernst van de situate onderschat.

Tot nu toe lees ik in deze status dat de 3,4GB die hij verwerkt heeft allemaal leesbaar was en dat er geen bad sectors gevonden zijn. Als dat zo is, waarom is de gemiddelde verwerkingssnelheid dan maar 699 kB/s?

Ddrescue gaat 'tot het gaatje' als een sector slecht leesbaar is. Hij leest dezelfde sector mogelijk wel tientallen keren, en als hij uit de verschillende uitkomsten een datablok krijgt met kloppende checksum, wordt dat weggeschreven. De kans dat die data dan klopt is behoorlijk groot. Maar het is wel een trage bedoening. Inplaats van streamen op 150MB/sec, valt hij terug naar misschien 4kB/sec, als hij een sector 100 keer moet lezen. (Eén omwenteling valt in de orde van 10ms).
Het is goed mogelijk dat de fout maar op een gedeelte van de schijf zit, en dat hij verderop wel een hoge snelheid kan halen.

[99ruud99]

Mijn tip zou zijn, stop de schijf in een niet gebruikte pc, en draai daar ddrecue op, dan kan je de rest van je server nog gebruiken.

Is de data niet belangrijk, gooi dan gewoon de schijf weg (even de plaat doorboren zorgt ervoor dat je data weg is.

[3raser]

@Mijzelf Ik heb ook nog pv gebruikt omdat ik gelezen had dat die mogelijk beter zou presteren. Wat mij betreft worden onleesbare sectoren gewoon overgeslagen. Maar pv had ook zeer slechte prestaties. Ik twijfel daarom ook een beetje of de slechte prestaties wel met slecht leesbare data te maken hebben, of dat de schijf om een andere reden zeer traag is geworden. Ddrescue heeft na 10 uur nog geen enkel onleesbaar deel gevonden.

@99ruud99 De schijf kan in principe rustig herstellen en de server is online.

[99ruud99]

Je begrijpt het verkeerd.
Als ddrecue een onleesbaar deel tegen komt blijft hij dat deel (tot max 2096 x ) lezen, op extra lage snelheid. Al die delen samen vormen data, als daaruit niets komt DAN PAS is het onleesbaar.
Vergelijk het met een moeilijke tekst, daar lees je langzamer doorheen, en vaak nog meerdere keren dezelfde zin. Uiteindelijk begrijp je de tekst dan. Echter, is het een juridische tekst zegt je na 10x te lezen 'ja pff ik snap er niets van'.

Dus ja, dat duurt wel heel lang .

[3raser]

@99ruud99 Bedankt voor je uitleg. Heeft dit dan ook te maken met de retry-passes parameter? Die staat standaard op 0 volgens de documentatie. Ik zou namelijk best eerst een poging willen wagen waarbij hij die slecht leesbare delen eerst zou overslaan als dit binnen (bijvoorbeeld) 2 dagen een resultaat op zou leveren. Dan kan ik daarna eventueel meerdere passes kunnen proberen om extra data te herstellen indien nodig.

[Mijzelf]

pv? Als in pipeview? Die weet helemaal niet van de onderliggende structuur, en pipe't gewoon de data uit /dev/sdX naar stdout. Als daar slecht leesbare sectoren inzitten zal de pipe input ook inzakken.

Als je wilt wetten of de disk verderop gewoon leesbaar is zou je met dd een blok verderop kunnen lezen:

dd if=/dev/sdX bs=1G skip=2000 of=/dev/null

om rond de 2TB een blok van 1GB te lezen.

[hcQd]

Mijzelf schreef op vrijdag 14 juni 2024 @ 10:15:
pv? Als in pipeview? Die weet helemaal niet van de onderliggende structuur, en pipe't gewoon de data uit /dev/sdX naar stdout. Als daar slecht leesbare sectoren inzitten zal de pipe input ook inzakken.

Als je wilt wetten of de disk verderop gewoon leesbaar is zou je met dd een blok verderop kunnen lezen:

dd if=/dev/sdX bs=1G skip=2000 of=/dev/null

om rond de 2TB een blok van 1GB te lezen.

Daar wil je misschien nog een count=1 bij, anders leest hij tot het einde van de schijf.

[Stanton]

3raser schreef op vrijdag 14 juni 2024 @ 08:38:
[...]

Ja, het is een WD Red. Betreft dit model: uitvoering: WD Red Plus, 4TB (64MB cache)

Aside: Bijna alles wat hierboven over ddrescue geschreven is van een hoog klok/klepel gehalte, zo ook de uitleg over 'pending sectors', dat deze per definitie fysiek in orde zouden zijn is onzin. M.b.t. ddrescue, het idee is juist dat ddrescue niet tientallen keren (ik zie zelfs iemand 100-en keren beweren) gaat lezen tijdens een eerste pass want dit herhaald lezen is juist wat je niet wilt met een 'onstabiele' drive. Het idee is juist dat je sectoren die je niet kunt lezen omzeilt met als doel verdere schade te beperken. En dit is ook waarom troep (ik gebruik de kwalificatie bewust) als SpinRite niets te maken heeft met data recovery en verre gehouden zou moeten worden van 'zieke' harde schijven etc..

Okee, dan is er waarschijnlijk sprake van de "slow response" of "slow responding" bug, iedereen geeft dat zijn eigen naam. Die houdt kort gezegd in dat de schijf enorm traag reageert zelfs als de sector (of sectoren) die op dat moment gelezen worden in orde zijn. Het is een firmware issue waar de drive het zo druk heeft met achtergrond taken dat de leesopdrachten op het 2e plan komen. Je ziet dit vaak op WD's met bad sectors en de drive is super traag zelfs als je op dat moment goede sectoren leest.

In bepaalde gevallen kan 'de bug' leiden tot een G-List overflow en dan kan alleen een data recovery bedrijf nog helpen. De overflow overschrijft de erop volgende firmware module. Eigenlijk is het dus van belang de schijf zo min mogelijk tijd te geven voor achtergrond processen.

Er zijn een paar trucs om de snelheid op te krikken, waarvan de simpelste is, lees grotere brokken in een keer. Door bijvoorbeeld 2 x zo grote blokken te lezen verdubbel je de lees snelheid. M.a.w. als de drive (eindelijk) een leesopdracht behandelt, lees je de dubbele hoeveelheid data.

Deze video legt dit uit: YouTube: HDDSuperClone Slow Responding Drives part1 2019 11 29

Een andere truc is het veranderen van time-out settings en de read afbreken (middels een reset) wanneer het achtergrond proces de read vertraagt en dan direct daarop hetzelfde blok opnieuw lezen, voordat de schijf zich opnieuw gaat bezighouden met achtergrond processen.

Demonstratie: YouTube: HDDSuperClone Slow Responding Drives part2 2019 12 07

Als laatste mogelijkheid is er het patchen van de firmware waarmee je het achtergrond proces dat ons in de weg zit stop zet. Dit is niet een permanente fix waarmee je de schijf repareert en dus kunt blijven gebruiken alsof er niets aan de hand is!

Demonstratie: YouTube: HDDSuperClone Slow Responding WD Patch 2020 04 04

De tool HDDSuperClone is net als ddrescue 'gratis' en open source. Het is ddrescue on steroids en functioneert in een aantal gevallen net zo goed als professionele data recovery hard/software.

Hoewel WD's hierom echt bekend staan is het een algemeen fenomeen dat ik ook vaak zie bij SSDs en zelfs geheugen kaartjes en USB stickjes. Eigenlijk in gevallen waar de controller/firmware slimmer is en op eigen houtje allerlei achtergrond taken uitvoert en deze hinderen eigenlijk het process wanneer je probeert data van de drive te clonen (of te lezen in algemeen).

Ik kan helaas niet echt helpen bij het gebruik van HDDSuperClone omdat ik het zelf niet gebruik, ik heb zelf nl. pro hardware hiervoor, maar idee is hetzelfde. Hier heeft mijn sub reddit mede moderator een soort van guide geschreven die wellicht helpt: https://www.reddit.com/r/...wiki/hddsuperclone_guide/

[ Voor 29% gewijzigd door Stanton op 14-06-2024 16:41 ]

[3raser]

@Stanton Bedankt voor je tips! Naar aanleiding van die video over de cluster size ben ik daar in ddrescue mee gaan spelen. Het is zoeken naar een bepaalde sweetspot en die lijkt bij mij nu op 8KiB te liggen. Daarmee is de snelheid ruim verdubbeld ten opzichte van de standaard instelling. De recovery time ligt nu alvast onder de 30 dagen.

[Renault]

Even een andere invalshoek: Je TS begint met een "ATA Error"-melding.
Zonder een volledige uitdraai van de Smart-tabel denk ik dan meteen aan CRC-errors, oftewel communicatiefouten tussen de SATA-chip op het moederbord en de SATA-chip op de harddisk.

Het meest voorkomende defect is dan een defecte SATA-kabel.
Dus schaf een nieuwe SATA-kabel aan en gebruik die!
En als het CRC-errors zijn: dat getal wordt niet minder, het gaat niet terug naar nul. Als het getal hetzelfde blijft en niet toeneemt, is het probleem opgelost.

[3raser]

Renault schreef op donderdag 20 juni 2024 @ 10:47:
Even een andere invalshoek: Je TS begint met een "ATA Error"-melding.
Zonder een volledige uitdraai van de Smart-tabel denk ik dan meteen aan CRC-errors, oftewel communicatiefouten tussen de SATA-chip op het moederbord en de SATA-chip op de harddisk.

Het meest voorkomende defect is dan een defecte SATA-kabel.
Dus schaf een nieuwe SATA-kabel aan en gebruik die!
En als het CRC-errors zijn: dat getal wordt niet minder, het gaat niet terug naar nul. Als het getal hetzelfde blijft en niet toeneemt, is het probleem opgelost.

Ik wist niet eens dat die kabels stuk konden gaan. Ik bedoel, zonder externe invloed zoals beweging.

Als die ATA-errors leesfouten zijn kan het dan misschien ook nog te maken hebben met die rare WD "bug" die ervoor zorgt dat de schijf zo extreem traag wordt?

De huidige status van de schijf is dat de recovery praktisch stil staat. Er zijn 2 leesfouten gedetecteerd volgens de voortgang en de reseterende tijd staat op een paar duizend dagen.

[Stanton]

ATA errors kan van alles zijn, voorbeeld waarin ik UDMA_CRC_Err_Cnt meeneem. Direct erachter ATA Error Count:

code:

199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

SMART Error Log Version: 1
ATA Error Count: 40878 (device log contains only the most recent five errors)
    CR = Command Register [HEX]

Dit gaat over een en dezelfde schijf. ATA error count > 0 is niet perse een issue, bijvoorbeeld kan resultaat zijn van host die commando's stuurt die de schijf niet begrijpt, een bepaalde feature aanzetten die de schijf niet ondersteunt bijvoorbeeld.

Maar goed, SMART data er eens bij pakken is geen gek idee ofzo .. Ik denk alleen niet dat het je gaat helpen in dit geval.

[ Voor 20% gewijzigd door Stanton op 21-06-2024 02:44 ]

[3raser]

Stanton schreef op vrijdag 21 juni 2024 @ 02:40:
Maar goed, SMART data er eens bij pakken is geen gek idee ofzo .. Ik denk alleen niet dat het je gaat helpen in dit geval.

Dit is wat smartctl over de schijf zegt:

code:

Model Family:     Western Digital Red
Device Model:     WDC WD40EFRX-68N32N0
Serial Number:    <verborgen>
LU WWN Device Id: 5 0014ee 2bbdef302
Firmware Version: 82.00A82
User Capacity:    4,000,787,030,016 bytes [4.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Fri Jun 21 09:09:02 2024 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

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     0x002f   190   190   051    Pre-fail  Always       -       421
  3 Spin_Up_Time            0x0027   197   171   021    Pre-fail  Always       -       5141
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       31
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   043   043   000    Old_age   Always       -       41629
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       30
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       21
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       1159
194 Temperature_Celsius     0x0022   116   105   000    Old_age   Always       -       34
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

ATA Error Count: 58064 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 58064 occurred at disk power-on lifetime: 41443 hours (1726 days + 19 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 61 02 00 00 00 a0  Device Fault; Error: ABRT

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ef 10 02 00 00 00 a0 08  24d+15:50:54.474  SET FEATURES [Enable SATA feature]
  ec 00 00 00 00 00 a0 08  24d+15:50:54.470  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 08  24d+15:50:54.470  SET FEATURES [Set transfer mode]
  ef 10 02 00 00 00 a0 08  24d+15:50:54.469  SET FEATURES [Enable SATA feature]
  ec 00 00 00 00 00 a0 08  24d+15:50:54.401  IDENTIFY DEVICE

[3raser]

3raser schreef op donderdag 20 juni 2024 @ 12:04:
De huidige status van de schijf is dat de recovery praktisch stil staat. Er zijn 2 leesfouten gedetecteerd volgens de voortgang en de reseterende tijd staat op een paar duizend dagen.

Blijkbaar werkt een herstart van ddrescue heel goed tegen dit soort traagheid. Na de herstart lijkt hij weer op de normale (trage) snelheid door te werken en er dus geen duizenden dagen meer over te doen.

[rikadoo]

Wel apart dat je server dit aangeeft, als ik naar je SMART waardes kijk zijn deze helemaal niet slecht.
Deze staan op 0, ik had dan wel verwacht dat deze hoger is.

Reallocated_Sector_Ct
Current_Pending_Sector

[3raser]

rikadoo schreef op vrijdag 21 juni 2024 @ 12:01:
Wel apart dat je server dit aangeeft, als ik naar je SMART waardes kijk zijn deze helemaal niet slecht.
Deze staan op 0, ik had dan wel verwacht dat deze hoger is.

Reallocated_Sector_Ct
Current_Pending_Sector

Misschien dan toch maar eens de kabel vervangen zoals Renault aangaf.
Wat ik wel vreemd vind is dat Current_Pending_Sector eerder wel een waarde boven de 0 heeft aangegeven. Kun die waarde ook weer terugvallen naar 0 dan?

[rikadoo]

Ja deze waarde kan weer 0 worden, als de schijf toch de 'eerder' slecht gelezen sectoren als goed beschouwd dan zakt deze waarde weer.
Ik zou nu ook verwachten dat je schijf wel goed/beter presteert. Ik zou als ik jou was de kabel vervangen en kijken wat er gebeurd, en dan al je data back-uppen naar een andere disk.

Hoe zit het met het benaderen van je disk nu dan? Gebeurd dit via samba o.i.d.?

[jeroen3]

Zolang de disk geen fysiek probleem heeft kan ddrescue hem lezen. Alleen kan dit weken duren.

Je kunt ddrescue ook in een andere volgorde laten werken.

[Stanton]

3raser schreef op vrijdag 21 juni 2024 @ 09:15:
[...]

Blijkbaar werkt een herstart van ddrescue heel goed tegen dit soort traagheid. Na de herstart lijkt hij weer op de normale (trage) snelheid door te werken en er dus geen duizenden dagen meer over te doen.

Wat herstart je precies? Het systeem of alleen ddrescue? Ik legde al uit:

Een andere truc is het veranderen van time-out settings en de read afbreken (middels een reset) wanneer het achtergrond proces de read vertraagt en dan direct daarop hetzelfde blok opnieuw lezen, voordat de schijf zich opnieuw gaat bezighouden met achtergrond processen.

Bij voorkeur stuur je reset commando's naar de drive, maar als de drive dit negeert is volgende stap een power-cycle, de schijf reboot zichzelf, gedraagt zich weer enige tijd om dan vervolgens weer trager te worden. Pro grade tools maar ook HDDSuperClone (gekoppeld aan relay) kunnen wanneer de reads trager worden dan vooraf ingestelde time-out de power-cycle afhandelen en na de drive te hebben herstart het imagen of clone hervatten.

Maar als je bedoelt dat je alleen ddrescue zelf herstart, dan is dit niet de verklaring. Het lijkt dan eerder een ddrescue dan een drive probleem.

[3raser]

rikadoo schreef op vrijdag 21 juni 2024 @ 12:23:
Hoe zit het met het benaderen van je disk nu dan? Gebeurd dit via samba o.i.d.?

De schijf is op de normale manier niet benaderbaar. Dat wil zeggen, als mount binnen Linux. Ddrescue kan hem blijkbaar nog wel lezen, al is het op extreem trage wijze (momenteel ongeveer 1600Kb/s).

Stanton schreef op vrijdag 21 juni 2024 @ 13:14:
Wat herstart je precies? Het systeem of alleen ddrescue?

Ik herstartte zojuist alleen ddrescue. En het is niet dat de schijf toen in eens snel werd, maar er was toen wel weer vooruitgang i.p.v. dat ddrescue compleet leek te zijn gestagneerd.

[rikadoo]

3raser schreef op vrijdag 21 juni 2024 @ 13:35:
[...]

De schijf is op de normale manier niet benaderbaar. Dat wil zeggen, als mount binnen Linux. Ddrescue kan hem blijkbaar nog wel lezen, al is het op extreem trage wijze (momenteel ongeveer 1600Kb/s).

Kan je hem niet meer opnieuw toevoegen aan je pool dan?

[Stanton]

3raser schreef op vrijdag 21 juni 2024 @ 13:35:


Ik herstartte zojuist alleen ddrescue. En het is niet dat de schijf toen in eens snel werd, maar er was toen wel weer vooruitgang i.p.v. dat ddrescue compleet leek te zijn gestagneerd.

I see. Vreemd.

MBT kabeltjes, je kunt altijd andere potentieel suspect hardware swappen, ook kabels. maar kabel werd eerst genoemd i.v.m. ATA error count. Dat zou iets met CRC errors te maken hebben.

Even een andere invalshoek: Je TS begint met een "ATA Error"-melding.
Zonder een volledige uitdraai van de Smart-tabel denk ik dan meteen aan CRC-errors

Wanneer we naar SMART kijken zien we hier echter geen enkele aanwijzing voor:

199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0

Naar mijn idee is de schijf zelf 'ziek', zeer waarschijnlijk de firmware issue die ik beschreef. En dit is waarschijnlijk de eenvoudigste manier om het imagen/clonen vlot te trekken:

Als laatste mogelijkheid is er het patchen van de firmware waarmee je het achtergrond proces dat ons in de weg zit stop zet. Dit is niet een permanente fix waarmee je de schijf repareert en dus kunt blijven gebruiken alsof er niets aan de hand is!

Demonstratie: YouTube: HDDSuperClone Slow Responding WD Patch 2020 04 04

Ik kan er ook naast zitten. Maar dit is een best educated guess gebaseerd op wat je beschrijft.

Als je je een beetje uit kunt drukken in de Engelse taal kun je het probleem hier bijvoorbeeld posten: https://www.reddit.com/r/datarecovery/. Daar hangen veel mensen rond die werken in data recovery.

[ Voor 6% gewijzigd door Stanton op 21-06-2024 16:40 ]

[3raser]

rikadoo schreef op vrijdag 21 juni 2024 @ 13:56:
[...]


Kan je hem niet meer opnieuw toevoegen aan je pool dan?

Er is geen pool. Het is een losse schijf die als NAS opslag werd gebruikt. Toen hij nog gekoppeld was kon er niks van worden gelezen. Daarom heb ik hem losgekoppeld en ben ik begonnen met ddrescue. En die heeft er zo te zien ook veel moeite mee gezien de leessnelheid.

Stanton schreef op vrijdag 21 juni 2024 @ 13:56:
Naar mijn idee is de schijf zelf 'ziek', zeer waarschijnlijk de firmware issue die ik beschreef. En dit is waarschijnlijk de eenvoudigste manier om het imagen/clonen vlot te trekken:

Die HDDSuperClone werkt zo te lezen niet via een command line en ik heb geen Linux desktop beschikbaar.
Ik sta er op dit moment zo in dat ik die 24 resterende dagen nog afwacht. Ik heb de data gelukkig niet morgen nodig.

[Stanton]

ok

[jeroen3]

Je kunt een oude pc pakken, disk via sata koppelen (niet usb) en dan ddrescue starten naar naar een externe disk (mag wel usb).
Je kunt dit in een live server doen, wat je nu ook hebt volgens mij, maar ata commando's kunnen de boel aardig ophouden als de disk niet meteen antwoord geeft. Dat is ook waarom Windows totaal niet om kan gaan met dit soort dingen en eigenlijk helemaal onbruikbaar wordt.

evt via live cd https://www.system-rescue.org/

En ja dit duurt lang als de disk niet meer tof is. Ik heb dit recent nog voor iemand gedaan met een defecte laptop schijf en dat heeft ~28 dagen geduurd voor een 320 GB schijf. Uiteindelijk alles op een paar MB na kunnen lezen. Die disk had moeite met seeken. Die error liep namelijk rap op.

Een herstelbedrijf kan misschien sneller gaan, maar dan moeten ze waarschijnlijk wel eerst iets repareren.

@Stanton ja, mensen moeten meer rtfm

quote: https://www.gnu.org/softw...nual/ddrescue_manual.html

(First phase; Copying) Copying is done in up to five passes. The first pass reads the non-tried parts of the input file, marking the failed blocks as non-trimmed and skipping beyond them. The second pass runs in the opposite direction as the first pass and delimits the blocks skipped by the first pass. The first two passes also skip beyond slow areas. The areas skipped are tried later in one or three additional passes (before trimming). The copying direction is reversed after each pass until all the rescue domain is tried.