animind - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

How can snapshot technology best be used for backup?

George Crump explains how snapshots can be used for backups in certain circumstances and why the role of traditional backup software is changing.

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.

Snapshot technology is available with almost every storage system on the market today, but it is underutilized.

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.

Next Steps

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

This was last published in February 2015

Dig Deeper on Backup and recovery software

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

6 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What are your primary concerns (if any) about snapshot technology? Resiliency? Something else?
Cancel
I have two concerns about snapshot technology. The first is how much space it's going to take - I think it's worth using if you rely on your data to keep functioning, but you will need to make a decision about how long to keep the information for.

At the same time, most snapshot techniques significantly slow down data writing. When you're on a deadline and trying to get things done, those extra delays aren't fun.
Cancel
Is there Granular file or object recovery using your 3 tier snapshot plan?
A lot of our restores are file and folder requests from customers.

Cancel
This makes total sense. If the backup system fails, the snapshots remain. As long as it's not treated as a long-term solution, it should work.
Cancel
Snapshots are the software tester's lifeline, especially if there are repetitive steps to deal with in setting up an environment, importing users, or doing some kind of action that has the potential to wipe out system resources (i.e. destructive testing). Having the ability to just roll back to a snapshot and pick it up again, hugely helpful.
Cancel
It seems like this would be a great market niche for somebody: Design a "snapshot management for dummies" software package that creates and manages these snapshots. Anybody have a few million and want to start a business? :)
Cancel

-ADS BY GOOGLE

SearchSolidStateStorage

SearchCloudStorage

SearchDisasterRecovery

SearchStorage

SearchITChannel

Close