The Future Of Backup And Recovery

I've got backup on the brain. I guess this isn't an unusual occurrence for me, but it's also been bolstered by a week at Symantec Vision, a week at EMC World, as well as backup announcements about IBM's data protection hardware and CommVault's PC backup enhancements not to mention the flurry of cloud backup news this week from Trend Micro, CA Technologies, and Carbonite. All of this has gotten me thinking about the future of backup... we've come a long way from simple agent-based backup and recovery. Backup is just one piece in an ever-increasingly complicated puzzle we call continuity. If backup software vendors want to stay relevant they're going to need to offer a lot more than just backup in their "data protection" suites.

Here is what I'm imagining for the long-term future of backup products: A user interface that presents all of your applications to you (perhaps it even auto-discovers and links interdependencies of them), you rate the applications by their criticality (mission-critical, business-critical, etc .), and define a recovery time objective (RTO), recovery point objective (RPO), and availability standard for them. The application will suggest the best way to protect the application and meet your requirements, whether it's through simple backup to disk, tape, or even cloud, continuous data protection, snapshots, application specific protection, clustering, asynchronous or synchronous replication, hot standby, etc. You select the method, and the tool will orchestrate and monitor the technology (maybe it integrates with your storage array to control the snapshots and replication, or cancall on VSS, VMware HA, or Oracle RAC, for example, when needed). The tool can monitor for failures at the hardware, OS, or application layer, alert you of a problem and even initiate a failover to an alternate site. The tool will be able to test your DR plans and validate RTOs and RPOs non-disruptively.

Of course, we can't call this backup anymore; it's a lot bigger than that. In a recent report, I called it "Unified continuity and recovery management" but I'm starting to think that's too much of a mouthful.

But I'm curious about what you think. Would you ever use a tool like the imaginary one I described? Where do you think backup is going? What would you call it? Is my vision too far-fetched for even 10 years down the line?

If you like having these types of discussion or if you want to learn more about backup and recovery, I'll be facilitating a session on June 7th in Barcelona for senior executives in infrastructure and/or operations. Click here for more information on the meeting.


Recovery part of 'vision'

Well, backup itself may get more intelligent in terms of what to backup, when to backup, how to failover and where to failover but 'recovery' still needs human intervention of some sorts. With cloud computing and huge growth in SaaS, and IaaS in the hands of a handful of providers, 'recovering' data and 'time to recover data and/or service' would be a key customer need. Backing up cloud based data and service and making it available to customer at all times for critical needs is something that I see as a huge requirement in the near term (5yrs). There could be a backup / restore and cloud portability convergence at some point to meed this end.

Good point, recovery is complex

Good point, the recovery aspect of this is really the most complex part. And where to recover to (original location, new location same site, new site, CLOUD?!?) is always going to involve some human intervention, but I believe we will someday get to a point where all the technology process of the recovery COULD be automated.

I feel that storage

I feel that storage management (backup and recovery) is need of a few items.

1. The reporting software integrates with backup application in which the software will autotune to maximize effeciency.
2. The backup application will help resolve the issues and give you more realistic suggestions. (Needs to be integrated with network, server, and storage).
3. Backup needs to be tested by the application instead of third party. (TSMWorks for example)
4. Recovery needs to be a single click operation.