A backup you have never restored

Two numbers nobody has said out loud

Before any discussion of tools and disks, the business has to answer two questions. Until it has, it is impossible to say whether the current backup is adequate, overpriced or dangerously thin. If nobody maintains the system either, settle ownership and access first, which is what the guide on taking over an unmaintained system is about.

• How much data may you lose? If the copy is taken nightly at two and the disk fails at four in the afternoon, you have lost a full working day. Is that acceptable or not?
• How long may you be down? Not how long the restore takes, but how long until people can work again, including sourcing hardware, installing and configuring.

Those two numbers determine everything else. For a manufacturer that cannot issue delivery notes for two days, those two days have a price, and that figure is the budget for protection. Without doing that sum you either overpay for something you do not need, or live for years on a risk nobody consciously accepted.

Three, two, one, and where it is usually broken

The classic rule says: three copies of the data, on two kinds of media, one of them off site. Each part of the rule exists because of a specific way data is lost.

• A copy on the same disk dies with the disk.
• A copy on the same machine dies with the machine, and leaves the building with it if it is stolen.
• A copy in the same building is lost to fire and flood.
• A copy reachable with the same credentials is lost along with the break-in.

A fourth condition belongs on that list today: at least one copy must be immutable or physically detached. A network drive permanently mounted on the server is not protection, because whatever encrypts the server encrypts it too.

What has to be in the copy

The most common mistake is keeping only the database. The database is the most valuable part, but on its own it does not put the system back in service. The copy also needs what makes the database usable:

• Documents and attachments the system keeps as files, outside the database.
• Configuration, environment variables and credentials for other systems.
• Certificates.
• A record of what the system depends on: operating system version, database version, library versions.
• Scheduled jobs that run overnight, which nobody notices until they stop.
• Instructions for putting all of it back together.

The restore test is the only proof

The existence of a backup file proves nothing. The proof is that you restored it and somebody could then work. An honest test looks like this:

1. The restore goes to a separate machine, never over the running system.
2. Time it from the moment the disaster is declared to the moment somebody can work. That is your real recovery time.
3. It is run by someone who did not set the system up, using the existing instructions. If the instructions are not sufficient, they are not finished.
4. Check the contents, not just that it started. Is the last invoice before the copy there, and is it correct?
5. Write the result down, with the date and the measured time.

TEST DATE          2026-10-31
COPY FROM          2026-10-30 02:00
DATA LOST          14 hours of work
RESTORE DURATION   3h 40min
BACK IN SERVICE    5h 10min
RUN BY             not the system's author
PROBLEMS           attachments to orders were missing
RESOLVED           yes, copy extended 2026-11-04

Compare the measured time with how long you may be down. The difference between those two numbers is your real exposure, stated concretely instead of as a feeling. Repeat the test at least twice a year, and after any significant change to the system.

Ransomware changed the maths

The old rules about backups were written for failures: a disk dies, the power goes, somebody drops a table by accident. A failure is random and is not trying to hurt you. An attack is, and it behaves differently.

• An attack usually sits quietly for weeks before it shows itself. By the time it does, even recent copies may already be compromised.
• The attacker deliberately looks for backups and deletes or encrypts them, knowing they are the only thing that saves you from paying.
• Backup credentials are a specific target, so they must not be the same ones used to reach the system.

The practical consequence is that keeping the latest copy is not enough. You need depth of history too, so there is something to go back to if the problem turns out to be three weeks old. And at least one copy has to be one that not even an administrator can delete.

Archiving is not backup

Two things that are constantly confused and serve different purposes. A backup exists so you can get back into service, and as a rule it is overwritten in rotation. An archive exists because you are legally or commercially obliged to keep something, and to keep it readable for years.

Concretely, for anyone trading in Serbia: the Electronic Invoicing Act requires private-sector entities to keep electronic invoices for ten years from the end of the year in which they were issued. A backup rotation that overwrites after thirty days does not satisfy that, however reliably it runs.

The second trap is readability. An archive is only worth having if you can open it in ten years. That means open, documented formats rather than an export from a program that may not exist by then.

The minimum for a firm of twenty to fifty people

No expensive systems, and no pretending you are a bank. This list covers the large majority of the risk in practice:

• Written down: how much data may be lost and how long you may be down, signed off by someone who gets to decide that.
• An automatic daily copy, with no step that depends on anyone remembering.
• One copy off site and one that cannot be deleted.
• An alert when a copy fails. Silent failure is the dangerous case, because it is found only when it is needed.
• A restore test twice a year, written down.
• Recovery instructions that somebody who did not build the system can follow.

Honestly: most firms do not need a more sophisticated backup. They need to check the one they already have. The first restore test nearly always finds something, and that something is nearly always cheap to fix while it is still not a problem.