Is this one worth continuing?
February 6th, 2012, 11:27
Got a Maxtor Calypso drive in this weekend from a business, complete with accounting files, database and other essential files. A computer technician initially called me and said a virus had wiped out "the boot sector." (I personally don't know whether that was an accurate statement or not about the virus or "the boot sector.") He attempted to fix it with chkdsk, he says, but could no longer view the drive in Linux afterwards, although it does show up properly under Windows Disk Managment. Hence the phone call to me.
Here is what I've done so far:
1) Hooked it up to PC3000 and copied the resources, tested the heads. Mechanically, it appears to be fine.
2) Fired up DE and attempted to create an image. It appeared to create an image (including errors) until the last 100 or so sectors. At that point, it froze and appeared to freeze DE as well. (In other words, the "stop" and "pause" buttons grayed out, only the drive power button was functional, but when I cycled the power manually, it just returned to the same state.)
3) After rebooting, I attempted to mount the image in DE, but it was unmountable. DE doesn't recognize it as a complete image.
4) Scanned the drive for NTFS structure. It found thousands of files, but no index, no mft records.
5) Just trying to take a short cut, I hooked the drive up to a write-blocker and attempted to scan it with GDB, no NTFS structure or files visible.
6) Now, I am imaging the drive with dd_rescue. It's a slow process that is showing 2.5 million bad blocks so far with 40% copied.
So, my questions are:
Are such a high number of bad blocks a typical result of chkdsk? This my first encounter with someone who admitted they used it. If this is really the work of chkdsk, is the game over at this point or is there something I can do to work through this mess? Maybe a reverse image in either DE or dd_rescue? Then run a raw recovery?
Perhaps I'm overlooking the real problem elsewhere while pointing the finger at chkdsk. Maybe someone with experience would be so kind as to tell me whether my suspicion of chkdsk is accurate?
Here is what I've done so far:
1) Hooked it up to PC3000 and copied the resources, tested the heads. Mechanically, it appears to be fine.
2) Fired up DE and attempted to create an image. It appeared to create an image (including errors) until the last 100 or so sectors. At that point, it froze and appeared to freeze DE as well. (In other words, the "stop" and "pause" buttons grayed out, only the drive power button was functional, but when I cycled the power manually, it just returned to the same state.)
3) After rebooting, I attempted to mount the image in DE, but it was unmountable. DE doesn't recognize it as a complete image.
4) Scanned the drive for NTFS structure. It found thousands of files, but no index, no mft records.
5) Just trying to take a short cut, I hooked the drive up to a write-blocker and attempted to scan it with GDB, no NTFS structure or files visible.
6) Now, I am imaging the drive with dd_rescue. It's a slow process that is showing 2.5 million bad blocks so far with 40% copied.
So, my questions are:
Are such a high number of bad blocks a typical result of chkdsk? This my first encounter with someone who admitted they used it. If this is really the work of chkdsk, is the game over at this point or is there something I can do to work through this mess? Maybe a reverse image in either DE or dd_rescue? Then run a raw recovery?
Perhaps I'm overlooking the real problem elsewhere while pointing the finger at chkdsk. Maybe someone with experience would be so kind as to tell me whether my suspicion of chkdsk is accurate?
Re: Is this one worth continuing?
February 6th, 2012, 11:52
Did you try to scan the (partial) image you created with R-Studio?
Also, DE is unlikely to hang the way you're describing. Maybe some problem with your machine?
How many bad sectors did DE show up during imaging? What settings did you use for imaging?
As per your other question about chkdsk, IMHO there is no solid answer. Yes chkdsk can cause irreversible damage to a failing drive, but that's all I can say.
Good Luck!
Also, DE is unlikely to hang the way you're describing. Maybe some problem with your machine?
How many bad sectors did DE show up during imaging? What settings did you use for imaging?
As per your other question about chkdsk, IMHO there is no solid answer. Yes chkdsk can cause irreversible damage to a failing drive, but that's all I can say.
Good Luck!
Re: Is this one worth continuing?
February 6th, 2012, 12:16
@dpc,
My $0.02 about chkdsk:
Assuming you mean uncorrectable read errors (UNC at a SATA level), and not "bad blocks" marked in a filesystem, then in my experience that isn't a typical result of running chkdsk, since chkdsk cannot deliberately cause UNC - however chkdsk can seriously mangle the filesystem, while trying to make it self-consistent.
However, if the drive has an underlying fault then since running chkdsk causes lots of head movement and read & writes, further damage (e.g. causing more UNCs) is a possible result, as northwind said, depending on the exact fault(s) with the drive.
I don't use dd_rescue (personally I found it slower & less configurable, compared to GNU ddrescue), but if its report about 2.5 million bad blocks is correct, that obviously suggests the drive is sick anyway. It would be interesting to see what exact Linux kernel messages are being logged during those read errors.
Personally I suspect the technician who called you had (wrongly) guessed at the diagnosis of a virus, and when they said that they could "no longer view the drive in Linux after [running chkdsk]", they were meaning the GUI drive icon (which represents the filesystem) was no longer shown. That's not the physical drive itself, which is what you were doing by looking in Windows Disk Management (i.e. apples & oranges comparison). The physical drive obviously is recognised by Linux, otherwise you couldn't be running dd_rescue.
My $0.02 about chkdsk:
dpc wrote:Are such a high number of bad blocks a typical result of chkdsk?
Assuming you mean uncorrectable read errors (UNC at a SATA level), and not "bad blocks" marked in a filesystem, then in my experience that isn't a typical result of running chkdsk, since chkdsk cannot deliberately cause UNC - however chkdsk can seriously mangle the filesystem, while trying to make it self-consistent.
However, if the drive has an underlying fault then since running chkdsk causes lots of head movement and read & writes, further damage (e.g. causing more UNCs) is a possible result, as northwind said, depending on the exact fault(s) with the drive.
I don't use dd_rescue (personally I found it slower & less configurable, compared to GNU ddrescue), but if its report about 2.5 million bad blocks is correct, that obviously suggests the drive is sick anyway. It would be interesting to see what exact Linux kernel messages are being logged during those read errors.
Personally I suspect the technician who called you had (wrongly) guessed at the diagnosis of a virus, and when they said that they could "no longer view the drive in Linux after [running chkdsk]", they were meaning the GUI drive icon (which represents the filesystem) was no longer shown. That's not the physical drive itself, which is what you were doing by looking in Windows Disk Management (i.e. apples & oranges comparison). The physical drive obviously is recognised by Linux, otherwise you couldn't be running dd_rescue.
Re: Is this one worth continuing?
February 6th, 2012, 17:06
DE's default is to modify the last two bytes of sector 00 of the image to make it unmountable. Do a sector read of 00 and see. If they are 55 BB, change it to 55 AA and you might have better luck with the other processes.
You can turn off this feature in the task manager section.
Jono
You can turn off this feature in the task manager section.
Jono
Powered by phpBB © phpBB Group.