Archiving Data with Snapshots in LVM2

Simplify the time-consuming data backup process with zero downtime using LVM2 snapshot.
LVM2 Snapshots

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.

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 a full-time Linux kernel, device-driver and application developer for embedded and server platforms. He has been working in the data storage industry for more than six years and enjoys discussing the same technologies.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix