LVM (Logical Volume Manager) is a popular method of managing storage on Linux systems, and it can be challenging to recover data from it when things go wrong. The article will cover the various steps involved in the LVM data recovery process, including identifying the LVM partition, creating a backup, and using data recovery tools.
What Is LVM?
LVM stands for Logical Volume Manager. It simplifies disk space management by organizing physical storage devices into logical storage pools called "volumes." These "volumes" can be further divided into smaller units called "logical volumes. These logical volumes can be used as physical storage devices, such as a hard drive or a partition.
LVM allows for resizing, renaming, and moving logical volumes without repartitioning the underlying physical storage devices. It also supports advanced features like RAID, snapshots, and mirroring. LVM separates the physical and logical storage, making it more flexible and easier to manage.
Causes of LVM Partition Data Loss
- You may accidentally delete a LVM partition or essential data on an LVM partition, resulting in losing all data on that partition and any logical volumes associated with it.
- A disk from a logical volume group can be removed from the server. This could lead to a loss of data on the logical volumes connected with that disk and a potential loss of the entire logical volume group.
- LVM metadata refers to the data that describes the layout of logical volumes. If this data is damaged or corrupted, it can be difficult or impossible to access it on logical volumes.
- In a multi-disk volume group, if one disk is permanently deleted, it can cause data loss on the associated logical volumes associated.
How To Recover Deleted or Lost LVM Partition
The symptoms of a deleted or lost LVM partition include:
- Unable to access the partition
- The partition not being recognized by the operating system
- Error messages related to the missing partition
Recovering data from a deleted or lost LVM partition is a process that can be performed using data recovery software such as Wondershare Recoverit. You can take the following steps to recover a deleted or lost LVM partition using Recoverit Linux Recovery:
For Windows Vista/7/8/10/11
For macOS X 10.10 or later
Step 1: Choose Linux Recovery
Install Wondershare Recoverit on your Windows or Mac computer. Start the program and select the "NAS and Linux" option on the left-hand side of the main interface. Then click the "Linux Recovery" button.
Step 2: Connect to Linux Device
A new window will appear on the screen. Input the necessary information to establish a remote connection between the data recovery software and the Linux device.
Allow the establishment of the connection; it might take some time. After a successful connection, Recoverit will start an automatic scan to locate any lost files on the Linux computer, including the deleted LVM partitions.
Step 3: Scan and Recover
The scanning process may take some time, depending on the size of the data being scanned. You can see the progress of the scan on the bottom bar. You can also stop the scan when you find the desired LVM partition and restore it.
For Windows Vista/7/8/10/11
For macOS X 10.10 or later
How To Recover LVM Partition From Removed Disk
Removing a disk from a logical volume group on a server may seem unusual. Still, it is a common occurrence with Storage Area Networks (SAN) or in situations where schedules are tight.
Symptom
Upon server boot, one of the initial observations made are notifications such as:
Suppose the /dev/sales/reports file system is configured for automatic mounting. In that case, it may result in server boot failure and necessitate logging in as the root user to resolve the issue.
- Enter the root password
- Modify the /etc/fstab file
- Add a comment preceding the line referencing /dev/sales/report
- Restart the server
A potential indication of a Logical Volume Manager (LVM) issue is the absence of a sales volume group. Confirmation of the loss of a disk on the server can be determined by executing the command cat /proc/partitions.
Solution
Luckily the metadata and file system on the disk identified as /dev/sdc are undamaged.
- Reinsert the disk that was /dev/sdc
- Restart the server
- The script "/etc/init.d/boot.lvm" will scan and activate the volume group during the boot process
- Ensure that the device "/dev/sales/reports" is uncommented in the "/etc/fstab" file
If the above steps fail to resolve the issue, it may indicate the presence of corrupt LVM metadata.
How To Recover LVM Partition From Corrupt LVM Metadata
The LVM information doesn't usually have problems, but if it does, the files in the LVM storage area may also not be stable. The primary objective in such cases is to recover the LVM volume and subsequently assess the integrity of the file system to ensure its stability.
Symptom 1:
When attempting to activate the volume group, the following error message may appear:
This symptom is the result of a minor alteration in the metadata. As a result of the limited damage, LVM can compare its internal checksum against the metadata on the device and determine that it is incorrect.
Despite the damage, there is still sufficient metadata available for LVM to recognize the presence of the "sales" volume group and associated devices. However, they are currently unreadable.
As observed through the pvscan command, all devices are present and correctly associated with the sales volume group. The issue at hand is not the absence of the device UUID but rather the non-discovery of the volume group UUID.
Solution 1
Given that the disk has not been physically removed, it is recommended to maintain its current configuration. The absence of device UUID errors suggests no requirement to restore the UUIDs. So, restoring the LVM metadata is the most appropriate action in the current observation.
Run file system check on /dev/sales/reports.
Symptom 2
Minor corruption to the LVM metadata can typically be resolved using the vgcfgrestore command. In instances where the metadata is absent or significantly damaged, LVM will recognize the disk as an "unknown device."
If the volume group in question comprises a single disk, the volume group and its logical volumes will no longer be accessible. The symptoms in this scenario are comparable to those that would occur if the disk was inadvertently removed, except the device name remained unchanged. In this case, the devices are still labeled as a through d as the disk /dev/sdc was not physically removed from the server.
Solution 2
Begin by replacing the disk. It is likely that the disk is present but has sustained some form of damage. Since the UUID for /dev/sdc is not present, a vgcfgrestore will not be effective.
Comparing the output generated by the commands cat /proc/partitions and pvscan can reveal the missing device. The pvscan command can also provide the UUID associated with the lost device.
Copy and paste the UUID displayed for /dev/sdc by pvscan to proceed with the LVM recovery process. This will ensure that the appropriate UUID is associated with the device during recovery.
Recover the LVM metadata
Run a file system check on /dev/sales/reports.
How To Recover LVM Data From Permanently Removed Disk
A solid backup is essential if a disk is permanently lost and its data is unrecoverable. However, recovering as much data as possible from the remaining disk in the volume group may be attempted without a backup.
Symptom
The symptom displayed in this scenario is identical to that of Symptom 2 in the Corrupted LVM Meta Data section. This may include errors relating to an "unknown device" and the missing device with its corresponding UUID.
Solution
- Introduce a replacement disk to the server, ensuring that it is empty.
- Utilize the UUID of the old disk as displayed by the pvscan command to create the LVM metadata on the new disk.
- To restore the LVM metadata for the sales volume group, use the backup copy of the metadata.
- To rebuild the file system, perform a system check by running the appropriate command.
To recover as much data as possible, mount the file system and proceed with the data recovery process.
Conclusion
You should never turn off the LVM's automatic backup feature to ensure a successful recovery in case of disk removal or metadata damage, and backup files should always be kept in /etc/lvm/backup and /etc/lvm/archive. Even in the case of permanent disk removal from a volume group, you can reconstruct the LVM metadata and perform LVM data recovery.