This lack of a data protection model often leads organizations to undertake a wide assortment of data protection tasks. For example, there are snapshots from the storage system, in-application backup 'dumps', ad-hoc copies or log shipping, and of course, some level of enterprise backup software - often all protecting the same data. This multitude of overlapping data protection efforts often leads to redundant purchases of data protection hardware and software and additional processes for the administrators to monitor. Considering the importance of data protection this might be a worthwhile investment, except that these same organizations still report no corresponding increase in recovery confidence as a result of all of this investment.

Part of the redundancy of investment comes from redundant data protection policies. Policies are the descriptors of the data protection process, detailing how data should be backed up, replicated and retained. Policies need to be examined and compared to make sure that redundant copies of data are not being retained consuming excessive resources. If two processes are protecting the same set of data but have different retention policies in place they may also affect how the company is adhering to compliance or corporate governance requirements. For example, if there is a policy to delete all email backups after three years but the email administrator has been burning a copy to a DVD and storing it separately, those backup copies may not get erased, leaving the company open to legal action.

This series of ad-hoc data protection tasks that develops is often the result of organizations focusing on the wrong thing: recovery. While many vendors promote recovery of data as the primary objective, the DPSM model projects a different focus: the Service Level Agreement (SLA). Clearly, a component of an SLA is the recovery of data, but it's not the recovery of all data all the time. Instead, the focus is the recovery of the right data at the right time. SLAs are only valid if they are written down and agreed to by the organization or business unit. Too often SLAs are implied. This gray area leads to the incredibly high expectation on the part of business unit managers that all data will be recovered at any point in time. SLAs level set those expectations to the right data being recovered at the right time, and allow the business to continue operations at a minimal cost.

Managing to the SLA makes data protection more realistic and actually improves the quality of the process. There are so many components to a successful data protection process that expecting all backups to work all the time is unreasonable. The application has to be in the right state, the network connectivity has to be correct, the backup application has to be properly configured, the backup targets have to be online and have enough capacity to store the backup, etc. With this many variables there is always a chance that some backups will fail. Trying to fix the situation and complete all backups actually puts other backups at risk, including the ones that are critical to the organization's SLAs.

Given the scope and number of components that are touched by a data protection task, requiring a backup administrator to manage and monitor these and then manually map them against a specific set of SLAs is too much to ask. What is needed is a software application like Bocada's Prism that can automate the DPSM process. Establishing an SLA allows the backup managers to first address the backups that put the SLAs at risk. However, without a DPSM process in place they have limited ability to identify which backup failures are placing which SLAs in jeopardy. The manager can spend more time trying to match polices to SLAs than they do just making sure all the critical backup jobs work. A DPSM software application is critical when trying to manage to SLAs and makes the time investment in creating SLAs worthwhile.

With a DPSM application in place the organization will find that the backup process generates a higher success rate by eliminating redundant policies, allowing the backup manager to focus on fewer more relevant tasks. They will also find that fewer backup polices will reduce the overall backup hardware and software investment, saving the organization money.

By making backups part of the larger process of meeting service level commitments, the IT department often finds its relationship with business unit managers and customers improves. Expectations are set correctly and the DPSM software can provide reporting so those customers can experience confidence that, in the event of a failure, their data can be recovered. They will also understand what their responsibility will be in the event of a system failure. Then they can plan and budget for that, which makes a data loss event more manageable for them as well.

Finally, DPSM with the appropriate software, allows the backup managers and compliance officers to better respond to audits. The backup manager has supporting documentation in place to monitor and prove that the correct number of copies are being retained for the correct length of time.

In many organizations, data protection has fallen into a cycle of throwing an endless amount of hardware and software at a corresponding number of independent backup tasks. To break this cycle, data protection must move to a more professional model, DPSM. The implementation of this model should drive down both capital and operational costs while improving overall effectiveness.

George Crump, Senior Analyst

This Article Sponsored by Bocada

Related Video
  Data Protection Needs a Model

Related Articles
  Restoring Confidence