When working with LVM (Logical Volume Manager) in CentOS 5.5 Xen environments, accidental deletion of logical volumes can occur. In this case, we're dealing with a situation where:

• A Xen guest's storage was provisioned using LVM
• The logical volume was removed using lvremove
• No subsequent LVM operations were performed on the volume group

Before attempting any recovery, follow these critical steps:

# First, prevent any further writes to the volume group
vgchange -an vg_name

# Create a complete backup of the physical volume
dd if=/dev/sdX of=/path/to/backup.img bs=1M conv=noerror,sync

There are several methods to attempt recovery of deleted logical volumes:

Method 1: Using vgcfgrestore

LVM maintains metadata backups in /etc/lvm/archive:

# List available backups
ls -l /etc/lvm/archive/vg_name_*.vg

# Restore the most recent backup
vgcfgrestore -f /etc/lvm/archive/vg_name_12345.vg vg_name

Method 2: Manual Metadata Reconstruction

If backups aren't available, you might need to manually reconstruct the metadata:

# Dump current metadata
vgcfgbackup -f current_metadata.txt vg_name

# Edit the metadata file to add the missing LV definition
# (This requires knowledge of LVM metadata structure)
nano current_metadata.txt

# Restore the modified metadata
vgcfgrestore -f current_metadata.txt vg_name

Method 3: Using TestDisk for Low-Level Recovery

For severe cases where metadata is corrupted:

# Install TestDisk if not available
yum install testdisk

# Run TestDisk against the physical volume
testdisk /dev/sdX

Implement these safeguards:

• Enable LVM metadata archiving in /etc/lvm/lvm.conf:

  backup = 1
  backup_dir = "/etc/lvm/archive"

• Create snapshot backups before destructive operations
• Implement a confirmation prompt wrapper for lvremove

When recovering Xen guest volumes:

# After volume recovery, update Xen configuration
xm block-attach domain_id phy:/dev/vg_name/lv_name xvda w

Remember that successful recovery depends on how much the underlying physical extents have been overwritten. The sooner you attempt recovery after deletion, the higher your chances of success.

---

When you run lvremove, LVM doesn't immediately wipe the physical data on disk. Instead, it:

• Updates the metadata in the volume group
• Marks the logical volume as deleted
• Updates the allocation tables

The actual data blocks remain untouched until they're overwritten by new allocations. This provides a recovery window if no further LVM operations have occurred.

# Immediately freeze LVM operations on the affected VG
vgchange -a n your_volume_group

# Backup current metadata state
vgcfgbackup -f /tmp/vg_backup.vg your_volume_group

LVM maintains metadata archives in /etc/lvm/archive. Locate the most recent pre-deletion state:

ls -lt /etc/lvm/archive/your_volume_group_*.vg

Restore from archive (replace XXX with actual timestamp):

vgcfgrestore -f /etc/lvm/archive/your_volume_group_XXXX.vg your_volume_group

If metadata archives aren't available, recreate the LV with identical parameters:

lvcreate -L 20G -n original_name your_volume_group
# Verify the new LV appears in vgdisplay output

Before putting the Xen image back in production:

# Activate without mounting
lvchange -a y your_volume_group/original_name

# Run filesystem check (ext3 example)
e2fsck -f /dev/your_volume_group/original_name

• Works best with recent LVM versions (2.02.98+)
• Effectiveness decreases if other LVM operations occurred post-deletion
• Xen-specific: Ensure restored LV has correct permissions for domU access

Add these to your standard procedures:

# Enable LVM metadata auto-archiving (if not enabled)
echo 'backup = 1' >> /etc/lvm/lvm.conf
echo 'backup_mode = "archive"' >> /etc/lvm/lvm.conf

# Create regular metadata snapshots
vgcfgbackup your_volume_group