Ik heb al behoorlijk wat recovery werkzaamheden verricht met de welbekende tools (heb GetDataBack aangeschaft een hele poos geleden nadat dit programma voor een kennis zijn manuscript (waar uiteraard geen backup van was) volledig hersteld heeft), maar nu heb ik last van het volgende:
Probleem: Een kennis van mij heeft een kapotte externe HDD van 6 maanden oud. Het slachtoffer: Een WD Elements 2TB USB 3.0 schijf. Alle foto's van de baby tussen 0 en 9 maanden foetsie.
Na mijn dreigement dat ze eerst gaan zorgen voor een goede backupoplossing (in de vorm van auto-sync met Dropbox+abbo voor meer storage en een NAS) en zij dit inmiddels geregeld hebben, wilde ik eens proberen om de foto's te redden. Bij de scan van GetDataBack sector 1640000 komt een Read error 23. Normaal geen probleem, die negeer je en hij gaat vrolijk verder. Maar de schijf die via USB is aangesloten doet automatisch een disconnect (unmount geluidje van XP klinkt ook) waardoor GDB alleen nog maar een aantal Error 55's er uit gooit. Enige manier om weer in contact te komen met de schijf is USB kabel los en weer vast.
Ik heb geprobeerd:
-De originele GDB config zoals ik die altijd gebruik (HP NX7300, 1GB, XP, USB3.0 SATA geval) - probleem
-Andere controller (Diginote USB2.0 2.5" gemod met 12V zodat 3.5" ook werkt) - zelfde probleem
-Andere controller (no-name IDE+SATA USB geval) - zelfde probleem
-Andere notebook (HP 6715s met Win7 Enterprise) - zelfde probleem
-Vaste PC met NForce2 Sata controller - Loopt vast bij de probleemsector, geeft zelfs geen error
-Andere recoverysoftware in de vorm van Recuva en Ontrack Easy Recovery - zelfde probleem
Nu kom ik er net achter dat als ik de startsector op ergens rond de 20% van de schijf zet, hij vrolijk verder gaat met uiteraard een hoop geklik en Error 23's, maar hij NIET disconnect.
De vraag: Hoe voorkom ik dat hij disconnect en zou het nog zin hebben om nog een Intel-based storage controller te proberen, of een actie met een linux-based OS? Of begint Windows een schijf "aan 't eind" te beschrijven en is er kans dat de foto's alsnog tevoorschijn komen? Laat de scan nu uiteraard lopen maar je weet maar nooit of hij er weer mee kapt..
Probleem: Een kennis van mij heeft een kapotte externe HDD van 6 maanden oud. Het slachtoffer: Een WD Elements 2TB USB 3.0 schijf. Alle foto's van de baby tussen 0 en 9 maanden foetsie.
Na mijn dreigement dat ze eerst gaan zorgen voor een goede backupoplossing (in de vorm van auto-sync met Dropbox+abbo voor meer storage en een NAS) en zij dit inmiddels geregeld hebben, wilde ik eens proberen om de foto's te redden. Bij de scan van GetDataBack sector 1640000 komt een Read error 23. Normaal geen probleem, die negeer je en hij gaat vrolijk verder. Maar de schijf die via USB is aangesloten doet automatisch een disconnect (unmount geluidje van XP klinkt ook) waardoor GDB alleen nog maar een aantal Error 55's er uit gooit. Enige manier om weer in contact te komen met de schijf is USB kabel los en weer vast.
Ik heb geprobeerd:
-De originele GDB config zoals ik die altijd gebruik (HP NX7300, 1GB, XP, USB3.0 SATA geval) - probleem
-Andere controller (Diginote USB2.0 2.5" gemod met 12V zodat 3.5" ook werkt) - zelfde probleem
-Andere controller (no-name IDE+SATA USB geval) - zelfde probleem
-Andere notebook (HP 6715s met Win7 Enterprise) - zelfde probleem
-Vaste PC met NForce2 Sata controller - Loopt vast bij de probleemsector, geeft zelfs geen error
-Andere recoverysoftware in de vorm van Recuva en Ontrack Easy Recovery - zelfde probleem
Nu kom ik er net achter dat als ik de startsector op ergens rond de 20% van de schijf zet, hij vrolijk verder gaat met uiteraard een hoop geklik en Error 23's, maar hij NIET disconnect.
De vraag: Hoe voorkom ik dat hij disconnect en zou het nog zin hebben om nog een Intel-based storage controller te proberen, of een actie met een linux-based OS? Of begint Windows een schijf "aan 't eind" te beschrijven en is er kans dat de foto's alsnog tevoorschijn komen? Laat de scan nu uiteraard lopen maar je weet maar nooit of hij er weer mee kapt..
[ Voor 4% gewijzigd door RadioAir op 19-12-2012 22:03 ]