LVM Storage Migration: How to Move Data Safely

LVM storage migration lets you move logical volumes between physical disks, or between volume groups, without unmounting the filesystem or interrupting running services. You use commands like pvmove, vgextend, and pvreduce to relocate data at the block level while the system stays online. This article explains the core concepts, the exact steps for common migration scenarios, and the pitfalls that can cause data loss if you skip verification.

What Is LVM and Why Migrate?

Logical Volume Manager (LVM) is a device mapper framework for Linux that abstracts physical storage into logical volumes. Instead of partitioning a disk directly, you create physical volumes (PVs), group them into a volume group (VG), and then carve logical volumes (LVs) out of that pool. This indirection is what makes migration possible: because the filesystem sits on a logical volume, the underlying physical disk can change without the filesystem noticing.

You would migrate storage for several reasons:

• Replace a failing disk before it causes downtime.
• Move to larger or faster storage (e.g., from HDD to SSD).
• Re-balance data across multiple disks in the same volume group.
• Move a volume group to a new server by exporting and importing it.

LVM migration is distinct from filesystem-level copy tools like rsync because it operates on the block layer, preserving all metadata, permissions, and even deleted-but-open files. It is also faster for large volumes since it only copies allocated extents, not empty space.

How LVM Migration Works

LVM stores data in fixed-size chunks called physical extents (typically 4 MiB). Each logical extent in an LV maps to a physical extent on some PV. Migration simply re-maps those physical extents to a different PV. The pvmove command does this in-place:

1. It reads the source PV’s allocated extents.
2. It allocates equivalent extents on the destination PV (or PVs).
3. It copies the data and updates the LVM metadata atomically per extent.
4. It frees the source extents after the copy is verified.

Because LVM metadata is small and updated transactionally, a crash mid-migration leaves the volume consistent — some extents moved, some not, but all valid. The pvmove command can be safely resumed after a reboot with the same command.

For whole-disk replacement, the typical sequence is:

1. Add the new disk as a PV: pvcreate /dev/sdb
2. Add it to the volume group: vgextend myvg /dev/sdb
3. Move all extents from the old disk: pvmove /dev/sda
4. Remove the old PV from the VG: vgreduce myvg /dev/sda
5. Remove the old disk from LVM: pvremove /dev/sda

During step 3, the filesystem remains mounted and fully usable. Reads and writes continue; LVM handles the relocation in the background.

Choosing the Right Migration Method

Not all migrations are the same. The right method depends on what you are moving and why:

• pvmove — for moving extents between PVs in the same VG. This is the most common and safest method for disk replacement or rebalancing.
• vgexport / vgimport — for moving a whole VG to another machine. You must unmount all LVs and run vgchange -a n first.
• Snapshot + merge — for testing a migration or creating a point-in-time copy. Not a true migration, but useful for validation.
• Filesystem-level copy — when LVM is not available or when you need to change the filesystem type. This requires unmounting and is slower for large volumes.

For most in-place disk swaps, pvmove is the answer. If you are moving between volume groups (e.g., from vg1 to vg2), you cannot use pvmove directly. Instead, you would use dd or a filesystem copy, or create a temporary LV in the destination VG and copy with dd or rsync.

Step-by-Step: Migrating to a New Disk

Here is a complete example assuming you have a VG called myvg with one LV on /dev/sda and you want to move it to /dev/sdb (same size or larger).

1. Verify current layout: pvs and lvs to confirm which PVs hold the LV extents.
2. Prepare the new disk: pvcreate /dev/sdb
3. Extend the VG: vgextend myvg /dev/sdb
4. Start the move: pvmove /dev/sda — this moves all extents from sda to any free extents in the VG (which is now sdb).
5. Monitor progress: pvmove -v or watch lvs -a -o +devices to see extents relocating.
6. Verify completion: pvs should show /dev/sda with 0 used extents.
7. Remove the old PV: vgreduce myvg /dev/sda then pvremove /dev/sda

If you only want to move a specific LV, use pvmove -n myvg/mylv /dev/sda. If the destination PV is not yet in the VG, add it first. If you have multiple destination disks, LVM will spread the extents automatically.

Common Problems and How to Avoid Them

LVM migration is robust, but mistakes happen. The most frequent issues:

• Not enough free space on the destination. pvmove will fail with a “No space leftâ€� error. Check pvs and vgdisplay for free extents before starting.
• Moving a PV that is part of a RAID or thin pool. These have special constraints; use lvconvert --repair or migrate at the RAID level instead.
• Forgetting to run vgscan after adding a new disk. The system may not see the PV until you rescan.
• Using dd to copy an entire disk without adjusting UUIDs. This creates duplicate PV UUIDs and confuses LVM. Always use pvmove or change the UUID with pvchange -u after a raw copy.

A common misconception is that pvmove requires downtime. It does not — the filesystem stays mounted. However, heavy I/O during migration can slow performance, so schedule it during low usage if possible.

Safety and Verification Steps

Before any migration, take these precautions:

• Back up the LVM metadata: vgcfgbackup -f /tmp/myvg.backup myvg. This allows you to restore the VG layout if metadata is corrupted.
• Check filesystem health: run fsck on a read-only copy or after unmounting, if possible.
• Verify the destination disk is not already in use: lsblk and blkid to avoid overwriting data.
• After migration, test the new disk: run smartctl -H /dev/sdb (if available) and confirm the system boots from the new disk if it is the root volume.

If you are migrating a root or boot volume, you must also reinstall the bootloader on the new disk (e.g., grub-install /dev/sdb) and update /etc/fstab if the UUID changed. LVM itself uses stable UUIDs, but the partition table on the new disk may differ.

Alternatives to LVM Migration

LVM is not the only way to move storage. Alternatives include:

• Filesystem-level tools like rsync or cp -a — works across any filesystem, but requires unmounting or a live backup tool and does not preserve block-level layout.
• Device mapper mirroring — create a mirror across old and new disks, then break the mirror. This is similar to pvmove but gives redundancy during the migration.
• Hardware RAID migration — if your disks are in a hardware RAID, you can often replace disks one by one and let the controller rebuild. This is simpler but requires compatible hardware.
• Stratis or Btrfs — newer storage management layers that offer similar pooling and migration features, but with different commands and trade-offs.

For most Linux administrators, pvmove remains the fastest and safest method for moving data between disks within the same volume group.

Frequently Asked Questions

Can I migrate a logical volume while it is mounted?

Yes. pvmove operates at the block layer and does not require unmounting. The filesystem stays online and consistent. However, you should avoid making a snapshot of the LV during migration, as that can cause confusion.

What is the difference between pvmove and vgmerge?

pvmove moves physical extents between PVs within the same VG. vgmerge combines two separate volume groups into one, which is a different operation. You would use vgmerge when you want to pool storage from two VGs, not when you want to replace a disk.

How long does a migration take?

It depends on the amount of allocated data, disk speed, and system load. A 1 TB volume with 500 GB used on a SATA disk might take several hours. You can check progress with pvmove -v or by looking at /proc/mdstat if using RAID. There is no built-in ETA, but you can estimate by observing the rate of extents moved per second.

What happens if the system crashes during pvmove?

LVM metadata is transactional, so the volume remains consistent. After reboot, run pvmove again with the same arguments; it will resume from where it left off. Do not attempt to remove the PV until the move completes successfully.

Can I migrate to a smaller disk?

Only if the used space on the source PV is less than the total capacity of the destination. pvmove will fail if the destination lacks enough free extents. You can shrink the filesystem and LV first, but that requires unmounting and is risky.

Do I need to update /etc/fstab after migration?

Usually not, because LVM uses stable device mapper names like /dev/mapper/myvg-mylv that do not change when the underlying PV changes. If you used raw device paths (e.g., /dev/sda1) in fstab, you should update them to the LV path. Also, if you moved the root filesystem to a new disk, you must reinstall the bootloader.

Related

• Solana Treasury Shrinkage: What It Means
• Mac Won’t Go to Sleep? Fixes That Actually Work
• Violet Abilities & Beginner Playstyle in Deadlock