Safely Remove a Physical Volume with vgreduce

A disk you want out of a volume group is not something you can just unplug. vgreduce removes a physical volume properly, extents and all. The safe path here is deliberately cautious: inspect, move, back up, then run the command.

Allow about fifteen minutes for an already familiar volume group, plus however long pvmove needs to copy allocated extents. These commands use the installed lvm2 package, version 2.03.16-3ubuntu3.2, with LVM tools reporting version 2.03.16(2).

1. Confirm the command and the target

Start with read-only checks. Replace the example names with values from your host. Do not guess a device path from a disk's size or serial number.

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

List the volume groups and their physical volumes before making a change:

# vgs
# pvs -o pv_name,vg_name,pv_size,pv_free
# pvs --segments --columns

Checkpoint: Write down the exact volume group and PV names. The command shape is vgreduce VG PV, where the volume group comes first and one or more physical volumes follow.

2. Check that the PV is empty

vgreduce removes physical volumes that are unused. It does not move allocated extents for you. The pvs report gives a quick indication, but a non-zero pv_used value means you must move data before reducing the group.

# pvs -o pv_name,vg_name,pv_size,pv_free,pv_used
  PV             VG       PSize   PFree   PUsed
  /dev/sdb1      archive  100.00g 100.00g 0
  /dev/sdc1      archive  100.00g  12.00g 88.00g

The column layout and values are host-specific. The useful condition is that the target PV, here /dev/sdb1, has no allocated extents. Also check the target is not the only PV that can hold the data you need to preserve.

3. Move allocated extents when necessary

If the target has allocated extents, use pvmove to move them to another PV in the same group. This changes LV placement and can take time, so plan around the workload using the storage.

# pvmove /dev/sdc1 /dev/sdb1
  /dev/sdc1: Moved: 12.50%
  /dev/sdc1: Moved: 100.00%

Do not treat the progress lines as a guarantee of success. When the command finishes, check the allocation again:

# pvs -o pv_name,vg_name,pv_free,pv_used /dev/sdc1
  PV         VG       PFree   PUsed
  /dev/sdc1  archive  100.00g 0

If pvmove is interrupted, its manual page says to run pvmove again without PV arguments to restart an operation in progress. It also documents pvmove --abort; an abort can leave already moved segments on the destination unless the move used --atomic.

4. Back up the volume group metadata

Make a metadata backup before the destructive step. vgcfgbackup writes the default backup file under /etc/lvm/backup. It backs up VG metadata, not the contents of logical volumes.

# vgcfgbackup archive
  Volume group "archive" successfully backed up.
# ls -l /etc/lvm/backup/archive

Checkpoint: Confirm that the backup file exists and is readable by root. If you need recovery later, vgcfgrestore is the LVM tool for restoring volume group metadata. Do not restore metadata casually: it can make the recorded layout disagree with the disks and can make a bad situation worse.

5. Dry-run the reduction

Use --test to exercise the command without updating metadata. This is a useful final review, but it is not a perfect simulation. The installed manual warns that multi-stage operations can print unusual errors because the tool believes metadata changed when it did not.

# vgreduce --test archive /dev/sdb1
  TEST MODE: Metadata will NOT be updated and volumes will not be deactivated.

Read the complete output. A successful test does not prove that a later real run will succeed if another administrator, service or storage event changes the group first.

6. Remove the unused PV

Warning: this changes LVM metadata. Make sure the PV is unmounted where appropriate, no maintenance job is using it, and you have identified the correct device. Run the real command with elevated privileges:

# vgreduce archive /dev/sdb1
  Removed "/dev/sdb1" from volume group "archive"

Without --yes, LVM can ask for confirmation. Keep that prompt in interactive work. Use --yes only in a reviewed automation path, because it accepts confirmations rather than making the operation safer. Automatic metadata backup is strongly advised by the manual; if your configuration disables it, add --autobackup y to this command.

7. Verify the result

Query both the volume group and the removed PV. The PV should no longer belong to the VG, while the VG should still show the remaining storage:

# vgs archive
# pvs -o pv_name,vg_name,pv_size,pv_free,pv_used

A normal result has no archive value in the vg_name column for /dev/sdb1. If the device is being retired, do not jump straight to pvremove: check mounts, signatures, backups and ownership first. vgreduce only removes the PV from the group; it does not erase the device.

When a PV has gone missing

--removemissing is a separate recovery operation, not a shortcut for a healthy disk. It removes missing PVs when no logical volumes are allocated on them and lets the VG resume normal operation.

# vgreduce --removemissing archive

If logical volumes still reference the missing PV, the manual allows --force to remove partial LVs. That can remove affected LVs and dependent snapshots completely, including parts that were on disks that are still present. Data recovery may be possible by activating affected LVs in partial mode before doing this, but that is an incident-response decision, not routine administration.

Warning: do not add --force because a normal reduction failed. For a present but occupied PV, move the extents. For a missing disk, identify what data is affected and preserve what you can before accepting partial logical-volume removal.

Done means