When you are considering between Backup or Disaster Recovery (DR); the question you need to be asking yourself is not “do I need Backup or Disaster Recovery?” but rather, “what am I trying to protect against?”
Typically, with a Backup or DR solution, you are looking to achieve the ability to recover from (or avoid):
- Human Error
- Malware\Ransomware Attacks
- Natural Disasters
- Equipment Failure
- Loss of Reputation
Traditional Views
Traditionally the lines between backup and DR were clear.
Backup was a copy of your data; be it files or something else requiring a granular restore – such as Microsoft Exchange. They were stored either on removable media devices like tape drives. The backup was then taken offsite in case of emergency. This rarely involved backing up the entire server.
Disaster Recovery, on the other hand, is the ability to recover the entire system after a failure.
One of the key differences between backup and DR is the amount of time this recovery takes, known as the Recovery Time Objective or RTO.
A true DR strategy has an RTO measured in minutes, NOT hours or days. The RTO of a traditional backup solution on the other hand, was typically measured in days and sometimes in extreme cases, weeks.
The age of the data also helps define Disaster Recovery over backup.
This is referred to as the Recovery Point Objective, or RPO, and is measured in minutes (or sometimes in seconds as shown in a recent customer example in the image above).
Comparing this to its backup counterpart, backups typically are taken daily. This being the case the RPO for a backup would typically be 1 day. This statement can be contradictory depending on several factors, for example:
- The time the failure occurred in correlation with when the backup completed
- How often the backup is configured to run. It is possible to run backup hourly if there is a business case to do so, however in production environments this could affect performance.
Modern Views
Nowadays the lines between DR and Backup are somewhat blurred depending on your perspective. Some reasons for this are:
- Backup Software can backup open files without the need for additional (expensive) Open File Agents. The ability to be able to perform this task has increased the flexibility of backup where businesses are now encouraged to backup the entire server.
- Lower storage costs also encourage businesses to maintain a solution that grants multiple recovery points going back months or even years.
- Backup Windows are less important as server performance tends to outweigh what is needed by the Operating System and applications and we don’t need to worry too much around locked files, meaning backups can take place (in a lot of cases) any time of the day.
- The ability to recover to various mediums, for example a physical server can be restored to Hyper-V or VMWare or a virtual guest can be restored to a physical server. We are no longer tied as we once were to the Hardware Abstraction Layer in the Operation System (some customisation is required in these scenarios).
However even in light of these flexible options for restoring your data, Backup is still NOT Disaster Recovery. Why?
- The Recovery Point Objectives are still considerably higher than that of a true Disaster Recovery solution, and
- The Recovery Time Objective is longer than any Disaster Recovery solution as you always have to restore to a different medium, so you’ll always have the restoration time, as well as in most cases the need to procure the hardware to restore to.
If you’re a small business, the costs (although not high compared to what they were 5 or so years ago to implement Disaster Recovery), might seem too expensive. In these circumstances, you might be tempted to consider backups only as your entire DR Strategy.
But before you do. Don’t!
I know from experience that businesses that do this end up paying more in the long run.
Data loss, the age of the data and costs associated to bring that data back up-to-date on an ad-hoc, “emergency” basis can be astronomical. That’s before you account for the costs involved in paying staff when they can’t work until systems come back online.
Harder items to measure, such as loss of reputation and business as a direct loss of service is another consideration.
Getting the Message Across
Most businesses appreciate the need to have a comprehensive, reliable and historical backup solution. One reason for this acceptance is at one point or another most businesses have had to recover some data, no matter how small from a backup. In the case of a catastrophic failure, not many businesses have had to endure this and therefore will not appreciate the value behind a Disaster Recovery solution until it happens to them.
The threats now from very sophisticated Malware, Human Error (a common reason for many failures, either deliberate sabotage or accidental), Natural Disasters or even governance, can be reasons that a business needs to consider DR.
Some key questions to ask yourself to self-assess your need for Disaster Recovery are:
- How long can you operate if all of your IT Systems go offline?
- How long will it take to recover under your current backup solution (more to the point have you tested this so you have accurate figures)?
- How much will it cost you to pay staff whilst the systems are being recovered, adding to the cost of procuring new equipment to run the systems on?
- Are there any governing bodies, shareholders, or partner agreements that dictate the requirement for a clear Disaster Recovery strategy?
Disaster Recovery Testing
Your DR strategy is only as reliable as your last test. But how often should you test and what should you test?
There is no simple answer to this but it is critically important you set time aside to:
- Write an invocation plan
- Test the invocation plan
- Document issues experienced and the fixes that need to be implemented to resolve
- Update the invocation plan.
It is my opinion the plan should be tested regularly, a sensible definition of regularly could be quarterly but this will vary from business to business. Remember though that although we are focusing on the IT in this post, you may need to consider other elements, i.e. workplace recovery centres, office furniture and other equipment.
These requirements will change from business to business so you need to engage with all members of the senior management team or the directorship and decide what is the best process for you.
Are backups still a necessity?
Yes, I’d still advise you make backups. Backups allow a business to maintain historical data, whereas DR is typically only the most recent data. Backups in some cases, for example SQL or Exchange, are needed to maintain the health of the overall system.
In the timeless words of Benjamin Franklin;
I couldn’t agree more. In summary, always plan for the worst.
If you need help to understand your own requirements, click the button below to tell me more about them and I’ll be happy to discuss your options and advise you on the perfect solution for your business.
