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):

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:

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:

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.

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.

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.