<br><br><div class="gmail_quote">On Thu, Jul 8, 2010 at 12:13 PM, Stuart D. Gathman <span dir="ltr"><<a href="mailto:stuart@bmsi.com">stuart@bmsi.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Thu, 8 Jul 2010, Stuart D. Gathman wrote:<br>
<br>
> Method 2:<br>
> With both new and failed drive connected, use dd_rescue or equivalent to<br>
> copy (most/some of) the failed drive to the new drive.  Remove failed<br>
> drive and bring up VG.  If UUID was not readable on failed drive, use<br>
> pvcreate to restore it on new drive.<br>
<br></div></blockquote><div><br>(Question: does new drive need to be same physical size? can Or can I just create a new partition with the old size - new drive is bigger.)<br><br>The real problem seems to be that the LV appears to the LVM as not formatted. I am guessing this is because not only the partition got trashed, but also the superblock(s)  data. I have tried to find backup superblocks, but I keep getting the ioctl error, even from mke2fs. I will try dd_rescue - I have to install it, since it is not by default.<br>
<br>I added a new drive to the LV, and tried pvmove, but, I got the ioctl error again with that.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
</div>I should mention that an external case-free USB adapter is the best way<br>
to attempt recovery of failed drives.  You can even run the IDE/SATA/Power<br>
cable to a box in the freezer (and the USB adapter can sit on top of the<br>
freezer and a long USB cable go to your computer) - which often helps recover<br>
data from failing drives.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br>If the mountain won't come to Mohammed... I can always just get a large bag of ice and (carefully wrapped up in waterproof cover) put the drive into it. Will try that also :-).<br>
<br>FWIW: I did run dmsetup _table, and from /var/log/messages:<br><br>____________<br>Jul 12 09:17:25 Elmer kernel: device-mapper: ioctl: error adding target to table<br>Jul 12 09:24:16 Elmer kernel: device-mapper: table: device 253:3 too small for target<br>
____________<br>
<br>Couple of thoughts:<br>* Using dd_rescue, is there a utility that can read through the physical blocks on the drive, searching for something that looks like a superblock?<br><br>* Or, is it possible to physically disconnect the bad drive, bring up the remainder of the LV with the hope of recovering whatever data was on those drives. Att this point, I am resigned to the fact that the first drive is dead or on its last gasp (SMARTD says something like: "Danger (Will Robinson!) drive failure imminent. Back up data immediately.)" But the other drives in the LV should have something on them still. Right?<br>
<br>As always thanks for the help.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div class="h5">
              Stuart D. Gathman <<a href="mailto:stuart@bmsi.com">stuart@bmsi.com</a>><br>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154<br>
"Confutatis maledictis, flammis acribus addictis" - background song for<br>
a Microsoft sponsored "Where do you want to go from here?" commercial.<br>
<br></div></div></blockquote><div><br>"All consuming fires of hell" - very loose translation from Mozart's unfinished Mass for the Dead :-)<br></div><br></div>ken<br>