On Wed, Jun 16, 2010 at 02:06:32PM +0800, Adrian Chadd wrote:
> You won't be able to. If you configured them up as a stripe (ie, no mirroring)
> with interleaving every x megabytes on each disk, you'll basically end up
> with a virtual hard disk with "holes" evenly spread out across 1/3rd of
> the image. I don't know of any (easy) tools to recover from that.
If configured with striping (which I expect is improbable) then the data
will have holes through it and is probably unrecoverable.
However if configured with linear mapping (append) then it is
possible to make the volume group active by using the --partial flag
to vgchange:
-P | --partial
When set, the tools will do their best to provide access to
volume groups that are
only partially available. Where part of a logical volume is
missing, /dev/ioerror
will be substituted, and you could use dmsetup (8) to set
this up to return I/O
errors when accessed, or create it as a large block device of
nulls. Metadata may
not be changed with this option. To insert a replacement
physical volume of the
same or large size use pvcreate -u to set the uuid to match the
original followed
by vgcfgrestore (8).
If I was doing it then I'd do what the last sentence said: get a block
device of the exact same size as the lost one; use pvcreate -u to add
the LVM PV metadata and set the uuid to match; vgcfgrestore;
"vgchange -a y $VGNAME" to make the volume group active, then run fsck
on all filesystems.
If the VG was separated into several filesystems then any wholly on the
last two disks should be perfect; anything wholly on the first disk
is lost, and anything which straddles both may be unrecoverable or
partially recoverable (e.g. through use of e2fsck and a backup superblock).
Now if ZFS were used instead of ext2/ext3, then the filesystem should
be able to tell which particular files are OK, due to the data checksum.
> I can think of what I'd write to try and recover -something- but it'd
> involve writing a whole lot of rather hairy looking filesystem-scraping
> code. I'm sure there are tools to do this kind of partial data recovery
> but they're bound to be -very- expensive.
Or you could just run 'debugfs'.
Nick.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
