If Only I had Known!
The pitfalls that await those developing a business continuity plan are numerous. This section serves to elucidate some mistakes that are made. This is by no means a comprehensive list. If you have experienced a problem that did not seem obvious when you developed your plan, please share it with us so that we may all learn!
a. One size does not fit all - when it comes to developing a business continuity plan, this is a truism. Using someone else's plan based on conditions or requirement your company does not have may result in a disaster of another type
The best way to avoid this pitfall is to think of the business continuity and disaster recovery plan as a sum of many parts that fit into the broader plan. When a disaster occurs, it should be mapped to the appropriate plan module and which then determines the appropriate response.
b. Business continuity and disaster recovery only involve the IT personnel - nothing could be further from the truth. While the concept of business continuity and disaster recovery originated from IT, conceptually planning only for IT infrastructure leaves a corporation open to possible catastrophe. For example, software for running critical operations are limited in the new environment and this was not pointed out to the IT department during the planning stages. The IT staff ensured successful log on and nothing more. Had the operations staff been involved, their input could have taken this a step further and ensured the correct data could be accessed!
The continuity team, which must include business owners, must state business requirement. Three important objectives are
- Recovery time objective (RTO) - the minimum time in which the business must recover
- Recovery point objective (RPO) - the point of time when the data must be recovered - start of the day, the last back up or last transaction
- Cost of downtime - potential losses as a result of the disaster and the recovery cost should be understood.
c. The further you are the better the DR center - not necessarily so. While if a large-scale disaster were to strike, further the DR site is the better, distance can create its unique set of problems. Greater the distance the greater the risk of broken lines, higher the cost of transmitting data, greater the time of travel between sites and less the interaction between staff.
There is no hard and fast rule for determining an optimal distance. To do this, one has to conduct a Business Impact Analysis. The best DR location is one that minimizes costs but meets over objectives of recovery. In addition, all systems at the recovery site have to be robust.
d. Disasters occur rarely therefore investing a lot of money in robust infrastructure is a waste - nothing could be further from the truth. This is like insurance. Paying the premium always gives heartburn - but the day you have to make a substantial claim, you are glad you paid the premium!
Sometimes a small investment can prevent a larger catastrophe. If your WAN connectivity is dependent on only a single connection, you are vulnerable to line failure - a relatively frequent occurrence. If you invest in a redundant connection from a different provider and use technology for router clustering and load balancing, this is a locally handle able disaster. You will have WAN uptime all the time (for more information visit www.fatpipeinc.com)
e. All I have to worry is to keep data losses to a minimum - while keeping data losses to a minimum is good practice, ensuring consistency of data at the backup site is even more important. If not, you may have to resort to a time consuming back-up which usually takes a lot of time. Conflicting data can add to the delay and thus consistency should be one of the primary drivers in disaster planning
f. Only one copy of back-up data is sufficient - if a copy is being made in synchronous mode and the link fails, the consistency of the remote data will compromised temporarily till the resynchronization is complete. However, if disaster strikes during this period, data in-consistency will be permanent and may require an extensive re-working (link failure can be prevented by having WAN redundancy visit FatPipe Networks for information on this technology)