Backup vs Disaster Recovery: What Is the Difference?

Why Your Business May Need More Than a Backup

Most businesses understand that important information should be backed up.

Customer records, emails, accounts, documents and business applications can all be difficult—or sometimes impossible—to replace when they are lost.

However, having a backup does not necessarily mean that your business is prepared for a disaster.

A backup helps you recover information. Disaster recovery considers how you will restore the systems, people, processes and technology needed to continue operating.

The two are closely connected, but they are not the same.

A business may have successful backups running every day and still be unable to recover quickly following ransomware, a server failure, a fire or a major cloud outage.

What is a backup?

A backup is a separate copy of your information that can be used when the original data is lost, damaged, deleted or encrypted.

Depending on your systems, backups may protect:

• Documents and folders
• Microsoft 365 emails
• SharePoint and OneDrive information
• Databases
• Servers
• Virtual machines
• Business applications
• Computer configurations
• Website files
• Cloud systems

Backups can be stored locally, in a data centre, within a cloud backup service or across a combination of locations.

The National Cyber Security Centre recommends backing up important business data and keeping copies separate from the computers and systems they protect. It also recommends protecting online backups with two-step verification.

What is disaster recovery?

Disaster recovery is the process and plan used to restore your business technology after a serious incident.

It considers more than whether a file can be recovered.

A disaster recovery plan may explain:

• Which systems must be restored first
• Where backups are stored
• Who is responsible for recovery
• How employees will communicate
• What replacement equipment is available
• How servers and applications will be rebuilt
• How internet and telephone services will be restored
• How employees can continue working
• How long recovery is expected to take
• How customers and suppliers will be informed

Disaster recovery can also involve replicating systems to a secondary location so services can be transferred during an outage.

For example, Microsoft Azure Site Recovery can replicate supported workloads from a primary location to a secondary location. If the primary site becomes unavailable, services can fail over to the secondary location and later fail back when the original environment is available again.

What is the main difference?

The simplest way to explain the difference is:

**A backup protects your information. Disaster recovery protects your ability to operate.**

A backup answers questions such as:

• Do we have another copy of this file?
• Can we recover an accidentally deleted email?
• Can we restore yesterday’s database?
• Is there a clean copy from before the ransomware attack?

Disaster recovery answers broader questions:

• How will employees work if the office is inaccessible?
• How quickly can we restore the main business application?
• What happens if the server has been completely destroyed?
• Can we operate from another location?
• Which system should be restored first?
• Who has the passwords and instructions needed for recovery?
• How long can the business continue without access to its systems?

Microsoft describes backups as copies of data retained for recovery, while disaster recovery can include replication, failover and the processes required to keep business applications available during an outage.

An example of backup without disaster recovery

Imagine that a business has a server containing its accounts, documents and customer management system.

The server is backed up every evening to a cloud service.

One morning, the server fails and cannot be repaired.

The backup may contain all the information needed, but the business still needs to answer several questions:

• Where will the backup be restored?
• Is replacement hardware available?
• Who knows how to rebuild the server?
• How long will the download take?
• Are the application installation files available?
• Are the required licence keys documented?
• Will the restored system work with current computers?
• Can employees work while recovery takes place?

The backup may be completely successful, but the business could still experience several days of disruption.

A disaster recovery plan would have considered these questions in advance and documented how the business should respond.

An example of disaster recovery in action

Now imagine that the same business has a documented disaster recovery service.

Its server is backed up regularly and replicated to an alternative environment.

If the main server fails, the IT provider can:

1. Confirm the cause of the outage.
2. Check that the recovery copy is safe.
3. Start the replicated system.
4. Redirect employees to the recovery environment.
5. Restore any additional information required.
6. Replace or repair the failed server.
7. Move services back when the main environment is ready.

The business may still experience some interruption, but the recovery process is already planned.

The difference is not only having a copy of the information. It is knowing exactly how that copy will be used to restore the service.

What incidents should a disaster recovery plan cover?

Disaster recovery is not only for floods, fires or other physical disasters.

A modern recovery plan should consider incidents such as:

• Ransomware
• Server failure
• Storage failure
• Accidental deletion
• Cyber attacks
• Stolen equipment
• Internet outages
• Power failures
• Cloud service outages
• Corrupted databases
• Office damage
• Supplier failure
• Administrator mistakes
• Compromised Microsoft 365 accounts

Different incidents may require different responses.

A deleted file may take a few minutes to restore. A ransomware attack may require the business to isolate devices, reset passwords, rebuild systems and check that backups do not contain malware before restoring them.

The NCSC advises organisations to confirm that backups and destination devices are clean before restoring information following ransomware.

What is a recovery time objective?

A recovery time objective, normally shortened to **RTO**, is the maximum amount of time a system should remain unavailable following an incident.

For example:

• Email may need to return within four hours.
• The accounts system may need to return within eight hours.
• An archive system may be allowed to remain unavailable for two days.

Not every system needs the same recovery time.

Restoring everything immediately can be expensive, so the business should identify which services are essential and which can wait.

A company that takes customer orders through an online platform may require that platform to recover within minutes. A small internal archive may be less urgent.

Recovery time objectives help the business and its IT provider design a solution that reflects the real impact of downtime.

What is a recovery point objective?

A recovery point objective, normally shortened to **RPO**, is the amount of recent information a business can afford to lose.

For example, if a system is backed up every evening, an incident late in the afternoon could result in most of that day’s work being lost.

An RPO of:

• 24 hours may require one backup each day.
• Four hours may require several backups during the day.
• One hour may require much more frequent protection.
• A few minutes may require continuous or near-continuous replication.

The appropriate target depends on how frequently information changes and how difficult it would be to recreate.

A system containing occasional reference documents may tolerate a longer RPO than a database processing customer orders throughout the day.

Backup frequency does not guarantee recovery speed

A business may assume that frequent backups mean it will recover quickly.

That is not always the case.

Backups may take time to:

• Locate
• Download
• Check
• Decrypt
• Restore
• Rebuild
• Reconnect to applications
• Test before employees can use them

A large server backup could take many hours to restore, even if the most recent copy was created only a few minutes before the failure.

Disaster recovery planning considers both how much information may be lost and how long the full recovery process will take.

Are cloud systems automatically backed up?

Cloud systems can provide strong availability and resilience, but businesses should not assume that every cloud platform provides a complete independent backup of their information.

Retention bins, version history and platform replication can be useful, but they may not protect against every situation.

For example:

• An authorised user may permanently delete information.
• A compromised administrator may remove retention settings.
• Ransomware may encrypt synchronised files.
• Data may be deleted before the problem is noticed.
• A cloud account may become inaccessible.
• Retention periods may expire.
• An application may corrupt synchronised information.

The NCSC advises organisations not to rely solely on the recovery features built into an online service for critical information. It recommends maintaining an independent copy in another safe location or service.

This applies to platforms such as Microsoft 365 as well as traditional servers.

Businesses should understand what Microsoft protects as part of operating the service and what information they remain responsible for protecting and recovering.

What about OneDrive and SharePoint?

OneDrive and SharePoint can provide features such as:

• File version history
• Recycle bins
• Retention policies
• Synchronisation
• Platform redundancy

These features can help recover information in many situations.

However, they should not automatically be treated as a complete disaster recovery strategy.

A full recovery plan should consider:

• How deleted files will be located
• How long information is retained
• Whether previous versions remain available
• How large-scale deletion will be handled
• How permissions and site structures will be restored
• How long a complete recovery will take
• What happens if an administrator account is compromised
• Whether an independent Microsoft 365 backup is required

The correct solution depends on the importance of the information and the length of time the business can operate without it.

Why ransomware-resistant backups matter

Backups are a common target during ransomware attacks.

Attackers know that a business with working backups may be less likely to pay a ransom.

They may therefore attempt to:

• Delete backups
• Encrypt backup filesDisable backup jobs
• Remove recovery points
• Steal backup administrator passwords
• Compromise the backup server
• Change retention settings

A backup stored permanently on the same network as the systems it protects may be accessible to the attacker.

The NCSC states that cloud and on-premises backups are not automatically resistant to ransomware. Its guidance recommends limiting access, making it possible to isolate backup systems and preventing ordinary user devices from modifying protected backup data.

CISA also recommends maintaining offline, encrypted backups of critical information and regularly testing their availability and integrity.

Should backups be stored in more than one location?

Keeping more than one backup copy can reduce the risk of a single failure destroying both the original information and the backup.

For example, a business may use:

• A local backup for faster recovery
• A separate cloud backup for wider disaster protection
• An isolated or immutable copy for ransomware recovery

The local copy may allow information to be restored quickly following a hardware fault.

The cloud or isolated copy may remain available if the building, network or local backup system is affected.

The NCSC recommends considering both an online backup and a separate storage device so one remains available if the other is lost, stolen or fails.

The exact design should reflect the business’s systems, risks and recovery requirements.

What is an immutable backup?

An immutable backup is designed so that saved recovery points cannot be altered or deleted for a defined period.

This can help protect backups if an attacker gains access to the network or compromises an administrator account.

Immutability may prevent someone from:

• Deleting recovery points
• Shortening retention periods
• Overwriting protected copies
• Encrypting existing backup data

Immutability is not a substitute for secure access controls.

Backup systems should still use:

• Multifactor authentication
• Separate administrator accounts
• Restricted permissions
• Security monitoring
• Strong encryption
• Protected management portals

The aim is to make it much harder for a single compromised account or device to destroy every recovery option.

Why backup monitoring is important

A backup job being configured does not mean it is working.

Backups can fail because of:

• Expired passwords
• Insufficient storage
• Software problems
• Network interruptions
• Changed permissions
• New servers not being added
• Devices being switched off
• Damaged backup files
• Retention errors
• Licence problems

If nobody is monitoring the service, a failed backup may remain unnoticed until the business attempts to recover information.

Backup monitoring should confirm:

• Whether the backup completed
• How much information was protected
• Whether the expected systems were included
• Whether recovery points are available
• Whether storage limits are being reached
• Whether failures are being investigated

A good managed backup service should not simply send an automated email. Failed or incomplete jobs should be reviewed and resolved.

Why backups must be tested

A successful backup report proves that information was copied.

It does not always prove that the information can be restored correctly.

Regular recovery tests can identify problems such as:

• Corrupted recovery points
• Missing application data
• Forgotten encryption keys
• Incomplete server configurations
• Undocumented passwords
• Slow internet connections
• Incompatible replacement hardware
• Applications that do not start after restoration
• Employees who do not know the recovery process

CISA recommends regularly testing backup procedures so teams can confirm that information can be restored fully and partially when required.

The NCSC also advises businesses to make sure relevant employees know how to restore backups and understand their responsibilities during an incident.

## What should be included in a disaster recovery plan?

A disaster recovery plan should be practical and easy to follow during a stressful situation.

It may include:

Important systems

A list of the applications, servers, cloud services and devices the business relies on.

Recovery priorities

The order in which systems should be restored.

Recovery objectives

The target recovery time and acceptable data loss for each important system.

Contact information

Details for employees, IT providers, software suppliers, insurers and other important organisations.

Roles and responsibilities

A clear explanation of who makes decisions and who completes each recovery task.

Backup information

Details of what is backed up, where it is stored and how it can be accessed.

Technical documentation

Passwords, licence information, network diagrams, application settings and restoration instructions.

Alternative working arrangements

Plans for employees to work from home or another location if the office is unavailable.

Communication procedures

Instructions for updating employees, customers, suppliers and regulators.

Cyber incident procedures

Steps for isolating compromised systems, preserving evidence and safely restoring services.

Testing schedule

Dates and responsibilities for reviewing and exercising the plan.

The NCSC advises that recovery plans should prioritise essential business functions and the systems and information required to support them.

Disaster recovery vs business continuity

Disaster recovery and business continuity are also related, but they are not identical.

Disaster recovery focuses mainly on restoring technology and information.

Business continuity considers how the wider organisation will continue operating during disruption.

For example, a business continuity plan may cover:

• Employees working from another location
• Diverting telephone calls
• Processing orders manually
• Contacting customers
• Using alternative suppliers
• Accessing emergency funds
• Continuing payroll
• Meeting legal and regulatory obligations

Disaster recovery should therefore form part of the wider business continuity plan.

A restored server is useful, but the business also needs employees, communications, premises and processes to use it.

Does every business need disaster recovery?

The complexity of the plan should reflect the size and requirements of the business.

A small organisation may not need a second data centre or instant server failover.

However, every business should understand:

• Which systems are essential
• What information is being backed up
• How long recovery will take
• How much information could be lost
• Who will manage the incident
• How employees will continue working
• What happens if the office is inaccessible
• Whether backups have been tested

Even a simple written recovery plan is better than attempting to make every decision for the first time during an emergency.

How much does disaster recovery cost?

The cost will depend on:

• The number of systems being protected
• The amount of data
• Required backup frequency
• Required retention
• Recovery time objectives
• Recovery point objectives
• Whether replication is required
• Whether replacement infrastructure is reserved
• Testing requirements
• Regulatory obligations
• Monitoring and support requirements

A business that can tolerate two days of downtime may need a different solution from one that would lose thousands of pounds after an hour.

Disaster recovery should therefore be designed around business impact rather than technology alone.

The starting point is understanding what downtime and data loss would cost the organisation.

Common backup and recovery mistakes

Some of the most common problems include:

• Backing up only some of the business’s information
• Assuming Microsoft 365 is automatically backed up
• Keeping backups on the same network
• Allowing the same administrator account to control everything
• Never testing a restore
• Not monitoring failed backup jobs
• Backing up data but not application configurations
• Having no recovery documentation
• Relying on one employee who knows the process
• Setting recovery expectations without testing them
• Keeping backups for too short a period
• Forgetting to protect new systems
• Restoring malware from an infected recovery point

A regular review can identify these gaps before they become part of a real incident.

Do you need backup or disaster recovery?

Most businesses need both.

A backup gives you the information required to recover.

A disaster recovery plan gives you the people, technology and process required to use that information effectively.

For less important systems, a traditional backup and documented restoration process may be sufficient.

For critical systems, the business may require:

• More frequent backups
• Replication
• Faster failover
• Alternative infrastructure
• Continuous monitoring
• Regular recovery exercises
• A fully documented response plan

The correct balance depends on how long the business can operate without each service.

How can Hamilton Group help?

At Hamilton Group, we help businesses protect their information and prepare for unexpected disruption.

We can help with:

• Cloud backup service
• Microsoft 365 backup
• Server backup
• Computer and laptop backup
• Ransomware-resistant backups
• Backup monitoring
• Recovery testing
• Disaster recovery planning
• Server replication
• Cloud disaster recovery
• Business continuity planning
• Incident response
• Cyber security monitoring
• Backup and recovery reviews

We can review your existing backup service and answer important questions such as:

• What is currently being backed up?
• How frequently are backups running?
• Are failed backups being investigated?
• Can Microsoft 365 information be recovered?
• Are backups protected from ransomware?
• How long would a complete recovery take?
• When was the last recovery test completed?
• What would happen if your main server or office became unavailable?

A backup is essential, but it is only one part of preparing for a serious incident.

Hamilton Group can help you create a recovery strategy that protects your information and helps your business return to normal operation as quickly as possible.

Call us on 0330 043 0069 or book an appointment with one of our experts.