public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-amd64@lists.gentoo.org
Subject: [gentoo-amd64]  Re: not amd64 specific - disk failure
Date: Mon, 19 Nov 2007 17:14:59 +0000 (UTC)	[thread overview]
Message-ID: <pan.2007.11.19.17.14.59@cox.net> (raw)
In-Reply-To: 47418F30.6050607@st.com

Raffaele BELARDI <raffaele.belardi@st.com> posted 47418F30.6050607@st.com,
excerpted below, on  Mon, 19 Nov 2007 14:27:12 +0100:

> Most of the resources I've read up to now imply that e.g. /dev/sdc1 is
> detected and a 'bad superblock' message displayed when attempting to
> mount.
> 
> In my case the kernel is unable to detect /dev/sdc1, after the long list
> of read errors below it ends up with only /dev/sdc.
> 
> Does this look like superblock issue, or something worse?

If you have a spare drive of the same size or larger, you can try dd, or 
probably better yet, merge dd-rescue and try it.  They copy a file or 
part of one, in this case an entire block device, from one location to 
another, "raw".  What you want to do is copy the entire bad device, /dev/
sdc above, to the new device.  Then you have a copy to play around with 
without worrying about making the bad device worse before you get 
whatever you were trying to get off of it, off.

dd-rescue is different than dd in that if there are bad blocks, it will 
run until it starts hitting them, then it will work backwards from the 
other end until it hits them there, then it'll try blocks in the middle.  
Thus, if you have good blocks, bad blocks, good blocks, bad blocks, good 
blocks, dd-rescue recovers more of the disk in a reasonable amount of 
time, as compared to straight dd, which will try straight thru only.

(The problem is that once you start hitting bad blocks, everything slows 
down, because the system tries and retries the bad block multiple times 
before giving up, taking minutes to read a block or finally decide it 
can't, before moving on, where it'd read a good block in seconds.  Thus, 
to work thru even a few hundred bad blocks can take DAYS.  Giving up 
after a few and starting from the other end, then trying in the middle, 
increases the number of blocks recovered, without sitting there waiting 
for days for it to work thru all the bad ones and get to the rest of the 
good ones again, and that's what dd-rescue does for you, automates the 
give up and try from the other end and then in the middle stuff.)

The thing to remember when working with either program is that you want 
to be **VERY** **SURE** you get the right devices specified, particularly 
for the output device.  If you tell it to write to the device that your 
main system is on instead of the new empty device, it WILL overwrite your 
main system device, boot record, partition table, and all.  Thus, make 
TRIPLE SURE you have the right output device specified before you hit 
that enter key.

The reason I'm suggesting dd/dd-rescue is because they'll grab the raw 
data (what they can of it) directly off of the device you point them at (/
dev/sdc above, but as I said, be absolutely sure the devices aren't 
reordered after you attach the new one).  Since you can't mount the 
partition, you need something that can grab the info off of the 
unpartitioned drive itself.  Then, once you get a copy to work with, you 
can check what fdisk says about it and go from there.

In fact, if the data is worth it and you have the money, you may want to 
get TWO replacement drives, one to make a "safe" copy to, and a second to 
make a working copy (from the safe copy) to.  Then you play with the 
working copy, and if you screw up, you can simply recopy from the safe 
copy, without having to go back to the damaged drive -- because it's 
possible you'll only get the one chance to get stuff off of the damaged 
one.

If the damage is severe enough dd-rescue can't pull anything off, 
consider wrapping the drive in paper for padding and moisture absorption) 
then plastic (preferably double- or triple-wrapped), then put it in your 
freezer overnight.  There are quite a number of tales of folks that had 
dead drives that they were able to revive long enough by freezing them, 
to get the stuff or at least part of the stuff off that they needed to.  
Keep in mind that as soon as you take it out and plug it in, it'll start 
warming up, and you may only have a few minutes, if it's bad enough.  In 
that case, if you have just a few smaller files you really want, you can 
hope the filesystem is usable again, and you may have time enough to 
retrieve them.  If that's not the case, and you need to go for the bulk, 
then you can write down how far you get, then try freezing it again, and 
tell dd-rescue to start where it stopped the second time.  Of course, you 
may have a limited number of times even freezing the drive will work, and 
you likely won't recover the entire thing this way, but if some is better 
than none...

There are special forensics LiveCD distributions out there.  Try STD and 
INSERT (google them, that's how I found them), both based off KNOPPIX, I 
believe.  INSERT is small enough to fit on the small credit/business-card 
sized CD, 180 MB or some such.  STD is a full-sized CD-image, basically a 
normal KNOPPIX only with enough stuff removed to load the extra forensics/
recovery/etc tools.  It even still has some games (Frozen Bubble, etc) on 
it.  They may help you recover something workable off the image you 
copied over with dd-rescue.  Of course, since they have a bunch of 
programs, including AV and other MS Windows recovery stuff (there's a 
nice MS eXPrivacy password blanker utility on there, my boss ran into 
trouble, hadn't created a password reset disk, and I had to use it on his 
box, yes, it was his), and network troubleshooting stuff as well, you'll 
probably want to grab them and play around with them a bit to see what 
they are like, before actually starting to work on recovering your data.

Hope that's useful.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list



  parent reply	other threads:[~2007-11-19 17:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-19 10:05 [gentoo-amd64] not amd64 specific - disk failure Raffaele BELARDI
2007-11-19 11:52 ` Beso
2007-11-19 13:27   ` Raffaele BELARDI
2007-11-19 13:56     ` Beso
2007-11-19 17:14     ` Duncan [this message]
2007-11-20  7:47       ` [gentoo-amd64] " Raffaele BELARDI
2007-11-20  9:01         ` Beso
2007-11-20 10:06           ` Raffaele BELARDI
2007-11-20  9:41         ` Duncan
2007-11-20 10:25           ` Raffaele BELARDI
2007-11-21  9:24         ` Raffaele BELARDI
2007-11-21 10:20           ` Raffaele BELARDI
2007-11-22  9:36             ` [gentoo-amd64] Re: not amd64 specific - disk failure - SUCCESS Raffaele BELARDI
2007-11-23 10:07               ` Duncan
2007-11-21 14:45           ` [gentoo-amd64] Re: not amd64 specific - disk failure Billy Holmes
2007-11-21 15:24             ` Raffaele BELARDI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=pan.2007.11.19.17.14.59@cox.net \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-amd64@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox