|
IT departments in any organization must implement a data protection and disaster recovery strategy to ensure business continuity, compliance and business process support. A clearly defined, well-documented and agreed-upon strategy allows you to formalize your requirements, procedures and expectations related to data protection. The process of creating the strategy provides your business with an understanding of the value of e-mail data, and provides cost justification for the resources you allocate to protect it.
The term data protection refers to measures you undertake to ensure your important data is accessible and is recoverable in an event of a disaster. These measures include, but are not limited to, backup, e-discovery and high availability. The term disaster recovery refers to the process you follow in an event of a disaster to recover your data to an acceptable level. Data protection and disaster recovery are closely related because data protection is put in place to maximize disaster recovery.
This chapter will provide practical guidance on creating a data protection and disaster recovery strategy. Unfortunately, many companies that overlook the creation of these strategies end up losing critical data and prolonging system downtime. Remember, it is too late to implement these strategies after you have been affected by a disaster.
Service Level Agreements
The SLA is an agreement between the users of your system and your organization’s management. It states the standards for availability, protection, recovery and performance expected from your system. Measuring the actual results (for example, the actual time it takes to recover from a disaster) against the standards set in the SLA determines whether your data protection strategy is indeed successful.
Ideally, the SLA should be established before you create a data protection and disaster recovery strategy. Doing so will allow you to create the strategy so it can meet the SLA goals. However, many organizations have had the messaging system for years and even decades and have not established an SLA upfront. In this situation you should establish the SLA as soon as possible and review the data protection and disaster recovery strategy as well as the system as a whole in view of the newly established SLA.
Gathering organizational requirements for data protection and recovery
Determining business requirements for data protection and recovery starts with measuring the value your organization places on its e-mail data. This determines acceptable levels of data loss in an event of a disaster, the acceptable time your users can spend without messaging functionality and the acceptable time the recovery process can take.
As disasters tend to strike unexpectedly you must perform regular test restores. Performing a test restore can help you determine whether the recovery procedures defined in your strategy meet the recovery objectives set by the SLA. It also helps your staff understand the cause of action to take in an event of a disaster. If a disaster occurs they will be able to act in a competent manner.
The process of gathering business requirements usually involves interviewing key stakeholders, interviewing business units and consulting with your legal advisors about compliance requirements. Analyze the gathered requirements to define the following specific points.
Recovery Point Objective
In an event of a disaster it is very unlikely that all messaging data will be recoverable. For example, in an event of full server failure you may not be able to recover e-mail items received since the database was last backed up. A recovery point objective defines the acceptable level of data loss in a disaster in the worst case scenario.
To determine your recovery point objective, aim to find out how valuable each e-mail message is to your organization. Analyze the consequences of losing last week’s, day’s or hour’s data and compare the cost of this loss with the cost of conducting more frequent backups and implementing a highly available system.
Until recently, a near-real time recovery point objective was not technically feasible. Relying on backup software alone, organizations had to make the tradeoff between frequency of backups and system performance. Unfortunately, most organizations that place high value on messaging data also have a lot of messaging data (100GB and larger mailbox databases). Performing a backup of such large databases takes a long time, and is nearly impossible to do during office hours without seriously interfering with system performance.
|
