Over the last few weeks, I have been taking a hard look at various data protection tools to determine if they meet the goals for the next generation of tools. Those goals are quite interesting, actually, the main goal being application-centric backup with increased visibility into our methodologies. We need to know not only how well any backup, replica, and recovery operation meets our SLAs, but also whether or not all our data is actually available. This includes determining if there are any dependencies for an application as well as taking a comprehensive look at all the different forms of data protection. The other major goal for the next generation of tools is to preclude the need for a human element: in essence, we need to provide data protection without needing a human to set it up for us.

What this all boils down to is a need to increase analytics surrounding data protection and data availability. This is not a simple set of analytics, but one that meets the increasing necessity to determine the topology of an application, the dependent systems required by it, and how those dependencies and applications are protected. We could employ several forms of data protection: backup, software replicas, storage snapshots, hardware replicas, recovery points, etc. However, we have a growing need to expand our data protection to include testing our recovery processes using a real-world scenario. Does the application work? Is the data whole? We need to know the answers and have them fed back into our data protection tools.
All of this takes automation, which is what I am seeing in most of the data protection tools currently within the market. They are starting to provide hooks for automation and some level of simple analytics for their own systems, as well as the ability to pick up new workloads if those workloads are added into the containers already defined. Yet, I do not see much addressing dependency detection or providing the feedback necessary for improving disaster recovery.
Several functions are necessary for the next generation of data protection:

  • Automated application detection: Data protection should be able to tell us the applications in use either by logging in to the systems in use or by detecting this on the network. It should automatically detect applications, systems, storage, switches, etc. Once our network is inspected, that inspection must continue in order to detect changes and new applications. I suggest that the backup tools team up with application management tools.
  • Automated dependency determination: Our systems are growing too complex; we need tools that not only protect what we tell them to, but also grow with our applications. Further, we also need to determine the full set of dependencies for an application, with specific instructions or automation scripts to fully restore an application from scratch. We cannot assume during a recovery that even our Active Directory server is running. For the ultimate disaster, we need a simple script that we can launch to get our applications running again.
  • Automated detection of issues: We need tools that will tell us if there are problems with our data protection: not just that the backup, replication, or snapshot failed, but why, how, and when (Continuity Software has a huge head start here).
  • Automated disaster recovery testing: We all know that disaster recovery testing is a long and laborious process, but what if it were not? What if it happened all the time? And what if feedback were delivered to us to help us improve our backup? The human would only need to be involved in making decisions on whether or not something should change or be added. (Veeam still leads the pack here.)
  • Automated IP address adjustments during recovery: We cannot be worried about IP issues during recovery. We now have backup tools that can ignore networking issues; we should continue to use them. (HotLink, RackWare, Datto, etc.)
  • Backup to and from the cloud: We need to be able to get our data “there and back again” and possibly even between multiple clouds. (HotLink, RackWare, Zerto, Veeam, Datto, etc.) Most data protection systems can back up data to a cloud, but we need to be able to recover our systems in the cloud. In addition, we have the need to get our data back out of a cloud in a usable form.
  • A big red button: Disaster recovery should happen automatically or when a big red button is pressed. It should not take hours or even more than that single press of a button. Once humans are involved, mistakes can happen. Those mistakes could be costly. (VMware vCenter Site Recovery Manager has a bit of this capability.)

The next generation of data protection takes what Veeam, Unitrends, Datto, RackWare, CommVault, and others have started to the next level, with the ultimate goal of removing the human from the disaster recovery scenario. From an analytics perspective, Continuity Software’s AvailabilityGuard is far ahead of the pack. It looks not only at backup, but also at various forms of replication, snapshots, etc., offering warning when a small change can have a major impact on data availability.
Yet, we need to go further. We need assurance that whatever tool we employ, our data will remain available. And that data should be available not only where it is currently used, but also according to what Veeam calls the “3-2-1 methodology” of data protection (3 copies, 2 different media, 1 off-site). If your data is 100% in the cloud, perhaps the off-site location is within your data center or another cloud. We need analytics that will tell us whether we are adhering to this policy and methodology as well as whether our data is at risk. The next generation of data protection includes analytics as the basis for automation, recovery, and planning.