Safely Remove an LVM Logical Volume with lvremove

You will remove a named LVM logical volume after checking that it is the volume you mean, that nothing has it open, and that you have a metadata backup. The examples use LVM version 2.03.16(2) from package lvm2 version 2.03.16-3ubuntu3.2 on the reference machine.

Allow 10 to 15 minutes for an ordinary volume and longer if you need to identify mounts or dependent snapshots. You need the lvm2 tools, a shell, and sudo access for commands that inspect or change system storage. Removing a volume destroys its logical-volume contents. There is no undo command for the data.

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.

Checkpoint: the target should be one specific path. If the row is absent, stop and investigate device visibility or the volume-group name; do not add force options.

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 that 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 that 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. If a snapshot contains the only copy of a required recovery point, export or otherwise preserve its data first. A snapshot is not a backup merely because it has a different name.

Checkpoint: you have confirmed the target path, its mount state, its open users and the effect on snapshots. If any of those answers is unclear, stop here.

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. This 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 that a later command will succeed. The device state can change between commands, and test mode does not prove that 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 that the path is gone and that 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

Two force options, written --force --force or -ff, may be required for damaged logical volumes. That is an exceptional recovery operation, not a general fix for an ordinary refusal. A failed command should first be diagnosed from its error, mount state, open users, locks and LVM metadata.

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 that 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 failure cases

If you removed the wrong volume, stop using the volume group and its remaining free extents. There is no lvremove undo operation. Recovery depends on a filesystem or application backup; the vgcfgbackup file is metadata assistance, not a copy of the removed files. Restore through the documented backup procedure rather than creating a new volume and assuming its old blocks are intact.

If LVM says the volume is open, repeat findmnt and lsof, then inspect swap, services, containers and device-mapper users. If it says the volume is active, an ordinary removal can usually deactivate it after open users have gone. If the volume is damaged, preserve diagnostics and a metadata backup before considering -ff. If the volume is not found, verify the volume group, device visibility and any configured devices file instead of guessing at a path.