Your help is mostly appreciated Andreas. May I ask one more question?<br>I would like to perform the recovery procedure on the image of the disk
(I am making it using dd) rather then the physical device. In order to
do that is it enough to bind the image to the loop device and use that
loop device as it is was a physical device?<br>
<br>
Best regards,<br>
<br>
Wojciech<br><br><br><div class="gmail_quote">On 20 October 2010 17:41, Andreas Dilger <span dir="ltr"><<a href="mailto:andreas.dilger@oracle.com">andreas.dilger@oracle.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 bgcolor="#FFFFFF"><div class="im"><div><span>On 2010-10-20, at 10:15, Wojciech Turek <<a href="mailto:wjt27@cam.ac.uk" target="_blank">wjt27@cam.ac.uk</a>> wrote:</span></div><blockquote type="cite"><div><div class="gmail_quote">
On 20 October 2010 16:32, Andreas Dilger <span dir="ltr"><<a href="mailto:andreas.dilger@oracle.com" target="_blank"></a><a href="mailto:andreas.dilger@oracle.com" target="_blank">andreas.dilger@oracle.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 bgcolor="#FFFFFF"><div>Right - you need to recreate the LV exactly as it was before. If you created it all at once on the whole LUN then it is likely to be allocated in a linear way. If there are multiple LVs on the same LUN and they were expanded after use the chance of recovering them is very low.</div>
</div></blockquote><div>There was one LVM on that LUN I created it using following commands:<br><br>pvcreate /dev/sdc<br>vgcreate ost16vg /dev/sdc<br>lvcreate --name ost16v -l 100%VG ost16vg<br><br>So in order to recreate that LVM on the formatted LUN i need to repeat above steps, is that right?<font color="#000000"><font color="#0023a3"><br>
</font></font></div></div></div></blockquote><div><br></div></div>If you know the exact LVM command then you probably don't need findsuper at all, since you should get back your original LV. The findsuper tool is useful if you don't know the original partition layout. <div>
<div class="im"><br><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#FFFFFF">
<div><span>That said, if there were filesystems formatted in each partition, the amount of data loss may be large. You may have some saving grace if the first partitions are very small and fit inside the space previously used by the 400MB journal.</span><br>
</div></div></blockquote><div>Unfortunately new partitions use much more space than 400mb<br> 8 32 7809904640 sdc<br> 8 33 10484719 sdc1<br> 8 34 4193280 sdc2<br> 8 35 4193280 sdc3<br> 8 36 8387584 sdc4<br>
8 37 7782640640 sdc5<br></div></div></div></blockquote><div><br></div></div>The only good news is that the new filesystems will be offset from the original filesystem due to the LVM metadata, and you are more likely to have newer data away from the start of the filesystem, so there is some hope of getting some data back. <div class="im">
<br><br><blockquote type="cite"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor="#FFFFFF"><div><span>On 2010-10-20, at 9:06, Wojciech Turek <<a href="mailto:wjt27@cam.ac.uk" target="_blank"></a><a href="mailto:wjt27@cam.ac.uk" target="_blank">wjt27@cam.ac.uk</a>> wrote:</span><br>
</div><div><div><div><br></div><div></div><blockquote type="cite"><div>Thank you for quick reply.<br>
Unfortunately all partitions were formatted with ext3, also I didn't mention earlier but the OST was placed on the LVM volume which is now gone as the installation script formatted the physical device. I understand that this complicates things even further. In that case i guess firstly I need to try to recover the LVM information otherwise fsck will not be able to find anything is that right?<br>
<br>Best regards,<br><br>Wojciech<br>
<br><div class="gmail_quote">On 20 October 2010 08:46, Andreas Dilger <span dir="ltr"><<a href="mailto:andreas.dilger@oracle.com" target="_blank"></a><a href="mailto:andreas.dilger@oracle.com" target="_blank"></a><a href="mailto:andreas.dilger@oracle.com" target="_blank">andreas.dilger@oracle.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>On 2010-10-19, at 17:01, Wojciech Turek wrote:<br>
> Due to the locac disk failure in an OSS one of our /scratch OSTs was formatted by automatic installation script. This script created 5 small partitions and 6th partition consisting of the remaining space on that OST. Nothing else was written to that device since then. Is there a way to recover any data from that OST?<br>
<br>
</div>Your best bet is to make a full "dd" backup of the OST to a new device (for safety), first restore the original partition table. If there was not originally a partition table, then you can just erase the new partitions:<br>
<br>
dd if=/dev/zero of=/dev/XXX bs=512 count=1<br>
<br>
Then run e2fsck -fy, followed by "ll_recover_lost_found_objs" (from a newer lustre RPM, if you don't have it). It is likely that you will get some or most of the data back. This depends heavily on exactly what was written over the original filesystem.<br>
<br>
If it was just a new partition table, there should be relatively little damage (ext3 is very robust this way, and can repair itself so long as the starting alignment is correct). If there were filesystems formatted in each of these partitions, then the amount of data available will be reduced significantly.<br>
<br>
Cheers, Andreas<br>
<font color="#888888">--<br>
Andreas Dilger<br>
Lustre Technical Lead<br>
Oracle Corporation Canada Inc.<br>
<br>
</font></blockquote></div><br>
</div></blockquote></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Wojciech Turek<br><br>Senior System Architect<br><br>High Performance Computing Service<br>University of Cambridge<br>Email: <a href="mailto:wjt27@cam.ac.uk" target="_blank"></a><a href="mailto:wjt27@cam.ac.uk" target="_blank">wjt27@cam.ac.uk</a><br>
Tel: (+)44 1223 763517 <br>
</div></blockquote></div></div></div></blockquote></div><br><br clear="all"><br>-- <br>Wojciech Turek<br><br>Senior System Architect<br><br>High Performance Computing Service<br>University of Cambridge<br>Email: <a href="mailto:wjt27@cam.ac.uk" target="_blank">wjt27@cam.ac.uk</a><br>
Tel: (+)44 1223 763517 <br>