Send your Storage question to David Hill today!

See other Storage tips from David

What seems to be the problem? In a previous storage tip ("When Is a Disaster Not a Disaster") the differences between operational recovery and disaster recovery was discussed. A reader has since raised a question about when a failover to a disaster recovery site would constitute an operational recovery rather than a disaster recovery. That question is important as the rules of the game (i.e. the service level objectives or SLOs) probably change when a disaster occurs. For example, under normal circumstances, a bank would have high availability (probably measured in seconds, minutes, or hours of unplanned downtime per year) for its ATM systems. However, after a regional disaster, such as Katrina, the immediate availability of the ATMs would not be the main priority; the safe preservation of customer account information would be.

What do you need to know? Differentiating between operational recovery and disaster recovery is not always clear-cut. There will always be some gray areas. No matter how many rules are suggested on how to differentiate the two, they will never be enough. However, here are some guidelines for when a failover to a remote site is an operational recovery problem and not a disaster recovery problem.



1. Any failure of any IT infrastructure component that is due to its "nature" is an operational problem. That would include disk failures, a failure on a server motherboard, software defects, etc. Such a failure is not systemic -- a disk array fails not all disk arrays; a server fails not all servers, a database table corrupts not all database tables for all applications. That does not mean that the problem is not a severe one. The problem may very well involve serious violations of service level agreements, but magnitude of the problem from a service level perspective is not the determinant between operational and disaster recovery.



2. If the equipment needed to resolve the problem could logically have been at the original site instead of physically at the remote site then the problem is an operational problem -- not a disaster recovery problem -- no matter how long the failure lasts. Non-systemic failures should be able to be handled theoretically at the same site through redundancy (say a spare disk array) or through recovery procedures (say backup and recovery procedures). Now an organization may choose to have the redundancy and/or recovery procedures in the same data center, in a building across the street, or at a disaster recovery site one thousand miles away. Therefore, the fact that you had to failover is irrelevant regardless of distance -- local or remote. The problem is still an operational one



3. If the IT staff at the original site is still able to work to solve the problem and if they are able to work at the original site, then the problem is an operational one. O.K., this is where some gray comes in. If a data center has suffered significant, but not total damage, some capabilities, such as communications, may still remain. Still, the data center is likely to be declared unusable and IT staff (except for emergency requirements) is likely to be kept out.



4. All logical data protection problems are operational problems. That guideline does not mean that logical data protection should not be performed at a remote site. For example, if a disaster recovery site has assumed the role of the production site and run applications, then logical data protection at the remote site is a necessity. But any logical data protection problem -- a virus, database corruption, or an accidental file deletion -- is an operational problem. In the case of a logical data protection problem, failover to a remote site probably would not do any good anyway. For example, remote mirroring would simply replicate the problem on the remote site. However, there may be cases where the original site is quarantined before the problem occurs on the remote site (say where asynchronous rather than synchronous remote mirroring is used). In this case, the original site would be isolated. Now continuous data protection (CDP) may be run at either the original production site or the disaster recovery site or both. CDP would provide logical data protection, but where the CDP appliance was located would not change the fact that a logical data protection problem was an operational recovery problem.



What can you do about it? When putting together the SLOs for your service level agreements, differentiate between operational recovery and disaster recovery because the objectives are likely to be different for each type of recovery. In the process, you should be able to put together some guidelines as to what the differences are between operational recovery and disaster recovery.



Most problems are operational problems not disaster recovery problems (fortunately!). You don't want to cry the disaster wolf when your operational recovery policies, practices, and procedures should be sufficient to address the data protection problem that you face.

storage.itworld.com

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine