Last week I got involved in a little back and forth with blogger Mark Twomey , who blogs under the title of Storagezilla. Mark is an EMC employee, but the blog represents his opinions, not EMC’s.
Storagezilla is a good name for him. He’s a feisty partisan who likes to stomp on cars, especially if those cars say “NetApp” on the side, or the name of other EMC competitors. I really enjoy his blog, but that’s not to say I always agree with his point of view.
Last week in a post called “Snapshots are not Backup,” he put up some comments on NetApp’s recent SnapProtect announcement and the notion of whether snapshots alone are valid as a backup mechanism. I responded from the point of view of NetApp Syncsort Integrated Backup (NSB), which works differently. You can read the back and forth, but I wanted to just state a few general points about using snapshots for backup. (Side note: there is another interesting back-and-forth going on between ‘Zilla and industry guru Curtis Preston, which you can read here.
There are a few common objections that people make when arguing that “Snapshots don’t work as backups.” Let’s look at a few.
Objection: Because the snapshot depends on the primary storage, if the primary fails the snap fails, so it’s not a backup.
True enough for primary-based snapshots. But NSB does something very different: it uses snapshots on secondary storage without the need to even have primary snapshots. That’s why it can support any primary storage (doesn’t have to be NetApp) and still store backup jobs as NetApp snaps, with all the great speed of recovery advantages snaps give you. Your primary storage can melt into a slag heap and it won’t affect your backup data.
Objection: Backups take up disk space and if you run out of space unexpectedly, your applications will fail. Too risky!
Again, true enough if you are doing snaps on primary, but NSB doesn’t. If an NSB volume filled up, the worst that could happen is a backup job would fail.
Objection: Snapshot are very large objects and they don’t have good restore granularity.
Could be true in some cases, but with NSB your snapshots are cataloged and searchable, so if you need to find every version of filexyz.doc across dozens or hundreds of snaps, you can do it in seconds. You can use wildcards, file size and date ranges, etc. Or, if you just want to browse the data, you can mount up a snap in about a minute to whatever server you want (assuming the same OS) and just poke around in the file system. And because everything is on secondary storage, none of this impacts your production in any way.
Objection: Even if you move the snap to secondary disk, that disk could fail or you could lose the site and lose all your backup data.
Well yes. But that’s not an objection so much as a design goal. Anything can fail. And if you only keep one instance of a backup on one disk array, of course you could lose the backup (or lose all your backups in the event of a site disaster). That is why NSB includes both disk-to-disk replication as well as tape output. Ideally, you want that third copy of data somewhere else to avoid loss if a site goes down.
You could present more objections (feel free to drop any in the comments, and I’ll respond to them), but to sum it up, the simple but powerful fact that makes NSB different is that we take the data from any primary storage and store it as snapshots without any dependency on that primary. As soon as you break that link between the primary storage and the snapshot, you eliminate most of the core objections around using snapshots as backups.
So can you use snapshots as backups? With NSB you can. If anybody knows of a reason why it’s not perfectly feasible, I’d like to know.
{ 0 comments… add one now }