The technology field is home to an unpredictable and ever changing landscape. Something heralded as an “industry game changer” today can be reduced to little more than an afterthought in just a few years’ time. Alternatively, other tech that is brushed aside as nothing more than a novelty item can quickly bloom into a massive business. Since no one can accurately predict what will succeed, and what will fail, it’s important to keep up to date on the new technology.
LVM-ing La Vida Loca
Back That Thing Up… Crazy Fast!
There are several aspects to Logical Volume Management (LVM) that make it a real lifesaver in the day of a Linux Administrator. Can it increase the size capacity of /home? Yep! Can it create temporary mount points that you only need for a short amount of time? Absolutely! Can it create snapshots of a volume? Eazy peezy! Can it unload your dishwasher? I don’t think they have that feature implemented.
In this blog, I’m going to focus on utilizing snapshots as temporary backups, which is very useful if you’re going to make a lot of configuration changes or patching software and want to be able to test before committing to it.
There are a couple of requirements that need to be met before you have the ability to snapshot.
- Using Linux with LVM2 installed
- The mount point you want snapshotted is a Logical Volume (LV)
- Some free space in the Volume Group (VG)
- You are logged in (or su or sudo) as ‘root’
Operating System: Oracle Linux 7 update 5
Physical Volumes: /dev/sda2 and /dev/sdb1
Volume Group: ol
Logical Volume: lv_u01
What do you want to do today?
For the example of this blog, we will be using LVM to create a snapshot of /u01 before we change the contents of a file (myTest.txt).
Don’t have a COW.
I’m sure you’ve heard this phrase before; however, contrary to what it says, you will actually need a COW (Copy-On-Write) table to create a snapshot. The COW table will be maintained using assigned free space on the VG (Volume Group) that holds the LV (Logical Volume) you are snapshotting. Use the pvs command to determine how much free space you have available in the VG:
This illustration shows that there is 8G free for the ‘ol’ VG.
Now that we know how much free space we have in the VG, let’s go ahead and take a snapshot. If you don’t know the mapper name of the LV, you can find out with the df command.
In this case it’s: /dev/mapper/ol-lv_u01
We can now create the snapshot named mySnapShot having a 2 Gig COW table size with read-only permissions.
At this point, any changes made to /u01 will be written into the COW table instead of the actual LV, so it’s important that there aren’t more than 2Gig of changes made to /u01.
Warning: If the COW table size is exceeded, the snapshot will become invalid, and you won’t be able to use it for anything. This is the risk with using snapshots in lieu of backups, so make sure you allocate way more space than you need. A reasonable strategy would be to allocate ALL of the VG free space for the snapshot because it will all be released back to free space after the snapshot is removed.
Taking care of business.
Now that the snapshot is created, we are free to make any modifications we want to the /u01 filesystem knowing that we can revert back if things go horribly wrong. For this example, I simply added an additional line to the myTest.txt file.
Curiosity and the cat.
One of the other cool features about snapshots is that you can take a peek at them if you want. To do this you simply mount it as another drive. In the example below I create a directory under /mnt and then mount the snapshot (/dev/mapper/ol-mySnapShot) to it so I can look at the files it contains.
Now that this is mounted, we can review what the contents of the file originally looked like. It was a single line. I’ll go ahead and cat out the contents of /u01/myTest.txt and /mnt/mySnapShot/myTest.txt to show the differences.
Note: With the snapshot mounted, you can also use ‘tar’ or another backup utility to create a more durable backup for archiving or retention.
Let’s pretend that the modification was a mistake and we cannot confidently manually revert it back, so we will rely on the snapshot to recover the contents of /u01. The revert process does require that we unmount /u01 in order to proceed.
Notice the message “Merging of snapshot ol/mySnapShot will occur on next activation of ol/lv_u01” when running lvconvert. This is caused because the VG that I’m using is the same one as the root filesystem, so a reboot is necessary to finish the rollback.
After the reboot, login and verify the contents of the file are back to original.
Wrapping it up.
I hope this helps with recognizing the power and usefulness of LVM snapshotting as a quick and easy safety net. Although my example used a small text file that could have easily and quickly been backed up using traditional methods (eg. tar), taking a snapshot is just as quick whether the LV is only a couple megabytes in size, or if it’s hundreds of gigabytes. As we all know, backing up hundreds of gigabytes takes more significant time and requires an equal amount of disk space while the snapshotting capability is quick and light. The biggest drawback is that it shouldn’t be used as a long-term backup solution.
And don’t forget to email the LVM developers about implementing the dishwasher capabilities!