Creating And Restoring LVM Snapshots On CentOS

Logical Volume Manager (LVM) snapshots provide a practical way to capture a point-in-time view of a filesystem on CentOS. They are useful before package upgrades, configuration changes, database maintenance, and other operations where a quick rollback may be valuable.

An LVM snapshot records changed blocks while the original logical volume continues serving data. It is fast to create, but it is not a complete backup. If the volume group, physical disk, or snapshot itself is lost, the snapshot cannot protect the system.

The commands below suit CentOS and related Red Hat-based systems. The device names may differ on a particular server, so identify the volume group and logical volumes before running any destructive command. Administrators maintaining systems in Sydney, Melbourne, or a Perth hosting facility should also check local backup windows and available storage before beginning work.

Task	Example command	Main consideration
Display LVM layout	`lsblk` and `lvs`	Confirm the correct volume path
Create a snapshot	`lvcreate -s -n root_snap -L 5G /dev/centos/root`	Allocate enough copy-on-write space
Mount a snapshot	`mount -o ro /dev/centos/root_snap /mnt/snapshot`	Use read-only access for inspection
Remove a snapshot	`lvremove /dev/centos/root_snap`	Delete it only after checking dependencies
Restore changes	`lvconvert --merge /dev/centos/root_snap`	Reboot may be required for an active root volume

Inspect The CentOS LVM Layout

Start by confirming that LVM is in use and recording the current arrangement of physical volumes, volume groups, and logical volumes:

sudo pvs
sudo vgs
sudo lvs -a -o lv_name,vg_name,lv_size,lv_attr,origin,data_percent
lsblk -f

A common layout uses a volume group named centos with logical volumes such as root, home, and swap. Your server might instead use names like vg0 and lv_root. Substitute the actual path in every command.

Check free space in the volume group with vgs. Snapshot space is allocated from that group, not from an unrelated filesystem. A local VM in Brisbane, for example, may have plenty of disk capacity but very little unallocated space inside its LVM volume group.

Create And Mount A Snapshot

Create a classic copy-on-write snapshot with a size suited to the expected amount of change:

sudo lvcreate --snapshot \
  --name root_snap \
  --size 5G \
  /dev/centos/root

The snapshot does not initially duplicate every block. LVM preserves the original version of blocks as the source volume changes. Monitor its usage during a long maintenance window:

sudo lvs -o lv_name,lv_size,lv_attr,origin,data_percent

If Data% reaches 100%, the snapshot becomes invalid. For a filesystem snapshot intended for browsing or file recovery, create a mount point and mount it read-only:

sudo mkdir -p /mnt/root-snapshot
sudo mount -o ro /dev/centos/root_snap /mnt/root-snapshot

For an XFS filesystem, add nouuid when mounting a cloned filesystem identity:

sudo mount -o ro,nouuid /dev/centos/root_snap /mnt/root-snapshot

The Linux administration tutorials on Linuxtpoint can provide useful background when adapting these commands to a CentOS server with a different storage layout.

Verify Snapshot Capacity And Contents

Snapshot sizing depends on write activity, not simply on the size of the original logical volume. A 100 GB root volume with light activity may need only a few gigabytes, while a busy database or log volume can consume snapshot space quickly.

Before a major change, inspect available space and estimate how long the snapshot must remain active:

sudo vgs
sudo lvs -o+devices
df -hT

Useful checks before creating a snapshot include:

Confirm the source logical volume and filesystem type.
Verify free extents in the volume group.
Estimate database, log, and package-update write activity.
Record the current snapshot name and creation time.

A mounted snapshot is suitable for comparing configuration files or recovering a deleted document. It should not be treated as a guaranteed application-consistent copy. For databases, flush or quiesce writes using the database engine’s procedures before capturing the snapshot.

Remove Or Merge An LVM Snapshot

When the maintenance work succeeds, unmount the snapshot and remove it:

sudo umount /mnt/root-snapshot
sudo lvremove /dev/centos/root_snap

Use -y only when the device path has been checked carefully. Removing the snapshot releases its allocated copy-on-write space, but it does not restore files that were changed after the snapshot was taken.

If an upgrade fails and the snapshot represents the desired earlier state, merge it back into the original logical volume:

sudo lvconvert --merge /dev/centos/root_snap

For a snapshot of an inactive data volume, the merge may complete immediately. A snapshot of the active root filesystem normally schedules the merge for the next reboot. Check the status and restart during an approved outage:

sudo lvs -a
sudo reboot

After the system returns, inspect services, mounts, and logs before declaring the rollback successful. A managed hosting provider in Australia may charge for emergency restoration or require a maintenance notice, so document the rollback plan before starting.

Plan Safe Rollbacks And Backups

A snapshot is short-lived protection against an unsuccessful change. It does not cover disk failure, accidental removal of the whole volume group, ransomware, or a damaged filesystem. Keep an independent backup on separate storage, ideally with an off-site or cloud copy in an Australian region when data residency requirements apply.

For production systems, test both the snapshot merge and the independent backup restoration. Record commands, volume names, filesystem types, and service dependencies in the server runbook. Administrators preparing for technical screening can also review Linux interview questions to reinforce storage and recovery concepts.

Before relying on a snapshot, verify these operational points:

The snapshot has sufficient free copy-on-write space.
Monitoring will alert before Data% reaches 100%.
Applications can be stopped or made consistent when required.
A separate backup remains available.

Keep snapshots only for the period they serve a clear purpose. Once validation is complete, remove temporary mounts and snapshots, record the result, and retain the independent backup according to the organisation’s policy. The practical workflow is simple: inspect the LVM layout, allocate adequate snapshot space, monitor usage, and test restoration before a real failure occurs.