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.