Disaster recovery sounds deadly serious and scary, but it’s simple really. The key to Disaster Recovery success is having a set of objectives that are realistic and just right for your business. Essentially, you need to think about three things – planning, preparation and technology.
I know it might sound simple, but a Disaster Recovery plan needs to represent all functional areas within I.T. and across your business before, during, and after a disaster. It needs to include applications, networks, servers & storage.
Contingencies, such as “what-if” scenarios should be considered as part of planning process. Decisions need to be made regarding levels of disruption that will constitute a disaster, downtime and loss tolerances.
This plan needs to be written down and accessible. Analyse impact, understand risks and prioritise recoverability.
Here some top tips to follow to help with your disaster recovery planning
Disaster Recovery is an INVESTMENT – not a cost
Data protection and recovery requirements may seem too expensive and Disaster Recovery is considered a particularly heavy expense, one that most organisations have a great deal of difficulty absorbing.
However, think about it – being able to address the I.T. cost for Disaster Recovery is an issue of integrating Disaster Recovery into standard operations as much as possible. Ideally, the Disaster Recovery resources and equipment are not viewed as technologies that are sitting idle. Ultimately, this comes down to making an informed decision of either spending money or accepting risk.
Newer technologies are emerging that make this more cost effective. Regardless, Disaster Recovery needs to be treated as an investment. It is an insurance policy.
Realistic Disaster Recovery Objectives
Prioritise your Disaster Recovery policy. Business continuity is important for any company, no matter how big or how small. However, in fact, some small business may feel it more because they don’t have the man power or infrastructure in place to be able to deal with an emergency.
So, lets looks at the Disaster Recovery capabilities and resources of your business. Are your goals attainable? If something goes down, how long do you expect it to take to be up and running again?
Depending on the size of your business you might already know this, but for the novices out there it is important to set realistic Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO).
Question. When does the clock start ticking and what tolerance is permissible for an outage? Those are Recovery Point Objectives to consider. As for the Recovery Time Objectives, ask yourself how current is the data prior to the disaster?
These are the key matrix items that need to be determined and supported. It is important to examine whether the infrastructure can support the goals.
Keep the Disaster Recovery Plan Current
Disaster Recovery planning needs to be part of the day-to-day operations of the I.T. environment and even though it is an exception, it should always be at the forefront of people’s minds. Once the Disaster Recovery plan is created, it needs to be maintained and updated every time anything changes within the I.T. environment. The dynamic nature of I.T. and technology ensures that the Disaster Recovery plan will fail if the management of the plan is not part of change management.
Test The Disaster Recovery Plan
The Disaster Recovery plan needs to be tested regularly to ensure the business can recover the operation successfully and in a timely fashion. Disaster Recovery testing is a major challenge for most IT departments, but if recovery has not been tested all the way to the application level, it is very likely that problems will occur.
Even though a Disaster Recovery test is a major operational disruption it shouldn’t be treated as a pro forma exercise but needs to include true end-to-end testing all the way to production. The focus needs to be on recovering applications rather than servers since with today’s complex applications, client server and web-based multi-tier applications, the components reside on multiple servers thus there are interdependencies between these. If disaster recovery has not been tested all the way to the application level, it is very likely that problems will occur.
The philosophy for Disaster Recovery testing needs to change. Basically the approach used for software quality testing should be adopted, where finding bugs is a positive thing. Finding problems in Disaster Recovery is equally positive as long as these issues are resolved to eliminate problems during a real disaster.
Disaster Recovery Risk
The Disaster Recovery plan needs to address the right risks. Disaster recovery is essentially an insurance policy. How much and what kind of insurance is needed? What sort of risks is the organisation willing to take? The definition of what constitutes a disaster that is covered by the plan has to be considered. Many recent disasters were floods but various kinds of other weather activity and fires need to be considered as well. There are elements within the organisation’s environment that need to be considered from the standpoint of what constitutes a disaster. A site outage, application outage, or even a server outage could constitute a disaster for an organisation.
Disaster Recovery BACKUPS
What happens when the backups don’t work? For many, tape backup is still the primary medium for disaster recovery, certainly for off-site disaster recovery. Who uses tapes anymore? As an alternative, replication across a WAN is growing, but it might be too costly an option for some businesses. Application recover-ability must be validated through the recovery of backups to the application level.