Our friends at Nimble Storage recently published an interesting infographic based on a survey of 1600 IT personnel across companies of all sizes. Questions were centered on data protection and recovery. I wasn’t really surprised by the survey results; it was more a case of validating my expectations. Still, the infographic reveals an ongoing IT challenge.
The first question focused on recovery point objectives (RPO) and recovery time objectives (RTO). Fifty-four percent of organizations had an (RTO) of less than six hours, and 69% had an (RPO) of less than six hours. In fact, as Nimble’s Sheldon D’Paiva reveals in the first of an ongoing series of blogs on the infographic, 42% of respondents actually have RPO requirements of under one hour. Think for a moment what those numbers translate to. RPO means how often you protect your applications. If the majority of organizations need to protect their data at six hour intervals or less, how are they getting there? They certainly can’t do it very successfully using traditional backup methods. Imagine if you were among the 42 percent needing to protect applications every hour. Are you really going to run a standard backup every hour? Go ask your backup administrator if you can do that, but put on a suit of armor first because things could get dicey!
The only reasonable way to meet these needs is using disk array snapshot technology. And the survey shows that 53% of organizations are, in fact, using snapshots. But look a bit deeper into that number and you see a significant variance. Among large companies, 60% use snapshots, but among small companies the number is only 40%. Why the difference?
The reason is IT overhead. While snapshots are the best way to capture data quickly and often, it takes a lot of work to coordinate snapshots with applications and/or virtual machines in order to take application consistent images (not crash consistent). Larger IT organizations have the staff bandwidth to maintain in-house scripts and array integrations; or as we see often, they have the budget to outsource frequent professional services engagements. Because the thing about snapshot scripts is that they are usually only good until the next update. Either an array firmware upgrade or an application upgrade can break a script.
Other things can break a script as well, such as adding a new database to an application, or migrating a DB from one LUN to another for performance reasons. Since snapshots are LUN based, if you move to a new LUN you have to mod your script. It’s a maintenance nightmare which is especially challenging for smaller organizations. And of course snapshot scripts are vendor specific! If you trade up to a newer, jazzier disk system – like a Nimble – there go all the scripts you’ve built!
And do you think taking the snapshots is challenging? Recovery is even more complicated! There are database files to restore (sometimes spread across multiple LUNs), logs to recover and replay, application awareness is necessary, and so on.
This is part of the reason why snapshot use isn’t more widespread, and why use is often limited even within organizations that use snaps. A company’s snap use is often limited to only a few critical Tier 0 or Tier 1 servers because anything more than that can’t be managed.
This is precisely why CommVault came up with Simpana IntelliSnap portfolio. Every day we help Nimble Storage users and others get the most value from their snapshot investments. We can help you too.