Re: [SLUG] LVM

[james <jam@xxxxxxxxx>]

On Tuesday 15 June 2010 10:00:03 slug-request@xxxxxxxxxxx wrote:
> > I am a PCLinuxos user and I have seen references to LVM here ( at SLUG)
> > I have 3 drives LVM'd to give me 1.3TB of storage space on my server.
> > The first drive of this set has died.
> 
> I am guessing that by "LVM'd" you mean "concatenated together, no
>  redundancy", right?  So, basically, you lost one disk and you have lost
>  (more or less) a third of the data under the file system, etc.

The stuff  below is interesting and a reference, but this highlights my 
favourite rant: Seagate's 'ATA more than an interface' says multiple disks in 
a machine *will* result in a higher failure rate, maybe much higher.
So raid is a less worse option than LVM. Heed the advice in slug talks about 
backup (Sorry Sonia and Margurite, I don't remember who presented them)

It is possible, but not likely that *every* file on your disks is distributed 
over all 3 disks, so worst cast is that you lost 1/3 of every file you have.

James
  
> I further assume that "first" means "the one that contains the superblock",
>  as in the linearly first space on the disk.
> 
> > I was wondering if any of you Guru's could suggest a method of getting
> > any remaing data from the LVM drives, that is drive 2 and 3, that are
> > left.
> 
> I can identify three approaches:
> 
> One: Get the "dead" drive working long enough to actually recover the
>  content from the file system with all the data around.
> 
> That should work provided "died" means "has a bunch of bad sectors" rather
> than "will not respond to SATA commands".
> 
> 
> Two: Use something that scans the disk and looks for file content, then
> extracts it.  This is unlikely to bring much joy, but might be better than
> nothing.
> 
> I have used some of the tools packaged in Debian before, especially
> 'testdisk', with reasonable success, on simple cases like "recover JPEG/RAW
> images from CF cards".  For a complex case like a 1.3TB file system, I
> wouldn't hold much hope for getting a lot of content back.
> 
> 
> Three: talk to the upstream file system developers, and see if they can
>  help identify a mechanism that might recover data without the first chunk.
> 
> 
> I suspect those are in decreasing order of what you get back, and other
>  than the first that will be "very little".
> 
> 
> Er, and there is another option: pay a data recovery company to do
>  this.  It shouldn't cost more than a few thousand dollars for a fairly
>  simple case, and might have a better recovery rate than the alternatives
>  if, say, disk one *isn't* responding, but they can get it back talking for
>  a bit without too much trouble.
> 
> > I have tried rebuilding the set, wg0, but the system want to reformat the
> > drive wg0, just created. Is this formatting going to format the real
> > drives and rather that just the LVM component?
> 
> All LVM does, in this case, is rewrite the "write" command so that it talks
>  to the appropriate bit of the underlying physical device.  So, yes,
>  because there is no difference between the two.
> 
> 
> 
> Anyway, for the future: if you concatenate drives, which is all that LVM
>  does, you increase the chance of total data loss in your system by the
>  number of devices; in your case — three disks, triple the chances you
>  lose.
> 
> So, the take-away lesson is that if you intend to do this take one of these
> three approaches:
> 
> 1. Format each device as a separate file system, rather than concatenating
>    them, so that loss of one device only takes away one set of data, not
>  all three.  Penalty: you now have a PITA job using all that space.
> 
> 2. Keep good backups, so that when (and it is "when", not "if") you lose a
>    device you recover much more gracefully.
> 
> 3. Use some sort of redundancy: software RAID is a pretty decent choice,
>  and is pretty inexpensive these days.  Certainly, I bet that the extra few
>  hundred dollars for a second set of disks is less than the cost of trying
>  to recover all that data.
> 
> 
> Um, and sorry: it sucks that you are now probably going to lose all that
>  data.
>