vgcfgbackup writes a small text snapshot of a volume group's structure, and you will be very glad of it the day a physical volume goes missing. This is a short, read-and-write administration task: allow about ten minutes, and use a root shell or sudo where the destination requires it. The examples match LVM2 version 2.03.16(2), installed from the lvm2 package on this system.
Safety boundary: vgcfgbackup saves volume group configuration and metadata. It does not back up the contents of logical volumes. A backup is not a substitute for a filesystem, database or virtual machine backup.
First confirm which implementation is installed and list the volume groups visible to LVM. These commands only inspect the system.
$ vgcfgbackup --version
$ vgsOn this installation, the first command reports LVM version 2.03.16(2) (2022-05-18). In the rest of this guide, replace VG_NAME with the exact name shown by vgs. If vgs cannot see a group, do not guess its name: investigate device visibility, the devices file and any system ID restrictions first.
Checkpoint: Write down the target VG name and decide whether you need one group or every group visible to this host.
Use --test when you want to check the command path without updating metadata files. It disables metadata writing but can still produce messages from a multi-stage operation, so treat it as a rehearsal rather than proof that the final write will succeed.
$ sudo vgcfgbackup --test --verbose VG_NAMEA healthy rehearsal should not report an invalid VG name or an inaccessible destination. On a restricted shell, LVM may still warn about locking or device access. Fix those errors before making the real backup. The command does not need --yes: that option automatically answers prompts and is unnecessary here.
With no --file option, LVM writes each backup to a separate file named after the volume group in /etc/lvm/backup. Back up one named group when you want an explicit, easy-to-check result.
$ sudo vgcfgbackup VG_NAMESuccessful runs normally identify the backup file in their output. Check the file directly and inspect its beginning without editing it:
$ sudo ls -l /etc/lvm/backup/VG_NAME
$ sudo sed -n '1,24p' /etc/lvm/backup/VG_NAMEThe file is a text representation of VG metadata, not a copy of the blocks in any logical volume. It contains information needed by LVM tools to describe the group and its logical volumes, including the physical volume layout recorded in metadata.
To back up all visible groups in one invocation, omit the VG argument:
$ sudo vgcfgbackupThat default is easy to overlook. It means an unqualified command operates on all visible VGs, not on a group selected by the current directory or an environment variable.
--file sends the output somewhere else. For one VG, give a complete file name. The destination directory must already exist and be writable by the command.
$ sudo install -d -m 0750 /var/backups/lvm-metadata
$ sudo vgcfgbackup --file /var/backups/lvm-metadata/VG_NAME.conf VG_NAME
$ sudo ls -l /var/backups/lvm-metadata/VG_NAME.confCreating that directory changes system state, and the backup command may replace an existing file with the same name. Before rerunning an important custom destination, preserve the existing file if it is present:
$ if sudo test -e /var/backups/lvm-metadata/VG_NAME.conf; then
sudo cp -a /var/backups/lvm-metadata/VG_NAME.conf \
/var/backups/lvm-metadata/VG_NAME.conf.previous
fi
$ sudo vgcfgbackup --file /var/backups/lvm-metadata/VG_NAME.conf VG_NAMEFor multiple VGs, the --file value is a template. LVM replaces %s with each VG name:
$ sudo vgcfgbackup --file /var/backups/lvm-metadata/%s.confVerify the result with a directory listing. Do not use a literal shared filename for several groups unless you have confirmed the overwrite behaviour you want; the documented multi-VG form is the %s template.
Protect the backup files from the same failure that could affect the host. The default directory is on the host, so copy it to an approved backup system or removable destination as part of your normal backup process. A local metadata file cannot help if the host and its storage are both lost.
Keep the configuration that controls LVM with the metadata backups when your operational process allows it. The installed manual recommends regularly backing up files in /etc/lvm. Treat those files as sensitive operational data: access to them can reveal storage layout and, in a recovery mistake, they can be used with other LVM tools to alter metadata.
Do not test recovery by running vgcfgrestore on a live production group. Restore is a separate, potentially disruptive operation. If you need to recover, stop and assess the affected devices, current VG sequence number, logical volume state and service impact first. Keep the original backup file unchanged and work from a copied file when a recovery procedure calls for editing.
--foreign asks the command to report or display those groups, but it does not remove the ownership or system ID boundary.--nolocking in ordinary administration. The manual warns that concurrent commands can then produce incorrect results.--test deliberately does not update metadata files. Check the real destination after the non-test run.