vgcfgrestore Command in Linux: Recover LVM Metadata From Archive

Deepak Prasad
Tested on Ubuntu 25.04 (Plucky Puffin)
Package lvm2
lvm2
Applies to Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Fedora
Privilege sudo or root
Man page vgcfgrestore(8)
Scope vgcfgrestore rebuilds volume group metadata from text backups created by LVM — usually under /etc/lvm/archive and /etc/lvm/backup. It recovers mistyped lvremove or vgcfg changes; it does not replace disk imaging when.
Related guides lvremove
lvchange
Linux commands

vgcfgrestore — quick reference

List and inspect backups

Read-only on production — safe to run vgcfgrestore -l on a live VG.

When to use Command
List archive and backup files for a VG sudo vgcfgrestore -l VG_NAME
Same with long option sudo vgcfgrestore --list VG_NAME
Create or refresh the current backup file sudo vgcfgbackup VG_NAME

Restore metadata

Destructive — restores VG/LV layout from a text metadata file. Run on production only after --test and a backup plan.

When to use Command
Restore from the newest backup in /etc/lvm/backup/ sudo vgcfgrestore VG_NAME
Restore from a specific archive or backup file sudo vgcfgrestore -f /etc/lvm/archive/VG_00001-....vg VG_NAME
Dry run — show what would change sudo vgcfgrestore --test -f /path/to/file VG_NAME
Short test flag sudo vgcfgrestore -t -f /path/to/file VG_NAME

After restore

When to use Command
Activate a restored LV sudo lvchange -ay VG_NAME/LV_NAME
Scan for active/inactive LVs sudo lvscan
Show LV details sudo lvdisplay VG_NAME/LV_NAME

vgcfgrestore — command syntax

Synopsis from vgcfgrestore --help on Ubuntu 25.04 (LVM 2.03.27):

text
vgcfgrestore VG
vgcfgrestore -f|--file String VG
vgcfgrestore -l|--list VG
vgcfgrestore --test -f|--file String VG

vgcfgbackup and LVM tools automatically write metadata snapshots to /etc/lvm/archive/ (timestamped, often before destructive commands) and /etc/lvm/backup/ (latest per VG). vgcfgrestore replays that text metadata onto the PVs — it does not copy user data blocks.

vgcfgrestore — command examples

Essential List metadata backups (read-only on production)

Before any restore, see which archive files exist and which command created each snapshot.

Run on a live system (read-only — does not change metadata):

bash
sudo vgcfgrestore -l ubuntu-vg

Sample output:

output
File:		/etc/lvm/archive/ubuntu-vg_00000-646425631.vg
  VG name:    	ubuntu-vg
  Description:	Created *before* executing 'vgextend ubuntu-vg /dev/sdb'
  Backup Time:	Tue Jun 30 15:35:49 2026

   
  File:		/etc/lvm/archive/ubuntu-vg_00001-1283759910.vg
  VG name:    	ubuntu-vg
  Description:	Created *before* executing 'lvextend -r -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv'
  Backup Time:	Tue Jun 30 15:35:52 2026

   
  File:		/etc/lvm/backup/ubuntu-vg
  VG name:    	ubuntu-vg
  Description:	Created *after* executing 'vgcfgbackup'
  Backup Time:	Tue Jun 30 19:12:01 2026

Pick the file whose Description matches the moment before the mistake (for example Created *before* executing 'lvremove ...').

Essential Dry run with --test

Validate a metadata file before applying it — no VG update and no activation in test mode.

Restore workflow on a disposable practice volume group:

bash
sudo vgcfgrestore vgcfg_lab5 --test -f /etc/lvm/archive/vgcfg_lab5_00001-1861322058.vg

Sample output:

output
TEST MODE: Metadata will NOT be updated and volumes will not be (de)activated.
  Restored volume group vgcfg_lab5.

If test mode reports errors about unknown PVs, the underlying disks moved or the wrong archive was chosen — fix PV layout before a real restore.

Essential Restore a removed LV from archive (lab)

After an accidental lvremove, replay metadata from the archive line created before that lvremove.

Lab sequence (loop device under /tmp):

bash
sudo lvremove -y vgcfg_lab5/datalv
sudo vgcfgrestore vgcfg_lab5 -f /etc/lvm/archive/vgcfg_lab5_00001-1861322058.vg

Sample output:

output
Restored volume group vgcfg_lab5.

Confirm the LV record exists again:

bash
sudo lvscan | grep datalv

Sample output:

output
ACTIVE            '/dev/vgcfg_lab5/datalv' [100.00 MiB] inherit

Data on disk survives only if extents were not wiped during lvremove — metadata recovery is not a substitute for backups or imaging when data blocks were discarded.

Common Activate an inactive restored LV

vgcfgrestore often leaves logical volumes inactive — activate before mounting.

Run the commands:

bash
sudo lvchange -ay vgcfg_lab5/datalv
sudo lvdisplay vgcfg_lab5/datalv | head -8

Sample output:

output
--- Logical volume ---
  LV Path                /dev/vgcfg_lab5/datalv
  LV Name                datalv
  VG Name                vgcfg_lab5
  LV Status              available

Then mount if filesystem metadata is intact:

bash
sudo mount /dev/vgcfg_lab5/datalv /mnt

If mount reports a bad superblock, the LV structure was recovered but filesystem blocks may be gone — restore from backups or run filesystem repair only after confirming extent data still exists.

Common Choose the right archive file

The newest file in /etc/lvm/backup/ is not always the one you want — it may reflect state after the accident.

List with descriptions:

bash
sudo vgcfgrestore -l ubuntu-vg

Choose the entry whose description says Created *before* executing 'lvremove ...' (or lvresize, vgreduce, etc.).

Restore that exact path:

bash
sudo vgcfgrestore -f /etc/lvm/archive/ubuntu-vg_00001-1283759910.vg ubuntu-vg

Using the wrong timestamp can remove other LVs from the VG map — always match the description to the failure event.

Common Restore without -f (latest backup file)

When the current /etc/lvm/backup/VG_NAME file is good, omit -f.

Run the command:

bash
sudo vgcfgrestore ubuntu-vg

Sample output:

output
Restored volume group ubuntu-vg.

This uses /etc/lvm/backup/ubuntu-vg — verify its Backup Time and Description with -l first. After an accidental lvremove, the default backup may already describe the broken state.

Advanced Manual backup before risky LVM work

LVM auto-archives before many commands, but a manual vgcfgbackup documents a known-good point.

Run before resizing or removing volumes:

bash
sudo vgcfgbackup ubuntu-vg
sudo vgcfgrestore -l ubuntu-vg | tail -6

Sample output:

output
File:		/etc/lvm/backup/ubuntu-vg
  VG name:    	ubuntu-vg
  Description:	Created *after* executing 'vgcfgbackup'
  Backup Time:	Wed Jul  1 18:50:00 2026

Store extra copies off-host (scp /etc/lvm/backup/ubuntu-vg backup-server:) — local archives do not help when the whole disk is lost.

Advanced Restore fails — PV UUID mismatch

If PVs were replaced or pvcreate was rerun on the wrong disk, metadata restore errors mention missing or unknown PVs.

Inspect PVs:

bash
sudo pvs
sudo pvdisplay

Compare UUIDs in the archive text file:

bash
sudo grep -E 'id =|device' /etc/lvm/backup/ubuntu-vg | head -20

Fix disk order or recover PV labels (pvcreate --restorefile / full LVM recovery guide) before vgcfgrestore can map extents correctly.

vgcfgrestore — when to use / when not

Use vgcfgrestore when Use something else when
  • A logical volume or VG metadata was removed or corrupted but PVs are intact
  • Archive files exist under /etc/lvm/archive or /etc/lvm/backup
  • You need to replay the LV map after a mistaken lvremove or vgcfgrestore test on the wrong file
  • You verified the correct archive with vgcfgrestore -l and --test
  • Physical disks failed or were overwritten → hardware replace + imaging, not metadata text files
  • Extents were wiped during lvremove and data is gone → backups / snapshots
  • You only need to resize an LV → lvextend / lvreduce
  • You need to export data from a damaged filesystem → mount recovery or dd imaging specialists
  • No LVM archives exist → pvcreate --restorefile or professional recovery

vgcfgrestore vs vgcfgbackup

vgcfgbackup vgcfgrestore
Direction Writes metadata text to /etc/lvm/backup/ Reads metadata text back onto PVs
Safety Read-only regarding LV data Overwrites current VG metadata
Typical use Before maintenance, off-host copies After accidental lvremove / bad vgchange

Always list with vgcfgrestore -l and run --test before applying on production.

vgcfgrestore — interview corner

What does vgcfgrestore do?

vgcfgrestore replays LVM volume group metadata from a text file produced by vgcfgbackup or automatic archives. It recreates VG/LV names, sizes, and extent maps on existing physical volumes.

It does not copy file contents — it restores the map of where LVM thinks data lives. User data remains only if the extents on disk were not overwritten or wiped.

A strong answer is:

"vgcfgrestore rebuilds LVM metadata from /etc/lvm/archive or backup files — it fixes mistaken lvremove at the metadata layer, not disk imaging."

Where does LVM store metadata backups?

Two locations:

  • /etc/lvm/archive/ — timestamped files, often created before destructive LVM commands (lvremove, lvresize, …)
  • /etc/lvm/backup/ — latest snapshot per VG, updated by vgcfgbackup and after some operations

Use vgcfgrestore -l VG to list both with descriptions and backup times.

A strong answer is:

"Archives under /etc/lvm/archive with 'Created before executing …' lines; latest per-VG file under /etc/lvm/backup. I list with vgcfgrestore -l before picking a file."

Why run vgcfgrestore --test first?

--test parses the metadata file and reports whether restore would succeed without writing VG metadata or activating volumes. It catches wrong files, missing PVs, and UUID mismatches before you damage a running system.

A strong answer is:

"vgcfgrestore --test is a dry run — I verify PV layout and pick the right archive before touching production metadata."

Why is my restored LV inactive?

Restore updates metadata; activation is separate. Run:

bash
sudo lvchange -ay VG/LV
sudo lvscan

Then mount the filesystem if superblocks are intact. Inactive status after restore is normal until lvchange -ay.

A strong answer is:

"vgcfgrestore only restores metadata — lvchange -ay activates the LV, then I mount and check filesystem health."

Does vgcfgrestore recover deleted files?

Only if the data extents still exist on the PVs. lvremove may discard data depending on version and options — metadata restore brings back the LV device node, but mount errors (bad superblock) mean blocks were wiped.

For real data loss, use backups, LVM snapshots, or imaging — not metadata text alone.

A strong answer is:

"Metadata restore ≠ file recovery. Data survives only if lvremove didn't wipe extents — otherwise I need backups or snapshots."

Troubleshooting

Symptom Likely cause What to try
Wrong LV layout after restore Used post-accident backup file vgcfgrestore -l, pick Created *before* executing 'lvremove'
Couldn't read volume group metadata from file Bad path or corrupt file ls -l /etc/lvm/archive/, retry with --test
Failed to find logical volume after restore Wrong archive or incomplete VG Different archive timestamp; pvs / vgs
LV active but mount fails (bad superblock) Extents wiped during lvremove Backups; do not run blind fsck on empty PV regions
File descriptor ... leaked warning Cursor/shell noise on some hosts Harmless in this environment; ignore if command succeeds

References

Read-only listing (vgcfgrestore -l) is safe on production. Full restore overwrites VG metadata — practice on a spare volume group before touching production.

  • vgcfgbackup(8) — Ubuntu man page
Rohan Timalsina

is a technical writer and Linux enthusiast who writes practical guides on Linux commands and system administration. He focuses on simplifying complex topics through clear explanations.

Expertise
  • Linux
  • HTML5
  • JavaScript
  • Web Design
  • Front-end Web Development

Related Articles

cheatsheet

pvcreate Command in Linux: Syntax, Options & Physical Volume Examples

pvcreate writes the LVM label and metadata on a disk or partition so it can join a volume group. Use it on …

7 min readlinux

Create and Mount Filesystems in Linux

Create ext4, XFS and VFAT filesystems in Linux with mkfs: identify the right block device, add labels, mount …

50 min readstorage

Configure LVM in Linux Step by Step

Create LVM physical volumes, volume groups, and logical volumes, format with XFS or ext4, mount by UUID, …

13 min read