Restore LVM Volume Group Metadata Without Guessing

You will finish with a controlled way to inspect LVM volume group metadata backups and restore one selected backup when the metadata on disk is wrong or a physical volume has been replaced. The restore writes volume group metadata to devices. It does not restore files inside logical volumes.

These examples use vgcfgrestore from the installed lvm2 package, version 2.03.16-3ubuntu3.2, reporting LVM tools 2.03.16(2). Allow about 20 minutes for inspection and a further maintenance window for an actual restore. You need root access, a known volume group name, a readable backup produced by vgcfgbackup, and a current backup of anything you cannot afford to lose.

1. Confirm the installed command

First check the binary and version. These are read-only commands and do not need elevated privileges:

$ command -v vgcfgrestore
/usr/sbin/vgcfgrestore
$ vgcfgrestore --version
LVM version:     2.03.16(2) (2022-05-18)

The version output also prints library and build details. Its exact warnings can vary with permissions and the device-mapper state. The installed manpage is the contract for this host, so check it if a distribution update changes the available options.

2. List the available metadata backups

Use --list before selecting a file. It lists the backup and archive files belonging to the volume group and does not restore anything:

# vgcfgrestore --list VG_NAME

For a specific file, add --file. This is useful when you want to inspect one candidate without applying it:

# vgcfgrestore --list --file /etc/lvm/backup/VG_NAME VG_NAME

The path must be the actual file on your host. A normal backup is usually created by vgcfgbackup, while archive files represent older metadata states. Compare timestamps, the volume group name, physical volume UUIDs and logical volume definitions with your incident notes. Do not choose the newest file automatically: the newest metadata may be the state that caused the problem.

3. Prepare the affected devices

If every physical volume is still present, record their current state with ordinary LVM inspection commands:

# pvs --uuid --units g
# vgs
# lvs --all --options lv_name,vg_name,lv_attr,lv_size

These commands do not change metadata. Save their output with the incident record. Check that the expected physical volumes are visible and that no unrelated volume group will be affected.

If a physical volume was lost and you are replacing it, the manpage describes a stricter sequence: use vgdisplay --partial --verbose to find the missing physical volume UUID and size, initialise a replacement with pvcreate --restorefile and the original UUID, then restore the volume group metadata from the selected file. That replacement procedure is destructive to the new device and needs its own device-level verification. Do not run pvcreate on a device until you have checked its identity several times.

4. Run a no-write rehearsal

Use --test with the explicit file. It disables metadata writing, but still returns success to the calling function, so treat it as a rehearsal rather than proof that the real restore will be safe:

# vgcfgrestore --test --file /etc/lvm/backup/VG_NAME VG_NAME
# printf 'test exit status: %s\n' "$?"
test exit status: 0

Some multi-stage operations can produce unusual messages in test mode because later stages read metadata that was not actually changed. A successful test is useful evidence that the command accepted the selected input. It is not evidence that the backup matches current thin-pool metadata or that the data in every logical volume is intact.

5. Restore the selected metadata

Before this step, stop users and services of the volume group and take any application-level backup required by your recovery plan. Then run the real restore as root, with the file and volume group named explicitly:

# vgcfgrestore --file /etc/lvm/backup/VG_NAME VG_NAME
# printf 'restore exit status: %s\n' "$?"
restore exit status: 0

An exit status of zero means the command completed successfully. It does not validate the application data or prove that the selected metadata describes the intended layout. Re-run the inspection commands and compare the result with the chosen backup:

# pvs --uuid --units g
# vgs
# lvs --all --options lv_name,vg_name,lv_attr,lv_size
# vgdisplay VG_NAME

Reactivate or restart services only after the physical volume list, volume group and logical volume definitions are correct. Then check the filesystems and applications using their own recovery procedures. There is no generic undo command: recovery means running vgcfgrestore again with a different, verified backup.

6. Treat thin pools as a hard boundary

If the volume group contains thin pools, stop before using --force. The installed manpage warns that changes to thin metadata cannot be reverted and that restoring metadata which does not precisely match thin-pool kernel metadata may cause data loss. The force option is required for a restore in this situation, but its presence is not a safety check.

Confirm the layout with lvs --all, identify whether thin-pool metadata changed, and involve the storage owner before proceeding. If the restore is not essential, preserve the current devices and gather diagnostics instead. Never add --force merely to bypass a prompt or an error you have not understood.

7. Keep the command from touching the wrong devices

LVM can restrict the devices visible to a command with --devices or a managed --devicesfile. Use those only when you understand the host's device inventory and the selected backup. A device excluded from the command appears missing, which can turn a correct recovery plan into a partial one.

Do not use --nolocking on a live system just to make the command proceed. The manpage warns that concurrent commands can then produce incorrect results. Likewise, use --yes only in a reviewed automation path: it answers confirmation prompts yes and removes a useful last pause before a storage change.