[SATLUG] 1st question - RAID5 quit - Retrieving data
adlabens at swbell.net
Sat Aug 22 07:01:43 CDT 2009
To get the new drive connected, I'll need to disconnect one of the old drives - there are only 5 SATA connections on the motherboard, so that's why I was asking if it would be ok to physically remove /sdb (least events).
So, I need to remove one, and might want to remove all but the suspect /sdc so that I'm not inadvertently messing with one of the good drives.
What do you think of this?
I'll also need to do something to the new drive so that the OS will recognize it and so that ddrescue will be able to use it as the target drive.
Is that the "sfdisk -d /dev/sda | sfdisk --force /dev/sdf" command?
I'm at work again today, and we have dinner this evening with cousins who are dropping their oldest off at UTSA for her freshman year, so I'll be able to get & respond to emails during the day. I would very much like to be able to move forward tonight with extracting the data from the /sdc drive.
San Antonio, TX
--- On Fri, 8/21/09, Samuel Leon <satlug at net153.net> wrote:
From: Samuel Leon <satlug at net153.net>
Subject: Re: [SATLUG] 1st question - RAID5 quit - Questions
To: "The San Antonio Linux User's Group Mailing List" <satlug at satlug.org>
Date: Friday, August 21, 2009, 11:33 PM
David Labens wrote:
> First, the setup:
> All the drives are the same age, purchased at the same time, installed simultaneously, and brought online together. The event counts, however, show:
> /sda1 = 2986
> /sdb1 = 89
> /sdc1 = 2978
> /sde1 = 2986
> This APPEARS to mean that /sdb1 failed a long time ago, and the data will probably be WAY out of sync. However, /sdb1 passed all the tests of the SmartMonTools. So, I think the data may be bad but the drive itself may be good. I think this MAY have happened due to a cable coming loose? But, I'm not sure.
> /sdc1 has the read errors and we know this one must be replaced. I think that the ddrescue program may be the best way to duplicate the drive data onto the new drive that I have. SpinRite is also available, but at a cost of about $90, I'd prefer to try ddrescue first.
> Second, my line of thinking:
> I think I need to physically remove /sdb1 because it's probably got data that's old and is out of sync from the other 3 drives.
> Then, I think I need to install the new blank drive (I'll call it /sdf or /sdf1 in this email for clarification purposes).
> Then, I need to ddrescue the data from /sdb1 to /sdf1
> Then, I SHOULD be able to reassemble the array and have access to the data.
> Now my questions:
> Is this the right process to be trying?
> Do I need to do anything to remove /sdb1 other than simply unplugging it (assuming that it's not mounted)?
> To make /sdf1 work, I'll need to physically connect it, and then run:
> sfdisk -d /dev/sda | sfdisk --force /dev/sdf
> which should copy the partition info from /sda (one of the apparently still-good drives) to the new drive.
> BUT, should I do that from one of the still-good drives, or should I do it from the drive that's bad?
> Once I do have the partition info on the new /sdf, then using ddrescue would seem fairly straight forward.
> Then, should I remove /sdc, and try to get the data to re-sync with just the 3 drives connected? - I am ignorant of the commands to get the data to re-sync, so I'm pretty apprehensive about it.
> I know I'm forgetting something, some really important questions that I need to ask, so any other hints & tips will be appreciated.
> David Labens
> San Antonio, TX
I would only worry about getting the data off of sdc for right now. The data on sdb could be so far out of sync that it is of no use. But we know that all the other drives beside sdc are in good shape according to SMART. So no need to mess with those. We just want to give the array some good drives so that it won't fail half way through the rebuild with read/write errors from a flaky drive. I would save the freezer trick as a last effort for fear of the drive filling up with moisture from condensation. Using ddrescue from sdc to the new drive will copy all of the drive data and partition tables too. (unless the drive refuses to work). ddrescue/dd copies byte per byte from one drive to the other. So work on seeing if we can copy sdc to a good drive with ddrescue. The command to rebuild I think should be as simple as mdadm --assemble --force --scan but with one bad drive and one drive horribly out of sync, lets not go there yet :)
SATLUG mailing list
SATLUG at satlug.org
http://alamo.satlug.org/mailman/listinfo/satlug to manage/unsubscribe
Powered by Rackspace (www.rackspace.com)
More information about the SATLUG