← All sims

PBQ2 Linux — LVM Volume Recovery

Performance-Based Question Walkthrough

3 Parts Drop-down Selection Wrong Answer Explanations LVM Recovery
Scenario

A junior system administrator removed an LVM volume by mistake.

Instructions

Part 1 — Review the output and select the appropriate command to begin the recovery process.

Part 2 — Review the output and select the appropriate command to continue the recovery process.

Part 3 — Review the output and select the appropriate command to complete the recovery process and access the underlying data.

Recovery progress
0 of 3 complete
Terminal Output — vgs
[root@comptiasim ~]# vgs
  VG    #PV  #LV  #SN  Attr    VSize    VFree
  vg01    1    0    0  wz--n-  <10.00g  <10.00g
VG Name
vg01
Volume group present
Physical Volumes (#PV)
1 ✓
Disk still recognized
Logical Volumes (#LV) ← CRITICAL
0 — LV was deleted
Should be at least 1
Free Space (VFree)
<10.00g = VSize
100% free confirms deletion
#LV = 0 with VFree equaling VSize confirms the logical volume was deleted. The VG and physical disk are intact — only the LVM metadata is missing. LVM archives VG config to /etc/lvm/archive/ before every change, so we can restore from there.
Select the command to begin the recovery process
[root@comptiasim ~]#
❌ Wrong Answer Explanations — Part 1
lvchange -a n /dev/vg01/lv01
Deactivates an LV (-a n = available no). The LV doesn't even exist at this stage — no metadata was restored yet. This fails immediately with "Failed to find logical volume."
lvchange -a y /dev/vg01/lv01
Correct tool, wrong order. This is the right command for Part 2, but you can't activate an LV whose metadata hasn't been restored yet. There is nothing in the VG to activate.
pvscan
Diagnostic only. Scans for physical volumes and updates the LVM cache. It does not restore deleted LV metadata — it just reports what already exists.
lvconvert --type mirror lv01
Completely unrelated. Converts an existing LV to a mirrored layout for redundancy. Requires a live, existing LV. Since the LV is gone, this would fail immediately.
vgcfgrestore vg01 -f /etc/lvm/backup/vg01
Trap answer. The /backup/ file is a single rolling file overwritten on every LVM change. After lvremove ran, this file was updated to describe the VG without the LV. Restoring from it restores the broken state.
vgcfgrestore -t -M /etc/lvm/archive/vg01_00001-810050352.vg
Two problems: (1) -t = test/dry-run mode — simulates the restore but writes nothing to disk. (2) vg01_00001 has a lower sequence number than vg01_00002, meaning it's an older snapshot that may not reflect the state immediately before deletion.

Key Concept: LVM Archive vs. Backup

📁 /etc/lvm/archive/

Multiple timestamped snapshots saved before each change. Higher sequence = more recent. Use this for recovery.

💾 /etc/lvm/backup/

Single file per VG, overwritten every change. After lvremove, this reflects the deleted state — not useful for recovery.

🔢 Sequence Numbers

vg01_00002 is more recent than vg01_00001 — always pick the highest sequence number archive for recovery.

⚠️ -t Flag

The -t flag on vgcfgrestore = dry-run mode. Simulates only — no changes are written to disk.

Terminal Output — blkid
[root@comptiasim ~]# blkid
/dev/xvda1: UUID="388a99ed-9486-4a46-aeb6-06eaf6c47675" TYPE="xfs"
/dev/xvdf:  UUID="1uyvyk-Ffd0-RrYF-cYba-15zC-EHRZ-UW3UHm" TYPE="LVM2_member"
/dev/xvda1
TYPE="xfs"
Root partition — untouched
/dev/xvdf ← KEY
LVM2_member ✓
vgcfgrestore worked — PV recognized
TYPE="LVM2_member" on /dev/xvdf confirms the metadata restore succeeded. But the LV is still inactive — the device mapper hasn't created /dev/vg01/lv01 yet. Nothing can be mounted until we activate it.
StateBlock DeviceCan Mount?
Before activationNo /dev/vg01/lv01✗ No
After activation/dev/vg01/lv01 exists✓ Yes
Select the command to continue the recovery process
[root@comptiasim ~]#
❌ Wrong Answer Explanations — Part 2
mount /dev/vg01/lv01/ /important_data
Premature. This is the right action for Part 3, but the LV block device (/dev/vg01/lv01) doesn't exist yet — the device mapper hasn't created it. Mount fails with "special device does not exist."
pvchange -x y /dev/xvdf
Wrong tool entirely. Modifies the "allocatable" attribute on a Physical Volume, controlling whether new extents can be assigned from it. Has nothing to do with activating a logical volume.
lvchange -a n /dev/vg01/lv01
Exact opposite. -a n means available = no — this deactivates an LV. We need -a y (available = yes) to activate it.
lvextend -L +54 vg01/lv01 /dev/xvdf
Completely unrelated. Extends an LV by adding 54 GB from /dev/xvdf. This has nothing to do with recovery, and the entire disk is only 10 GB — 54 GB doesn't exist to add.

Key Concept: LV Activation

-a y vs -a n

lvchange -a y = available yes (activate). lvchange -a n = available no (deactivate). We need -a y to create the block device.

Device Mapper

Activation tells the Linux kernel's device mapper to read LVM metadata and create the virtual block device at /dev/vg01/lv01.

Terminal Output — lsblk
[root@comptiasim ~]# lsblk
NAME        MAJ:MIN  RM  SIZE  RO  TYPE  MOUNTPOINT
xvda        202:0     0    8G   0  disk
'-xvda1     202:1     0    8G   0  part  /
xvdf        202:80    0   10G   0  disk
'-vg01-lv01 253:0     0    9G   0  lvm   <-- no mountpoint
xvda1
Mounted at /
Root — healthy
vg01-lv01 ← ACTION NEEDED
No mountpoint
Active (9G lvm) but not mounted
The LV is activevg01-lv01 (253:0, 9G, lvm) is visible but the MOUNTPOINT column is empty. We need to mount it directly. mount /important_data /dev/vg01/lv01 attaches the logical volume device to the /important_data directory, making all recovered data accessible.
OptionWhat it doesValid?
mount /important_data /dev/vg01/lv01Mounts LV directly to directory✓ Correct
mount -aReads /etc/fstab entries✗ Not used here
Note — error in the original exam item. The keyed answer below is mount /important_data /dev/vg01/lv01, which has its arguments reversed. The correct syntax is mount /dev/vg01/lv01 /important_datadevice first, mount point second. The correctly ordered form appears as a distractor in Part 2, so the source contradicts itself. Answer it as keyed for exam fidelity, but type it the right way round on a real system.
Select the command to complete recovery and access the data
[root@comptiasim ~]#
❌ Wrong Answer Explanations — Part 3
xfs_repair /dev/vg01/lv01
No corruption exists. This repairs filesystem-level corruption in XFS volumes. The only problem here was deleted LV metadata — now fixed. Running xfs_repair unnecessarily can cause data loss by deleting files it considers "orphaned."
mount -a
Too indirect. Mounts all entries in /etc/fstab — but only works if a valid fstab entry exists for this volume. A direct mount command is the explicit, reliable choice that does not depend on fstab configuration.
xfs_mdrestore /dev/vg01 /important_data
Wrong scenario entirely. Restores an XFS filesystem from an xfs_metadump archive created by a separate tool. No such dump exists here. This is an XFS metadata tool, not an LVM tool.
lvscan -a
Invalid flag + wrong purpose. lvscan has no -a option — this returns an error. Even if it were valid, lvscan only lists logical volumes; it does not mount them or make data accessible.

Key Concept: Direct Mount

mount syntax

mount <mountpoint> <device> — mounts the logical volume directly to the target directory without relying on fstab.

Why not mount -a?

mount -a depends on a valid /etc/fstab entry existing. A direct mount is explicit and works regardless of fstab configuration.