- To: slug@xxxxxxxxxxx
- Subject: Re: [SLUG] LVM
- From: james <jam@xxxxxxxxx>
- Date: Tue, 15 Jun 2010 11:14:38 +0800
- User-agent: KMail/1.12.4 (Linux/18.104.22.168-0.1-desktop; KDE/4.3.5; x86_64; ; )
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.
> 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
> 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
> 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