There is an interesting article in this week's issue of eWeek titled 5 Steps to Continuous Data Protection. The basic premise of the article is that organizations are not doing enough to ensure the protection of their company's data. The article goes on to point out five high-levels steps to take along the path to continuous data protection (CDP). The steps are:
- Plan around staff
- Determine data
- Evaluate tech requirements
- Check for compliance
- Test for holes
Of course, to really understand these 5 steps you should click on over and peruse the article. I think the author makes some good points and lends some useful guidance, albeit at a very high level.
The eWeek article discusses CDP for all data, but I would like to add some thoughts to these steps in terms of database data. First of all, a good DBA should, at a minumum, have the recoverability of every database object covered. Recoverability is the first part of data and database availability. Without a recovery plan, nothing else much matters, so it should always be the DBA's first priority. Think about it! If you cannot recover your databases after a problem then it won’t matter how fast you can access them, will it? Anybody can deliver fast access to the wrong information. It is the job of the DBA to keep the information in our company’s databases accurate, secure, and accessible.
Only after we know the business impact of the data being unavailable can we develop an appropriate backup and recovery plan. DBAs need to create service level agreements (SLAs) for recovery just like we have SLAs for performance. The recovery SLA needs to be from an application perspective, such as “Time to restore application availability after a failure for application X cannot exceed 2 hours (or 10 minutes or …)” . . . and then test for compliance with the SLAs before facing a recovery situation.
As you address the recoverability of your databases you should also take the time to address database archiving for all of your sensitive database data. Why do I bring up archiving in this context? Well, recall that database archiving is the process of removing selected data records from operational databases that are not expected to be referenced again and storing them in an archive data store where they can be retrieved if needed.
With this definition in mind we can see how archiving helps to optimize our recovery strategy. By archiving "dormant" data from our databases when it is no longer needed for business operations, the size of our databases will decrease. And that means we will not be backing that data up every time we need to make image copy backups to ensure the recoverability of our operational databases. We treat the archived data separately, in the archive data store. Because the data is stable, it does not need to be backed up more than once (other than to assure the ongoing viability of the backup medium). This approach not only saves us space (less data being copied regularly) and time (backups run faster because less data is copied), but it protects our data that must be stored for long retention periods.
Simply stated, you cannot ensure an efficient, effective, and viable CDP environment without addressing archiving.