Disaster Recovery Plan: Prepare for the Worst, with Peace of Mind

A disaster recovery plan describes how your site and data come back online after a major incident: a major outage, fire, ransomware, or human error. Writing it before you need it transforms a crisis into a procedure to follow. Here is how to build one without getting lost.

Disaster: What are we talking about?

A disaster is not just a server going down. It is any event that renders your data or service unavailable for an extended period: widespread hardware failure, general corruption, a fire or flood in the datacenter, a ransomware attack that encrypts your files, or a human error that deletes the essentials.

What distinguishes a disaster from a common incident is the scale: you do not restart a machine, you rebuild the service from backups. This is why a plan is essential.

RPO and RTO: Two figures to define

Every recovery plan is based on two numerical objectives.

The RPO (Recovery Point Objective) is the maximum acceptable data loss: the duration between two backups that you are willing to lose. An RPO of one hour means that, worst case, you lose one hour of data. An RPO of zero requires continuous replication.

The RTO (Recovery Time Objective) is the maximum acceptable time to bring the service back online. An RTO of four hours means you must be able to restore within four hours.

These two figures are decided based on your business: an online store aims for short RPO and RTO, while a brochure site can afford more. They then determine the resources to be deployed.

For example, a store that processes payments continuously might aim for an RPO of a few minutes and an RTO of one hour, whereas a brochure site might settle for a daily RPO and a one-day RTO. The cost increases with the requirement: the tighter the objectives, the greater the resources required.

Off-site backups and redundancy

The plan is based first and foremost on backups, but not just any backups. A backup stored on the same server as the disaster is useless.

Apply the 3-2-1 rule: three copies, on two media, with one off-site. The off-site copy is your last resort when everything else is affected. Our article on 3-2-1 backup strategy details the principle.

Redundancy complements backups: a database replica or a second server reduces the RTO, as it avoids rebuilding everything. However, redundancy does not replace backups: it does not protect against logical corruption or accidental deletion, which propagate to replicas.

Documenting the restoration

A written recovery plan is better than a single person's knowledge. Document precisely:

• where backups are located and how to access them;
• the restoration order: infrastructure, data, configuration, certificates;
• who is authorized to trigger the plan;
• contact points: hosting provider, developer, manager.

If the person who knows everything is on leave on the day of the disaster, the plan must allow someone else to manage it. Our help on making a backup copy is a good starting point, and opening a support ticket shows you how to contact the hosting provider in an emergency.

An up-to-date contact list is as valuable as the procedure itself: during a crisis, you do not have time to look up who to contact. Also note the duration of each restoration exercise: it should be close to the targeted RTO, otherwise the plan must be adjusted.

Testing the recovery plan regularly

An untested plan is just theory. Schedule regular exercises: restore a backup on a separate environment, time the return to online status, and compare it to the RTO you set for yourself.

The test reveals what is missing: an unsaved dependency, an outdated procedure, a revoked access. Each exercise makes the plan more reliable, and the team more at ease.

Who does what during the crisis

A recovery plan is also a human plan. Define roles in advance:

• who declares the disaster and triggers the plan;
• who contacts the hosting provider and follows the restoration;
• who communicates to clients and teams;
• who verifies that the service is truly restored.

During the crisis, everyone knows what to do instead of improvising. This is what separates a controlled recovery from a costly mess.

Knowing how to react when the site goes down is the first reflex: our article on site outages covers the immediate steps. For sensitive data, the question of local hosting also deserves reflection: see our article on hosting data in Morocco.

For hosting that places verified backup and documented restoration at the heart of its offering, discover Atlas Hoster's high availability plan.

Pitfalls to avoid

• Confusing redundancy with backup: a replica does not protect against accidental deletion or corruption, which propagate automatically.
• Keeping the plan in one person's head: if they are absent on the day of the disaster, the procedure remains inaccessible.
• Never testing restoration: an untested plan is just theory. Only a real exercise proves that it works.
• Neglecting the off-site copy: a backup in the same building disappears with the disaster.

Frequently Asked Questions

What is the difference between RPO and RTO?

RPO measures acceptable data loss (how far back in time we go), RTO measures acceptable downtime duration (how long it takes to come back online). One concerns data, the other the service.

Does redundancy replace backups?

No. Redundancy protects against hardware failure, not against logical corruption or human error, which propagate to replicas. Both are necessary.

How often should you test a recovery plan?

At least once a year, and after every major infrastructure or team change. Regular testing is the only proof that the plan works.