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
next prev 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