← Back to news 02.10.2026 Series: Quiet work, part 1

To the ones who test the restore

Quiet work, part 1: a backup that reports green every night says nothing about whether anything can be brought back from it. Only someone who tries knows, on a Tuesday afternoon, without cause and without an audience. Why IT-Grundschutz requires exactly that as a basic requirement, and why hardly anyone notices it anyway.

October is European Cybersecurity Month. We are taking it as the occasion for a new Friday series: Quiet work, about hands-on tasks that appear in no report and without which nothing works. Part 1 is for the ones who test the restore.

The scene is unspectacular. A Tuesday afternoon, no incident, no audit announced. Someone in IT operations takes a backup from last week and restores it onto an empty server. Not a single file, but the whole system, with database and application. Then they measure how long it took and check whether the application actually starts afterwards.

What the green status does not say

The backup software reports "successful" every night. That means the data was written. It does not mean it can be read, that the database is consistent afterwards, that the key for the encrypted backup still exists, or that the restore succeeds within a time the business can absorb.

IT-Grundschutz describes exactly this gap as a threat of its own in module CON.3 Backup concept (our translation):

"Backing up data regularly does not automatically guarantee that it can also be restored without problems."

And it derives a basic requirement from it, one every institution must meet, CON.3.A15 (our translation):

"It MUST be tested regularly whether the backups work as intended, above all whether backed-up data can be restored flawlessly and within a reasonable time."

"Within a reasonable time" is the part people tend to skip. A backup from which accounting can be restored in four days is technically intact and practically worthless if operations stop after one day.

Why nobody sees it

A successful test has no result anyone notices. Nothing happens, and that was the point. A failed test, by contrast, is uncomfortable: it shows that a backup everyone relied on does not hold. Whoever runs it brings either no news or bad news. Neither is often thanked.

On top of that, the test takes time that is in no ticket and needs a server that is not supposed to be doing anything else. So it gets postponed until the emergency takes care of it. By then it is no longer a test.

The module names a second trap: if the restore instructions exist only in digital form, they can be lost as well in a major incident such as ransomware. Whoever tests notices, because they actually need the instructions while doing it.

To them

To the ones who, on an ordinary afternoon, restore a backup, write down the minutes and file the result, even when it is bad. They are the reason someone can say how long it takes in an emergency instead of guessing.