Backups that hold up: copies, distance and a proven way back

In most companies where we take stock, the backup is running. It often runs reliably and has done so for years, and the daily report says success. What that report confirms, however, is only one thing: data was written. It says nothing about whether the written data is usable, whether all required systems are included, whether the data set can be retrieved without the very software that has just been encrypted, and how long restoring it would take. Those four points decide the outcome in an emergency, and none of them is covered by the green tick.

The findings resemble each other more than one would expect. Databases of the core application are frequently backed up while running, so the files exist but are not internally consistent. The backup target frequently sits on the same network, under the same credentials and on the same power circuit as the source. Mailboxes are frequently missing because they are hosted by a provider and therefore count as somebody else's problem. And there is almost always no record of who starts what, in which order, in an emergency. Day-to-day IT operations keep the systems alive, but preparing for their failure is a separate task.

On top of that, the emergency is rarely spectacular. A project folder deleted by accident, a failed disk, an update of the core application that goes wrong, a device that no longer starts after a power cut: these are the everyday cases. An encryption attack is the exceptional case with the largest impact, but the preparation for the everyday cases is the same. A backup that has never been restored is not a backup but an assumption.

A simple rule has become established as the minimum: several copies of the data on at least two different systems or media, at least one of them at another location (BSI). The rule looks banal, but it answers exactly the three kinds of failure that actually occur in mid-size companies. The second copy protects against a defective medium or device. The other location protects against events that hit the entire room: fire, extinguishing water, burst pipes, burglary, lightning. And the third addition, which has become just as important, protects against an attacker inside the network: at least one copy that is not permanently reachable.

This third requirement is the one most often overlooked, because it is inconvenient. A permanently mounted network share, a constantly attached drive, a backup target using the same credentials as the production system: all of that is convenient, and all of it is encrypted along with the source during an attack. A copy that is permanently reachable shares the fate of the system it is meant to protect. The distance has to be enforced technically rather than maintained by carefulness.

There are several workable routes for the off-site copy: a second company location, a safe deposit box for removable drives, the data centre of a service provider. What matters is less the route than checking two points. First: is the copy encrypted, and is the key kept separately from it in a place that stays reachable in an emergency? Second: how long does it take to retrieve the data from there? With larger volumes, shipping a drive is sometimes faster than the line, and that is worth knowing beforehand rather than discovering during an incident.

A restore test is more than opening a backup file. It means restoring a data set in a separate environment, having the associated application open it, checking the content from a business point of view and measuring the time required. The business check is the part most often missing: it is not the IT staff but the person from the department who can tell whether the last order from the previous day is present, whether prices are correct and whether attachments still hang on the right record.

The interval depends on the importance of the system and on how often it changes. For central systems a test at least twice a year has proven workable, for everything else at least once a year (project experience). In addition, a test belongs after every significant change: after an update of the core application, after switching the backup target, after moving a server and after adding a new system to the scope. Without that trigger, a broken backup chain is only noticed at the next regular test.

The second run shows the real benefit of the test. The fault was not in the backup but in the scope list, and without the test it would have stayed hidden until an incident. That is exactly why the log matters more than the result: date, system tested, state restored, measured duration, who carried out the business check, which deviation occurred and which action follows from it. These logs are at the same time the evidence a customer, an insurer or a supply chain review will want to see.

When every screen is dark in an emergency, it is not the quality of the backup alone that decides, but whether somebody knows what has to be done in which order. A recovery plan is not a thick manual. A few pages describing the sequence are enough, provided they are available outside the company's own systems. Paper in a folder, a printout at management level, a copy at a second location: a plan that only sits on the encrypted network drive is not available at the decisive moment.

This plan is not a special task for IT but part of the process documentation. It is written once, briefly reviewed at every restore test and updated whenever the system landscape changes. For it to be useful, it is enough that a person familiar with the site understands it without needing access to a system that has failed.

The effort for these four steps is manageable and largely one-off. What remains is half a day per test run and a short update whenever something changes. Measured against what several days without order processing cost, this is one of the cheapest safeguards a company can put in place. And unlike many other precautions it delivers a verifiable result: a measured time and a log that can be shown to somebody.

The order matters here. Anyone starting with the technology buys storage and software and still does not know afterwards whether the way back succeeds within the time the business can absorb. Anyone starting with the two figures per workflow has a yardstick against which every later decision can be measured, and it usually turns out that part of the existing means is already sufficient and simply has to be used differently.