Archiving Data with Snapshots in LVM2
Now that I've covered a brief summary of how LVM2 is structured and managed, it's time to focus on the snapshot feature. It is worth noting that the LVM2 snapshot feature can be used only on LVM2-managed logical volumes. Assuming that an LV already exists, possibly the partition for the / directory path, a second LV needs to be created for the snapshot of the original logical volume. With regard to size, another great feature of the snapshot is that the snapshot volume does not have to be equal in size to the original volume. The size even can be half or less than the original volume, allowing only that many changes of data to be backed up. By default, LVM2 will disable the snapshot automatically if the snapshot LV ever gets filled. The amount of storage space necessary is dependent on the usage of the snapshot. If the snapshot size equals the size of the original LV, it never will overflow, and snapshot service will not be interrupted. In the worst-case scenario, if it is found that space is running out on the snapshot, the LV always can be resized dynamically to a larger capacity.
Define the size to allocate for the snapshot. Create the snapshot on the desired VG by using the lvcreate command, with the size followed by the snapshot switch, the name for the snapshot and the VG. In this example, only 500MB are allocated for modified data. Realistically, this is not an ideal size to use (it's too small but serves its purpose here):
$ sudo lvcreate -L500M -s -n rootsnapshot /dev/VolGroup/lv_root Logical volume "rootsnapshot" created
The lvdisplay command displays all details pertaining to the snapshot LV. One detail to keep an eye on is the “Allocated to snapshot” value. In this example, it is set to 0.06%:
$ sudo lvdisplay /dev/VolGroup/rootsnapshot --- Logical volume --- LV Name /dev/VolGroup/rootsnapshot VG Name VolGroup LV UUID kAc3Iq-Gn3e-pBWs-KC9V-bFi8-0fHr-SsdRLR LV Write Access read/write LV snapshot status active destination for /dev/VolGroup/lv_root LV Status available # open 0 LV Size 5.51 GiB Current LE 1410 COW-table size 500.00 MiB COW-table LE 125 Allocated to snapshot 0.06% Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:3
If the original LV is written to, using the copy-on-write mechanism, the snapshot will write all original data from the original volume to the snapshot volume before it replaces the original volume with the new data. To better understand the mechanics behind the snapshot, mount the snapshot volume, so that it can be accessed like any other mounted device.
Listing 1. Mounting and Listing of the Snapshot-Enabled Volume
$ sudo mkdir -p /mnt/VolGroup/rootsnapshot $ sudo mount /dev/VolGroup/rootsnapshot /mnt/VolGroup/rootsnapshot/ $ ls -l /mnt/VolGroup/rootsnapshot/ total 124 dr-xr-xr-x. 2 root root 4096 May 15 07:45 bin drwxr-xr-x. 2 root root 4096 May 15 06:59 boot drwxr-xr-x. 9 root root 4096 Sep 26 06:12 cgroup drwxr-xr-x. 2 root root 4096 May 15 06:59 dev drwxr-xr-x. 116 root root 12288 Sep 26 06:19 etc drwxr-xr-x. 3 root root 4096 May 15 08:10 home dr-xr-xr-x. 17 root root 12288 May 15 07:42 lib drwx------. 2 root root 16384 May 15 06:58 lost+found drwxr-xr-x. 3 root root 4096 Sep 26 06:15 media dr-xr-xr-x. 2 root root 4096 Sep 26 06:13 misc drwxr-xr-x. 3 root root 4096 Dec 4 2009 mnt dr-xr-xr-x. 2 root root 4096 Sep 26 06:13 net drwxr-xr-x. 2 root root 4096 Dec 4 2009 opt drwxr-xr-x. 2 root root 4096 May 15 06:59 proc dr-xr-x---. 4 root root 4096 Aug 31 15:54 root dr-xr-xr-x. 2 root root 12288 May 15 07:48 sbin drwxr-xr-x. 2 root root 4096 May 15 07:02 selinux drwxr-xr-x. 2 root root 4096 Dec 4 2009 srv drwxr-xr-x. 2 root root 4096 May 15 06:59 sys drwxrwxrwt. 15 root root 4096 Sep 26 06:27 tmp drwxr-xr-x. 14 root root 4096 May 15 07:14 usr drwxr-xr-x. 22 root root 4096 May 15 07:48 var
Here is a simple exercise to verify that the snapshot is functional: write to the original volume—that is, modify an existing file or add/remove a file. The original data for those files will be present on the mounted snapshot. If a new file is added/removed from the original volume, it will not be present on the snapshot. Note that the same logic applies if the snapshot data is modified. The original volume will remain unaltered:
$ dd if=/dev/zero of=/home/petros/test.file count=65536 65536+0 records in 65536+0 records out 33554432 bytes (34 MB) copied, 2.95349 s, 11.4 MB/s $ ls /home/petros/ Desktop Downloads Music Public test.file Documents drvadm Pictures Templates Videos $ ls /mnt/VolGroup/rootsnapshot/home/petros/ Desktop Downloads Music Public Videos Documents drvadm Pictures Templates
Using the lvdisplay command, you now can observe that more space has been allocated for the snapshot volume. The value for the “Allocated to snapshot” field has increased to 0.24%:
$ sudo lvdisplay /dev/VolGroup/rootsnapshot --- Logical volume --- LV Name /dev/VolGroup/rootsnapshot VG Name VolGroup LV UUID kAc3Iq-Gn3e-pBWs-KC9V-bFi8-0fHr-SsdRLR LV Write Access read/write LV snapshot status active destination for /dev/VolGroup/lv_root LV Status available # open 1 LV Size 5.51 GiB Current LE 1410 COW-table size 500.00 MiB COW-table LE 125 Allocated to snapshot 0.24% Snapshot chunk size 4.00 KiB Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:3
Removing a snapshot is almost as simple as creating it. First, unmount the snapshot, and then use the lvremove command to remove the LV from the VG:
$ sudo umount /mnt/VolGroup/rootsnapshot/ $ sudo lvremove /dev/VolGroup/rootsnapshot
In some versions of various Linux distributions, including Red Hat Enterprise Linux (also in the latest beta release of RHEL 6), CentOS and even SUSE Linux, there exists a known problem when attempting to remove or deactivate logical volumes. Unable to remove the LV, the following error message will be returned: Can't remove open logical volume "rootsnapshot". If dmsetup info -c rootsnapshot is invoked on the command line, the status of the LV will be returned and it will confirm the error message. To work around this, use the dmsetup command followed by the lvremove command. Confirm that the LV has been removed with the lvdisplay command:
$ sudo dmsetup remove /dev/mapper/VolGroup-rootsnapshot-cow $ sudo dmsetup remove /dev/mapper/VolGroup-rootsnapshot $ sudo lvremove /dev/VolGroup/rootsnapshot Logical volume "rootsnapshot" successfully removed
Petros Koutoupis is currently a senior software developer at Cleversafe, an IBM Company. He is also the creator and maintainer of the RapidDisk Project. Petros has worked in the data storage industry for more than a decade.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide