A Recovery Plan: More Necessary Than You Think

The what, how, and why of a disaster recovery plan

Picture the scenario. It is a beautiful July weekend. It is 35 degrees outside and you are cooling off in the pool. You get a call from the plant foreman. Everything is down! The IT systems are no longer working, neither is the phone, and there is no more internet. You ask your foreman to go to the server room, and when you open the door to your server room, a blast of hot air comes with the silence! That is worrying. All the systems shut down because the ambient temperature was too high. Pollen and pollution stuck to the air conditioner's condenser, preventing it from working properly.

Once the air conditioning is back on, you start bringing the systems back up one by one. As misfortune never comes alone, a corruption renders your entire IT environment non-functional for several more hours, even several days.

What are you going to tell the customers waiting for their order to be delivered tomorrow morning?

You have the good sense to trigger your recovery plan. Within a few minutes, all your servers are started up in the cloud. The most critical systems for the plant's production are restored first. The database and production can start running again. In the minutes that follow, the less critical systems come back online.

Generally, the recovery plan fits within a broader framework that covers a shutdown of the company's operations, the possible risks, the vulnerability, and the business impacts. However, a specific section should be devoted to IT. Here we cover, at a very high level, what your recovery plan should contain.

– List of critical applications and the associated systems that support the applications

o Method of accessing the applications

o Manufacturer and support-contract information, contact

o Application dependencies (database, middleware, presentation layer)

o The RPO and RTO of each application

§ RPO: Recovery Point Objective: Ask yourself: how much data am I willing to lose? 1 minute? 1 hour? 1 day?

§ RTO: Recovery Time Objective: How long can you live without this data?

§ Your RPO and RTO objectives should define your backup policy.

o Runbook for the servers covered by your plan.

– Data recovery methodology

o Backup system used

o Data recovery procedure

o Backup frequency and policies

o Location of offline backup copies

– Recovery site information:

o Depending on whether your site is hot or standby.

§ A Hot Site is a site where systems run at the same time as your primary production site. As a rule, the systems are synchronized between the two sites. The main advantage of this model is the speed of recovery, which is for all practical purposes instantaneous; however, the operating cost is higher.

§ A Standby site is a site where systems are not running but are ready to be started and gradually take on the load. The main advantage is its much lower cost in exchange for a longer recovery time.

o Information to access it

§ Remote access

§ Information for media delivery (if needed)

§ On-site contacts (remote hands)

– Contact list

o Key people and vendors

o Internet provider

o VPN / MPLS provider

It is imperative to test this plan regularly. It will not be perfect on the first try. Use these tests to improve the plan's performance and make the necessary changes in production so the plan is functional. Note the changes to the plan after each test. Also note the time it took you to recover the applications at your recovery site to make sure your RPO and RTO are in sync with your backup plan and that your plan holds up.

Considering that many of a modern company's operations rely on IT, it is imperative to protect this asset. Prevention remains, now as always, the best way to protect your IT assets.

Do not hesitate to contact us to establish your IT recovery plan.