Do you Adapt or Replace your Backup Application?
Do you Adapt or Replace your Backup Application?
How do you make sure that your backup application protects, and where possible, takes advantage of all the changes and new technologies available in environment? Do you adapt your current backup application or replace it?
Thursday, October 22, 2009
The data protection process is constantly changing. In just the past few years we have seen the updated versions of Microsoft Exchange and Oracle with new versions on the way. We have seen the introduction of a whole new server infrastructure with VMware and a whole new set of target devices with data deduplication appliances. In addition, new products like Microsoft SharePoint are now becoming mainstream. In the middle of all of this is the backup application itself.
Costs of Replacement
Just like the lure of a new car, a new backup application may seem like the best way to advance the backup process. The replacement of a backup application may mean a slicker interface and better support of the latest backup hardware. It may even include some capabilities that are found in stand-alone devices or applications, like deduplication, for example. At what cost does this replacement come and if the decision is made to replace it, how long before that backup application needs to be replaced?
The cost of replacing a backup application is extensive. First, there is the obvious issue of having to purchase the application. While the potential backup vendor may have ROI calculators to the contrary, the check for the application has to be written up- front; and seldom do ROI calculations happen as quickly in reality as they do on paper.
In addition to the actual purchase there is the hard cost of deploying the application. It is amazing how many "easy to use" applications require professional services to deploy. In addition to laying down the agents, each agent needs to be tested and confirmed that it works on production applications; protecting their data without significantly impacting performance. Then, there are procedures to be created for special cases where support is not available. What if the new application does not protect a legacy platform? Does the old application stay in place? It is unlikely that the legacy platform is replaced.
There is also the cost of re-training administrators and users on how to use the new application. While some suppliers provide training it is usually in a classroom setting and not on the data center's configuration. There is also an "unlearning" cost associated with backup education. After years of doing something one way, learning to do it another way may be more time consuming than if the admin had never used a backup application in the first place.
Old Backup Data
If the hard costs can be somehow justified (or overlooked), what about the old backup data that exists? It’s likely this data is stored on years’ (or decades’) worth of backup tapes. Unless some sort of format conversion utility is created, it is highly unlikely that the new backup application will be able to read those tapes. In general, two options exist. First, restore all the old tapes and then back them up into the new backup application. This is potentially the best solution, because the new backup solution will then have knowledge of that historical data and be able to maintain the information in its own indexes. In reality this option is totally unrealistic. The time required to actually make this conversion is almost immeasurable.
Most organizations will go with option two; maintaining a copy of the original backup application for the lifespan of those existing backup tapes. As stated earlier, this could mean running the old backup application for years, if not decades. Regardless of the current backup application, as well as the application under consideration, cost, implementation, retraining, and managing old data are real issues that need to be addressed.
Integration, but the sum is weaker than the parts
When reviewing backup applications, one final consideration about switching to a new application is compelling. Occasionally, there is a specific advantage in the coverage of a particular application. But more often than not this comes from small, singularly focused companies that deliver protection to a new or small market share application (more on that later).
More common today is the discussion of backup applications that integrate multiple capabilities; for example, a single interface that drives backup, email archive, search and file archive There are two challenges with these types of applications. First, in many cases, the sum product is weaker than the individual parts. These backup products often are really a collection of disparate applications that, while integrated under a common interface, often still don't really interact very well.
The second challenge to this approach is that the development effort involved in maintaining technical parity with the other stand alone, targeted applications that compete in the market is enormous. Not only does this integrated solution need to keep pace with its competitors in each of its functional areas, (email, search, archive, etc), it also has to maintain integration. Finally, since the user is totally reliant on that application they must wait for it to support any new software initiatives or hardware technology to be able to utilize that capability in the data center and have it protected.
Extendable Backup Architectures
Potentially, a better solution is now becoming available; extendable backup architectures. This is an API-driven capability that allows other software and hardware suppliers to tap into an existing backup application. Doing so allows for the backup feature set to be expanded without requiring separate administrative steps or responsibilities.
An API set like Symantec's OpenStorage Technology, for example, allows the backup administrators to add unique application support or advanced technology to their existing backup processes without having to manage two separate interfaces. It also allows Symantec to address the potential of integrating the technology into its products under a timetable that makes sense for them and their users.
For example, data deduplication has captured a lot of interest of late because of its ability to lower storage consumption and in some cases, network bandwidth. Several deduplication appliances have gained significant market share over the past few years. By comparison, the few backup applications that have added deduplication have just done so within the last few months. Understand that deduplication is a technology that, be design, does not store all the data that is sent to it, counting instead on references to the original data.
There is a risk associated here and a backup administrator would be wise to invest in a solution that has been tested in the real world, across many installations. The challenge is that this can lead to a disk backup target that needs to be managed separately. As a result of solving two backup problems, capacity and speed, you’ve added another one - backup management.
This is where a backup application extended by an API set can bring value to the environment. It allows the customer to invest in a technology that can enhance their backup infrastructure without requiring a separate management point. The customer gets the best of both worlds, adoption of well tested technology without adding to the management headache. Then, when the backup application supplier adds that particular capability, the customer can make the decision when and if they should switch.
As the use cases and the API set evolve, other theoretical competitors to the backup vendor could integrate into the application as well. For example, a database vendor with market share that is too ‘nichey’ for the backup application vendor to spend development resources on could develop their own plugin to the enterprise backup environment. Doing so would give the smaller vendor the competitive advantage of supporting the enterprise process.
When to Switch
Switching backup vendors is similar to switching network or SAN infrastructure vendors. These products are at the foundation of what the data center does. When it comes time to replace a backup vendor it makes sense to select one that can be extended, no one vendor can accurately predict the future.
There were practically zero server virtualization projects five years ago, nor where there many data centers that had embraced deduplication. It is impossible to know what the next five years will bring. Selecting a vendor whose solution can be extended and easily integrated with will allow for that backup solution to be a part of the foundation permanently.
An API set has become the critical ‘must have’ capability for customers looking for a more permanent backup infrastructure.
George Crump, Senior Analyst