Backups in Place – but Business Still at a Standstill: How to Plan a Restore Test

The backup reports “successful”. Even so, the ERP system cannot be started in time after a server failure: the database is there, but a required service is missing. Or the backup is encrypted, and the key happened to be on the failed system.

Situations like these show why a successful backup alone says little about recoverability. A restore test checks whether data and applications become usable again under defined conditions.

The German Federal Office for Information Security (BSI) makes such tests a basic requirement of its IT baseline protection: it must be tested regularly whether backups work as intended, above all whether backed-up data can be restored correctly and within a reasonable time (BSI: module CON.3, requirement A15, in German). What matters is not only whether files can be copied back, but when employees can work again.

What a restore test should actually prove

An integrity check verifies whether stored backup data is technically intact. A boot test shows whether a restored system starts. Both are valuable, but they don't answer every question: for a business process, user sign-in, database, permissions and interfaces must also work.

Backup vendors explicitly distinguish between these levels. Veeam, for example, offers a check of backup integrity and content only, as well as full recoverability testing in which systems are started in an isolated environment and applications are tested (Veeam: SureBackup). With Proxmox Backup Server, verify jobs check whether backups still match their checksums; Proxmox itself additionally recommends regularly testing the restore and boot of backups (Proxmox Backup Server: documentation).

A meaningful test therefore has a concrete goal – for example: “Order processing can be used again with a defined data state.”

Step 1: Define business targets

Before IT plans a test, management and the business departments should answer two questions:

• How much data loss is acceptable at most? This value is called the recovery point objective (RPO). It describes how far back the recoverable data state may be at most in an emergency.
• How quickly must the service be usable again? The recovery time objective (RTO) describes the targeted recovery time.

An example target could be: order processing must be usable again no later than four hours after a failure; at most one hour of changes may be missing. These are planning assumptions, not a general recommendation for every company.

A nightly backup does not match an RPO of one hour. Conversely, a short interval between backups says nothing about how long recovery takes. Also define what “usable” means: is a limited emergency mode enough, or must all interfaces be available? According to the BSI, the order in which systems are restored also belongs in the backup plan (CON.3.A4).

Step 2: Choose a realistic failure scenario

A restore test is only as meaningful as its assumptions.

Start with a business-critical service that can still be tested in a controlled way. Then extend the scope to cover further critical areas. If a cyberattack is simulated, it must also be clear how a clean data state is selected and how the target environment is secured – a successful restore alone does not prove that the cause of an attack has been eliminated.

Step 3: Prepare a suitable test environment

Restored systems must not unintentionally interfere with production: a copy can have the same names, IP addresses or scheduled tasks as the original. Veeam therefore recommends an isolated network for manual tests, in which dependent systems are started in the correct order – for example DNS, then the domain controller, then the system being checked (Veeam: manual verification).

Define which connections are allowed and prevent, for example, real payment orders, outgoing email or write access to production interfaces. The environment also needs sufficient computing power and storage. If the test hardware is considerably slower than the intended recovery environment, this must be taken into account when evaluating the measured times.

Also check access to encryption keys. With encrypted backups in Proxmox Backup Server, data is inaccessible without the right key; if the key was only on the failed system, no restore is possible. The vendor therefore recommends, among other things, keeping a paper copy of the master key in a safe place (Proxmox Backup Server: encryption). For elevated protection needs, the BSI also recommends protecting the keys used with a separate backup (CON.3.A13).

Step 4: Measure the entire recovery

Start timing at the previously defined beginning of the scenario – and don't just record the data transfer. Recovery can include:

• reaching the responsible people and assessing the incident,
• selecting the backup state and providing access,
• preparing target resources,
• restoring systems and data,
• starting services in the required order,
• checking technical and functional operation,
• releasing operations.

Fictitious example: an application has an RTO of four hours. In the test, preparation takes 30 minutes, the restore 110 minutes, starting dependent services 40 minutes and functional acceptance 35 minutes. That adds up to 215 minutes, or 3 hours and 35 minutes. The target is met under the tested conditions – but with only 25 minutes to spare.

Whether that is enough depends on the scenario. If, for example, all credentials were prepared in advance although they would first have to be obtained in an emergency, the measurement only partly reflects a real outage.

Step 5: Have the business department check the result

The technical check should be complemented by a functional acceptance. For an ERP system, the business department could open an order, check line items and create a test document. For a file store, spot checks from different folders make sense: can the files be opened, and do the right people have access?

Predefined test steps are particularly meaningful – “looks fine” is not a reproducible acceptance. Also document the actual data state: an application can start without errors and still contain an older state than the agreed RPO allows.

What belongs in the test report?

A compact report makes results comparable and prevents identified defects from being left unresolved. Use this structure as a template:

A failed test is a useful result – if the cause is fixed and then tested again.

How often should businesses run restore tests?

There is no interval mandated by law or by the BSI; the IT baseline protection requires regular tests. BSI Standard 200-4 on business continuity management gives, as an example, a functional test at least once a year for processes and resources with a recovery time of less than 24 hours (BSI Standard 200-4, in German). Criticality, rate of change, technical complexity and previous test results should determine the frequency.

As an example starting point that has to be adapted to your own environment:

• check selected files or individual backup states monthly,
• restore an important service including its dependencies quarterly,
• practice a more extensive recovery under a defined emergency scenario annually,
• retest specifically after significant changes, such as a migration or a new backup solution.

Automated checks can support the process. However, they do not replace all functional checks and organizational exercises.

Conclusion: backups with proven value

A reliable backup concept combines backup, protection of backups and practical recovery – as the 3-2-1 backup rule also provides with its extension to tested restores. What matters is whether your business-critical data comes back in time and in usable form. The same applies to cloud data, as our article on backing up Microsoft 365 shows.

With Backup as a Service, oneCorp supports companies with setup, monitoring and recovery; regular restore tests can be added (Backup as a Service). Together we define which systems take priority and what a test should prove.

As of October 2026. Requirements cited from the BSI IT-Grundschutz Kompendium, Edition 2023, module CON.3. The BSI is gradually replacing the Kompendium with “Grundschutz++”. Test intervals in this article are planning suggestions, not requirements.