From: "Ryan B. Lynch" <rlynch@strozllc.com>
To: maarten van den Berg <maarten@vbvb.nl>
Cc: linux-raid@vger.kernel.org
Subject: Re: two-disk-failure question
Date: Wed, 22 Oct 2003 12:55:12 -0400 [thread overview]
Message-ID: <3F96B670.2020802@strozllc.com> (raw)
In-Reply-To: <200310172315.56815.maarten@vbvb.nl>
Hey Maarten,
Maarten van den Berg wrote:
>cables and such. So my obvious question is: Is this step (mkraid --force
>with one of the offline disks defined as failed-disk) destructive, or could I
>(theoretically) experiment endlessly with the order in which the disks are
>defined in /etc/raidtab before I decide to mount it read-write and raidhotadd
>a fresh disk ?
>
I had to do this about a year ago, on account of a bad IDE controller,
and was successful on the first try. I recall from the HOWTO that the
'mkraid --force' command IS destructive, and it WILL lose the array if
you get it wrong.
My incident involved data which would have been a bear to restore from
backup, so I didn't take any chances. Prior to the 'mkraid --force'
step, I labelled each physical disk with it's number in the array, and
then copied each disk to an identical disk using the 'dd' command
[somthing like 'dd if=/dev/sda of=/dev/sdb bs=8192' where /dev/sda is
the original and /dev/sdb is a handy blank disk, repeated for each
original disk in the array]. Of course, this required five extra hard
disks, but I had them lying around anyway. And that's the foolproof
method. If you're really paranoid (you don't have a backup of the
failed array), you might want to also do an 'md5sum /dev/sdb; md5sum
/dev/sda' and compare the two hash values to ensure that each copy is
faithful--re-do the copy that doesn't pass the hash check. Since you're
juggling so many hard drives, make sure you label all the
disks--scotch-taped sticky notes on the cover, with the array #s written
in felt pen worked for me.
Then, you can run off and do whatever with the originals, and you'll
always have something to go back to if you utterly wipe out your array
while trying to restore it. If that happens, you just take the
clobbered disks, and re-do the 'dd' command to write the copy back to
the originals. Hash if necessary, and go to town again. Repeat until
you either successfully restore the array, or you swear off computers
and enroll in florists' school.
Keep in mind that this can add a LOT of time to a restore operation.
With Western Digital WD200 IDE disks (7200 RPM, 18.6 GB), I can move
about 30-22 MB/sec (beginning-end) on direct disk-to-disk copies like
this, with an average around 25 MB/sec. That's ~1.5 GB/min, so you can
estimate your own ETAs. Hashing will take a similar amount of time if
you use 'md5sum' on a reasonably fast machine (P4 1.8+).
-R
prev parent reply other threads:[~2003-10-22 16:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-17 21:15 two-disk-failure question maarten van den Berg
2003-10-22 16:55 ` Ryan B. Lynch [this message]
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=3F96B670.2020802@strozllc.com \
--to=rlynch@strozllc.com \
--cc=linux-raid@vger.kernel.org \
--cc=maarten@vbvb.nl \
/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;
as well as URLs for NNTP newsgroup(s).