In short and in plain language
A backup is a safety copy of your data. It only counts once you can restore it.
This post shows why you should test the restore. A real emergency is a bad moment for the first try.
Decide how much data you can afford to lose. And how long it may take until the site runs again.
A mirror is not a backup. A mistake is simply copied there too. Each test needs a record with date, length and result.
We test the restore for your website and write the record.
A backup that runs every night is a promise. It is only kept at the moment somebody restores it, and that moment is usually the worst possible time to find out for the first time whether the restore works at all. The gap shows up in the statistics: 90.07 percent (Eurostat) of German enterprises with ten or more employees back up their data to a separate location, yet only 42.51 percent (Eurostat) carry out any ICT security tests. Backing up is close to universal; checking the result is not. This article describes the way back: the two target values that make a restore measurable, how a test run works, what belongs in the record, and where restoring typically fails under pressure.
Key takeaways
- A backup remains an assumption until somebody has restored it. The German IT baseline protection compendium therefore treats the restore test as a basic requirement rather than an optional extra (BSI).
- Two target values make an incident plannable: the acceptable data loss (RPO) and the time to restore service. Without both, every backup setting is guesswork rather than a decision.
- 90.07 percent (Eurostat) of German enterprises with ten or more employees back up to a separate location, but only 42.51 percent (Eurostat) run ICT security tests at all.
- Mirroring is not a backup: in RAID systems the mirrored data is changed simultaneously (BSI), so an accidental overwrite travels straight to the second disk.
- The test does not end when the archive is unpacked. It ends once somebody has opened the restored site, submitted a form and written down the date, the duration and the outcome.
Why the backup is only half the distance
In everyday use, the word backup covers two very different operations. One is writing a copy; the other is putting that copy back onto a running system. The German IT baseline protection compendium separates the two explicitly and states that a complete backup concept covers not only how backups are created but also how they are restored onto the original system (BSI). In practice the second half is rarely rehearsed, because it costs effort and because nothing forces it: a backup job reports success as soon as the copy has been written. Whether the copy is usable is not something it checks.
The distinction sounds academic until it gets expensive. An archive can be complete and still unusable because the database sits in a format the newer server version no longer reads. A backup can run every night and skip one directory for weeks without anyone noticing, because that directory only holds uploaded images. A backup set can be encrypted with the key stored in the same folder. None of these cases shows up while backing up. All three show up on the first restore, and if that first restore is the actual incident, each of them adds hours to the outage.
Backing up data regularly does not automatically ensure that the data can also be restored without difficulty.
The sentence comes from the module's threat section and describes the gap precisely: regularity is a property of backing up, not of restoring. Anyone who wants evidence for the second half needs a separate procedure with its own date and its own result. How that fits into day-to-day operations is closely tied to the rest of the care a website needs; we set out the building blocks in our article on the basics of website security.
What the statistics say about the gap
European business statistics record both sides separately, and the distance between them is the real finding. For 2024 Eurostat reports that 90.07 percent (Eurostat) of German enterprises with ten or more employees use a backup to a separate location, including backup to the cloud. The EU average is 79.23 percent (Eurostat). With security tests the picture flips: in Germany 42.51 percent (Eurostat) run such tests, against an EU average of 34.64 percent (Eurostat). Germany is above average on both counts, yet the distance between backing up and testing is wider here.
| Indicator (survey year 2024) | Germany | EU total |
|---|---|---|
| Backup to a separate location, ten or more employees | 90.07 % | 79.23 % |
| ICT security tests, ten or more employees | 42.51 % | 34.64 % |
| Document on ICT security measures, ten or more employees | 40.25 % | 35.50 % |
| Backup to a separate location, 10 to 49 employees | 88.77 % | 77.09 % |
| ICT security tests, 10 to 49 employees | 36.99 % | 29.76 % |
| ICT security tests, 50 to 249 employees | 62.14 % | 54.07 % |
Breaking the figures down by size shows where the gap is widest. Among enterprises with ten to 49 employees, 88.77 percent (Eurostat) back up to a separate location while only 36.99 percent (Eurostat) test. Between 50 and 249 employees the testing share rises to 62.14 percent (Eurostat). Smaller businesses do not have a backup problem. They have an evidence problem for the second half, and that half is what decides how long an outage lasts.
The damage side explains why this matters beyond the individual case. The German digital association Bitkom puts the damage caused by cyberattacks in the German economy in 2026 at 160.4 to 205.8 billion euros (Bitkom); 58 percent (Bitkom) of the companies surveyed suffered damage from cyberattacks in the past twelve months. At 25 percent (Bitkom) of all companies, attackers encrypted data and offered to release it only against a ransom; the year before the figure was 34 percent (Bitkom). The decline is good news and at the same time an argument for preparation, since Bitkom attributes it explicitly to companies having prepared for attacks of this kind (Bitkom).
Two numbers make an incident plannable
A backup setting cannot be judged until it is clear what it is meant to achieve. Two numbers are enough. The first is the maximum acceptable data loss, known in contingency planning as the recovery point objective or RPO; the German IT baseline protection compendium names it as one of the essential requirements that should be taken into account in the backup concept (BSI). It answers the question of how many hours of work may be lost in the worst case and therefore sets the interval between two backups. The second is the time to restore service: the span from noticing the fault to the point where the website is usable again.
Acceptable data loss
How much work may be lost in the worst case? For a company website that changes monthly, a daily backup is generous; for a shop taking orders it is not. This number sets the interval.
Time to restore
How long may the outage last? This number depends less on the backup method than on preparation: credentials at hand, the sequence written down, a target system available, someone reachable.
Retention depth
How far back does the chain reach? A fault noticed only after two weeks cannot be undone with a seven-day chain. Daily, weekly and monthly restore points cover different kinds of error.
Both numbers are business decisions, not technical ones. They are not dictated by the backup method but by the value of the work created between two backups and by what a day of standstill costs. Only once they are fixed is it possible to say whether a nightly backup is sufficient or whether hourly database snapshots are needed as well. Anyone who cannot name both values has a backup habit rather than a backup strategy.
Where the backup sits is part of the answer
Where restoring breaks down
The failure patterns repeat, and they share one property: none of them is visible while backing up. The following list gathers what blocks or lengthens the way back in practice. Every point can be ruled out within an hour during a test run and is hard to repair under time pressure during a real incident.
- Mirroring is mistaken for a backup. In RAID systems the mirrored data is changed simultaneously (BSI); an overwrite or a piece of malware travels to the second disk with it.
- The key sits with the data. If the backup is encrypted and the key is affected by the same data loss, the data cannot be restored (BSI). The key belongs in separate storage.
- A directory is missing from the pattern. Uploaded files, configuration outside the project folder and scheduled jobs are often outside the backup scope, because they did not exist when it was set up.
- The database is present but inconsistent. A copy taken during active writes can contain half-finished transactions. A dump with a consistent state costs seconds more and saves hours later.
- The instructions exist only in digital form. If the information needed for restoring is available only digitally, it can be lost in a major incident as well (BSI). A printed page with the sequence and the credentials costs nothing.
- Storage space has run out. If the target fills up, the software may overwrite older restore points that are still needed; without monitoring nobody notices.
- Nobody knows what to start with. Under the German IT baseline protection compendium, the backup plan has to define the order in which IT systems and applications are restored (BSI). Without that, everyone starts somewhere else.
It is striking how well this list matches the causes companies name themselves. In the Bitkom survey, 59 percent (Bitkom) of the affected companies attribute the damage to inadequate detection of security incidents and 57 percent (Bitkom) to misconfigured IT systems. These are not sophisticated attacks but blind spots in day-to-day operations, and a restore test is the simplest way to light up several of them at once.
The test is cheaper than the incident
A test run in six steps
A restore test is not a project. It is a fixed sequence repeated twice a year that runs noticeably faster the second time. What matters is that it runs into a separate target and not onto the live system. A test run that overwrites the production website is not a test but a second incident.
- Pick a restore point and record it. Do not take the newest one, take a defined one, for example the day before yesterday. Calculate a checksum and note it so it is later clear which file was actually checked.
- Provide a separate target. An empty environment with the same versions of server software and database. Anything that differs here will differ during a real incident too.
- Restore and measure the time. From the first command to the first successful page view. That duration is the number later compared against the agreed time to restore.
- Compare content by sample. Hold the number of pages, orders or posts against the production state. A figure that is off by an order of magnitude is a finding.
- Walk through the functions, not just the home page. Login, contact form, search, checkout, payment in test mode. This is exactly where missing configuration shows up.
- Write the record and take the target down. Date, restore point, measured duration, measured data loss, open points. Without this step the test remains a memory instead of evidence.
The first two steps can be done with standard tools and need no special equipment. What matters is that the checksum is calculated before unpacking and that the number of files in the archive is compared against an expected value. An archive that is suddenly a third smaller than last time is typically the first visible sign of a skipped directory level.
The final step is the one most easily skipped and most urgently needed. A record does not have to look good, it has to be comparable: the same fields each time, the same format each time, stored somewhere that stays reachable when the website is not. A small file is enough, as long as it puts the date, the measured values and the agreed targets side by side.
{
"date": "2026-09-17",
"occasion": "scheduled half-year test",
"source": "backup from 2026-09-16, 03:15",
"target": "separate test system, identical versions",
"data_loss_measured": "9 h 12 min",
"data_loss_target": "24 h",
"time_to_available": "41 min",
"time_target": "4 h",
"checked": ["home page", "contact form", "login", "checkout"],
"result": "complete",
"open": "media folder missing on first run, backup scope extended"
}Two fields carry the actual result: the measured data loss against the agreed value and the measured duration against the agreed value. Everything else is context. If either number misses its target, the consequence is not a discussion but a change to the interval, the method or the preparation, and the next test run checks exactly that change.
Separation, access protection and responsibility
For a backup to be available during an incident, it has to sit somewhere the same incident does not reach. The German IT baseline protection compendium states this as a basic requirement and additionally demands that backups be protected against unauthorised access, ensuring in particular that they cannot be overwritten deliberately or accidentally (BSI). In practice this means separate credentials, an account without delete rights on the backups, and a second location that is not reachable through the same login as the website.
By contrast, data mirroring via RAID systems is not regarded as a backup, because the mirrored data is changed simultaneously.
The second question is who is responsible, and it is often asked for the first time during the incident itself. Who may request the backup? Who has access to the hosting control panel, who to the domain account, who to the database credentials? That clarification belongs before the incident, not inside it; we describe it in detail in our article on who owns your website, domain, access and rights. If a website is moving anyway, that is the cheapest moment to settle both at once, as described in our article on switching hosts without downtime.
Move the test ahead of the busy season
The legal framework is clearer than many assume
Anyone processing personal data, which includes every website with a contact form, a customer account or a checkout, will find the requirement in the legal text itself. Article 32 of the General Data Protection Regulation lists the ability to restore quickly among the appropriate technical and organisational measures, and in the same paragraph a process for regularly reviewing the effectiveness of those measures (General Data Protection Regulation). Together, the two describe exactly what a documented restore test delivers.
the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident
The regulation names no deadlines and no intervals, because both depend on the risk. It does require an ability and a process, however, and an ability that has not once been tried is hard to evidence. A record with date, duration and outcome is therefore not only useful operationally but also the simplest evidence available. The other points that belong on a website are collected in our GDPR checklist. When rebuilding after an incident, the same rules for redirects and addresses apply as in a planned rebuild, as described in our article on typical relaunch mistakes.
What we take on
We do not set up backups as a checkbox but as a chain with two target values and a piece of evidence. It starts with the question of how much work may be lost, runs through the separation of website and backup location, and ends with a record you can show. What that looks like in day-to-day operations is described under website care; why regular maintenance is more than installing updates is set out in our article on the importance of website maintenance.
Backups with target values
We agree the acceptable data loss and the time to restore with you and set interval, retention depth and storage location accordingly, instead of accepting a default.
Separate test run
The restore point is put back into a separate target, the duration is measured and the functions are walked through. Your live website stays untouched throughout.
Record and sequence plan
You receive a record with date, measured values and open points, plus a short guide listing the order of restoration and the credentials required.
For a website with occasional changes, a daily backup with one test run every six months is usually sufficient. For an online shop taking orders, more frequent database restore points are added and the test run belongs ahead of the high-revenue weeks. Which arrangement fits depends on the two numbers from the beginning, not on the size of the website. An overview of the operating and maintenance work is available on our services page, and if the backup location itself becomes the question, our article on the benefits of web hosting in Germany helps with the assessment.
The next step is a small one
Sources and studies
Related Articles
HTTPS certificates: shorter lifetimes from 2026 onwards
From 2026 the maximum lifetime of HTTPS certificates falls in three steps to 47 days. What that means in operation and how renewal runs without a manual step.
Switching Web Host: Move Site and Email Without Downtime
Change hosting provider without downtime for site and mailboxes: backups, auth code, TTL, parallel operation and a migration schedule from T-14 to T+7.
Website contracts: terms and year-end notice periods
Which contracts sit behind a website, how term, renewal and notice period interact, and why late September is the last date for a clean exit at the year's end.