In this SearchStorage.com expert Q&A, W. Curtis Preston, executive editor at TechTarget and independent backup...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
expert, discusses some of the biggest challenges associated with snapshot technology for data backups. Learn the differences between a snapshot and a copy, how to tell if snapshot technology is right for your environment and where you can use snapshots in your storage environment. To hear the entire interview, listen to the MP3 below.
Download for later:
Snapshot technology with W. Curtis Preston
• Internet Explorer: Right Click > Save Target As
• Firefox: Right Click > Save Link As
SearchStorage.com: What is the difference between a snapshot and a copy?
Preston: The difference between a snapshot and a copy is that one is virtual and one is physical. A snapshot is a virtual copy; it's a photo, or static view of your data.
A copy is a physical copy of your data, which is typically also called a business continuance volume [BCV], or split mirror, where you mirror the data and then split off that copy. Snapshots and copies also take up different amounts of data storage. A snapshot doesn't create any space the moment it's created; it grows over time. Since a copy is physical, when you make a copy, your data storage requirements immediately go up two times.
SearchStorage.com: Are snapshots for everyone? How do I know if I need this technology in my environment?
Preston: I think snapshots are for everyone. But this statement comes with some requirements on the user end. People who want to implement snapshots in their data backup environment must be able to mitigate some of the challenges that can occur with snapshots, use the right kind of snapshots, get their data in the right state prior to taking the snapshot, and have something to control, manage, configure and report on the snapshot process.
SearchStorage.com: What are some of the challenges associated with snapshot backup?
Preston: The first challenge is that a lot of people don't realize snapshots are a virtual copy and then they try to do a restore from it -- after a failure. For example, say you have a RAID 5 array and you have a double disk failure. You go to your snapshot to do a restore, but the snapshot won't be any good because it's relying on the original storage array.
The second challenge is that not all snapshot technology is created equal. You have to choose between two main types of snapshot technology: copy on write and redirect on write. There are advantages and disadvantages to both types of snapshot technologies. Copy on write requires a separate volume on snapshot history data, whereas redirect on write uses the same volume on snapshot history data. Since the snapshot data is in an extra volume with copy on write, if you fill up that snapshot volume, the only thing you need to do is delete some snapshots. With redirect on write, if you fill up the volume with snapshot history, you also affect the primary volume.
Another main difference between copy on write and redirect on write are their performance levels. Redirect-on-write snapshots have a significantly better performance level when you take a lot of them. Copy-on-write snapshots are best used to create a stable virtual copy of the volume you want to back up. You need to be aware of the type of snapshot technology you have or want to avoid challenges. If you plan on keeping data for weeks or months at a time, then you should consider using a redirect-on-write-style snapshot.
The third challenge associated with snapshots stems from the data itself. You shouldn't take a snapshot of data that isn't ready to be photographed. If you have a bunch of data, you need to get it all to stand still. That's less of a challenge with unstructured data, but more of a challenge with structured data. But with any database, you need to put it in backup mode prior to taking a snapshot. If you don't, most of your backups and most of your restores will work, but occasionally you will get a restore that your database is unable to recover. If you don't take a snapshot, you're forcing your application to go into crash recovery mode, which doesn't always work. Lastly, you must copy the data out to another location, which means you need bandwidth and a separate storage system.
SearchStorage.com: The common perception may be that snapshotting is a storage system feature, but that's only one place that the technology may reside. What are some other implementations where you would use snapshots?
Preston: I'd say it's a belief -- the storage system is where most people do their snapshots and have had the most success in doing snapshots. But just like RAID and volume managers, snapshot functionality can be done in the storage array, a virtualization system that sits in a storage-area network [SAN] in between the storage array and the host, or it can be done in volume management software in the host. Where is it best to do snapshots? We aren't going to solve that question. It's really a virtualization feature, so the question is where your company has chosen to do virtualization.
SearchStorage.com: So if snapshots are so great, why haven't they revolutionized backups yet?
Preston: First off, I would say they have revolutionized backups for a lot of people. For example, take a look at EMC Corp. vs. NetApp. When you talk to NetApp, snapshots are awesome, and they really sell strongly that tape backup or even regular traditional style backup is old, and I tend to agree with them. If you go down the route of NetApp and vendors like them, you will hear their success stories with snapshots and data replication, and therefore don't need traditional backups. However, if you look at EMC and other vendors like them, their story is the opposite of NetApp because they're using copy-on-write technology. They're not able to use snapshots in that degree. You can use and leverage snapshots in EMC technology, but not to the level of NetApp. So that's part of the problem -- there's an inconsistent story, and not everyone can do the type of snapshotting I'm talking about.
Another reason why snapshots haven't revolutionized backups yet is that progress in the backup and recovery space moves at a glacial pace. Backup people, by nature, are paranoid. They keep a copy of everything, and tend to be really slow about implementing new technologies. While I completely understand and respect that challenge, at some point someone needs to examine the newer technologies and say, "Hey, we need to revolutionize instead of evolutionize our backup system." It may mean you need to change your storage vendor. It may mean you need to do a lot of work up front to test it. But the water's warm. It's time to come on in. Snapshots haven't revolutionized backups for all of those reasons, but keep in mind that it has changed it for a lot of people. A lot of people have replaced traditional backup systems with snapshots for both on-site and off-site storage systems without touching a tape.