An untested backup is not a backup
Almost every business that has lost data had backups running. The backup job was green. What nobody had was a restore they had actually performed — and those are not the same thing.
The blog is written in Serbian. This is the English translation.Serbian version
A backup is a claim; a restore is evidence
A backup job reporting success tells you that a file was written. It does not tell you that the file contains what you think it contains, that it can be opened, that the encryption key still exists, or that the system it came from can be rebuilt around it.
The only way to know any of that is to restore it. Until someone has, a backup strategy is an assumption with a scheduler attached.
How this fails in practice
- The backup covers the database but not the files the application expects beside it, so the restore runs and the system still does not work.
- It has been silently failing for months. Nobody reads the success emails, so nobody noticed the absence of one.
- It is on the same machine, or the same account, as the thing it protects. Ransomware and a deleted account both take the copy with the original.
- The restore works, but takes three days. That may be fine for an archive and fatal for the system your business runs on.
- The one person who knew the procedure has left.
Two numbers worth deciding on purpose
Before any technical discussion, the business side has to answer two questions. How much data can you afford to lose, measured in time — an hour, a day, a week? And how long can you be down while it comes back?
Those two numbers determine everything about the design, and they are business decisions, not IT decisions. Answering them honestly is also the fastest way to find out that the current arrangement was never sized for the answer.
A test that is worth running
The exercise is deliberately blunt: restore to somewhere that is not production, from the backup as it exists today, following written steps, and then have someone who uses the system confirm it works. Time it. Write down what was missing.
The first attempt almost always surfaces something — a missing configuration file, a credential nobody recorded, a step that only worked because one person knew a detail they had never written down. That is the point. Finding it during a test costs an afternoon. Finding it during an incident costs whatever the outage costs.
Then make it a habit
Once a restore works, the remaining risk is drift: systems change, and a procedure that worked in March may not work in November. A restore test on a schedule — even a small one, even once a quarter — is what keeps the answer current.
If you do not know when your backup was last restored, that is the place to start. We can run that test with you and tell you plainly what it found.