Your Backup Says 'Successful'. Could You Actually Recover?

Most backup systems send a report every morning: green ticks, "completed successfully", perhaps a percentage. It's reassuring. But it answers a narrower question than most business owners think.

A successful backup job tells you that data was copied. It doesn't tell you whether everything the business needs was included, whether the copy can actually be opened, or how long it would take to get people working again. Those are recovery questions, and only a restore test answers them.

This article is about that gap: how to prove, rather than assume, that your business could recover.

The video asks the questions that matter. The rest of this article explains how to get honest answers to them.

Backup and recovery are not the same thing

A backup is a copy of your data. Recovery means getting systems and data back into a usable state, in the right order, quickly enough that the business can carry on.

The main security frameworks treat these as separate steps. The US National Institute of Standards and Technology's Cybersecurity Framework (NIST CSF 2.0) says backups should be "created, protected, maintained, and tested". It then adds recovery requirements of its own: backups should be checked before they are used for a restore, and after a restore, "the integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed" (NIST CSF 2.0).

The US Cybersecurity and Infrastructure Security Agency (CISA) advises organisations to "regularly test the availability and integrity of backups in a disaster recovery scenario" (CISA). The UK's National Cyber Security Centre (NCSC) says to "regularly test that it is working as expected" (NCSC).

None of them treat a completed backup job as proof that recovery will work. Testing is a separate step.

The three questions a restore test answers

1. Is it all there? Were all the systems and data the business depends on actually in scope? Common gaps include a folder excluded years ago, a new server that was never added, a line-of-business database backed up as files that won't restore cleanly, and Microsoft 365 data that everyone assumed was covered.

2. Does it open? Restored files should open. The accounting system should start and show the latest transactions. A restored mailbox should be complete. A copy that exists but can't be used is not a backup you can rely on.

3. How long would it take? This means the time from starting the restore until people can work again. It's the question most businesses have never measured, and the one that matters most on the day.

RPO and RTO in plain business language

These two terms come up in every serious conversation about recovery. NIST defines them (RPO, RTO), but in business terms they are simple:

• Recovery Point Objective (RPO): how much recent work could we afford to lose? It is measured in time. If a system is backed up once a night and fails late the next afternoon, most of a day's work may have to be re-captured.
• Recovery Time Objective (RTO): how long can this system be down before it really hurts? This covers the whole recovery, not just the time the backup software reports.

These are business decisions, made system by system. They are not IT settings, and there is no universal right number. Your accounting system, your email and a shared archive folder will have very different answers. NIST's contingency planning guidance places these targets in a business impact analysis, alongside the longest outage the business could tolerate (NIST SP 800-34).

An illustrative example

The figures below are invented to show how the ideas fit together. They are not targets for any business.

A 25-person distribution company backs up its accounting database once a night at 22:00. The server fails at 16:00 the next day. The newest copy is from 22:00 the night before, so about 18 hours of invoices and payments would have to be re-captured. If management decides it can only tolerate losing about an hour of work, nightly backups don't meet that target.

The owner says the warehouse can run on paper for one working day before orders start being lost. The IT recovery has to fit inside that window, with time left to re-capture and check the data.

A restore test shows that rebuilding the server takes 9 hours, and re-capturing the missing data takes another 3. That makes 12 hours in total. It fits within a working day only if the failure happens early in the morning. The test result, not the backup report, is what reveals this.

The options are then clear. The company could back up the database more often, find a faster way to restore it, or accept the risk in writing. Any of these is a legitimate decision. Not knowing is not.

Backup, disaster recovery and business continuity

These terms are often used interchangeably. They mean different things.

• Backup is the copies.
• Disaster recovery is the plan and the capability to get IT systems back after a major failure. NIST describes a disaster recovery plan as "a written plan for recovering one or more information systems" after a major hardware or software failure or the loss of a facility (NIST).
• Business continuity is how the business keeps operating while that happens: people, manual workarounds, communication with clients and suppliers. NIST describes it as how business processes "will be sustained during and after a significant disruption" (NIST).

A South African example shows the difference. When ransomware encrypted the Department of Justice and Constitutional Development's information systems in September 2021, the department said it had moved to manual processes, including manual recording equipment, while its systems were unavailable (Department of Justice). That is continuity: keeping essential work going while recovery happens.

Ransomware changes the question

A backup protects you from a failed disk or a deleted file. Ransomware is different, because attackers go looking for your backups.

CISA warns that "many ransomware variants attempt to find and subsequently delete or encrypt accessible backups". The NCSC has described ransomware encrypting connected USB and network drives holding backups, and compromising connected cloud storage that held backups (NCSC).

This has happened in South Africa. After the National Health Laboratory Service was hit by ransomware in June 2024, its official statement said that "sections of our system have been deleted, including in our backup server and this will require rebuilding" (SAnews).

What this means in practice:

• Keep at least one copy out of the attacker's reach. That means offline, or immutable. An immutable backup is designed so that it can't be changed or deleted for a set retention period, even by an account with administrator access. Microsoft's guidance describes immutable and/or offline or off-site backups as the "Strongest Protection" (Microsoft Learn).
• Know how far back you can go. Retention matters. You need a clean copy from before the problem started, not just last night's.
• Get alerted when something changes. The NCSC's principles for ransomware-resistant cloud backups include alerts when backups stop or retention settings change (NCSC).
• Restore carefully. The NCSC advises scanning backups for malware before restoring files, so you don't restore the problem along with the data.
• Protect the recovery instructions. Microsoft notes that attackers target recovery documentation too. Keep your restore procedure somewhere it won't be encrypted along with everything else.

For the wider picture of how attacks start and the layers that stop them, see our guide to ransomware protection in South Africa.

Microsoft 365: retention is not the same as backup

Many businesses assume Microsoft 365 data is backed up because it's in the cloud. Microsoft's own documentation gives a more careful picture:

• Deleted items in Exchange Online are kept for 14 days by default, and this can be extended to a maximum of 30 days (Microsoft Learn).
• Natively, Exchange Online "does not provide a way to perform a traditional backup of mailboxes", and point-in-time restoration of mailbox items is out of scope for the service (Microsoft Learn).
• Deleted SharePoint sites are kept for 93 days (Microsoft Learn). A departed user's OneDrive is kept for 30 days by default, although this can be changed (Microsoft Learn).
• Microsoft sells Microsoft 365 Backup as a separate, pay-as-you-go product (Microsoft Learn). That in itself shows that native retention and backup are not the same thing.

Whichever product protects your Microsoft 365 data, the same test applies: restore a mailbox, a SharePoint site and a OneDrive folder, and check them. There's more on this in our article on Microsoft 365 backup.

Which restore tests to run

Different tests prove different things. A sensible programme uses several of them.

The tabletop exercise is a discussion rather than a technical test. NIST describes it as people "discussing simulated system problems and their responses". It is often the cheapest way to find the gaps nobody has written down.

Whatever you test, write it up: what was restored, whether it worked, how long it took, and what needs fixing. A test that isn't recorded is hard to learn from and impossible to show anyone.

How often should you test?

No authoritative standard sets one right frequency for every business. NIST leaves the frequency to each organisation to define, and its contingency planning guidance gives "yearly" only as an example. CISA's Cross-Sector Cybersecurity Performance Goals (2022 checklist) set a minimum: backups "tested on a recurring basis, no less than once per year" (CISA). That is a baseline for US critical infrastructure. It is a floor, not a recommended target.

The monthly and quarterly schedules you'll see recommended online are opinions. Some are sensible, but they are not standards. A better approach is to decide the frequency per system, based on:

• how critical the system is. The systems you can't trade without deserve more frequent tests.
• how quickly its data changes. A busy transactional database changes more than a document archive.
• how tight your recovery targets are. A one-hour RTO needs more evidence than a one-week RTO.
• your risk. Consider exposure to ransomware, the age of the systems, and any past incidents.
• material change. Test after a new server, a migration, a new line-of-business application or a change of backup product, whatever the schedule says.

Decide, write it down, and keep to it.

What evidence should you ask your IT provider for?

You don't need to be technical to ask these questions, and a good provider will be able to answer most of them from records they already keep.

• What is backed up, and what isn't. A list of the systems, data and Microsoft 365 workloads in scope, and anything deliberately excluded.
• Recovery targets. A written RPO and RTO for each critical system, agreed with management.
• The latest restore-test results. When the test was done, what was restored, whether it worked, how long it took, and what was fixed afterwards.
• Backup success and failure history. The last 30 to 90 days, and how failures were resolved.
• Who gets the alerts. Who is notified when a backup fails or stops, and what happens next.
• Isolation. Where the copies are held, whether at least one is offline or immutable, and who is able to delete backups.
• Retention. How far back you can restore each type of data.
• Encryption and access. Who holds the encryption keys, and how you would get your data back if your provider weren't available.
• The recovery runbook. The written restore procedure, and where it is kept.
• Microsoft 365 coverage. Whether Exchange, SharePoint, OneDrive and Teams are backed up independently of Microsoft's native retention.

If the answer to "when did we last do a full restore?" is a long pause, that is your most important finding.

What POPIA actually says

It's common to see claims that POPIA "requires backups". The Act doesn't say that, so it's worth being precise.

Section 19 of the Protection of Personal Information Act requires a responsible party to secure the integrity and confidentiality of personal information. It must take "appropriate, reasonable technical and organisational measures" to prevent, among other things, "loss of, damage to or unauthorised destruction of personal information". Section 19(2)(c) requires the responsible party to "regularly verify that the safeguards are effectively implemented" (POPIA).

POPIA does not mention backups or restore testing. Our reading is practical rather than legal. If backups are one of the safeguards you rely on to prevent loss of personal information, a restore test is a sensible way to check that the safeguard actually works. That is our interpretation, not wording in the Act. For your specific obligations, speak to your legal adviser.

Separately, if an incident such as ransomware involves personal information being accessed or acquired by an unauthorised person, section 22 requires the responsible party to notify the Information Regulator and the affected people.

Where to start

You don't need a big project to close most of this gap. Three steps will tell you where you stand:

1. List the systems the business can't operate without, and agree an RPO and RTO for each with the people who run the business.
2. Ask your IT provider for the evidence above. Pay particular attention to the date and result of the last restore test.
3. Run one real restore of your most important system in an isolated environment, and time it. Then compare the result with the target you just agreed.

If you'd rather have someone independent look at it, see how we approach backup and disaster recovery, or request the complimentary review below.

Sources and further reading

• NIST Cybersecurity Framework 2.0: PR.DS-11, RC.RP-03 and RC.RP-05
• NIST SP 800-34 Rev. 1: Contingency Planning Guide
• NIST glossary: Recovery Point Objective and Recovery Time Objective
• CISA #StopRansomware Guide
• CISA Cross-Sector Cybersecurity Performance Goals checklist
• NCSC: Mitigating malware and ransomware attacks
• NCSC: Offline backups in an online world
• NCSC: Principles for ransomware-resistant cloud backups
• Microsoft Learn: Backup and recovery plan to protect against ransomware
• Microsoft Learn: Exchange Online and mailbox backup
• Microsoft Learn: Microsoft 365 Backup overview
• Protection of Personal Information Act 4 of 2013
• SAnews: NHLS hit by cyber attack (June 2024)