Does LVM increase the risk of data loss?

Question

Let's say I have two identical disks, and I set one LVM logical volume on them (no mirroring). Question: What will happen when one of the disks fails?

1. I will lose all the data from all the disks
2. I will lose the data from broken disk, but I get data from still working one
3. something else (what)

?

Thank you in advance for clarification.

From what I've read mentioning RAIDs in LVM articles indicates I will lose everything, on the other hand shrinking LV indicates something opposite.

Update

Good read: http://www.redhat.com/magazine/009jul05/features/lvm2/

According to this article with linear mapping (default, it is my case) and no mirroring, in case of failure you should lose data only from broken disk. I hope it is true, and eventually I find out :-/

Solution 1

The worst and most likely case is that you will lose everything. If you have a single logical volume spanning both drives, and you lose one drive with no mirroring, you've essentially wiped out half the file system.

From this point, it gets mildly better depending on what file system you are running on your volume. Assuming that you are not using striping, which will kill any chance you have, you may be able to get some of your data back by running recovery software on the second drive. I don't have personal experience with that case, but it should be theoretically possible to get some or most of the files that were exclusively on the still functional drive if you are using one of the more 'robust' file systems (i.e. ext3 or ext4).

Your mileage will vary depending on what filesystem you are using on top of LVM and how your files are arranged on the disks though. If they are fragmented across both disks then you will still lose those files too.

Solution 2

Since your concern is data loss using LVM, it's useful to discuss loss of one of your two disks using the (3) LV configurations available to choose from:

LV Types:

• Linear: The DEFAULT option when creating an LV without supplying any switches to create the other two types of LV's below. In a Linear LV, if a Physical Volume (PV) drops out of the Volume Group (VG), you only lose the LV(s) on that PV. However, if an LV spans MULTIPLE PVs and any PV (disk) it uses drops out, the entire LV will be lost. This is logical: the filesystem is spanned across the 2 PVs, so it would be catastrophically damaged with the loss of either disk. Any LV's residing on or NOT spanned across the missing PV member will survive.

• Striping: Specify the " -i " switch when creating an LV. Although this provides better write performance, ALL data is written round-robin across the striped PVs. If any PV in the stripe is lost, so too are ALL LVs residing on ALL the PVs.

• Mirroring: Specify the " -m " switch when creating your LV. This is analogous to RAID1: Increased fault tolerance to protect against data loss, but uses twice the space.

Finally, when managing data- LVM, RAID or no abstraction at all- you're only as good as your PROVEN backups.

Check How Physical Extents Mapped

To see how your data is mapped in relation to PVs it lives on:

pvdisplay -m 

Check if LV's are striped (multiple PVs)

If you have multiple PVs and need to determine if the LV is striped across them:

lvs -o+lv_layout,stripes

Simplified Illustrative Example:

As you can see in the illustration, since LV "var" requires extents from all three PVs, were any of the PVs lost, the filesystem on LV "var" would be catastrophically damaged.

Useful References:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/logical_volume_manager_administration/lv_overview#linear_volumes

http://manpages.ubuntu.com/manpages/xenial/man8/lvcreate.8.html

Solution 3

I agree with Matthew Scharley - losing from half to all is most likely case, assuming linear mapping.

While you might be able to recover some of the data when a single disk dies, it's like losing half the blocks on a filesystem using a single hard disk. The filesystem's fsck will certainly have big problems recovering data, and it would take a long time to finish - it's quite possible it won't be able to recover at all.

You can use 'file carving' type software to extract data from such a broken filesystem but its success will depend on how fragmented the files are on disk.

See https://serverfault.com/questions/279571/lvm-dangers-and-caveats for more on the risks of data loss with LVM generally, and some links on LVM recovery tools (including file carving tools), and other experience.

Comments

[F1Linux]

Incorrect. If you have an LV spanning both drives and lose one of them, you lose ALL your data- not "half". See my full answer below

[greenoldman]

Thank you, but I am looking for definitve answer, not speculative. "Half of the system" differs -- when I cut the disk in half, I get nothing, when I delete half of the files, I still get the rest of them.

[Matthew Scharley]

@macias: The only speculation in my answer is how much you'll lose (from half to all). If you have a striped setup, you will lose all your data. If you don't, you may lose up anything from all or none of your files, but the number will depend on which file system you have (ie, how recoverable files are), and how they are arranged on disk. If your LV is half full, but all the files are located on the disk that fails, then you've lost all your data because there are no files on the recoverable disk. Conversely, you may lose nothing because the inverse situation may apply.

[Matthew Scharley]

@macias: The difference between shrinking a LV and losing a disk is that shrinking the LV is a controlled environment. It assumes you have the capability to store all your data on one disk, and that you have done so. The first step of shrinking a LV is shrinking the filesystem so that it will fit on one drive.

[greenoldman]

Speculative because I am interested in data from working disk, and "may" is pretty vague ;-) Anyway, I finally found out some doc from RH, which states LVM feature is such reliability in case of failure -- that you can get the rest of the data. That is the answer I was looking for. Since you made me to dig deeper, I am marking your post as THE answer.