Storing anything important on a logical volume is simply plain stupid. This is what my personal experience has taught me. Your opinion could be different. But I am sure in case of an emergency, when your drive or partition will be barely accessible, you’ll wonder why you ever stored your important data in a logical volume.
On Linux systems (and also on Windows) you can define a number of logical volumes. They are also called drives or partitions. The reason why one needs to define these logical volumes on a Windows systems is that there could only be a maximum of 4 extended partitions on a Windows system (this hasn’t changes yet as per my knowledge and latest Windows is Windows 7 at the time of me writing this blog), and it can happen that you require more than 4 partitions on your system. On Linux however I don’t know why would one need logical volumes when you can have all real volumes. I understand that you can mix and match multiple logical volumes in a group to act as a single volume, but not a safe approach for important data.
The problem is that in the event of a crash, it is not easy to access the data stored in a logical volume, though you can easily access any non-logical volume, as long as data is still there.
So this happened to me not too long ago that a server at my client’s lab started to malfunction. The SSH connection won’t work. I rebooted the server and got Grub Error 15. This is the most common Grub boot loader’s error, and it basically means that it can’t find the boot files, which in this case for CentOS 5.2 were the Kernel file vmlinuz and initrd.img. Usually solution to this problem is very simple, i.e. using the grub’s own command prompt, give it path to these two files, and everything will be fine. But when I tried that, it still didn’t work.
Remember, for all Linux related emergency situations, as a good system admin, you must have the famous Knoppix Live CD in your tool belt. Knoppix is a life saver. It is a Linux live CD with all sorts of tools to get you our of the emergency situation.
Now I had the Knoppix CD, but the server didn’t have a CD-ROM. I hate these servers which don’t have a CD-ROM, as if the vendor thinks they’re shipping the server to some children, who will damage it if they’ll have CD-ROM access. Anyways, at that time I didn’t have a portable CD-ROM drive either, so following instructions at the Knoppix wiki at http://ilovetovoip.com/50 and created a live Knoppix 6.2 USB. A live USB is anyways better than a live CD.
Next, the server’s cheap BIOS won’t boot from the USB drive although it had the option to boot from any USB drive. In BIOS’s settings there was an option saying something like to “Emulate USB device as Fixed Disk”. Selecting this worked, and finally server came up with Knoppix.
Once it was up, to my surprise I found that the whole /boot folder was empty. How it happened, no idea. Some virus? I highly doubt. No one at that location was interested either to play with that server. The good thing was that it was only a lab server, not a server in the production. How it happened remained a mystery.
Now the problem started. I decided to simply copy important data from the /sda2 partition and reinstall Linux on the server, which would have been a very simple and quick process, until fdisk -l showed me that /sda2 was a logical volume. Crap. What to do now. Last time few years ago I had dealt with a similar situation and had learnt that you can’t access a logical volume doesn’t matter what. So my first thought was that all has gone lost, no way to recover data other than to somehow reinstall kernel on the server, which should exactly be the same to the deleted kernel. Now that was not a quick or easy task to do.
Rest is a long story, but I’d make it short here. By the end of the day I had figured out how to mount the logical volume and copy data out of it. Although to even more surprise all the folders on the logical volume which contained the important data were also empty. I couldn’t figure out how it all happened.
Googling lead me to the commands and ways to mount the logical volume as follows. It worked for me on this system, but doesn’t necessarily mean it will work for you.
Summary of what I did would be like this: Once in Knoppix, open a terminal window, switch to root by typing su, and issue the following commands:
modprobe dm-mod modprobe dm-mirror modprobe dm-snapshot vgscan --mknodes vgchange -ay lvscan
And that’s it. If you see any error, unfortunately I can’t help. If no error, you will see your logical drive found, assigned to a logical group and given a name. Rest is simple, you mount it just like any other device. In my case, I created a folder named ‘labserver‘ and mounted it there:
mkdir /labserver mount /dev/[logical group name]/[logical volume name] /labserver
Now I was able to see the partition in /labserver folder, which had unfortunately many important folders emptied out, but for whatever was remaining, I was able to scp it to another server, leaving this one for formatting at a later stage with no more logical volumes.
Your experience with LVM “mirrors” my own — it has never (not ever) solved a problem for me. It has only caused problems and made recovery more difficult.
Four physical partitions is a shortcoming of the hard drive MBR, not Windows. No OS can have more than 4 physical partitions.
I think the main attraction of logical volumes is the ability to dynamically expand (or contract) a single storage volume. Several physical disks can all be part of a single logical volume, allowing data to be spread across the drives. This has the same risk as RAID 0 though, because there is no redundancy.
I thought I had read somewhere that logical volumes all showed up in /dev/mapper somewhere, but I have not worked with LVM that much and have never had to recover data from it.
I had the same problem too with my squid cache server . And Google didn’t help me that time .Next time that I hope never come , I know where to find my solution
Thanks