Myth number one regarding business continuity management (BCM) and disaster recovery (DR), says Gartner, is that one plan fits all.
"Think of business continuity and recovery scenarios as modules that fit into a broader business continuity plan. When an incident or crisis occurs, it is mapped to the appropriate business continuity scenario(s), which then dictates the appropriate recovery plan modules to be invoked," the research company says.
Myth number two, the report notes, is that planning and testing with IT personnel only is enough.
"It's true to say that BCM had its origins in the IT department, but that doesn't mean it should stay there. All too often, the IT department decides to focus on those applications it can technically recover without first conferring with the business units about what the right applications may be. And worse, access to the application is tested only to the point of a successful logon; no one ensures the correct data has been recovered. Only business personnel can test this recovery requirement successfully. However, businesses are often short-sighted in saying to the IT department, 'Technology is your job, you recover it' or 'It's just a form of insurance; we'll never need it so I'm not going to invest much in it'. Neither view is correct and both could be seen as negligent.
Gartner's third myth is that greater distance means better disaster protection.
"There is no hard and fast rule about the minimum distance required between data centres," the company notes. "Rather, the distance is dictated by regulations, management's appetite for accepting risk and the location of corporate assets.
For example, increasing the distance between data centres reduces the likelihood that the two centres will be affected by the same disaster. However, few disasters happen on a large scale, and putting too much distance between them increases the risk of broken links, line failures and the cost of transmitting data. It may make travelling to the recovery site more difficult for employees. These and other considerations make choosing a secondary site a complex process. Few companies can choose their secondary site freely. Instead, the choice often depends on the location of other owned or affiliated sites or service provider facilities."
The most important issue in remote copy design is to keep the data losses to a minimum is the fourth myth, says Gartner.
"Keeping data losses to a minimum is critical for some applications, but a more important issue is assuring data consistency and integrity at the recovery site. If the data is not consistent at the recovery site, a time-consuming backup is usually required, which may take days. Also, hunting down conflicting data and reconciling the status of key information can mean a much longer recovery time. Many companies mistakenly believe replication technology suppliers that say there will always be data consistency in a disaster."
Still on the topic of data, myth number five is that one copy of mirrored data at the recovery site is sufficient. Says Gartner: "If synchronous remote copy is suspended (as a result of link failure, for example) and then activated, the updates to the recovery site will be sent sequentially and not in the order in which they arrive to the primary system. The act of starting a resynchronisation activity between the primary system and the remote system will temporarily compromise the consistency of the remote data until resynchronisation is complete. If a disaster strikes in the meantime, it will result in lack of consistency and data integrity at the recovery site."
Finally, says Gartner, is the myth that planned telecommunications bandwidth should exceed the peak data transfer requirements.
"Ensure that only the bandwidth in synchronous remote copy exceeds peak data transfer requirements. For asynchronous remote copy, the bandwidth for average activity is sufficient," Gartner advises.
Source: Gartner, Management Update: Six Myths About Business Continuity Management and Disaster Recovery, Josh Krischer, Donna Scott, Roberta J Witty, March 2005
* Article first published on brainstorm.itweb.co.za
Share