Snapshot-based backup systems can literally change the game for anyone interested in using them as their primary method for backing up and restoring critical data. Snapshots offer significantly easier and faster backups than any traditional backup system can provide, and they offer recovery time objectives (RTOs) and recovery point objectives (RPOs) that are also impossible with a traditional backup system. In this context, a traditional data backup system is one that backs up files by placing them into some kind of backup format (e.g., Symantec Corp. NetBackup image, EMC Corp. NetWorker saveset, IBM Corp. TSM aggregate), and then places that format on tape or disk. However, not all snapshot backup systems are alike, and not all of them have what it takes to completely replace a backup system. In the following, we'll help you understand the benefits and drawbacks of such a system and allow you to make your own decisions as to whether or not you might want to investigate using a snapshot backup system for your organization.
When discussing snapshot-based backup systems, there are a number of misconceptions that must be dealt with before beginning the conversation. The first of these misconceptions is that snapshots aren't backups at all -- they are point-in-time copies. There are those that believe that if a copy of data doesn't change form -- such as being put inside a tar image -- then it's not a backup. It's unclear where this idea came from, but changing form is not a requirement for something to be a backup.
How are snapshot backups defined?
The Storage Networking Industry Association (SNIA) defines a backup as "A collection of data stored on (usually removable) non-volatile storage media for purposes of recovery in case the original copy of data is lost or becomes inaccessible; also called a backup copy. To be useful for recovery, a backup must be made by copying the source data image when it is in a consistent state." The only part of this definition that snapshot-based backups might have trouble with is the "usually removable" part, but this is simply SNIA stating the obvious that most backups are placed on tape.
SNIA's definition does bring up one very important aspect of snapshot-based backup systems -- a snapshot is not really a backup until it has been replicated to another storage system. This is because a snapshot is a virtual copy of the data, not an actual copy of the data. If something happens to the volume upon which a snapshot resides, the snapshot of the volume will be of no use -- unless it was copied to another volume via replication.
In a traditional backup system, backup software and tapes create the ability to restore multiple points in time. This is a critical function of a backup system, as data corruption or other factors may require us to restore the system to a point in time other than the most recent backup. In a snapshot-based backup system, the snapshots provide this functionality. Multiple snapshots -- each created at different times -- are used to present multiple virtual views of the file system as they existed at different points in time.
Another important function of a backup system is to provide a copy of the data in case of disaster. A traditional backup system does this by sending tapes off-site via an off-site vaulting vendor such as Iron Mountain. A snapshot-based backup system accomplishes the same thing via replication. In fact, a snapshot backup system can place multiple copies of the data in multiple locations using replication. For example, operational recoveries may come from an on-site storage system that is physically different than the storage system being backed up, and disaster recoveries may come from an off-site storage system that receives a replication stream from the same system. This may be accomplished by having the primary storage system replicate to both systems, or having it replicate to the on-site storage system, and having that system replicate to the off-site storage system. There are advantages and disadvantages to each approach.
The last part of the SNIA definition of backup is that the data must be in a consistent state when it was copied. With traditional data backup applications, this is usually done via file system and database agents, and snapshot-based backup systems must also figure out a way to make sure that data is copied in a consistent state in order for the backups to be worth anything. It's not acceptable simply to make a snapshot of the database and ask the crash recovery system of that database to make the image consistent during recovery. The snapshot must be created in a way that is supported by the database application. One example of this would be snapshot systems that integrate with Windows Volume Shadow Services (VSS), as it acts as an intermediary between a snapshot system and the applications that need to be placed in a consistent state. Before considering any snapshot-based product as the core of your backup system, make sure the product has a good answer to this particular requirement.
Another area where snapshot backup systems often fall short is the vendors that make them feel that since all you have to do is "cd" into a certain directory and grab the file you need, there's no need for any centralized backup catalog or index, the way traditional backup systems have. While it is true that a snapshot backup system is somewhat "self-indexing," it is also true that sometimes people don't know where the file they need to restore resides, and a backup catalog can help with that. With some products, this functionality may actually be provided by marrying a traditional backup product and a snapshot-based product, as some traditional products offer indexing of snapshot-based backups via NDMP.
Make sure your snapshot backup product can scale
Where the rubber meets the road is in configuration, monitoring and reporting. What works for a small shop with one storage system isn't going to work with an enterprise with hundreds or thousands of them. When examining this area of functionality, be sure to ask yourself how well a particular product's capabilities will scale if the size of your data center grows drastically over time. Some systems require you to maintain snapshot and volume relationships via the command line where others have sophisticated Web-based user interfaces to do that for you.
The most important question for any backup administrator to answer every day is "Did the backups work?" Larger shops may actually have a staff of operators watching backups as they are performed, and smaller shops may have a single person who checks last night's backups first thing in the morning. Either way, the monitoring functionality of the backup system must be able to answer this question quickly and efficiently.
Reporting is slightly different, as it helps to understand backup trends over time. Are there certain volumes that have difficulty backing up on a regular basis? Is there enough capacity for snapshots and production data? Are there any snapshots that are taking up significantly more room than other snapshots? These questions are answered by the reporting functionality of the product.
One final thing to consider if you are thinking about replacing your traditional backup systems with a snapshot backup system is that most of the former are host-based and most of the latter are storage-based. The significant increase in server and storage virtualization increases the difficulty of doing storage-based backups. In a world where a "server" can magically move from one physical server and its associated storage to a completely different server and storage resources with a single mouse click, host-based backups are the easiest way to ensure that that server (actually a VM) is backed up no matter where it resides. Storage-based backups need to account for this particular phenomenon.
It's possible under certain circumstances to completely replace a backup system and all of its functionality with a snapshot-based system. Just make sure you think through all of the things that your backup system does for you today, and make sure that your new system can do those things as well.
About this author:
W. Curtis Preston (a.k.a. "Mr. Backup"), executive editor and independent backup expert, has been singularly focused on data backup and recovery for more than 15 years. From starting as a backup admin at a $35 billion dollar credit card company to being one of the most sought-after consultants, writers and speakers in this space, it's hard to find someone more focused on recovering lost data. He is the webmaster of BackupCentral.com, the author of hundreds of articles, and the books "Backup and Recovery" and "Using SANs and NAS."
Read about storage snapshot technologies
Podcast on snapshot technology for data backups
Expert response: How to use snapshot technology
Learn how to simplify virtual machine backup
Podcast: NAS backup
Curtis' backup best practices