No, what you think you have, is not a Disaster Recovery

For the 'Friday rant' series (started on my Linkedin profile several months ago now), here is this week's topic:

"No, what you think you have, is not a Disaster Recovery".

No, it is not a Disaster Recovery, if the data is saved on a RAID disk.

No, it is not a Disaster Recovery, if the data is copied once a day to an external disk.

No, it is not a Disaster Recovery, if you only make one backup.

It is not, if the backup is on the same operating system.

It is not, if you have everything in the cloud.

It is not, if you have a copy of your data on One Drive, Google Drive, Dropbox

It is not, if you take your data home every day/week/month.

Nor is it, if you have systems in high reliability, clusters, hyper-convergent, etc.

Let's start with the basics: "Disaster"

Having a copy of data backups is an essential, dare I say vital factor for a company. But what slips through the cracks when it comes to the subject is the 'disaster' issue:

In the unfortunate event of a fire in your office, plant or building, are you able to return to work in a reasonable time? Let's say the next day?

When we speak of disaster, we are not talking about the power going out or Internet access going down, but rather catastrophic situations in which business is totally compromised.

Situations in which it may not be possible to re-enter the building for several days or even weeks.

When we talk about catastrophic situations, we refer to:

• theft (for on-premises solutions)
• flooding
• fires
• earthquakes
• floods

At a time when the climate crisis is making itself felt, scenarios such as fires and floods are unfortunately no longer as remote as they seem.

Back in operation: "Recovery"

There is a rule I outline whenever I talk about Disaster Recovery:

The closer you want to be to 'zero down-time', the more zeros there must be in the amount invested in the infrastructure

There are always technical times for the recovery or transition of technology systems to DR, and these can be longer or shorter depending on the solutions chosen.

However, one substantial element remains: in the event of a 'catastrophic situation' we ask the right questions:

• where will people work from?
• from where does activity resume?
• in what order?
• will it be possible to return to headquarters? If so, when?

These are just some of the questions to be asked, but they make up most of the whole process.

What many forget: "Plan"

A Disaster Recovery Plan (DRP) is primarily made up of procedures and, for them to be effective, these must be built on a well-founded knowledge of your processes.

A Disaster Recovery Plan based only on 'data replication' is a failure and serves no purpose.

When implementing a 'Disaster Recovery' plan, it is good to keep in mind that it is also necessary to provide for

• communication to the parties involved (customers, suppliers, employees, collaborators)
• according to the data processed, all parties involved (the 'loss' of data is a 'treatment')
• communication of interested parties (shareholders, stakeholders, etc.)
• who to contact for technical activities and procedures to follow
• how to get people up and running, according to business needs
• who to contact to start data recovery

Just to name a few. And questions vary according to the type of structure.

Even if you think you are 'totally in the cloud'.

Considerations

The reason why I get angry about issues such as Disaster Recovery or Business Continuity stems from the fact that many companies sell it as a 'product' or that it is an 'obvious' thing that you don't need to dwell on because, after all: "it shouldn't happen anyway".

The reality, however, is that it is an essential element that determines the survival of a company following an unforeseen, unpredictable, and catastrophic situation.

A bit like a life insurance policy: you take it in the hope that you will never have to use it.

And your business, does it have a Disaster Recovery Plan?

Is it really a DRP or is it just an illusion?

Sometimes it is better to know, even if ignoring a problem may seem easier.