Tuesday, November 3, 2009

Snapshots

In my last post we discussed Storage Area Networks or SANs and their outstanding abilities to manage your storage needs. There is a lot more technical information we can cover on SANs but I decided a followup post was needed to explain what a snapshot is.

For many companies in the construction industry, they might have a single server that has their accounting and file serving roles combined. As storage runs out and processing and memory run dry, inevitably, an additional hardware server will be required. For those companies, many have a dedicated file server, and users simply access the data on in through a UNC path \\Servername\Sharename, or the IT director maps the UNC share to a mapped drive for the users. Backup and recovery is typically done either through a USB drive or a Tape drive. Although there are many valid reasons for using these methods for backup, Snapshots provide huge advantages to traditional tape backup and even some big advantages over simple disk backup, but snaps are not a total backup solution unless they are used in conjunction with a cloned volume on a SAN.

OK, now what is a snapshot. A snapshot is a picture of what a volume looked like at an exact point in time. Snapshots can be done instantly but accurately record an entire volume, even if the volume is hundreds of gigabytes. How can it do this so quickly and yet use up such a small amount of space? Well the snapshot actually uses the volume it snaps as the data for the snap. So when a snap is made, nothing really happens, other than a record that a snap was made. Then as the contents of files, actually the individual sectors on the volume, are changed, it writes the changes to an unused sector and maps the old sectors to the snap. Using this method the original volume can make changes throughout the course of business and the snaps gradually get the old sectors mapped to it so by combining the volume as it stands now and substituting the old sectors, the snapshot can recreate the data as it existed at the exact moment of the snap. For volumes that do not change that often, snaps typically remain small and only contain the data that has changed since the snap. For volumes that have transactional data that change frequently, the snaps can eventually take up as much space as the volume itself, but never more than the volume. Snaps do not cause additional I/O load on the drive and can be accessed at any time and mounted as new volumes that you can recover data from.

The real disadvantage with snaps is that it relies on the the original volume staying intact and healthy in order to recover data. This means snaps are awesome for recovering corrupt or deleted files, but do not allow you to recover from a complete volume failure. For that, you mitigate the risk by using raid or SAN technology, and then use another solution for offsite backup. While some might think this limits the usefullness of snapshots, most of the recovery that takes place in the IT world is due to deleted and damaged files, not storage system crashes.

How do you get your hands on snapshots? Three ways I know of. Buy snapshotting software, get a direct attached storage array that supports it, or get yourself a Storage Area Network. The latter of which I am a fan of. I’ll post another article about snapshot scheduling and remote snapshots, both features of high end SANs.

No comments:

Post a Comment