Backup & Restore file groups in Linux

— ny_wk

To backup an LVM volume group in Linux, run vgcfgbackup -f /path/to/file vgname to save its metadata, and restore it later with vgcfgrestore -f /path/to/file vgname. This protects the layout of your logical volumes against accidental deletion, a corrupted metadata header, or a misfired command — without ever touching the actual data blocks on disk.

This guide explains exactly what an LVM volume group backup does (and does not) cover, walks through a full backup-and-restore cycle on a sample volume group, and shows how to recover when a vgremove or a damaged metadata area takes your storage offline. Every command here is real and tested against modern lvm2.

What vgcfgbackup actually saves

A common misconception trips up new administrators: vgcfgbackup does not copy your files or your logical volume data. It saves only the LVM metadata — a small text description of the volume group: which physical volumes belong to it, their UUIDs, how many extents each has, and how the logical volumes (LVs) are mapped onto those extents.

That distinction matters. The metadata backup lets you rebuild the structure of a volume group, but it relies on the underlying physical volumes still being intact. Think of it as restoring the table of contents and chapter map of a book — the pages (your data) must still be on the disk for the map to be useful.

• What it covers: VG name and UUID, PV membership and UUIDs, LV names, sizes, extent mappings, and stripe/mirror layout.
• What it does NOT cover: filesystem contents, file data, or the bytes inside any logical volume.

For real disaster protection you still need a conventional data backup (with tar, rsync, snapshots, or a backup product). The metadata backup is the companion that lets you put the structure back so the data backup has somewhere to land.

LVM already backs up metadata automatically

Before doing anything manual, know that LVM is already protecting you. Every time you change a volume group, lvm2 writes an automatic metadata backup to /etc/lvm/backup/ and keeps a rolling archive of previous versions in /etc/lvm/archive/. This behaviour is controlled by the backup and archive settings in /etc/lvm/lvm.conf and is enabled by default.

So in many real recovery situations you do not even need a hand-made file — you can restore directly from the archive. Listing the archive entries for a volume group is the first thing to try after an accidental change:

1. List archived metadata versions for a VG: vgcfgrestore -l vgname
2. Inspect the timestamped files directly: look in /etc/lvm/archive/vgname_*.vg

The manual vgcfgbackup command is still valuable when you want a portable copy you can store on NFS, copy off the host, or version-control before a risky maintenance window.

Scenario: a volume group with two logical volumes

To make the steps concrete, assume a volume group named umvg built on one or more physical volumes. It contains two logical volumes:

Confirm the current state before you begin so you have something to compare against after the restore:

1. Show the volume group summary: vgs umvg
2. List the logical volumes: lvs umvg
3. List the physical volumes that back it: pvs -S vg_name=umvg

Step 1: Back up the volume group metadata

Use vgcfgbackup with the -f (file) option to write the metadata to a location you choose — /opt, /tmp, or an NFS share are all fine. Avoid putting the only copy on a logical volume inside the same VG you are backing up, because if that VG fails you lose the backup with it.

1. Write the backup file: vgcfgbackup -f /opt/umvg.vg umvg
2. Confirm it was created: ls -l /opt/umvg.vg
3. Peek at the human-readable contents: head -40 /opt/umvg.vg

Here -f /opt/umvg.vg is the destination file and umvg is the name of the volume group to back up. The output is plain text, so you can open it in any editor and read the LV definitions directly. If you run vgcfgbackup with no -f and no VG name, it refreshes the automatic backups in /etc/lvm/backup/ for every VG.

Step 2: Inspect a backup or archive file

To list the metadata versions LVM holds for a VG and to validate a file before relying on it, use the -l (list) option. To list the contents of your specific backup file, combine it with -f:

1. List archived versions for the VG: vgcfgrestore -l umvg
2. List details of your own backup file: vgcfgrestore -l -f /opt/umvg.vg umvg

This prints each saved version with its timestamp and a short description of what changed, which helps you pick the right point to roll back to. Always confirm the file you intend to restore really describes the VG and LVs you expect before you proceed.

Step 3: Simulate a failure (remove the volume group)

To demonstrate recovery, deliberately tear the volume group down. Unmount the filesystems first — LVM will refuse to remove active volumes, and forcing it while mounted risks corruption.

1. Unmount both filesystems: umount /um1 && umount /um2
2. Deactivate the volume group: vgchange -an umvg
3. Remove the logical volumes and the VG: vgremove umvg

Confirm the prompts when vgremove asks, or pass -y in a script. Crucially, vgremove clears the metadata and frees the physical volumes, but on standard removal it does not wipe the data extents themselves. That is precisely why a metadata restore can bring the structure — and therefore access to the still-present data — back.

Important caveat: this only holds while the underlying physical volumes are untouched. If those PVs were reused, reformatted, or overwritten after the removal, restoring metadata will point at data that no longer exists. Test this procedure on a non-production VG first.

Step 4: Restore the volume group from the backup

vgcfgrestore rewrites the saved metadata onto the volume group's physical volumes. The physical volumes must still carry their original UUIDs — the metadata file is matched to the disks by UUID, not by device name like /dev/sdb.

1. (If the PV header itself was lost) recreate the PV with its original UUID and the backup file:
   pvcreate --uuid <original-uuid> --restorefile /opt/umvg.vg /dev/sdb
2. Restore the volume group metadata: vgcfgrestore -f /opt/umvg.vg umvg

Here -f /opt/umvg.vg is the source backup file and umvg is the VG to restore. If you only deleted the VG (and the PVs still hold their headers), step 1 is unnecessary and a single vgcfgrestore is enough. After it completes, the volume group and its logical volume definitions exist again — but the LVs come back inactive.

Step 5: Activate and mount the restored logical volumes

A freshly restored volume group is not automatically activated, so /dev/umvg/umlv1 and /dev/umvg/umlv2 will not appear until you turn them on. Activate the whole VG, then remount.

1. Activate every LV in the VG: vgchange -ay umvg
2. Verify the LVs are now active (look for an a in the Attr column): lvs umvg
3. Remount the filesystems: mount /dev/umvg/umlv1 /um1 && mount /dev/umvg/umlv2 /um2

Your data is accessible again under /um1 and /um2. Because the data extents were never overwritten and the metadata maps them back to the same positions, the filesystems mount exactly as before.

Common pitfalls when restoring LVM metadata

Most failed restores come from a handful of avoidable mistakes. Watch for these:

• Trying to restore over reused disks. If the PVs were reformatted or repurposed after removal, the data is gone and metadata restore cannot recover it.
• Missing PV UUID. If a PV header was wiped, you must recreate it with pvcreate --uuid <uuid> --restorefile ... using the exact original UUID from the backup file, or the restore will fail to find its disks.
• Forgetting to activate. Restored LVs are inactive by design; run vgchange -ay before you try to mount them.
• Restoring while the VG is in use. Deactivate and unmount before destructive steps to avoid corruption.
• Storing the backup inside the same VG. Keep at least one copy off-host (NFS, object storage, or another disk).
• Confusing metadata with data. A successful vgcfgrestore never replaces lost file contents — keep real data backups too.

Verification: confirm the restore succeeded

Do not assume the restore worked just because the commands returned cleanly. Verify end to end:

1. VG exists with the right size and PV count: vgs umvg
2. Both LVs are present and active: lvs -o lv_name,lv_size,lv_attr umvg
3. Filesystems mount cleanly: mount | grep -E 'um1|um2'
4. Run a quick filesystem check if you suspect issues: fsck -n /dev/umvg/umlv1 (read-only check)
5. Confirm your expected files are present: ls -l /um1 /um2

If vgs shows the VG, lvs shows both volumes with active attributes, and your files are readable, the recovery is complete and trustworthy.

Key Takeaways

• vgcfgbackup saves metadata, not data — it records the VG/LV layout, so you still need separate file-level backups.
• LVM auto-backs up metadata to /etc/lvm/backup/ and /etc/lvm/archive/ on every change; vgcfgrestore -l vgname lists those points.
• Restore works only if the PVs are intact — metadata is matched to disks by UUID, and reused or wiped disks cannot be recovered this way.
• Restored logical volumes come back inactive — always run vgchange -ay vgname before mounting.
• Verify after restoring with vgs, lvs, and a real mount-and-list test before declaring success.

Frequently Asked Questions

Does vgcfgrestore recover the data inside my logical volumes?

No. It only restores the LVM metadata — the map of how LVs sit on physical volumes. The actual data must still be present on the physical volumes. If those disks were reformatted or overwritten, the data is unrecoverable by this method, so always keep conventional data backups as well.

Where does LVM keep its automatic metadata backups?

Current metadata backups live in /etc/lvm/backup/ and a history of previous versions is archived in /etc/lvm/archive/. Both are written automatically whenever a VG changes, controlled by the backup and archive options in /etc/lvm/lvm.conf.

Why are my logical volumes inactive after a restore?

This is expected behaviour. vgcfgrestore rewrites the metadata but does not activate the volumes. Run vgchange -ay vgname to activate every LV in the group, then mount them as usual.

What if the physical volume lost its UUID header?

Recreate the PV with its original identity using pvcreate --uuid <original-uuid> --restorefile /opt/umvg.vg /dev/sdX, taking the UUID from the backup file, then run vgcfgrestore -f /opt/umvg.vg umvg. Using a new UUID will break the mapping, so the original value is essential.

Found this helpful? Subscribe on YouTube @explorenystream for more Linux and sysadmin walkthroughs.