Overview
If it hasn’t happened to you yet, you’ll eventually experience a package update or system change that renders your server useless. You’ll then be suffer through multiple stages of fright, ranging from “Do we have a recent backup?” to “Where’s the documentation to rebuild this thing!?”
With the advent of logical volumes in Linux, we now have the ability to create snapshots of any our volumes before we make any changes to the system or the data. Snapshots allow us to rollback changes to a point in time before anything was done.
In this tutorial, I’ll show you how protect your system from bad patches or package installations. The method shown isn’t limited to system patching, it can be used for any use case where changes are made. For example, you could create snapshot of a volume hosting your users’ profiles before running scripts that modify them. If scripts causes a major problem, you can roll back.
Another great example for snapshots is backups. Although snapshots should never be considered a form of backup, they do allow you to create a consistent state of a volume which can be targeted by your backup software.
It’s important to remember that logical volume snapshots create crash consistent states of your data; lvm cannot create application consistent snapshots, therefore, If you are running database services, remember to stop them first. Failing to do so may result in corrupted tables.
Prerequisets for Logical Volume Snapshots
The following are required before you can use snapshots on a volume.
- It must be a logical volume. Disk partitions cannot be snapshotted.
- The volume group hosting the logical volume must have unused space available.
- The amount of unused space must be enough to hold changes to the volumes data. If your change rate is 100MB a day and the snapshot is expected to be around for half a day, you’ll need at least 50MB.
System Configuration
To make this tutorial easier to follow along, our lab server had the following disk configuration.
| Volume Group | Device | Size | Unused Space |
|---|---|---|---|
| vg01 | SDA2 | 120 GB | 20 GB |
The following logical volumes were created.
| Log. Volume | Volume Group | Size | Mount Point |
|---|---|---|---|
| swap | vg01 | 2 GB | |
| lv_root | vg01 | 12 GB | / |
| lv_var | vg01 | 60 GB | /var |
| lv_home | vg01 | 26 GB | /home |
Creating a Snapshot
- Verify the amount of unused storage in the volume group. Replace vg01 with the name of your volume group.
vgdisplay vg01 - The output should look similar to the one below. I’ve highlighted the area which details the unused space.
- Create a snapshot for the root volume, lv_root.
lvcreate -s -n lv_root_snap -L 10G vg01/lv_root-s Signals to lvm that a snapshot is being created. -n Snapshot name -L Snapshot size, in kilobytes, megabytes, gigabytes, etc. vg01/lv_root Volume to be snapshotted. - If successful, you will see the following output.
Modify Data on Logical Volume
With the snapshot created, we can now proceed with any planned modification to the volume. In this scenario, we’re going to install system and application patches.
- Install the latest system patches.
yum update
Rollback Snapshot
Our applications stopped working after the update. Instead of spending time trying to isolate the problem and attempt to correct it, causing longer down-time for our applications, we’re simple going to rollback the snapshot to before the update.
- If possible, unmount the snapshotted volume. We created a snapshot of the root volume, so we won’t be able to.
- Rollback the snapshot to bring volume to a state before the updates were installed.
lvconvert --merge /dev/vg01/lv_root_snap - If the volume was still mounted, like ours was, you will get the following notification. Reboot the server to complete the rollback. Otherwise, if you can just mount the volume to see the rollback.
Can't merge over open origin volume Merging of snapshot lv_root_snap will start next activation.
Mounting a Snapshot
Volume snapshots can also be mounted alongside their parent volumes. This allows us to do many things, such as browse the volume’s state before changes were made; modify the volume, with an ability to safely rollback our changes; or create a point-in-time copy of a volume for our backup software, so that our data remains consistent while users are logged in.
- Create a directory to mount our snapshot into.
mkdir /snapshots - Mount the snapshot.
mount /dev/vg01/lv_root_snap /snapshots - When done, unmount the snapshot.
umount /snapshots
Deleting Snapshots
Finally, snapshot changes can be applied to their parent volume after changes are made, if the results of whatever modification you made are satisfactory. To do this, we simply delete the snapshot.
- Unmount the snapshot, if you have it mounted.
- Delete the snapshot.
lvremove /dev/vg01/lv_root_snap - When prompted, type ‘y’ and press Enter to confirm the deletion.
- You should see the following output if deletion was successfully completed.
Do you really want to remove active logical volume lv_root_snap? [y/n]: y Logical volume "lv_root_snap" successfully removed
- Verify the snapshot was deleted.
lvdisplay vg01/lv_root_snap - You should get the following message if the snapshot was deleted.
One or more specified logical volume(s) not found.
