In this Q&A with SearchDataBackup, Rachel Dines, a senior analyst at the Cambridge, Mass.-based Forrester Research, discusses the role of snapshots and replicationtechnology as part of your backup and recovery strategy. While there remain issues of cost and whether a backup product retains snapshots in its native format, there are also the potential benefits of faster, more storage-efficient backup processes.

Download this free guide

Amazon S3 in the spotlight: Your 34-page backup guide

In this guide curated by the SearchAWS.com editors, you’ll evaluate and overcome the DR tradeoffs associated with Amazon S3, with guidance on solidifying an AWS backup plan and securing S3 buckets. Download your copy now.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

What is driving adoption of using snapshot and replication in backup today?

Rachel Dines: Well, a few things are driving the adoption. First of all, organizations are looking for ways to back up large volumes of data -- like large file stores, large databases -- in a way that is not only faster, but also less disruptive than the traditional type of backup. You get to pretty much eliminate your backup windows and get rid of long, long running backups on large systems, but depending on how the backup software uses the snapshot, you can then also have a very fast recovery for the systems.

The main driver, I'd say, is the need for the ability to back up large systems and complex systems quickly [and] recover them quickly. But I do also think that the advanced integration that backup software providers have been rolling out is also helping the adoption rate pick up a bit as well, because a lot of backup applications are now given the ability to control and manage snapshots from within that console, which is a level of convenience that's helpful in the adoption as well. So it's coming from both sides: both the customer demand and the vendor supply.

The thing is now, though, that I'm starting to see disaster recovery and backup strategies converging. So saying, 'This snapshot is just for DR, just for backup,' doesn't really make sense. Most organizations will use it for a combination of the two. So that's the nice thing about snapshots and replication, is that they can be really flexible. You can use a single approach [if] you keep a local copy with [snapshots]; that could be a way to augment your backup strategy. You replicate them to an off-site location -- that could be part of your disaster recovery strategy as well. So it's really more of a dual-purpose role.

What are the biggest challenges people face with snapshot plus replication?

Dines: Well, the challenge in general with using snapshots and replication as a component of your backup strategy is that it actually tends to be somewhat expensive, because snapshots -- a lot of times -- take up a lot of storage and you have to license them. Same deal with replication, you have to license it. So that is one challenge that really doesn't go away with backup software managing snapshot and replication, but we're seeing some advancements in terms of more storage companies including replication for free or for a much smaller price tag. Also, snapshots [are] getting a lot more storage-efficient, being able to do differentials.

What's nice about the backup software coming in to manage it is that it just gives you that single console, so instead of trying to figure out, 'Oh, was this protected with a backup or with a snapshot or with something else?', you just have one place to go to do recovery. So it cuts down on the complexity.

What are the ideal use cases?

Dines: The ideal use cases are really for systems that really take a long time to back up. So usually, I've found that's large file systems, or large databases that are difficult to back up in a traditional manner that take too long or [are] too disruptive, that's the primary use case. But I'd say another great use case is any system that you need to build out rapid recovery for, because if the backup software stores the snapshot's native form, instead of recovering backup, you can just rapidly mount the snapshot. Sometimes you can mount the snapshot within the backup data store and then migrate to the primary data store.

I do see people using array-based snapshots for virtual backup, but that was more in the era of VCB -- VMware Consolidated Backup. Now that vStorage API is pretty good, it uses VMware snapshots, but it doesn't use array-based snapshots. Now that that's around, and the backup software providers have embraced that, I see less of this snapshot array-based approach to backing up virtual environments. It's still a good option -- but I see less of it now that there are other good options from VMware and from the software providers.

Can you explain how backup software handles snapshots?

Dines: When we talk about backup software using snapshots, there's actually two ways that we use them, and there's a little bit of confusion here. The way that has been around for a while is what I call snapshot-assisted backup, which is essentially calling in the snapshot, then taking the backup from the snapshot and releasing that.

That method has been around for a while, but now there is newer method of keeping snapshots in their native format; there's been a little bit of confusion and some vendors are purposely being vague about this, because they might support one and not the other. So to clarify, the method that has been around for a while -- snapshot-assisted backup -- the backup is still called and managed through the backup software, but they don't keep a snapshot in its native form.

With the newer method, the backup software makes the call into the array to make the snap, and then stores the snap in its native format in the backup catalogue. So the 'backup' is really a snapshot -- and the software catalogs it like a backup, but it's still in the native snapshot format, which means that it can be rapidly mounted and bring back data or entire systems if you need it.

One thing that's worth noting: Snapshots and replication are two different things. And the backup software for the most part, most of the providers are only offering the ability to control snapshots. The ability to control array-based replication is further out on the horizon. So just to clarify, they are two different things; they're linked, and long-term, backup software providers will be able to control the snaps and the array-based replication, but there are not that many [providers doing that] yet.

Most of the major enterprise backup software players can work with certain storage array vendors, but maybe not others. So, it's going to be quite a while, I think, before we find all the enterprise software players working with all of the array-based players, but in the short-term, most of the [backup] providers will have a few of the array-based replication providers under their belt.

1 comment

Register

Login

Forgot your password?

Your password has been sent to:

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.

I am missing something. If the actual data is not copied, and then it is changed by a fault, or it is changed by a virus, or changed by a miscreant, or accidentally changed, or changed by a bug, or destroyed in a flood what do you do?