<div dir="ltr">Brian has good advice here.. but if it wasn't obvious you'll need a Linux system up and running<br>where you can mount the disk on its own. I'd also suggest scanning /dev for partitions<br>on your disk.<br>
<br>If your 3TB disk is /dev/sdb, look for /dev/sdb1 /dev/sdb2 etc. If those don't show then<br>the RAID metadata may be occupying the first parts of the disk or the partition table<br>could be corrupted.<br><br>I'm mostly a FreeBSD guy and I'd suggest using scan_ffs to recover the slice table but<br>
I think gpart can also do this on Linux.<br><br><a href="http://www.brzitwa.de/mb/gpart/">http://www.brzitwa.de/mb/gpart/</a><br><br>It can scan the disk for partition signatures and help you rebuild the table. I'd work on one<br>
disk at a time so if something goes wrong you don't jeopardize your data.<br><br>If you have another system with 3TB+ of data the safest way to play with it is to set it up<br>as a loop device. Something such as:<br><br>
dd if=/dev/sdb of=data.img bs=128k<br>losetup /dev/loop0 data.img<br><br>You can mess with /dev/loop0 all you want and not change any data<br>on your disks should you end up deciding to send it to a commercial<br>recovery company.</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 2, 2014 at 10:47 AM, Brian Cluff <span dir="ltr"><<a href="mailto:brian@snaptek.com" target="_blank">brian@snaptek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it's a RAID 1 you shouldn't need to assemble it to get your data, just mount the raid partition directly read only and copy your data off to somewhere else.<br>
<br>
You should be able to do something like:<br>
<br>
mount --read-only /dev/sdb1 /mnt<br>
or if the above one doesn't work:<br>
mount --read-only /dev/sdc1 /mnt<br>
<br>
The other possibility you could try sounds terrifying but it works... Just create a new array:<br>
mdadm --create /dev/md0 -n2 -l1 /dev/sdb1 /dev/sdc1<br>
<br>
When you create an array all it does, for the most part, is write a superblock at the end of the partition so that it can later identify the associated drives and be able to automatically put them back together. The data area itself it unaffected, so it should be safe to just create a new array (just don't mkfs it afterwards). Creating a new array will change the RAID's UUID and such, so you won't be able to just put it back into service without first creating a new mdadm.conf and running mkinitrd but otherwise it should just mount up and go... as long as the data isn't completely corrupted.<br>
<br>
Tripple check that the partitions are absolutely correct or it will destroy your data when it starts to resync the array upon creation.<br>
<br>
You could also give yourself 2 chances to get your data back and make 2 RAID1 arrays out of your 2 raid drives by doing this:<br>
mdadm --create /dev/md0 -n2 -l1 /dev/sdb1 missing<br>
mdadm --create /dev/md1 -n2 -l1 /dev/sdc1 missing<br>
<br>
That will give you /dev/md0 and /dev/md1 which you could then mount up and hopefully copy all your data off.<br>
<br>
I hope this helps,<br>
Brian Cluff<br>
<br>
On 02/02/2014 09:25 AM, George Toft wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've spent over 15 hours on this (google . . . head . . .desk . . .<br>
repeat).<br>
<br>
I need to recover the data off of one of these hard drives.<br>
<br>
Background<br>
Two 3TB hard drives in a Raid 1 mirror, working fine for months. OS:<br>
Centos 6.5<br>
Woke up a few days ago to a dead system - looks like motherboard<br>
failed. And when it failed, it appears to have corrupted the RAID<br>
partition (supposition - see problems below). I moved the drives to<br>
another system and it will boot then the kernel panics.<br>
<br>
Partitions<br>
part 1 - /boot<br>
part 2 - swap<br>
part 3 - RAID<br>
<br>
I think the RAID partition has just one filesystem (/).<br>
<br>
<br>
What I've done:<br>
Rescue mode: Boots, unable to assemble raid set:<br>
<br>
# fdisk -l | egrep "GPT|dev"<br>
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util<br>
fdisk doesn't support GPT. Use GNU Parted.<br>
<br>
WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util<br>
fdisk doesn't support GPT. Use GNU Parted.<br>
<br>
Disk /dev/sda: 80.0 GB, 80025280000<br>
Disk /dev/sdb: 3000.6 GB, 3000591900160 bytes<br>
/dev/sdb1 1 267350 2147483647+ ee GPT<br>
Disk /dev/sdc: 3000.6 GB, 3000591900160 bytes<br>
/dev/sdc1 1 267350 2147483647+ ee GPT<br>
<br>
# mdadm --assemble --run /dev/md0 /dev/sdb<br>
mdadm: Cannot assemble mbr metadata on /dev/sdb<br>
mdadm: /dev/sdb has no superblock - assembly aborted<br>
<br>
# mdadm --assemble --run /dev/md0 /dev/sdb1<br>
mdadm: cannot open device /dev/sdb1: No such file or directory<br>
mdadm: /dev/sdb has no superblock - assembly aborted<br>
<br>
<br>
parted tells me I've found a bug and gives me directions to report it.<br>
<br>
-----------<br>
<br>
Booted Knoppix and ran disktest. I can copy the RAID partition to<br>
another drive as a disk image and I end up with image.dd. When I try to<br>
build an array out of it, I get an error: Not a block device.<br>
<br>
Tried commercial RAID recovery software (Disk Internals) - it hung after<br>
identifying 2.445 million files.<br>
<br>
<br>
-------------<br>
<br>
Ideas on what to do next?<br>
<br>
Is anyone here up for a challenge? Anyone need beer money? I need the<br>
data recovered, and will pay :)<br>
<br>
All help is appreciated :)<br>
<br>
</blockquote>
<br>
------------------------------<u></u>---------------------<br>
PLUG-discuss mailing list - <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.<u></u>org</a><br>
To subscribe, unsubscribe, or to change your mail settings:<br>
<a href="http://lists.phxlinux.org/mailman/listinfo/plug-discuss" target="_blank">http://lists.phxlinux.org/<u></u>mailman/listinfo/plug-discuss</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>- Brian
</div>