Databases Reference
In-Depth Information
Filesystem Snapshots
Filesystem snapshots are a great way to make online backups. Snapshot-capable file-
systems can create a consistent image of their contents at an instant in time, which you
can then use to make a backup. Snapshot-capable filesystems and appliances include
FreeBSD's filesystem, the ZFS filesystem, GNU/Linux's Logical Volume Manager
(LVM), and many SAN systems and file-storage solutions, such as NetApp storage
appliances.
Don't confuse a snapshot with a backup. Taking a snapshot is simply a way of reducing
the time for which locks must be held; after releasing the locks, you must copy the files
to the backup. In fact, you can optionally take snapshots on InnoDB without even
acquiring locks. We'll show you two ways to use LVM to make backups of an all-
InnoDB system, with your choice of minimal or zero locking.
A snapshot can be a great way to make a backup for specific uses. One example is as a
fallback in case of a problem during an upgrade. You can take a snapshot, upgrade,
and, if there's a problem, just roll back to the snapshot. You can do the same thing for
any operation that's uncertain and risky, such as altering a huge table (which will take
an unknown amount of time).
How LVM snapshots work
LVM uses copy-on-write technology to create a snapshot—i.e., a logical copy of an
entire volume at an instant in time. It's a little like MVCC in a database, except it keeps
only one old version of the data.
Notice we didn't say a
physical
copy. A logical copy appears to contain all the same
data as the volume you snapshotted, but initially it contains no data. Instead of copying
the data to the snapshot, LVM simply notes the time at which you created the snapshot,
then it reads the data from the original volume when you request it from the snapshot.
So, the initial copy is basically an instantaneous operation, no matter how large a vol-
ume you're snapshotting.
When something changes the data in the original volume, LVM copies the affected
blocks to an area reserved for the snapshot before it writes any changes to them. LVM
doesn't keep multiple “old versions” of the data, so additional writes to blocks that are
changed in the original volume don't require any further work for the snapshot. In other
words, only the first write to each block causes a copy-on-write to the reserved area.
Now, when you request these blocks in the snapshot, LVM reads the data from the
copied blocks instead of from the original volume. This lets you continue to see the
same data in the snapshot without blocking anything on the original volume.
Fig-
ure 15-1
depicts this arrangement.
The snapshot creates a new logical device in the
/dev
directory, and you can mount this
device just as you would mount any other.
