Data Context and Reducing Application Downtime
At Commvault GO 2016, I co-presented a session on reducing application downtime using snapshots. We had a great turnout, even more so considering that it was the end of the conference, and a number of folks were anxious to get home before Hurricane Matthew hit the next day. The session was well-received. I saw a lot of nodding in agreement when I covered the challenges customers face around snapshot management, and quite a few customers came up to talk with me afterward about their own snapshot challenges.
I’m not going to go into a long spiel about how great snapshots are for protection and recovery or even how well IntelliSnap technology integrates with your storage hardware. Commvault has plenty of that already.
One of the customers who I talked to afterward described one of the classic snapshot management problems: “I take snapshots from several applications and back them up from another server. Can you guys use a script to handle the mounts?”
Of course we can, but that’s not really the solution.
Context is key to effective recovery
This is by no means the only customer facing this problem. Customers are conditioned by other products to think of snapshots and backups as separate things. And that makes operations inefficient because it loses two levels of context. Effective protection and recovery needs to track where data came from and what type of data it is. Creating snapshots with one process and backups with another means the customer has to track that information, plus they have to track all the relationships between servers, proxies and paths, as their environment grows, changes and evolves. And what’s worse, they have to go back and look those relationships up again on recovery.
System context means tracking the source of the data back to production. Losing system context means that when it comes time to recover, you have to know what production server it came from, and you have to translate the paths where you mounted the snapshots when you’re trying to find the right data.
Data context means knowing what type of data you have - files, databases, VMs. No data context means database snapshots became flat file backups. That means you have to put those files back, and you (someone else, more likely) have to recover the application to the right time.
All of that context loss adds up to more time and effort during recovery, and when an application is down you want to minimize those as much as possible. Maintaining context lets Commvault track the relationships from snap through backup, with knowledge of where the data came from and what kind of data it is. Tie that together with knowledge about how to automate point-in-time recovery for an application, and all you do is pick your data and time and go.
That, of course, lets you get out of the tracking game and go focus on keeping your apps up.