Safely remove an LVM volume group with vgremove

You will remove an LVM volume group only after checking its logical volumes, physical volumes and backups. The final command deletes the VG metadata and can remove its logical volumes, so treat this as an irreversible storage change.

Allow 10 to 20 minutes for a small, well-documented VG. You need the lvm2 tools and a root shell for the actual change. The examples use the installed Ubuntu package, lvm2 2.03.16-3ubuntu3.2, whose manpage identifies the LVM tools as version 2.03.16(2).

1. Identify the volume group

Set a shell variable to the exact VG name. Replace the example with the name you have confirmed from your host:

$ VG_NAME=old-data
$ vgs "$VG_NAME"
  VG        #PV #LV #SN Attr   VSize   VFree
  old-data    2   0   0 wz--n-  1.81t   1.81t

The displayed row should be the group you intend to retire. If the name is wrong, stop here. Do not use a broad selector while learning the command.

2. Check logical volumes and mounted filesystems

vgremove removes one or more VGs. If logical volumes exist, it asks for confirmation before removing them. Review them before you reach that prompt:

$ lvs -a -o vg_name,lv_name,lv_attr,lv_size,devices "$VG_NAME"
  VG       LV       Attr       LSize Devices
  old-data  archive -wi-a----- 500g  /dev/sdb(0)

An empty #LV is the easiest case. If any LV is present, identify its filesystem, mount point, snapshots and dependent services. Check mounts with:

$ findmnt -rn -o SOURCE,TARGET,FSTYPE | grep -F "/dev/$VG_NAME/"

No output means this particular check found no mounted device path. It does not prove that no service, container or virtual machine has opened the device. Stop those consumers through their normal service controls, then check again.

3. Record the PVs and make a metadata backup

Review which physical volumes carry the group and whether LVM sees them as present:

$ pvs -o pv_name,vg_name,pv_attr,pv_size,pv_free "$VG_NAME"
  PV         VG       Attr       PSize  PFree
  /dev/sdb1  old-data a--         1.00t  1.00t
  /dev/sdc1  old-data a--       832.00g 832.00g

Save the current LVM metadata before removing anything:

# vgcfgbackup "$VG_NAME"
  Volume group "old-data" successfully backed up.

The backup is a recovery aid for LVM metadata, not a copy of the logical-volume contents. Keep it somewhere you can still access after the disks are detached. Do not confuse a metadata backup with a filesystem backup.

4. Run a no-write test

Use --test to exercise the command without updating metadata. LVM documents this as disabling metadata writing while still returning success to the calling function, so messages from a multi-stage operation can be unusual:

# vgremove --test --verbose "$VG_NAME"
  TEST MODE: Metadata writes are disabled. Test mode: Metadata changes will NOT be applied.
  Volume group "old-data" successfully removed

The exact verbose wording can vary. The useful result is that the command reaches the removal path without a device, lock or metadata error. Confirm that the group still exists afterwards:

$ vgs "$VG_NAME"
  VG        #PV #LV #SN Attr   VSize   VFree
  old-data    2   0   0 wz--n-  1.81t   1.81t

If the test reports a missing PV, do not jump to force removal. The installed manpage points to vgreduce --removemissing for making VG metadata consistent when one or more PVs are lost. That is a separate destructive decision that needs its own recovery plan.

5. Remove an empty, verified group

For a group with no LVs and no active users, run the real command as root:

# vgremove "$VG_NAME"
  Volume group "old-data" successfully removed

Recheck the result:

$ vgs "$VG_NAME"
  Volume group "old-data" not found

A non-zero result here is expected because the named VG no longer exists. Use the exit status from the command itself for automation, not the wording of its report.

6. Handle a group that still contains LVs

If the group contains LVs, the normal command prompts before removing them. Read the prompt and answer only after verifying that the data is disposable:

# vgremove "$VG_NAME"
Do you really want to remove active logical volume old-data/archive? [y/n]: y
  Logical volume "archive" successfully removed
  Volume group "old-data" successfully removed

Do not add --yes to a first manual run. It suppresses the confirmation and assumes yes. Likewise, repeated --force, written --force --force or -ff, forcibly removes LVs without confirmation. The manpage describes force as overriding checks, confirmations and protections. That is for a deliberately reviewed recovery operation, not a way around an unclear prompt.

If you have not yet removed the group and need to undo your decision, stop before running vgremove. Once the metadata and LVs are removed, restoration depends on your backups and the exact storage state. vgcfgrestore may restore LVM metadata in suitable cases, but it is not a general undelete operation and should be planned against a copy or recovery procedure.

Common traps

• Using the wrong name: run vgs first and copy the exact VG name.
• Assuming no mount means no dependency: inspect services, containers, virtual machines and open devices.
• Trusting test mode as a complete rehearsal: it prevents metadata writes, but later stages can report unusual results because their expected changes did not happen.
• Forcing around a missing PV: investigate with vgreduce --removemissing only when you understand which data and metadata are already unavailable.
• Running as root unnecessarily: use ordinary privileges for inspection where they work, and reserve sudo or a root shell for LVM changes that require it.