Disk dying -- Patient has critical evidence. CPR needed!

[Dan]

Afternoon, guys.

SITUATION/411:
Trying to avoid some ultimate data loss here. - Bad superblock reported by fsck.



SIZE-UP:
Make & Model=Maxtor DiamondMax Plus 9 80g

USB at /dev/sdg - external.

Host Operating System version=F11
Running Kernel=Linux **********.*** 2.6.30.10-105.2.23.fc11.x86_64 #1 SMP Thu Feb 11 07:06:34 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

MITIGATING FACTORS:
Was a dual boot drive.
Partitions as follows:

Device Boot      Start         End      Blocks   Id  System
/dev/sdg1   *           1        7295    58597056    7  HPFS/NTFS
/dev/sdg2            7296        7308      104422+  83  Linux
/dev/sdg3            7309        9907    20876467+  83  Linux
/dev/sdg4            9908        9964      457852+   f  W95 Ext'd (LBA)
/dev/sdg5            9908        9964      457821   82  Linux swap / Solaris

sdg1 has the error which is b*tching the works. Gparted, or any other partitioning tool (save palimpsest) locks up whilst reading the drive, resulting in the dreaded "ker-click ... ker-click ... ker-click ..."

Nautilus can read most of it until I access one of two 15.x g directories. So I have been able to fetch some data off this drive. (it was a back-up drive.)

Trouble is, there's critical data in those two inodes.

Fsck complains about the superblock and quits. Says it can't access it.

QTBAs:
1) Am I totally screwed here?
2) If not, any bright ideas to fetch the data save spending money outsourcing it. (Not that critical. If I can't fetch it, I'll drink a toast to it with a cold cup of coffee ... and fetch the magnets. --> Which will happen soon anyway. Hard drives don't heal.)



That, my friends, is the afternoon's conundrum.

Any ideas?


Dan

[brunson]

There are many copies of the superblock.

sudo dumpe2fs <device> | grep -i superblock

then e2fsck with -b to specify an alternate superblock.

[Dan]

Dang.

dumpe2fs 1.41.9 (22-Aug-2009)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdg
Couldn't find valid filesystem superblock.

[BugRocks1]

dd?

noerror
Does not stop processing on an input error. When an input error occurs, a diagnostic message is written on standard error, followed by the current input and output block counts in the same format as used at completion. If the sync conversion is specified, the missing input is replaced with null bytes and processed normally. Otherwise, the input block will be omitted from the output.
notrunc
Does not truncate the output file. Preserves blocks in the output file not explicitly written by this invocation of dd. (See also the preceding of=file operand.)

http://www.inference.phy.cam.ac.uk/s...artitions.html
http://www.garloff.de/kurt/linux/ddrescue/

---------- Post added at 01:47 PM CDT ---------- Previous post was at 01:45 PM CDT ----------

Purpose of dd_rescue
The latter three features make it suitable for rescuing data from a medium with errors, i.e. a hard disk with some bad sectors.
Why?

* Imagine, one of your partitions is crashed, and as there are some hard errors, you don't want to write to this hard disk any more. Just getting all the data off it and retiring it seems to be suitable. However, you can't access the files, as the file system is damaged.
* Now, you want to copy the whole partition into a file. You burn it on CD-Rom, just to never lose it again. You can setup a loop device, and repair (fsck) it and hopefully are able to mount it.
* Copying this partition with normal Un*x tools like cat or dd will fail, as those tools abort on error. dd_rescue instead will try to read and if it fails, it will go on with the next sectors. The output file naturally will have holes in it, of course. You can write a log file, to see, where all these errors are located.
* The data rate drops very low, when errors are encountered. If you interrupt the process of copying, you don't lose anything. You can just continue at any position later. The output file will just be filled in further and not truncated as with other Un*x tools.
* If you have one spot of bad sectors within the partition, it might be a good idea, to approach this spot from both sides. Reverse direction copy is your friend.
* The two block sizes are a performance optimization. Large block sizes result in superior performance, but in case of errors, you want to try to salvage every single sector. So hardbs is best be set to the hardware sector size (most often 512 bytes) and softbs to a large value, such as the default 16k.

Sounds a lot with what you want.

Hello Dan,
That's a bummer, I hate to have to play Taps for those things. I wonder if dd could retrieve the data for ya.

Ky

[Dan]

Ah! dd_rescue is in the repos.

Just mounted the drive in question internally. Palimpsest instantly blew the whistle on it.

Irritating.

I just checked that drive a week ago, (Using F13 Beta LiveCD) and it reported as being just peachy-keen fine. <....>

Fat lot of warning I got on that one.

[Chilly Willy]

My first thought - image it ASAP - & do nothing else with it until then.

Let us know when the funeral is, I'll send flowers... :-)

[BugRocks1]

[fun]When it dies you can test the iron oxide method LoL[/fun]

http://www.tetherdcow.com/?p=7497

On serious note there is a video of a guy who owns a rescuing company that gave a talk at shmoocon 2010 maybe there is in there some good tips.

DIY Hard Drive Diagnostics: Understanding a Broken Drive
http://www.shmoocon.org/presentations-all.html#wifibomb

link to the video(376MB):
http://www.shmoocon.org/2010/videos/HDDiag-Moulton.m4v

[stevea]

Originally Posted by Dan

....
Partitions as follows:

Device Boot      Start         End      Blocks   Id  System
/dev/sdg1   *           1        7295    58597056    7  HPFS/NTFS
...

sdg1 has the error which is b*tching the works.

Fsck complains about the superblock and quits. Says it can't access it.

Originally Posted by brunson

There are many copies of the superblock.

sudo dumpe2fs <device> | grep -i superblock

then e2fsck with -b to specify an alternate superblock.

NTFS FS (the sg1 fs) don't have superblocks and can't be recovered w/ dumpe2fs, an ext2/3 tool.


The ntfsprogs utility might help, but I think you'll find stronger ntfs recovery tools in the Redmond OS.
ntfsfix /dev/sg1
ntfsck /dev/sg1

[BugRocks1]

Nice educational videos about recovery/problems.
http://www.youtube.com/user/SuperFly.../0/vCapEFNZAJ0

---------- Post added at 06:06 PM CDT ---------- Previous post was at 05:56 PM CDT ----------

At 11:20 in the video he gives out the tools that work for him for imaging disks:

- MyRescue (http://myrescue.sourceforge.net/)
- DDRescue(lin)
- Media Tools Pro(win)
- SpeedClone
- HD Duplicator
- CopyR DMA
- ByteBack
- Ultimate Boot CD (http://www.ultimatebootcd.com/)

http://www.myharddrivedied.com/presentations/

[Firewing1]

When I was in a similar situation I was able to recover it by freezing the drive [1] and then running dd:

dd if=/dev/sdg of="/media/BackupDisk/sdg.img" bs=512 conv=noerror

That will attempt to read the drive 512 bytes at a time and continue if any errors are encountered. You can speed the process up by increasing the value of "bs" to 1024 or even higher for example, but then you risk losing larger portions of data should a sector be unreadable.

[1] http://www.firewing1.com/v1/77

Edit: Also, if you would like progress reports as dd is running, run:

killall -SIGUSR1 dd

On the terminal running dd there should be some information displayed.

[beaker_]

+1 for ddrescue. Just remember that depending on the type of failure, that old harddrive may not survive dragging those heads across its surface so don't bastardize your image right away. Back it up to.

[Dan]

Epilogue:

Well, in the end, I retrieved about 15 useful gigabytes of data from the drive. The linux partitions remained unaffected until just before the very end. The NTFS partition, however, went quickly into cascade failure. What started as a dozen or so bad blocks had become hundreds after an hour's work, and probably thousands after I finally shut it down, and let it cool down. ddrescue fetched a bunch of it, but we rapidly hit the point of diminishing returns, and I decided to re-asses my need for that data which remained.

Long story short, yeah. I lost some data. But on the bright side, my cell phone is now hanging from the arm of my desk lamp suspended there by a spanking new set of really strong magnets. The remains of the drive are living in the bottom of a ferrous metal sorting bin somewhere in a northeast Texas recycling facility.

And that's good enough for me. I wish it well.

What's left of it, anyway.

<-30->

[Chilly Willy]

RIP