企业官网建设流程全解析

You Set Up LVM During Install and Never Touched It Again#

Don’t worry, most people are in this camp. LVM (Logical Volume Manager) is one of those Linux features that gets configured during OS installation and then just… works, invisibly, while you go about your life. The abstraction layer does its job, your filesystem has space, everything is fine.

But LVM has capabilities that most people never discover because the tutorial they read five years ago coveredlvcreateandlvextendand called it a day.

Snapshots and thin provisioning are the features worth learning. Snapshots let you freeze a point-in-time copy of a logical volume — useful for backups, testing upgrades, or just having an “undo” before you do something potentially regrettable. Thin provisioning lets you allocate more storage than you physically have, which sounds like a bug but is actually a legitimate feature with real use cases.

Quick LVM Recap#

LVM has three layers:

• Physical Volumes (PV): actual disks or partitions (/dev/sda,/dev/nvme0n1p3, etc.)
• Volume Groups (VG): a pool of storage assembled from one or more PVs
• Logical Volumes (LV): virtual partitions carved out of a VG — these are what you format and mount

The workflow when you need more space: add a disk → create a PV → extend the VG → extend the LV → resize the filesystem. LVM handles the abstraction so you’re not dealing with disk geometry.

Terminal window

# Check your current setup

pvs # show physical volumes

vgs # show volume groups

lvs # show logical volumes

# More detailed view

pvdisplay

vgdisplay

lvdisplay

Copy

LVM Snapshots: Instant Undo Buttons#

A snapshot is a copy-on-write (COW) point-in-time image of a logical volume. At the moment you create the snapshot, no data is actually copied — LVM just records what the LV looks like at that instant. As you write new data to the original volume, LVM copies the old blocks to the snapshot before overwriting them. The snapshot preserves the old state; the original continues changing.

Creating a Snapshot#

Terminal window

# Syntax: lvcreate -L <size> -s -n <snapshot-name> <source-lv-path>

lvcreate -L 5G -s -n mydata_snap /dev/vg0/mydata

Copy

The snapshot needs its own space — this is where people get tripped up. The size you specify (-L 5Ghere) is not the size of the snapshot image. It’s the amount of COW space allocated to track changes. If you write 5GB of new data to the original volume before you’re done with the snapshot, the snapshot fills up and becomes invalid.

Rule of thumb: size your snapshot at 10-20% of the original LV if you’re using it for a quick backup, or larger if you expect heavy writes during the backup window.

Terminal window

# Check snapshot usage and health

lvs -o +lv_snapshot_invalid,snap_percent

Copy

Thesnap_percentcolumn tells you how full the COW space is. Watch this number. A snapshot at 100% is a dead snapshot.

Mounting a Snapshot for Backup#

The snapshot is a readable block device. Mount it to access the frozen filesystem state:

Terminal window

# Mount the snapshot read-only

mkdir /mnt/snapshot

mount -o ro /dev/vg0/mydata_snap /mnt/snapshot

# Now rsync or tar from here — the data won't change while you copy

rsync -av /mnt/snapshot/ /backup/destination/

# When done, unmount

umount /mnt/snapshot

Copy

This is much better than trying to back up a live filesystem. The snapshot gives you a consistent point-in-time image. Your backup tool isn’t racing against active writes.

For databases, you still want to quiesce writes or use application-level snapshot hooks before creating the LVM snapshot — MySQL’sFLUSH TABLES WITH READ LOCK, PostgreSQL’spg_start_backup(), etc. LVM handles the filesystem consistency, not the application consistency.

Merging a Snapshot Back#

If you created a snapshot before an upgrade and the upgrade went badly, you can roll back by merging the snapshot into the original:

Terminal window

# The volume must be unmounted (or the system should be in single-user mode)

umount /mount/point

# Merge snapshot into origin

lvconvert --merge /dev/vg0/mydata_snap

Copy

After merge, the snapshot disappears and the origin LV is restored to the snapshot’s state. If the LV was the root filesystem, you’ll need to do this from a live USB or by setting it up to merge on next boot:

Terminal window

# Schedule merge on next boot (for root LV)

lvconvert --merge /dev/vg0/root_snap

# Reboot — merge happens automatically

Copy

Removing a Snapshot When Done#

Terminal window

# Just remove it like any LV

lvremove /dev/vg0/mydata_snap

Copy

Don’t leave old snapshots sitting around indefinitely. They consume COW space and every write to the origin LV is slightly slower because LVM has to check if it needs to copy blocks to active snapshots.

Thin Provisioning: Lying About Your Storage (Productively)#

Traditional LVM is “thick provisioned” — when you create a 50GB logical volume, you immediately consume 50GB from the volume group, whether or not you’ve written a single byte to it. This works fine but it means your total allocated LV sizes can never exceed your physical storage.

Thin provisioning flips this. You create a thin pool, then create thin volumes that are backed by the pool. A thin volume reports to the OS that it has X GB available, but only consumes space from the pool as data is actually written.

This lets you over-provision — create more logical space than you have physical space — which is useful for:

• VM and container storage where many volumes will never actually fill up
• Development environments where you allocate space generously but most of it stays empty
• Multi-tenant environments where you want to give each tenant a quota without pre-reserving it

Setting Up a Thin Pool#

Terminal window

# Create a thin pool LV inside a volume group

# This example creates a 100GB thin pool on vg0

lvcreate -L 100G --thinpool mypool vg0

Copy

Creating Thin Volumes#

Terminal window

# Create a thin LV backed by the pool

# Note: -V specifies the virtual size — more than the pool can hold is fine

lvcreate -V 20G --thin -n vm1_disk vg0/mypool

lvcreate -V 20G --thin -n vm2_disk vg0/mypool

lvcreate -V 20G --thin -n vm3_disk vg0/mypool

# Total virtual: 60GB, pool: 100GB — fine, as long as actual data < 100GB

Copy

Terminal window

# Check thin pool usage

lvs -o +data_percent,metadata_percent vg0/mypool

Copy

Watchdata_percent. When it approaches 100%, your thin volumes will run out of backing space even though they think they have room. This is the “lying about storage” part — eventually reality catches up.

Thin Pool Monitoring and Autoextend#

LVM can automatically extend the thin pool when it gets full, as long as the VG has free space:

Terminal window

# Edit /etc/lvm/lvm.conf

# Find the activation section and set:

thin_pool_autoextend_threshold = 80

thin_pool_autoextend_percent = 20

Copy

This says: when the thin pool hits 80% full, automatically extend it by 20%. Combined with monitoring alerts at 70%, you’ll have breathing room.

Thin Snapshots#

Thin volumes support their own snapshot mechanism that’s more efficient than traditional LVM snapshots:

Terminal window

# Create a snapshot of a thin volume

lvcreate -s --name vm1_disk_snap vg0/vm1_disk

Copy

Thin snapshots don’t require pre-allocated COW space — they share the pool and only consume space for the actual changed blocks. You can create multiple snapshots without the “how much COW space do I need” calculation. This is the mechanism that most VM hypervisors and container storage drivers use under the hood.

Practical Use Cases#

VM Disk Snapshots Before Updates#

Before updating a VM’s OS or applying a major config change:

Terminal window

# Snapshot the VM's disk LV

lvcreate -L 10G -s -n vm1_before_upgrade /dev/vg0/vm1_disk

# Do the upgrade in the VM

# If it goes wrong:

lvconvert --merge /dev/vg0/vm1_before_upgrade

# If it goes right:

lvremove /dev/vg0/vm1_before_upgrade

Copy

Database Backup Pipeline#

#!/bin/bash

# Backup script with LVM snapshot

DB_LV="/dev/vg0/pgdata"

SNAP_NAME="pgdata_backup_snap"

SNAP_SIZE="5G"

BACKUP_DEST="/backup/postgres"

# Freeze PostgreSQL writes (or use pg_start_backup)

psql -U postgres -c "SELECT pg_start_backup('lvm_snap', true);"

# Create snapshot

lvcreate -L $SNAP_SIZE -s -n $SNAP_NAME $DB_LV

# Resume PostgreSQL writes immediately

psql -U postgres -c "SELECT pg_stop_backup();"

# Mount and back up from snapshot

mkdir -p /mnt/pg_snap

mount -o ro /dev/vg0/$SNAP_NAME /mnt/pg_snap

rsync -av /mnt/pg_snap/ $BACKUP_DEST/

# Cleanup

umount /mnt/pg_snap

lvremove -f /dev/vg0/$SNAP_NAME

Copy

The PostgreSQL freeze window is as short as it can possibly be — just the time to create the snapshot, which is nearly instant. The actual backup runs against the snapshot, not the live database.

Common LVM Commands Reference#

Terminal window

# Physical volumes

pvcreate /dev/sdb # Initialize a disk as PV

pvs # List PVs

pvremove /dev/sdb # Remove PV (VG must not use it)

# Volume groups

vgcreate myvg /dev/sdb # Create VG from PV

vgextend myvg /dev/sdc # Add PV to VG

vgs # List VGs

vgdisplay myvg # Detailed VG info

# Logical volumes

lvcreate -L 20G -n mydata myvg # Create 20G LV

lvcreate -l 100%FREE -n mydata myvg # Use all free space

lvextend -L +10G /dev/myvg/mydata # Extend by 10G

lvextend -l +100%FREE /dev/myvg/mydata # Extend using all free VG space

resize2fs /dev/myvg/mydata # Resize ext4 filesystem after extending

xfs_growfs /mount/point # Resize XFS filesystem after extending

# Snapshots

lvcreate -L 5G -s -n mysnap /dev/myvg/mydata # Create snapshot

lvconvert --merge /dev/myvg/mysnap # Merge snapshot back

lvremove /dev/myvg/mysnap # Remove snapshot

# Thin provisioning

lvcreate -L 100G --thinpool mypool myvg # Create thin pool

lvcreate -V 20G --thin -n vol1 myvg/mypool # Create thin volume

Copy

LVM rewards the people who take time to understand it. Snapshots turn “I hope this upgrade works” into a recoverable situation. Thin provisioning turns “how much disk do I give this VM” into a question you can answer generously and correct later. These aren’t exotic features — they’re the parts of LVM that make it worth using instead of just partitioning your disk directly.