Protect your data with snapshots

Storage snapshots are among the best data protection features that any server or storage platform can offer. The ability to quickly and easily roll back to a previous point in time without pulling out a tape or copying data puts a healthy distance between you and disaster.

Yet the term “snapshot” has come to mean many different things — and not all snapshot mechanisms are created equal. So let’s look at what snapshots can and can’t do, with some cautionary verses about pitfalls along the way.

Snapshots to the rescue

The starkest example of how snapshots can help is in a data corruption. Let’s say your organization runs a large Microsoft Exchange implementation (although for this example, any complex database will do). Exchange database corruption is far less common than it was in the dark ages of Exchange 5.5 and 2000, but it still happens, and it’s universally reviled as one of the most infuriating and time-consuming failures to remedy.

Using tape backup, you generally have two routes to recovery. The first involves running a series of database check and repair processes in an attempt to correct the problem and proceed without any major loss of data. Depending upon the size of the database and the speed of your storage, these can take anywhere from a few hours to the better part of a day to run. The second option involves restoring your last backup from tape — forcing you to give up hope of recovering data generated since the last backup. Worse, the data in your most recent backup may contain the same database inconsistencies.

With a SAN snapshot, you can skip back days, hours, or even minutes (depending on how you’ve configured things) without touching a tape. The threat of expensive and unpleasant downtime is rendered harmless in minutes, provided you set up the snapshots properly in the first place.

So, if snapshots are so great, why doesn’t everyone use them? That’s actually a good question — everyone should use them! But each type of snapshot has its strengths and weaknesses, and which one you choose depends on the infrastructure you have in place — or on how much you’re willing to spend to upgrade it.

Common pitfalls

Snapshots are not without their drawbacks. The first and most obvious is that you will use more disk space. Because snapshots mean you’re retaining data that would normally be overwritten, this should come as no surprise, but the quantity of space can be a little daunting. An effective snapshot regimen may require anywhere from 50 to 300 percent of the disk space occupied by the data being protected, depending on the efficiency of the snapshot mechanism and how much data turnover you expect.

The other downside is performance. Some snapshot mechanisms are extremely inefficient and can cut the speed at which writes are committed to disk in half. Others are extremely efficient and display almost no performance effect whatsoever. Still others will display no performance degradation until the device nears its total capacity. So spend some time familiarizing yourself with how your device and/or operating system performs snapshots and what the effects will be.

Above all, note that snapshots are not a replacement for traditional backups. If you’re relying on a SAN or NAS to perform snapshots and that system fails, you need another level of protection behind it where data can be archived.

SAN snapshots

SAN snapshot mechanisms vary widely. In fact, you’ll find greater difference in how SANs handle snapshots that in most other SAN features. Issues to consider include the number of snapshots you can maintain, the amount of space they consume, and the impact on storage performance.

Because SANs store data at the block level, snapshots taken via SAN are considered quite reliable. It’s not necessary to trust server operating systems or file systems to ensure that snapshots are taken and available.

File system snapshots

Server file systems generally include a built-in snapshot mechanism. Microsoft’s Volume Shadow Copy (VSC), for example, has been included in every copy of Windows since the release of Windows Server 2003. VSC is notable in that it lets users view snapshots of their own files and folders and restore them on their own.

That’s great for file shares, but VSC doesn’t work as well for databases and other transactional systems due to the I/O overhead incurred when VSC is active. More often, you’ll see VSC used by various backup software as a means to obtain a consistent copy of a database (Exchange and SQL backup agents commonly use shadow copies for this). Unfortunately, stability problems with VSC are fairly common.

Far and away the best file system snapshot capability can be found in Sun’s ZFS file system. Too bad it is only supported by Solaris, FreeBSD, and NetBSD, so you don’t run into it outside of Sun-based shops or storage appliances based on FreeBSD or NetBSD. Too bad. ZFS is probably the best file system in existence today.

Virtualization hypervisor snapshots

Just to make things interesting, most virtualization platforms also provide a means to make snapshots of virtual machines. Note, however, that a snapshot of a virtual machine is barely recognizable when compared to SAN or even file system snapshots in terms of form and function.

Virtual machine snapshots are almost exclusively used as a temporary means to obtain a consistent backup of a virtual machine’s disks or for very short periods of time surrounding a large upgrade or patch.  Most hypervisor snapshot implementations are woefully inefficient from a performance standpoint when even a few snapshots are created — and are absolutely ineffective as a long-term data protection strategy.

Putting it all together

A data protection scheme that combines file system snapshots, SAN snapshots, and some form of traditional backup can deliver the most bulletproof single-site storage configuration you can find. These multiple layers of protection provide extra weapons in your arsenal when data corruption or loss occurs. If you haven’t implemented snapshots in your organization, do it now.

This story, “Protect your data with snapshots,” was originally published at InfoWorld.com.