Data backup vs disaster recovery: what does your business need?

If your business lost access to its files, applications or servers tomorrow, how quickly could your team get back to work?

It is a question worth asking before something goes wrong. Your employees might rely on customer records, shared documents, accounting software and communication systems throughout the day. Losing access to just one of these can interrupt several business processes.

Having backups is an important starting point. However, restoring a deleted document and recovering an entire business system are different challenges.

Understanding data backup vs disaster recovery helps you plan for both. You need to protect important information and establish how your business will use it again following a disruption.

What is data backup?

Data backup means creating additional copies of information so it can be recovered if the original becomes lost, damaged or inaccessible.

Depending on your business, that information might include:

• Customer and supplier records.
• Financial documents and accounting databases.
• Emails and shared files.
• Application data.
• Server configurations.
• Information stored on employee devices.

Backups can be stored using different technologies and locations. The right arrangement depends on the systems involved, the sensitivity of the information and how quickly you need to recover it.

Frequency matters too. A backup taken once a day provides a different recovery position from one taken more frequently. Your business needs to understand what could be lost between the latest successful backup and the point when an incident occurs.

What is disaster recovery?

Disaster recovery is the wider process of restoring IT systems and services following a serious disruption.

The trigger does not have to be a major natural disaster. It could be a failed server, a cyber incident, an unsuccessful system change or the loss of access to your premises.

A disaster recovery plan brings together the technology, people and instructions needed to recover. It should explain:

• Which systems take priority.
• Who is responsible for making decisions.
• What equipment or alternative environments are required.
• How information will be restored.
• How recovered systems will be checked.
• How employees and customers will receive updates.

A useful plan is specific enough to follow under pressure. A document that simply says “contact IT and restore the backup” leaves too many decisions until the incident is already happening.

Data backup vs disaster recovery: the key difference

Backup focuses on recovering information. Disaster recovery focuses on restoring the IT services that make that information useful.

Imagine a business loses the server running its order management software.

Its backup contains customer details and recent orders. That is valuable, but employees still need a working environment in which to run the application. They may also need software licences, network access, security settings and connections to other systems.

Until those elements are restored and checked, the business may remain unable to process orders.

Backup and disaster recovery therefore work together. The backup provides recoverable information, while the recovery plan explains how systems and people return to an agreed working state.

How does business continuity fit in?

Business continuity considers how the organisation will keep operating during disruption.

Disaster recovery forms part of that wider picture, but business continuity also covers matters beyond IT.

For example, you may need alternative premises, temporary working arrangements, supplier contacts or a process for communicating with customers.

If your order system is unavailable, business continuity planning might define how staff record urgent requests temporarily. Disaster recovery planning would address how the system is restored.

These arrangements need to connect. Temporary records must eventually be reconciled with the recovered system, and staff need to know when normal processes can resume.

Decide how much data loss you can tolerate

A recovery point objective, usually shortened to RPO, describes the amount of data loss a business can tolerate, measured in time.

Suppose a system fails at 3pm and the latest usable backup is from midday. Recovering from that backup could leave three hours of changes to investigate or recreate.

Whether that is acceptable depends on the system.

A frequently updated order database may need a shorter recovery point than a folder containing reference documents that rarely change.

Set priorities with the people who use each system. Ask what would happen if they lost an hour, a working day or several days of information.

The answers help establish suitable backup requirements.

Decide how quickly systems need to return

A recovery time objective, or RTO, describes how quickly a system needs to be restored.

Different services will have different priorities. Your customer support platform may need to return before an internal reporting tool, for example.

Recovery time includes more than copying information. It may involve obtaining equipment, rebuilding applications, restoring access and checking that everything works correctly.

This is why a successful backup report cannot prove that your business will recover within a particular timeframe.

Treat recovery targets as requirements to test. Your technology, suppliers and procedures must be capable of supporting them.

Identify dependencies before an incident

Business systems rarely operate in isolation.

A finance application might depend on a database server, identity service, internet connection and third-party integration. Restoring the application without those dependencies may leave it unusable.

Create a simple map of what each critical service needs.

Include access to administrative accounts, documentation, encryption keys and supplier support. Consider whether those resources would remain available if your normal systems were inaccessible.

For example, recovery instructions stored only on an unavailable server will be difficult to use. The same applies to supplier contact details held exclusively in an affected mailbox.

Check what your cloud services actually protect

Moving information to the cloud changes how systems are managed, but it does not remove the need to understand recovery.

Check the recovery features included in each service, the information they cover and how long previous versions or deleted items remain available.

Ask practical questions:

• Can we recover an individual item?
• Can we restore a larger collection of information?
• Who has permission to carry out recovery?
• What happens after the available retention period?
• Does the arrangement meet our recovery requirements?

Avoid assuming that file synchronisation provides the same protection as a separate backup. Its purpose is to keep information aligned between locations, which can also spread unwanted changes.

Make recovery testing realistic

A test should demonstrate that your business can recover something useful.

Restoring a sample file is worthwhile, but critical systems may need a more complete exercise. That could involve recovering an application in a controlled environment and asking a business user to confirm that essential tasks work.

Record the steps, timings and problems encountered.

Did the team have the correct credentials? Were any files missing? Did an integration fail? Was an important decision dependent on someone who was unavailable?

The National Cyber Security Centre’s data security guidance recommends regularly testing backups and understanding how to restore files before a real incident.

Give someone responsibility for the plan

Recovery planning needs a clear owner.

Someone should be responsible for checking backup alerts, arranging tests, maintaining documentation and coordinating updates when systems change.

That does not mean one individual must perform every task. It means responsibilities are understood and progress is reviewed.

Revisit the plan when you introduce new software, move premises, change suppliers or significantly increase the information your business handles.

A recovery arrangement designed for last year’s infrastructure may no longer cover today’s operations.

Build a practical recovery plan with Silver Lining

Start by listing the systems your business cannot operate without. Agree how much information you could afford to lose and how quickly each service needs to return.

Then compare those requirements with your current backup arrangements and the results of a recovery test.

Silver Lining’s business data backup services and wider business IT solutions provide a starting point for discussing your requirements.

Speak to Silver Lining about protecting important information and planning how your business would recover from IT disruption.

Frequently asked questions

Does every business need disaster recovery planning?

Any business that depends on IT should understand how it would recover from disruption. The detail and technology required should reflect its systems, risks and operational needs.

How often should backups run?

There is no single schedule suitable for every business. Backup frequency should reflect how quickly information changes and how much recent work the organisation can afford to lose.

How often should a recovery plan be reviewed?

Review it regularly, after recovery tests and whenever significant changes affect systems, suppliers, locations or business processes.