Re: [linux-lvm] Restoring data after losing a drive

["Saad Shakhshir" <saads@alum.mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 3783 bytes --]

Does anyone have ideas on this?  I would really appreciate the help.

On 5/13/07, Saad Shakhshir <saads@alum.mit.edu> wrote:
>
> Right now after running 'vgreduce --removemissing' it resized the volume
> group to include only the available drives.  I got back my one small logical
> volume (/dev/fileserver/home) and the data is all intact.  The other large
> logical volume which spanned the rest of the drives (including the one that
> went bad) isn't there anymore.  So it thinks that the majority of the volume
> group is unused space, however there is data on there.  If I now create a
> logical volume on the remaining space in the volume group, will it
> automatically see the data that is there?
>
> Where does the filesystem information get stored in terms of inode
> locations?  Will that get overwritten now if I create a new logical volume?
>
> On 5/12/07, Stuart D. Gathman <stuart@bmsi.com> wrote:
> >
> > On Sat, 12 May 2007, Saad Shakhshir wrote:
> >
> > > The data on the damaged disk is not recoverable at this
> > point.  However
> > > there is data on the other remaining good disks that was part of that
> > one
> > > large logical volume.  At this point I want to get back the remaining
> > data
> > > that was in that logical volume and on the remaining good physical
> > volumes
> > > without the data that was on the physical volume I lost.  I know that
> > the
> > > data is still intact on those drives... I just need to know how to get
> > my
> > > system to recognise that it's still there.
> >
> > The solution involves restoring the metadata to memory or a replacement
> > hard
> > drive from /etc/lvm (if it is intact) or a backup.  I'll let the experts
> > talk about details.
> >
> > However, the LVM should be able to handle losing a PV and still bring
> > LVs
> > for that PV online.  Any attempted IO would result in errors, of course.
> > But the metadata for a PV should be automatically loadable even with
> > the PV missing.  When the missing PV blows a hole in your large LV,
> > it would simplify recovering the pieces if the missing data got I/O
> > errors.
> > If you replace the drive and restore the metadata, the missing data will
> >
> > have whatever is on the drive.  It might help recovery to write a
> > pattern
> > to the replacement drive to help recognize the missing data.
> >
> > You will also need to be a filesystem wizard to navigate with a huge
> > hole
> > like that.  If you have one large file with a regular record format, it
> > might be simplest to scan all blocks for records - then paste any
> > missing
> >
> > I used to run into such problems a lot, and developed a filesystem where
> >
> > each block is tagged with the inode of the file it belonged to.  The
> > recovery program can recover each and every readable block into the
> > proper file in the proper location regardless of how much of the
> > filesystem
> > is missing or garbled due to horrendous errors.  There is no inode table
> > either - any block can be an inode (so blowing away the first part of
> > the
> > filesystem doesn't lose all your files).  There are drawbacks to
> > this approach, of course.  E.g. block size is reduced by the header
> > present on every block (and is therefore not a power of 2).
> >
> > --
> >               Stuart D. Gathman <stuart@bmsi.com >
> >     Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703
> > 591-6154
> > "Confutatis maledictis, flammis acribus addictis" - background song for
> > a Microsoft sponsored "Where do you want to go from here?" commercial.
> >
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
> >
>
>

[-- Attachment #2: Type: text/html, Size: 5133 bytes --]