Backup Is Not Enough: Why Companies Should Document Restore Tests

The backup runs every night. The software reports success. Every status light is green. But what happens when your most important server fails tomorrow morning, and nobody actually knows whether the data can be restored?

That's exactly where one of the most underrated risks in IT security hides: a successful backup is not the same thing as a successful restore.

Many companies invest in backup software, NAS systems, cloud storage, and external drives. But the decisive step is often missing: regularly checking whether the saved data can actually be restored. It gets even more problematic when restore tests do happen occasionally, but are never documented.

Because in a real incident, what matters isn't how many backup files exist. What matters is whether IT systems come back within an acceptable time, and how much data is actually lost in the process.

This article explains why restore tests are essential, what role they play for NIS2 and other security requirements, and how to build a recovery record that actually holds up.

Why a successful backup doesn't guarantee anything

Picture a mid-sized company with 40 employees. Its IT consists of a central file server, a database, several virtual machines, and an industry-specific application.

Every night, the systems get backed up automatically. In the morning, the administrator gets an email:

Backup completed successfully
Status: Success · Data backed up: 850 GB · Errors: 0

Everything looks fine. Until, one day, the central virtualization host fails. The IT team starts the restore. And suddenly, problems appear:

• The backup file can't be fully read.
• The database won't start after the restore.
• A required encryption key is missing.
• The restore takes almost a full working day instead of two hours.
• The application doesn't work because an external dependency is missing.

The backup was technically successful. The restore still failed.

Here's the key difference: backup software usually confirms that a backup job finished. It doesn't automatically prove that every system actually works again after a restore.

Backup, restore test, and disaster recovery: the differences

These three terms get mixed up constantly in day-to-day IT work. They describe different jobs, though.

A backup answers the question: did we save our data? A restore test answers: can we actually recover and use that data? A disaster recovery test goes further still: can we get our critical business processes running again after a major outage?

What a good restore test actually checks

A meaningful restore test doesn't just check whether a file can be pulled out of a backup. It also covers:

• Completeness and integrity of the restored data
• Whether operating systems and applications can actually start
• Database consistency
• User and access permissions
• Dependencies between different IT systems
• The actual time the restore took
• The age of the recovery point used

Only these checks show how reliable an existing backup strategy really is.

Why restore tests should be documented

A restore test without documentation can still be technically valuable. For long-term quality assurance, though, it's barely traceable.

If the administrator who ran it leaves the company, nobody may remember which systems were successfully tested, and what problems came up.

Structured restore-test documentation delivers three key benefits.

Traceability: every test leaves a clear record. Responsible people can see when a given system was tested, and whether the restore succeeded.

Comparability: teams that test regularly can spot trends. If a restore took 45 minutes in January and three hours in October, that's worth investigating.

Audit readiness: documented tests can serve as evidence for internal controls, customer requirements, security reviews, and, where applicable, regulatory obligations.

One thing matters here: documentation alone doesn't prove effective recoverability. It has to be based on a test that was actually performed and verified.

NIS2, GDPR, and ISO 27001: what role do restore tests play?

For companies, restore tests aren't purely a technical best practice. Depending on industry, company size, regulatory classification, and contractual obligations, legal and normative requirements can apply too.

NIS2: business continuity and disaster recovery

The EU's NIS2 Directive (EU) 2022/2555 sets out cybersecurity risk-management requirements in Article 21. Article 21(2)(c) explicitly names backup management, disaster recovery, and crisis management as part of the baseline measures — built on an all-hazards approach that covers more than just cyberattacks.

That creates a clear practical need for companies in scope: backup and recovery concepts can't just exist on paper; their effectiveness should be verifiable. NIS2 doesn't impose a blanket requirement for every company to run a monthly restore test with a specific protocol, though. The actual requirements depend, among other things, on national implementation and the applicable rules.

GDPR: restoring personal data

Article 32(1)(c) GDPR requires, as part of appropriate technical and organizational measures, the ability to restore the availability of and access to personal data in a timely manner in the event of a physical or technical incident. Article 32(1)(d) adds a process for regularly testing, assessing, and evaluating the effectiveness of those measures.

For companies processing personal data, restore tests are therefore an important building block for meeting these requirements in practice.

ISO 27001: recoverability as part of security management

ISO/IEC 27001:2022 and its associated ISO/IEC 27002:2022 controls cover information backup, redundancy, and preparing IT for business disruptions, among other things. Control 8.13 on information backup is especially relevant here: it calls for regular backup copies of information, software, and systems under an agreed backup policy — and explicitly requires that those backups be regularly tested.

Documented restore tests can help demonstrate to auditors that backup requirements are actually implemented and effective. They don't replace a complete information security management system or the other required controls, though.

Note: the specific legal obligation has to be assessed based on the company, the applicable laws, and the relevant scope of review.

RTO and RPO: two numbers every company should know

Assessing recoverability needs measurable targets. The two most important metrics are RTO and RPO.

RPO – Recovery Point Objective: how much data loss is acceptable at most?

RTO – Recovery Time Objective: how long is the restore allowed to take at most?

Here's an example: a company sets an RPO of 30 minutes and an RTO of two hours for its order database. During a test, the database is successfully restored, but it takes three hours and contains data from 45 minutes before the simulated failure. The restore technically worked, but both defined targets were missed.

That's exactly why "restore successful" isn't enough in a test report on its own. It also has to be documented whether the defined recovery targets were actually met.

Running a restore test: a step-by-step guide

A solid restore test doesn't need a huge IT team. Even smaller companies can set up a standardized process.

Step 1: Define the test scope

Choose the system, the recovery point, and the test type — for example, a single file, a database, or a complete virtual machine.

Step 2: Prepare an isolated test environment

Use a separate network or an isolated virtualization environment where possible. Restored systems must not accidentally affect production services, IP addresses, or databases.

Step 3: Start the restore

Run the restore following your existing disaster recovery runbook. Measure the actual duration, and document the credentials, tools, and dependencies needed — without storing secrets in the report itself.

Step 4: Check that it actually works

Start the restored application, and check data consistency, permissions, and core business processes. A successful VM boot alone isn't always enough.

Step 5: Document the result

Record start and end time, the backup used, the RTO/RPO comparison, test results, errors, and evidence. Assess the result against criteria you defined beforehand.

Step 6: Fix issues and retest

Assign any identified problems to a responsible person, set a deadline, and then verify that the fix actually worked.

A practical example: restoring a virtual machine from backup

Say a company runs an important line-of-business application on a virtual machine, for example in a Proxmox environment. The VM gets backed up daily by a central backup solution. For the test, the machine is restored in an isolated environment.

Fictional example for illustration. In a real test, the timestamps, results, and evidence must come from the test that was actually performed.

The report should also record which backup software and backup version were used, who ran the test, and where the technical evidence is stored. It's also important to distinguish between the pure restore duration and the full time until the business process is usable again. If an application technically starts after 47 minutes, but users can't actually work again until 90 minutes in, the RTO assessment has to be based on the right definition of "recovered." For more on AI-assisted administration of a virtualization environment like this, see Manage Proxmox with AI: ChatGPT and Coding Agents as Helpers (Read article).

Interactive restore-test checklist

Use this checklist to check whether a planned restore test covers the most important technical and organizational requirements. Print it out, check items off, and keep it handy:

• Test system and responsible people assigned
• RTO and RPO defined
• Backup and recovery point identified
• Isolated test environment prepared
• Restore fully carried out
• Data integrity and application functions checked
• Measured times compared against RTO/RPO
• Report and technical evidence saved
• Deviations and follow-up actions documented
• Test result reviewed and approved

How often should companies run restore tests?

There's no one-size-fits-all testing frequency. What matters is how critical the systems are, how fast they change, the defined recovery targets, and any applicable regulatory requirements.

These intervals are suggestions, not legal minimums. Additional tests make sense after major changes to backup infrastructure, migrations, version upgrades, new encryption methods, or changes to the recovery concept. Not every test should hit the same file or the same virtual machine, either — a risk-based rotation makes sure that different systems, backup media, and recovery scenarios get checked over time.

The most common restore-test mistakes

Even companies that test regularly often end up with gaps that undermine what the test actually proves.

Mistake 1: Restoring only individual files. A file-level restore can succeed while the full database or application no longer starts.

Mistake 2: Always using the same backup. A working older recovery point doesn't prove that current backups are usable.

Mistake 3: Testing the restore only on the original system. In a real incident, that exact system might be unavailable. Alternative recovery environments need to be considered too.

Mistake 4: Not measuring RTO and RPO. A technically successful restore can still be useless from a business standpoint.

Mistake 5: Passing results along only verbally. Without a traceable report, important information about scope and deviations gets lost later.

Mistake 6: Not following up on failed tests. A documented failure is only actually resolved once the root cause is fixed and the fix has been verified.

Automating restore tests: what's possible?

Modern backup and virtualization platforms can automate parts of a restore test, including:

• Automatically restoring virtual machines in isolated environments
• Checking whether the operating system boots
• Running defined application tests
• Measuring restore duration
• Capturing logs and technical evidence
• Generating standardized test reports

In Proxmox, VMware, Hyper-V, or containerized environments, the achievable level of automation depends on the backup solution in use. Scripts and configuration management tools like Ansible can also help build reproducible test environments and run checks. For how to create clean, reviewed playbooks for this with AI assistance, see Ansible with ChatGPT: Create, Review, and Improve Playbooks (Read article).

One distinction matters here: an automatically passed technical check is not the same as full proof of business usability. A successful boot check, for example, doesn't prove that an ERP system processes every order correctly.

Can AI agents help with restore tests?

AI can be a useful addition. For example, it can help analyze backup logs, spot unusual durations, structure test reports, or compare deviations across several restore tests. For how to analyze log files like that with ChatGPT in a structured way, see Analyze Linux Logs with ChatGPT: syslog, auth.log, and journalctl (Read article). An AI assistant can also help write scripts for recurring checks.

That said, an AI system should never claim on its own that a restore succeeded when no verifiable test results actually exist. AI can help with analysis. The technical proof has to come from the test that was actually performed.

What audit-ready restore-test documentation looks like

A good test report doesn't need to be overly complicated. But it does need to contain all the information needed for a later review and assessment.

That means, at minimum, a unique test ID, the system tested, the test date, who was responsible, the backup source, and the recovery point used. You also need the planned recovery targets, the actual measured values, the functional checks performed, and the assessment of the result.

For failures, document the root cause, the impact, the person responsible, the planned fix, and the retest. Technical evidence — backup job IDs, relevant log excerpts, checksums, or test outputs — should be clearly linked to the report.

The documentation itself needs protection too: proper access controls, traceable changes, a defined retention period, and storage that's hard to tamper with. A PDF by itself isn't automatically audit-proof. What actually matters is the organizational and technical control around the whole evidence process.

What does a restore test cost – and what does skipping one cost?

A restore test takes effort. IT staff need time, test environments consume resources, and some applications need extra configuration.

But the economic case shouldn't stop at the direct cost of testing. If a critical system is down a full extra working day longer than planned, that can mean significant costs from lost production, unprocessed orders, external vendors, and possible contract breaches.

An illustrative calculation that excludes probability of occurrence, restart costs, or further follow-on damage. These figures are not universal averages. They simply show why it's worth comparing testing effort against potential downtime cost realistically.

Frequently asked questions about restore tests

Is a backup worthless without a restore test?

No. Having a backup is always better than having no data protection at all. But without a restore test, it stays uncertain whether the saved data can actually be fully recovered within the time you need, if a real incident happens.

Are restore tests legally required for every company?

There is no blanket legal rule requiring every company to run a monthly restore test. Depending on GDPR, NIS2-related duties, sector-specific rules, and contractual requirements, regular effectiveness checks can still be required.

What has to be in a restore test report?

At minimum: test date, system, responsible people, backup source, recovery point, test steps, functional checks, timing measurements, result, and any deviations. Extra technical evidence is useful for especially critical systems.

How long does restore test documentation need to be kept?

There is no single retention period that applies to every company. The retention period should be derived from applicable legal, contractual, and internal requirements and set out in a retention policy.

Can a restore test be run automatically?

Yes, at least in part. Many backup solutions support automated restore and integrity checks. Whether that is sufficient depends on which technical and business functions are actually being tested.

Is a successful backup integrity check enough?

Not necessarily. An integrity check can confirm that backup data appears technically consistent or readable. It does not necessarily prove that the operating system, database, application, and business process actually work after a restore.

Conclusion: what counts isn't the backup — it's the successful restore

A reliable backup strategy is more than daily backup jobs and green status lights. Companies need to know whether their critical systems can actually be restored, how long that takes, and whether the available recovery points match business requirements.

Regular restore tests give you those answers. Documentation makes the results traceable, comparable, and usable for both internal and external review.

Neither small businesses nor mid-sized IT teams need to roll out a complex enterprise solution right away. A sensible starting point: identify your most important systems, set clear RTO and RPO targets, run a first restore test, and record the results in a structured way.

Because a backup is a promise. Only a properly tested restore shows whether that promise actually holds.

More practical guides on AI agents, automation, and IT security are available on the KI-Buster blog.

Sources and further reading

Editorial review date: October 29, 2026. Primary sources: [1] Directive (EU) 2022/2555 (NIS2), in particular Article 21, [2] General Data Protection Regulation (GDPR), in particular Article 32, and ISO/IEC 27001:2022 together with ISO/IEC 27002:2022 (Control 8.13, Information backup). The example report, checklist, and cost calculation are simplified, original illustrations for demonstration purposes only; no measured productivity gains or conducted project tests are claimed.