SpinRite ervaring / vraag

Pagina: 1
Acties:

  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
Ik heb sinds een tijdje een nieuwe PC met Windows 7... van mijn oude PC (XP) de extra harddisk (minder dan een jaar oud) overgezet in de nieuwe... in het begin geen problemen, alhoewel de toegang tot de extra harddisk wat traag leek... tot op een gegeven moment mijn PC ineens niet meer aan wilde... extra harddisk losgekoppeld en de extra harddisk bleek het probleem... harddisk vervangen en de oude harddisk aan een externe behuizing gehangen en via USB gekoppeld aan een laptop...

eerst geprobeerd met Acronis een backup te maken van de oude HD om via die weg de nodige files terug te kunnen krijgen... helaas... Acronis ging tot 7 procent en stopte na een week uit zichzelf met backuppen...

Toen SpinRite aangezet... SpinRite is keihard aan het werk :), maar is nu 407 uur bezig en heeft pas 1.67% geprocessed.... en alles wat hij geprocessed heeft staat op "processed" en niet op "recovered/unrecovered/defective".. m.a.w. in de eerste 1.67% lijken geen beschadigde sectoren te zitten...

Er lijkt dus geen beschadiging te zijn in de eerste 1.67%, maar toch gaat alles supertraag... Op een of andere manier doet dat bij mij het vermoeden rijzen dat de harde schijf zelf misschien wel niet beschadigd is, maar misschien wel de leeskop of een ander onderdeel van de schijf.

Mijn vragen zijn nu:
- is mijn gedachte gang mogelijk? en zo ja, enig idee hoe dit op te lossen?
- begrijp ik de blokjes die spinrite weergeeft wel goed, of zijn er misschien toch beschadigingen?
- kan er nog een andere reden zijn waarom spinrite er zo ontzettend lang over doet?

even ter aanvulling:
na mijn laatste backup van de harde schijf heb ik nog een aantal bestanden die redelijk lastig na te maken zijn op de harde schijf staan... deze wil ik graag terug hebben... het is geen ramp als het niet lukt, maar het is ook een beetje de "sport" om het toch voor elkaar te krijgen ;)

Verwijderd

Lees je SMART uit en je weet precies om hoeveel bad sectors het gaat.

Verder, je kunt SpinRite laten starten op een ander begin dan 0% door shift+enter bij de laatste stap te doen, staat er ook dus lees de schermpjes goed door voordat je op enter drukt, want ergens doe je dan shift+enter en kun je het percentage opgeven waar hij moet beginnen. Skip die eerste paar bad sectoren en kijk wat je verder kunt recoveren.

Maar ik raad je sterk aan de SMART eerst uit te lezen; anders vernietig je bewijs. Gebruik HDtune of CrystalDiskInfo om de SMART uit te lezen. Current Pending Sector = actieve bad sectors, Reallocated Sector count = passieve bad sectors, UDMA CRC Error Count = kabelfouten. Dat zijn de drie belangrijkste SMART attributen.

Veel mensen denken bij SMART aan de stomme self-tests. SMART is echter vooral nuttig omdat je direct kunt zien of er bekende problemen zijn met de schijf zoals kabeldefecten en bad sectors. Dat kun je in één opslag zien want de schijf zelf weet dit. Enige bad sectors die niet in je SMART voorkomen is als je sommige plekken van je schijf lange tijd niet hebt 'aangeraakt'. Maar in dat geval kunnen die bad sectors ook niet voor problemen hebben gezorgd; want dan zou de schijf die bad sector wel kennen en zal de Current Pending Sector raw value hoger zijn.

Dus post hier je SMART en probeer de tip met SpinRite shift+enter daarna. Dan kom je al een heel eind. Andere methode is om een ruwe dump te maken onder Linux met een minstens even zo grote schijf. Maar probeer eerst bovenstaande suggesties eens.

  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
ik heb de trial versie van HDTune en CrystalDiskInfo geinstalleerd en gerund...

dit zijn de resultaten...
Afbeeldingslocatie: http://www.formulaworld.com/got/1.JPG
Afbeeldingslocatie: http://www.formulaworld.com/got/2.JPG
Afbeeldingslocatie: http://www.formulaworld.com/got/3.JPG
Afbeeldingslocatie: http://www.formulaworld.com/got/4.JPG

RAW Read Error Rate is dus blijkbaar het ergste... geen idee wat het inhoudt :(

Verwijderd

Nee dat is niet het probleem; daarom moet je ook NOOIT de interpretatie van SMART overlaten aan programma's. Vrijwel zeker dat ze je ALTIJD een foutief advies geven. Zo ook in dit geval.

Je RRER is roodgekleurd, calibration retry ook maar het enige wat ROOD met knipperlichten zou moeten worden weergegeven is de Current Pending Sector count, dat is hét probleem zoals zo vaak.

Je hebt dus 4065 onleesbare sectoren op deze schijf. Dat zijn er zoveel dat ik denk dat SpinRite geen oplossing is. De schijf is sowieso kansloos verloren, voor recovery zul je moeten proberen zoveel mogelijk er vanaf te halen. Dit kan onder andere met een speciaal dd commando onder Linux, waarbij de opties 'conv=sync,noerror' worden gebruikt om een ruwe kopie van de schijf te maken en daarbij de onleesbare bad sectors over te slaan. Op de doelschijf waar je alles naartoe schrijft krijg je dan een 1:1 kopie van je bronschijf die problemen heeft, exclusief de bad sectors die blijven gewoon leeg. De hoop is dan dat je met de nieuwe doelschijf kunt recoveren omdat deze dus enkel datacorruptie heeft doordat de inhoud van 4065 sectoren met nullen wordt verhuld, maar.. die schijf heeft geen bad sectors en kun je dus ook prima recovery mee proberen.

  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
Verwijderd schreef op dinsdag 18 september 2012 @ 10:35:
Nee dat is niet het probleem; daarom moet je ook NOOIT de interpretatie van SMART overlaten aan programma's. Vrijwel zeker dat ze je ALTIJD een foutief advies geven. Zo ook in dit geval.

Je RRER is roodgekleurd, calibration retry ook maar het enige wat ROOD met knipperlichten zou moeten worden weergegeven is de Current Pending Sector count, dat is hét probleem zoals zo vaak.

Je hebt dus 4065 onleesbare sectoren op deze schijf. Dat zijn er zoveel dat ik denk dat SpinRite geen oplossing is. De schijf is sowieso kansloos verloren, voor recovery zul je moeten proberen zoveel mogelijk er vanaf te halen. Dit kan onder andere met een speciaal dd commando onder Linux, waarbij de opties 'conv=sync,noerror' worden gebruikt om een ruwe kopie van de schijf te maken en daarbij de onleesbare bad sectors over te slaan. Op de doelschijf waar je alles naartoe schrijft krijg je dan een 1:1 kopie van je bronschijf die problemen heeft, exclusief de bad sectors die blijven gewoon leeg. De hoop is dan dat je met de nieuwe doelschijf kunt recoveren omdat deze dus enkel datacorruptie heeft doordat de inhoud van 4065 sectoren met nullen wordt verhuld, maar.. die schijf heeft geen bad sectors en kun je dus ook prima recovery mee proberen.
ok... bedankt voor je uitleg... nu nog ergens een linux machientje zoeken :)
ubuntu cd'tje moet vast wel lukken he? ;)

Verwijderd

Ik gebruik Ubuntu voor recovery ja. Maar welke route wil je nu precies proberen?

Je hebt de gegevens nog nodig van de schijf die nu vol zit met bad sectors? Zo ja, als je dit onder Linux wilt doen, gaat dat grofweg zo:

1) boot van de LiveCD; installeren is niet nodig
2) check hoe je disks heten via de disk utility; bijvoorbeeld /dev/sda voor je probleemschijf terwijl /dev/sdb een nieuwe lege schijf is die je voor recovery gaat gebruiken. Deze nieuwe '/dev/sdb' schijf moet minimaal even groot zijn als de probleemschijf /dev/sda. Check driedubbel of je de juiste diskbenaming gebruikt.
3) in een root terminal (sudo su) kun je het volgende doen:

dd if=/dev/sda of=/dev/sdb bs=1m conv=sync,noerror

Dit commando 10 keer controleren!
if = input file, hiervan ga je lezen
of = output file, hierna toe ga je schrijven (dus of=/dev/sdb betekent dat sdb helemaal wordt overschreven!)
bs = blocksize, dan gaat het wat sneller
conv = speciale filters, in dit geval zéér belangrijk. De noerror zorgt dat dd doorgaat met kopiëren ook al komt hij een onleesbare sector tegen, en extreem belangrijk: de sync zorgt ervoor dat bij zo'n bad sector de doelschijf ook met nulletjes wordt opgevuld, anders slaat de doelschijf de bad sectors over en klopt het niet meer omdat vanaf dat moment alle data op de verkeerde plek terecht komt (net één sector te vroeg). Dat is corruptie en dus moet je conv=sync,noerror gebruiken.

Wees alsjeblieft voorzichtig met dd. Ontkoppel alle schijven die je niet nodig hebt; zodat je enkel de probleemschijf en de nieuwe doelschijf hebt aangekoppeld.

Nadat je de doelschijf hebt volgeschreven kan je deze aan windows koppelen en proberen te recoveren. Chkdsk zou ik eerst mee proberen en kijken wat er over blijft. Anders gewoon echte recoveryprogramma's - daar zijn er heel veel van.

  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
Verwijderd schreef op dinsdag 18 september 2012 @ 14:54:
Ik gebruik Ubuntu voor recovery ja. Maar welke route wil je nu precies proberen?

Je hebt de gegevens nog nodig van de schijf die nu vol zit met bad sectors? Zo ja, als je dit onder Linux wilt doen, gaat dat grofweg zo:

1) boot van de LiveCD; installeren is niet nodig
2) check hoe je disks heten via de disk utility; bijvoorbeeld /dev/sda voor je probleemschijf terwijl /dev/sdb een nieuwe lege schijf is die je voor recovery gaat gebruiken. Deze nieuwe '/dev/sdb' schijf moet minimaal even groot zijn als de probleemschijf /dev/sda. Check driedubbel of je de juiste diskbenaming gebruikt.
3) in een root terminal (sudo su) kun je het volgende doen:

dd if=/dev/sda of=/dev/sdb bs=1m conv=sync,noerror

Dit commando 10 keer controleren!
if = input file, hiervan ga je lezen
of = output file, hierna toe ga je schrijven (dus of=/dev/sdb betekent dat sdb helemaal wordt overschreven!)
bs = blocksize, dan gaat het wat sneller
conv = speciale filters, in dit geval zéér belangrijk. De noerror zorgt dat dd doorgaat met kopiëren ook al komt hij een onleesbare sector tegen, en extreem belangrijk: de sync zorgt ervoor dat bij zo'n bad sector de doelschijf ook met nulletjes wordt opgevuld, anders slaat de doelschijf de bad sectors over en klopt het niet meer omdat vanaf dat moment alle data op de verkeerde plek terecht komt (net één sector te vroeg). Dat is corruptie en dus moet je conv=sync,noerror gebruiken.

Wees alsjeblieft voorzichtig met dd. Ontkoppel alle schijven die je niet nodig hebt; zodat je enkel de probleemschijf en de nieuwe doelschijf hebt aangekoppeld.

Nadat je de doelschijf hebt volgeschreven kan je deze aan windows koppelen en proberen te recoveren. Chkdsk zou ik eerst mee proberen en kijken wat er over blijft. Anders gewoon echte recoveryprogramma's - daar zijn er heel veel van.
cool... heel erg bedankt !
ik heb de probleemschijf (500 Gb) extern via USB aan een laptop zitten waar ik de ubuntu live cd in heb gedaan... ben nu op een pc mijn externe harddisk aan het leegmaken (data ff op mijn harde schijf aan het zetten)... en ga dan bovenstaande doen.. (en goed controleren dus :))...

ik laat het resultaat weten... mocht er niets te herstellen zijn heb ik pech, maar wel weer wat geleerd ;)

  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
het ziet er niet al te best uit (of ik interpreteer het verkeerd)...

heb exact jouw commando overgenomen (alleen andere disknames)

hij is nu bijna een dag bezig en krijg iedere seconde ongeveer een nieuw regeltje tekst.. dat loopt dus lekker door... maar de inhoud van die regeltjes is niet al te hoopgevend:

code:
1
2
3
4
dd: reading '/dv/sdb': Input/output error
24461+12459 records in
36920+0 records out
38713425920 bytes (39 GB) copied, 82169.6 s, 471 kB/s


regel 1 is vanaf het begin af aan al het zelfde.... regel 2 en 3 weet ik niet of die hetzelfde zijn... maar het valt me op dat records in en records out iig niet gelijk zijn...

over de laatste regel, ik weet niet hoe lang, maar het eerste getal is al een tijdje hetzelfde... het laatste getal, de snelheid, was gisteren toen ik het proces startte zo rond de 950 kB/s... das dus aardig ingekakt...

en net nu ik dit typ kijk ik naar het scherm en valt me op dat het scherm niet meer update... de regel zoals ik hierboven in de code heb getypt is EXACT het laatste in het venster....

laat hem wel doorlopen... vraag me wel af of ik het terecht somber inzie of dat dit allemaal nog niets zegt?

edit:
toegevoegd:

nu 24 uur later loopt hij in ieder geval weer door... nog steeds zelfde melding en zelfde snelheid... totaal 76Gb verwerk.... de schijf is 500 Gb, dus hij is nog wel even bezig

edit:
toegevoegd:

nu 11:30 uur, is de harde schijf begonnen met kabaal te maken... ongeveer iedere seconde een tik... klinkt niet goed :(... het dd-proces lijkt ook stil te staan...

[ Voor 13% gewijzigd door P.O. Box op 21-09-2012 11:34 ]


  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
even een update, misschien dat er iets zinnigs over te zeggen valt door deze of gene :)

het dd proces loopt nog steeds... het getik van de harde schijf is na ongeveer 2 uur afgelopen... daarna ging hij verder met steeds dezelfde meldingen...

afgelopen dinsdag was het terminal venster van ubuntu ineens zwart... er leek helemaal niets te gebeuren... dit is zo gebleven tot vandaag... toen ik vanmorgen keek stonden er weer lettertjes... echter niet zoals er eerst stond, maar nu:

code:
1
2
3
4
dd: reading '/dev/sdb': Input/output error, 113 kB/s
71646+12463 records in: Input/output error, 114 kB/s
84109+0 records out88 GB) copied, 777529 s, 113 kB/s
88194678784 bytes (88 GB) copied, 777608 s, 113 kB/s


en exact deze regels (dus dezelfde getallen) herhalen zich continue...

verschil met vorige week is nu dat er 2 regels (van de 4) zijn met "Input/output error", terwijl dat er vorige week maar 1 was.... verder is de laatste kolom met de snelheid drastisch kleiner qua waarde.
Pagina: 1