Restore deleted LVM (Advanced)¶
Case of partition filesystem restore is much-much more trivial. It filesystem got corrupted - refer guides on that topic and use "TestDisc".
On the whole Internet until this post was no information on how to restore LVM, when no backup was present.
1. Do backups of the whole drive metadata.
2. On multiple drives - you would do Analyze and Restore for all drives involved.
So one way or another. Boot-sector and partition table are deleted from the drive. If only that first sectors was erased, it is great, we can work hard and restore the LVM.
If happened the classic in sence of:
1 2 3
How to do boot-sectot backups¶
1 2 3
LVM complicates the task of recovery, because it is basically a dynamically shifting layer between physical drives partitions and filesystems.
Delete the LVM info - filesystem with data basically locked in a chaos claster you can not penetrate.
There is small info on Internet on how to resurrect your true HDD/SDD LVM friend(s) alive - but check that info anyway also.
Here is the black magic.
- If you understand LVM in depth. LVM dynamically allocates physical space pieces (Physical extent (PE)).
Physical extent (PE)
The smallest size in the physical volume that can be assigned to a logical volume (default 4MiB))This is one of main facts here.
- Second fact - like most disc solutions - LVM does not shrink by itself. We can do that process, if we want. But LVM, by itself, only expands.
- Third fact - LVM does not move Physical extents (PE) around, they are statically placed. They allocated from free pool, given to Logical volume (LV), written in it info and that is it.
But now you see. LVM is a array of Physical extent (PE), and they was allocated and information stored on them is a complete chaos to us and to tools of recovery (they does not support LVM). That is why it seems impossible to resurrect for most people. But with dedication, way is described here.
More info on LVM¶
LVM maps Physical volumes (PV), to Volume groups (VG).
Physical volume (PV)
Partition on hard disk (or even the disk itself or loopback file) on which you can have volume groups. It has a special header and is divided into physical extents. Think of physical volumes as big building blocks used to build your hard drive.
Volume group (VG)
Group of physical volumes used as a storage volume (as one disk). They contain logical volumes. Think of volume groups as hard drives.
On Volume group (VG) you can describe a Logical volume (LV).
Logical volume (LV)
A "virtual/logical partition" that resides in a volume group and is composed of physical extents. Think of logical volumes as normal partitions.
And when Logical volume is going to need to expand its physical space, it does this by getting Physical extent (PE) and mapping it to Logical extent (LE) units, that then LVM includes to Logical volume (LV). It can expand until reaching quota, or free Volume group space available.
Logical extent (LE) units are additional abstraction for mapping LVM RAID PEs or PEs from different drives to single Logical volume.
Explaining the idea¶
Besides corner stones described in LVM, next piece also plays as important part.
Not so known fact, LVM does a backups of it's work information.
/etc/lvm/backup it stores last backup. In
/etc/lvm/archive lays a history of previous backup versions.
But it is a backup inside the filesystem we trying to restore.
Here comes a dirty magic I was talking about.
If only we could revive LVM to any metadata state (even non-consistent), than almost certainly we can expect to get the hold of that
/etc/lvm/backup. And it going to shine a lite on us.
TestDisc can find LVM partition remains, but TestDisc doesn't support work with LVM. It only can say: it looks like some version of LVM table. So TestDisc can't somehow find for us, what version of LVM structure it restores (old or last one), and how consistent that LVM data is.
So idea is. To revive the largest LVM TestDisc can find (probably the latest one, because LVM only expands most of the time and LVM PE data is static), and then
chroot to that somewhat alive filesystem from working system and restore
Process of restoring¶
- Connect the drive to working system or boot from Live image that is compatible with distribution that you restore.
As I used Arch Linux on that machine, I used Arch based Antergos Live image. DD-t ISO on a flash drive. Antergos image has X11, Desktop Environment and Gparted prettiness.
- Install (update)
testdisk. LVM2 as you guess provide LVM support. TestDisk is magical but not intuitive tool.
Backup full device¶
Backup at least what is on the drive:
Because the process is somewhat nontrivial, long and uses a hack in it.
ddrescue output can't be archived on the fly. If you need compression - use filesystem level compression on the backup media.
Choose right partition table¶
Choose here right type of the partition. It is up to your research. Probably you have one of:
[EFI GPT], [Mac ], [Intel ].
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Hint: Intel partition table type has been detected. Note: Do NOT select 'None' for media with only a single partition. It's very rare for a disk to be 'Non-partitioned'.
Analyze of the system (long operation)¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Correct disk geometry is required for a successful recovery. 'Analyse' process may give some warnings if it thinks the logical geometry is mismatched.
1 2 3 4 5 6 7
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Restoring LVM partition with TestDisc¶
After that scan TestDisc review several partitions to restore. One of which is LVM. And it says drive is to small (1T<1.3T or something like that) to reincarnate all that partitions. So you restore the LVM partition (the biggest).
At this stage partition and filesystem can be in inconsistent state. Minimize writing to system and proceed further. Restore from backup is going to get us consistent filesystem.
To refresh drive boot-partition information - reboot after restoring.
After reboot while doing:
1 2 3 4 5 6 7 8 9 10 11
You began to see:
1 2 3
Restoring from backup¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
After that, if you try to boot to recovered system, - you can get error:
Because no bootloader was configured. Now we need boot from Live image once more.
(optional) Make partition bootable¶
If you was booting from LVM.
Mark partition bootable (that flag was in old boot-sector, as you know old-one went away).
Right click on partition. Flags. "boot".
Mounting everything on working system (preparing for chroot)¶
Now you need by yourself mount all LVM volumes to single tree in /mnt/root, exactly how it was on that system. Because your LVM config is unique, as also mine, I can't give you literal instructions.
I going to mount:
1 2 3 4 5 6
So I did:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Control what you are mounting where with
lsblk. You need do everything right before going
Chroot to the system:
System maps filesystem data to current system.
Setup the bootloader¶
1 2 3 4 5 6 7 8 9 10 11
After this you have fully restored system. So now you can reboot to your long awaited system and everything is going to run smooth.