Since I have invented a button I can press which makes the attention seeking Lotus Eaters come over all frothy and then simper for my attention in public, I’ve decide to press it once again.
Pointer based Snapshots are not backups.
Because they depend on the data they’re a snapshot of existing.
That’s not a backup, a backup is “A collection of data stored on (usually removable) non-volatile storage media for purposes of recovery in case the original copy of data is lost or becomes inaccessible; also called a backup copy.”
A pointer based snapshot fails in being a backup as if the volume the snapshot is inaccessible then so is the snapshot.
Lets take the case of a large social networking site (And NetApp user) who had a shelf or four get blown away during what they described as routine upgrade, the result being that 15% of their users photos were vaporized.
Snapshots of those volumes were worthless as they were on the same storage which was inaccessible. What did they restore from? Tape. Soon after, The Social Network went off and introduced an in house developed storage system for all such photos.
So much for “Integrated Data Protection” it’s so integrated that failures cascade from primary to backup as their concept of backup is intertwined with the primary data.
But what else is wrong with building your backup infrastructure the SnapProtect way?
NetApp systems can only take 255 snapshots of a volume. Sounds large, not when you’re dealing with backup and recovery it isn’t. It’s less than 37 weeks if you were taking one snapshot a day. The phrase “long term retention” doesn’t come into play.
What’s the answer?
Get the data off the array and onto external storage. This is what SnapMirror to Tape was designed for, used it myself to unclog backup data out of primary storage to Data Domain Protection Storage, and that’s what they’re trying to do by reselling CommVault.
NetApp are coming up with ways to get backup data off of primary storage.
Of course there’s a couple of other issues with what they’re trying to push.
Weren’t the SnapManager products supposed to “replace” backup? That failed idea now appears to have been shot in the head.
With SnapProtect you put a whole bunch of VMs on a volume and want to backup two of them as part of a group, you end up quiesicing all of them. That’s really fun when different VMs are in different backup groups with different backup policies.
Snapshot was designed 20 years ago when each server had it’s own volumes. In the grand server virtualised present Virtual Machines share storage, treat it as a commodity and bounce around between volumes. Using SnapProtect what you inflict on one of them you inflict on all of them.
Who’s dedupe should customers be using? The PR people appeared to do everything they could to tap dance away from answering that question.
Since it’s a matter of record NetApp dedupe runs as fast as a glacier working it’s way across a flat landscape if you’re using regular snapshots for your backup you’re now clogging up your primary storage with duplicate blocks as NetApp dedupe can’t eliminate duplicates if they’re part of Snapshots.
Now that you’re filling your storage array with backup data, causing ever decreasing deduplication ratios in their wake, are storage admins expected to buy new disk shelves or just start deleting backup data when their applications start running out of storage?
Deduplicate before you Snap? So much for high speed zero impact snapshots if you’re waiting for post process fixed block deduplication to churn Array CPU and finish.
When asked about heterogeneous backup NetApp tell you to buy a V-Series. So you too can watch snapshots calcify your primary storage while their Dedupe burns CPU cycles and does nothing.
The bottom line is while SnapProtect does everything to get the data off the primary storage, something NetApp said you didn’t need, it’s not a heterogeneous backup solution and shouldn’t be thought of as.
It’s just another silo they want a Backup Administrator to spend time baby sitting independent of a heterogeneous backup and recovery design.