animind - Fotolia
Snapshot technology is available with almost every storage system on the market today, but it is underutilized. Many data storage managers keep only a few active snapshots per volume, even though many storage systems have the ability to store thousands. The primary reason for this is a legitimate concern over the resiliency of snapshot technology.
Snapshots can be designed to overcome these resiliency issues, however, and play a larger role in the backup/data protection process.
Overcoming the single system
The biggest challenge facing a design that leverages storage snapshot technology as a primary data protection technique is the vulnerability of the system itself. Essentially, if the storage system fails then the snapshots fail right along with it. As a result, snapshots are seen as a method to recover corrupted or deleted files and nothing more.
This can be overcome by leveraging another technology that is becoming commonplace in modern storage systems: snapshot replication. While usually presented as a way to efficiently copy data off site, it can also be leveraged to copy data to a second storage system in the data center, as well as a third system in a remote site. A decade ago, the cost of delivering such a solution was out of reach for all but the largest data centers. Now, thanks to a much more competitive market and concepts like software-defined storage (SDS), this design is feasible for organizations of all sizes.
Architecting self-protecting primary storage
This three-storage-system approach could be implemented during a storage refresh where a single vendor is used to provide the two on-site storage systems and the third storage system off site. If the timing is not right for a storage refresh or if there are plenty of existing assets, then a technology like SDS or a storage virtualization product could be used. This would allow for the replication between different storage systems (specifically the primary system and the lower-cost on-site and off-site systems).
The second on-site system does not have to be used as a passive standby. Instead, the workloads can be divided between the two systems and they can cross-replicate snapshots between them. This allows the data center to buy two less-powerful systems instead of one high-performance system. The third system (at the disaster recovery site) would need to have enough capacity to accept data from both on-site systems.
Most storage systems and software have the ability to integrate with various applications, either through direct module support, operating system integration like Microsoft's Volume Shadow Copy Service or simple scripting. This ensures that clean snapshots can be taken for data integrity.
Three-storage-system snapshot process:
- Once the snapshot is taken on the primary storage system, it is replicated to the second system and a snapshot is taken on that system.
- The second storage system then replicates its snapshot to the third system at the disaster recovery site.
- The result is one interaction with the application, but two additional copies.
- The snapshot schedules and retention are maintained separately on each system depending on the organization's recovery point and recovery time objective requirements.
With this design, any of the three storage systems can fail without interrupting data access. More importantly, all the data is in a "live" state, meaning an application can be recovered by simply pointing a server or virtual machine to the alternative storage system. No data has to be copied back into place via a recovery process.
How many snapshots are too many?
The next question is: "How far can this model extend?" Modern storage systems and software have the ability to maintain thousands of snapshots, but finding data within those snapshots can be difficult when there are so many. Unlike a traditional backup application, snapshot technology does not typically include a sophisticated metadata tracking tool that can provide information about what each snapshot contains.
There is also the challenge of capacity consumption. While it is true that snapshots are space-efficient, they do consume some space, especially the further away from the active data set they become. And, snapshots are really designed for a rapid recovery of data. While recovering old data is certainly going to be a requirement, the need to do so rapidly is diminished with age.
Factoring in these realities, a finite number of snapshots should be taken throughout the day and retained for a few weeks. At the same time, volumes should be backed up to a traditional backup application. But the role of the backup process has changed. Backups are performed so a rich metadata history can be created for data and so that the data can be recalled months or even years later. Snapshots in this design are the go-to copy to meet various recovery point and recovery time objectives.
So can snapshots be backups? Yes. They're needed to meet the front-end pressing expectations of data protection and to provide rapid recovery from a server or storage system failure. But for long-term retention, a backup application and a deep storage technology like high-capacity disk, cloud or tape should be used. The combination should allow for the complete protection and retention of an organization's data assets.
About the author:
George Crump is president of Storage Switzerland, an IT analyst firm focused on storage and virtualization.
A resource guide to snapshot technology and snapshot backup
Top three mistakes people make when considering snapshots
How snapshot technology fits into data protection strategy
Where snapshots fit with traditional backup