Snapshot technologies are commonly used to enhance data backup systems and dramatically shorten RTOs and RPOs. But you need to know how snapshot implementations can vary, and what those differences could mean to your environment.

A snapshot is commonly defined as a copy of a set of files, directories and/or volumes as they were at a particular point in time. As its name suggests, a snapshot is very much like a photograph because it captures an image of a certain set of data at a specific moment or point in time.

Snapshot technology was originally architected to solve several data backup problems, including:

• Backing up data that's too large to complete in the allocated time
• Failing to back up data because it has moved from a directory that hasn't been backed up to one that already has
• Corruption of backed up data that can occur when it's being written to while it's being backed up
• The affect on application performance while a backup is in process

All of these backup problems can be resolved with snapshots. But snapshots shouldn't be considered a backup panacea. There are some issues with snapshots that require workarounds (see "Snapshot snafus," below).

Snapshot problems can occur when structured data is involved, such as databases and applications built around databases like email, enterprise resource planning (ERP) or customer relationship management (CRM). Most snapshot technologies aren't integrated with structured data applications, so when a snapshot is executed the snapshot doesn't wait for the database to be quiesced, the cache to be flushed, writes completed, and index and metadata to be updated. If the snapshot is taken when data is in the cache, or before all of the updates are completed, the snapshot isn't crash consistent -- it's corrupted.

This is less of an issue for structured data applications running on a Windows server if the snapshot technology takes advantage of Windows Volume Shadow Copy Services (VSS) through its API. VSS is designed to specifically work with structured data applications, and it does all the heavy lifting of quiescing the database, flushing the cache, and completing the writes and updates before initiating the snap.

Unfortunately, there isn't an equivalent service or API in Linux or Unix operating systems. VMware Inc. has a partial solution via its vCenter storage API. The API will allow a snapshot technology to send a command to vCenter ...

But there's an excellent workaround for snapshotting structured data applications in a crash-consistency manner without using Windows VSS. The workaround requires backup software that integrates with the snapshot technology's API so it can leverage structured data application agents from the backup software. The agent quiesces the application, flushes the cache, completes the writes and updates, and then tells the backup software to notify the snapshot technology to perform the snapshot. This workaround is a relatively effective solution.

[IMAGE]

< PREV PAGE   |   1  |   2  |   3  |   4  |   5  |   6  |   7  |   NEXT PAGE  >