Safely Remove an LVM Volume with lvremove

lvremove destroys a logical volume's contents with no undo, so the whole job here is checking you have the right one before you press enter. The examples use LVM version 2.03.16(2) from package lvm2 version 2.03.16-3ubuntu3.2 on the reference machine.

• Time: 10 to 15 minutes for an ordinary volume, longer if you need to identify mounts or dependent snapshots.
• Needs: the lvm2 tools, a shell, and sudo access for commands that inspect or change system storage.

1. Identify the exact logical volume

Use an unprivileged listing first. Replace nothing in this command; it is a read-only inventory:

$ sudo lvs -o vg_name,lv_name,lv_path,lv_attr,lv_size,origin,lv_active

Find the row for the volume you intend to remove. Record its complete path, such as /dev/example-vg/archive, and check the volume group name, size, active state and origin columns. Do not identify a volume from a short name alone when several volume groups contain the same name.

2. Check mounts and open users

An active volume cannot be deactivated or removed while it is open, including when it contains a mounted filesystem. Check mounts and holders before changing anything:

$ findmnt --source /dev/example-vg/archive
$ sudo lsof /dev/example-vg/archive

No output from findmnt means that exact device is not mounted through the usual mount table. An empty lsof result is useful but not proof every dependent device is idle: a filesystem, swap area, container, database, or another mapped device may refer to the volume indirectly. Check the service and application that owns the data before proceeding.

If the volume is mounted, stop the owning service using its normal service procedure, unmount it, and verify the result:

$ sudo systemctl stop example-service
$ sudo umount /dev/example-vg/archive
$ findmnt --source /dev/example-vg/archive

The stop and unmount commands change service state and require elevated privileges. If the unmount reports the target is busy, find the remaining user and fix that dependency. Do not use a lazy or forced unmount as a shortcut around understanding what is still using the data.

3. Look for snapshots and dependent volumes

Removing an origin also removes its dependent snapshots. Review the origin relationship explicitly:

$ sudo lvs -a -o vg_name,lv_name,lv_path,lv_attr,origin,lv_size

If the target appears in another row's origin column, that row is a dependent snapshot. Decide whether each snapshot is disposable before removing the origin: a snapshot is not a backup merely because it has a different name. If a snapshot contains the only copy of a required recovery point, export or otherwise preserve its data first.

4. Back up LVM metadata

Save the volume group's metadata before the destructive command. The standard tool writes a text backup using the configured LVM backup location:

$ sudo vgcfgbackup example-vg
$ sudo vgs -o vg_name,vg_size,vg_free,pv_count,lv_count example-vg

Check the command's success status and keep the resulting metadata backup somewhere covered by your normal backup process. It can help reconstruct LVM metadata, but it cannot restore filesystem blocks already destroyed by lvremove; do not treat it as a substitute for a data backup.

5. Run a no-change test

Use LVM's test mode with the exact path. It exercises the command without committing metadata changes:

$ sudo lvremove --test /dev/example-vg/archive

Output varies with the device state and configuration. The useful result is a successful exit status and a plan that names the intended logical volume. Confirm it immediately:

$ printf 'test status: %s\n' "$?"

Test mode is a rehearsal, not a guarantee a later command will succeed. The device state can change between commands, and test mode does not prove the data is backed up. Re-run the inventory if there has been a delay.

6. Remove the volume and verify it

This is the irreversible step. Read the path twice, then run the normal command and answer its confirmation prompt only after checking the name shown:

$ sudo lvremove /dev/example-vg/archive
Do you really want to remove active logical volume example-vg/archive? [y/n]: y

The prompt is expected when an active volume must be deactivated; an open volume cannot be removed. For a volume already inactive, the command may not need that prompt. Do not add --yes merely to make a script run faster: it answers prompts automatically, but does not identify the right volume for you.

Verify the path is gone and the group's free space increased by roughly the removed logical-volume size:

$ sudo lvs -o vg_name,lv_name,lv_path,lv_size,origin example-vg
$ sudo vgs -o vg_name,vg_free,lv_count example-vg

The exact table formatting and free-space amount depend on extents and other volumes. The removed name should no longer appear as a normal LV, and lv_count should be lower.

7. Use force only for a known reason

A single --force removes confirmation and makes LVM try to deactivate unused volumes. It does not make a mounted or otherwise open volume safe to remove. Use it only when you have already performed the checks and an unattended, reviewed operation genuinely needs no prompt:

$ sudo lvremove --force /dev/example-vg/archive

If historical LV recording is enabled, LVM can retain a simplified record for an LV that forms part of a thin-snapshot ancestry. Such a record has a hyphen-prefixed name, cannot be activated, and can be removed separately with lvremove when you have confirmed the history is no longer useful. The --nohistory option disables recording for the removal; use it only when that loss of ancestry information is deliberate.

Recovery and common traps

• You removed the wrong volume. Stop using the volume group and its remaining free extents. There is no lvremove undo operation; the vgcfgbackup file is metadata assistance, not a copy of the removed files. Restore through your documented backup procedure rather than creating a new volume and assuming its old blocks are intact.
• LVM says the volume is open. Repeat findmnt and lsof, then inspect swap, services, containers and device-mapper users.
• LVM says the volume is active. An ordinary removal can usually deactivate it once open users have gone.
• The volume is damaged. Preserve diagnostics and a metadata backup before considering -ff.
• The volume is not found. Verify the volume group, device visibility and any configured devices file instead of guessing at a path.

Done means

• Identified the exact volume path from lvs.
• Checked mounts, open users and dependent snapshots.
• Backed up LVM metadata with vgcfgbackup.
• Rehearsed the removal with --test where practical.
• Removed the volume without unreviewed force options.
• Verified lvs no longer lists the removed volume and checked the volume group's free space.