A Backup Is Not a Recovery Plan Until Somebody Tests It

01

Start with the business service, not the backup product

The backup dashboard is green. Every scheduled job has a tick beside it. The monthly report says the company is protected.

That is reassuring, but it is not the same as knowing the business can recover.

A successful job may still contain the wrong folders, an incomplete database, a damaged archive or data that is too old to be useful. The copy may depend on credentials nobody can access during an incident. It may sit in the same cloud account an attacker has compromised. The team may know how to restore one file but not how to rebuild the application that makes the data usable.

Backups matter. The National Cyber Security Centre describes regular backups as an essential part of recovery and advises organisations to know how to restore them and test that they work. The harder question is whether the backup system has been designed around the business that must continue when something goes wrong.

This article explains how backup monitoring, restore tests, recovery targets and clear ownership turn stored copies into a recovery capability.

Imagine an established service business with a customer portal. Customers upload documents, staff review cases, managers see progress and finance receives approved values.

The visible application is only one part of that service. Recovery may also depend on:

• the main database;
• uploaded documents held in object storage;
• application files and versioned source code;
• server and network configuration;
• encryption keys and secret values;
• user identities, roles and access rules;
• scheduled jobs and message queues;
• DNS records and domain access;
• third party integration settings;
• a clear set of recovery instructions.

Backing up the database while forgetting the uploaded documents would produce a portal full of records that point to missing files. Keeping the files without the encryption key could make them unreadable. Saving the application code without its environment and configuration could leave the team with all the ingredients and no recipe.

The first useful question is not, "Do we have backups?" It is, "Which business services must we be able to restore, and what does each one depend on?"

02

A completed job proves less than people think

Backup software usually reports whether a scheduled process started, copied data and finished without a known error. That is useful operational evidence.

It does not prove all of the following:

• the correct data was selected;
• the copied data is complete and internally consistent;
• the retention period is long enough to reach a clean version;
• the copy is protected from the same account or attack as production;
• the credentials and keys needed for recovery still work;
• the team can rebuild the surrounding application;
• the restore will finish within an acceptable time;
• the restored service will behave correctly for its users.

Monitoring therefore needs to look beyond a simple pass or fail result. A backup that is suddenly much smaller than usual may have excluded a directory. A database backup that finishes unusually quickly may deserve investigation. A destination running out of capacity may silently shorten retention. A job that has not produced a new recovery point for two days matters even if the last recorded run was green.

Good monitoring asks whether the backup is recent, plausible, protected and usable.

03

Decide how much data and downtime the business can tolerate

Two recovery targets help turn a vague promise into a decision.

The recovery point objective, usually shortened to RPO, is the maximum amount of recent data the business is prepared to lose. If the portal can tolerate losing no more than one hour of work, a backup that runs once each night cannot meet that target on its own.

The recovery time objective, or RTO, is the maximum acceptable time between an interruption and restoration of the service. A four hour target creates a different technical and operational plan from a target of two working days.

These numbers should come from the business impact, not from whichever schedule is easiest to configure. Ask what happens while the service is unavailable. Can staff work from a controlled manual process? Will customers miss a contractual deadline? Does finance lose the ability to issue invoices? Will recent submissions need to be recreated?

Not every system needs the same target. A customer portal may need faster recovery than an old archive. Treating every database and folder as equally urgent increases cost without necessarily reducing the most important risk.

04

Monitor the health of the backup, not just the schedule

A useful monitoring routine should make exceptions visible to a named person. Depending on the system, that may include:

• whether the expected backup ran at the expected time;
• the age of the latest successful recovery point;
• backup size and record count compared with a normal range;
• duration compared with previous runs;
• warnings, retries and partially completed jobs;
• available capacity at the destination;
• retention and deletion behaviour;
• replication to a separate location or account;
• encryption status and access controls;
• evidence from the latest restore test.

The monitoring platform is only part of the answer. An alert in a shared inbox can sit unread for days. A warning sent only to the person who is on holiday has not created resilience. A supplier saying it monitors the system does not tell the business who decides whether a failure is acceptable.

Give each important backup an owner, a response time and an escalation route. Record what happens when a job fails, when a recovery point becomes stale or when storage is close to its limit. The process can be simple, but it cannot be imaginary.

05

Keep a copy outside the likely failure

Another copy in the same place is useful for some mistakes. It may not survive the incident that matters.

The NCSC warns that on premises and cloud backups are not resistant to ransomware by default. Attackers may target backup systems early because deleting recovery copies increases pressure on the victim. The same administrative account, network access or synchronisation process that makes backup convenient can also connect production and backup failure.

A common starting point is to keep multiple copies across different storage locations or technologies, with at least one copy isolated from normal production access. The exact design depends on the business, but the separation should survive the realistic event being planned for.

That may mean an offline copy, immutable storage, a separate cloud account, a backup service with protected deletion controls or an offsite system managed through different credentials. Two copies inside one removable drive or one cloud tenancy are not independent simply because they appear in different folders.

Isolation brings its own responsibilities. The team still needs secure access, suitable encryption, documented retention and a recovery route that works when normal identity systems are unavailable.

06

Restore tests provide the missing evidence

A restore test turns assumption into evidence.

It does not always need to begin with a dramatic full disaster exercise. Tests can build in scope:

• restore one recently deleted file and check its contents;
• restore a database into an isolated environment and verify key tables and record counts;
• rebuild a non production application from code, configuration and backups;
• restore a complete service, run agreed checks and record the elapsed time;
• simulate the loss of normal administrator access and use the emergency recovery route.

The test should prove more than the ability to download an archive. Open the files. Connect the application. Sign in with a test account. Run a small set of important business actions. Check that documents match their records, scheduled processes resume safely and integrations do not send live messages from the test environment.

Record what was restored, which recovery point was used, who performed the test, how long it took and what failed. A restore that eventually works after six hours of undocumented investigation may still miss a two hour recovery target.

The ICO says organisations processing personal data should be able to restore access and availability in a timely manner after an incident and should regularly test the effectiveness of their security measures. That makes restore testing more than a technical preference when personal data is involved.

07

Recovery often fails around the data

The backup itself may be healthy while the surrounding recovery path is broken.

An application can depend on an old database version that is no longer available from the normal package repository. A private container image may have been deleted. The encryption key may exist only in the unavailable production account. The domain may be registered under a former employee's email address. The runbook may assume that one developer remembers a command they have not used for three years.

This is why source code, infrastructure definitions, configuration templates and recovery instructions belong in the continuity conversation. Some secrets should not be copied into ordinary documentation, but the route for obtaining them must be tested and available to the right people.

Recovery also needs an order. Restoring the reporting dashboard before the identity service will not help users sign in. Bringing integrations online before the database has been checked can repeat or lose messages. The runbook should reflect technical dependencies and the order in which the business needs services.

08

Read a backup report like an operator

A report should lead to a decision, not simply provide comfort.

A useful report shows exceptions, trend and evidence. A long list of green jobs without context can hide the one missed service the business depends on.

09

Use a rhythm that matches the risk

There is no universal test schedule for every system. A busy transactional platform and a low change archive do not need identical treatment.

A sensible operating rhythm might include automated checks after every backup, a weekly review of exceptions and storage trends, regular sample restores and a wider service exercise several times a year. More critical or rapidly changing services may need more frequent testing. A small, stable internal system may justify less.

The important part is that the frequency follows the recovery targets and rate of change. Review the routine after infrastructure changes, major releases, supplier changes, security incidents and failed tests.

Do not let successful automation remove human ownership. The system can detect that a job failed. A person still needs to decide what the missed recovery point means, whether an immediate rerun is enough and who should be told.

10

Ask suppliers for recovery evidence

Cloud hosting, managed backup and software as a service can reduce the work a business performs itself. They do not remove the need to understand the recovery boundary.

Ask suppliers:

• exactly which data and configuration they back up;
• how often recovery points are created;
• how long versions are retained;
• how backup deletion is protected;
• whether copies sit in a separate region, account or system;
• how failed jobs are monitored and escalated;
• how often restore procedures are tested;
• what evidence customers receive;
• how long a full recovery is expected to take;
• how the business can export data if the service becomes unavailable.

A service level agreement about platform availability is not automatically a promise that accidentally deleted customer data can be restored. The contract, architecture and shared responsibilities need to say what actually happens.

11

A backup is a stored copy; recovery is an ability

The imagined customer portal needs more than a nightly database file. It needs the documents, keys, application, configuration, access and instructions that make the data useful. It needs recovery targets based on business impact. It needs monitoring that spots stale or unusual copies. It needs isolated backups that can survive the same incident as production. Most importantly, it needs proof from real restores.

A green tick is a good start.

Confidence comes from knowing what was captured, who owns the alert, how the service will be rebuilt and how long the tested recovery actually takes.

If an important business application has backups but nobody can show when the full service was last restored, I can help map its dependencies, review the current backup and monitoring approach and plan a recovery test around the way the business really works.