<div dir="ltr">Re:all<br><div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">E.S. Rosenberg</b> <span dir="ltr"><<a href="mailto:esr@cs.huji.ac.il">esr@cs.huji.ac.il</a>></span><br>Date: Wed, Jan 24, 2018 at 10:59 PM<br>Subject: Re: [lustre-discuss] undelete<br>To: "Dilger, Andreas" <<a href="mailto:andreas.dilger@intel.com">andreas.dilger@intel.com</a>><br>Cc: "<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.org</a>" <<a href="mailto:lustre-discuss@lists.lustre.org">lustre-discuss@lists.lustre.org</a>><br><br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Jan 24, 2018 at 1:05 PM, Dilger, Andreas <span dir="ltr"><<a href="mailto:andreas.dilger@intel.com" target="_blank">andreas.dilger@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-7754829293765943893gmail-">On Jan 22, 2018, at 19:03, E.S. Rosenberg <<a href="mailto:esr%2Blustre@mail.hebrew.edu" target="_blank">esr+lustre@mail.hebrew.edu</a>> wrote:<br>
><br>
> Dragging the old discussion back up....<br>
> First of thanks for all the replies last time!<br>
><br>
> Last time in the end we didn't need to recover but now another user made a bigger mistake and we do need to recover data.<br>
<br>
</span>Sounds like it is time for backups and/or snapshots to avoid these issues in the future.  If you don't have space for a full filesystem backup, doing daily backups of the MDT simplifies such data recovery significantly.  Preferably the backup is done from a snapshot using "dd" or "e2image", but even without a snapshot it is better to do a backup from the raw device than not at all.<br></blockquote></span><div>Yeah I think our next Lustre system is going to be ZFS based so we should have at least 1 snapshot at all times (more then that will probably be too expensive).<br></div><div>OTOH this whole saga is also excellent user education that will genuinely drive the point home that they should only store reproducible data on Lustre which as defined by us is scratch and not backed up. <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-7754829293765943893gmail-"><br>
> I have shut down our Lustre filesystem and am going to do some simulations on a test system trying various undelete tools.<br>
><br>
> autopsy (sleuthkit) on the metadata shows that at least the structure is still there and hopefully we'll be able to recover more.<br>
<br>
</span>You will need to be able to recover the file layout from the deleted MDT inode (which existing ext4 recovery tools might help with), including the "lov" xattr, which is typically stored inside the inode itself unless the file was widely striped.<br>
<br>
Secondly, you will also need to recover the matching OST inodes/objects that were deleted.  There may be deleted entries in the OST object directories (O/0/d*/) that tell you which inodes the objects were using.  Failing that, you may be able to tell from the "fid" xattr of deleted inodes which object they were.  Using the Lustre debugfs "stat <inode>" command may help on the OST.<br>
<br>
You would need to undelete all of the objects in a multi-stripe file for that to be very useful.<br>
<span class="m_-7754829293765943893gmail-"><br>
> Has anyone ever done true recovery of Lustre or is it all just theoretical knowledge at the moment?<br>
><br>
> What are the consequences of say undeleting data on OSTs that is then not referenced on the MDS? Could I cause corruption of the whole filesystem by doing stuff like that?<br>
<br>
</span>As long as you are not corrupting the actual OST or MDT filesystems by undeleting an inode whose blocks were reallocated to another file, it won't harm things.  At worst it would mean OST objects that are not reachable through the MDT namespace.  Running an lfsck namespace scan (2.7+) would link such OST objects into the $MOUNT/.lustre/lost+found directory if they are not referenced from any MDT inode.<br>
<span class="m_-7754829293765943893gmail-"><br>
> (As far as the files themselves go they are most likely all single striped since that is our default and we are pre PFL so that should be easier I think).<br>
<br>
</span>That definitely simplifies things significantly.<br>
<br>
Cheers, Andreas<br></blockquote></span><div>Thanks!<br><br></div><div>Some of what I wrote before was due to my hope to do in-place recovery and make stuff 'visible' again on lustre.<br></div><div>I actually ran into a different interesting issue, it seems extundelete  balks at huge ext filesystems (33T) it considers some of the superblock values to be out-of-domain (a quick look at the source suggests to me that they assumed INT32, but 32T is also the limit of ext3).<br></div><div>ext4magic returns the error <a href="tel:(213)%20357-1465" value="+12133571465" target="_blank">2133571465</a> from e2fsprogs which according to the source maps to EXT2_ET_CANT_USE_LEGACY_<wbr>BITMAPS not sure what to make of that.<br></div><div>and bringing up the rear is ext3grep which doesn't know xattrs and therefor stops.<br><br></div><div>Thanks again for all the pointers!<br></div><div>Eli<br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="m_-7754829293765943893gmail-HOEnZb"><div class="m_-7754829293765943893gmail-h5"><br>
> On Thu, May 4, 2017 at 2:21 AM, Dilger, Andreas <<a href="mailto:andreas.dilger@intel.com" target="_blank">andreas.dilger@intel.com</a>> wrote:<br>
> On Apr 27, 2017, at 05:43, E.S. Rosenberg <<a href="mailto:esr%2Blustre@mail.hebrew.edu" target="_blank">esr+lustre@mail.hebrew.edu</a>> wrote:<br>
> ><br>
> > A user just rm'd a big archive of theirs on lustre, any way to recover it before it gets destroyed by other writes?<br>
><br>
> Just noticed this email.<br>
><br>
> In some cases, an immediate power-off followed by some ext4 recovery tools (e.g. ext3grep) might get you some data back, but that is very uncertain.<br>
><br>
> With ZFS MDT/OST filesystems (or to a lesser extent LVM) it is possible to create periodic snapshots of the filesystems for recovery purposes.  ZFS handles this fairly well performance wise, LVM much less so.  With Lustre 2.10 there are new tools to manage the ZFS snapshots and allow mounting them as a separate Lustre filesystem.<br>
<br>
Cheers, Andreas<br>
--<br>
Andreas Dilger<br>
Lustre Principal Architect<br>
Intel Corporation<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></span></div><br></div></div>
</div><br></div></div>