Security

How long until you are back up? The question nobody tries to answer

A backup never restored is a file you trust. The two questions that matter are how long it takes to be operational again and how much data you lose: they must be declared per service and measured with periodic drills. A proper restore drill also verifies that data protections come back on, not just that the data is there.

29 May 2026 · 8 min read · updated on 27 Aug 2026

"We do take backups" is the answer we get in every company. It is nearly always true. The next question — "when was the last one restored, and who checked the data was complete?" — gets silence instead, or a "we should try that".

In that silence lies the difference between having copies and having a plan. A backup never read back is not a guarantee: it is a file you trust, and trust cannot be verified on the day you need it.

The two questions that matter

Business continuity comes down to two numbers, and neither is technical. They must be decided by whoever knows the cost of downtime, not by whoever administers the servers.

How long can we be down? Not "how long would we like": how long the company genuinely holds before the damage turns serious. For an online shop it is hours; for a professional firm it may be a day; for a connected production line, minutes.
How much data can we lose? If the last copy is from last night and the failure happens at five in the afternoon, you have lost a working day. Is that acceptable? If yes, nightly backups are enough. If not, you need more frequent copies, and they cost more.

These are the same two questions technicians name with acronyms. Call them what you like: without a written answer for every important system, everything else is improvisation dressed as procedure.

A number never verified is a wish. A number that came out of a drill is a commitment.How we treat recovery objectives

What a proper restore drill checks

Restoring doesn't mean watching a file return to its place. It means verifying, in this order:

That the archive is intact, before touching anything: a truncated file is discovered now, not halfway through an emergency.
That all the data is there. Counts that add up, latest transactions present, attachments reachable — not just the database, the linked documents too.
That the protections come back on. The check almost nobody performs, and the one that actually saves you: if the restore brings the data back with the wrong permissions, everything works and everyone sees everything.
How long it took. The stopwatch is part of the drill: it is the only way to know whether the number you declared is true.

On a shared platform we look after, the third point is automated in a precise way: after the restore the system connects the way the application would, without declaring whose data it is looking at, and verifies that no row comes back. Counting the rules would not be enough: if the account had returned with the wrong privileges the count would look identical, and every customer would silently see everyone else's data.

The golden rule: never over the live one

A restore drill must never touch the system in use. You rebuild onto a throwaway database or environment, verify, and drop it. The same applies to a real restore: create a new environment and move onto it, rather than overwriting the existing one.

The reason is simple: if halfway through you realise that copy is no good, having overwritten means you have lost what was there too. It is the kind of mistake you make only once.

Three things that make a backup useless

It sits in the same place as the data. A copy on the same server, or in the same room, protects against human error and nothing else — not fire, not flooding, not an attack that encrypts everything it can reach.
It is reachable with the same credentials. If whoever gets into the system can also delete the copies, the copies are part of the problem. You need copies the system itself cannot alter.
Nobody knows what it contains. Copying the "documents" folder without knowing whether the database is in there, or without the keys to decrypt it, produces an unusable archive discovered at the wrong moment.

To do this month, even without budget

Write down the two numbers — how long down, how much data — for the three systems without which the company stops.
Ask whoever runs your systems when the last test restore happened. If the answer is "never", you already have your first action.
Do one, even a small one: take yesterday's backup of a single system and try to bring it back elsewhere, with a stopwatch.

What you learn in that afternoon is worth more than any report, and it almost always contains at least one surprise.

Continuity is not a feature to buy: it is a drill to repeat. Anyone selling it to you without ever running it is selling you the same trust you already had, with an extra invoice.

How often should a restore drill run?

Automated, even weekly: if it runs by itself onto a throwaway environment it costs nothing to repeat. If it is manual, a quarter is the reasonable minimum — and it has to be in the calendar, otherwise it doesn't happen.

Does the cloud back up for us?

Providers replicate infrastructure, which is a different thing: if you delete data or an attack encrypts it, replication faithfully copies the damage. Responsibility for copies of your data almost always stays yours: read the contract, not the brochure.

How long should copies be kept?

It depends on how late you would notice a problem. If corrupted data can go unnoticed for weeks, seven days of retention won't save you. Thirty days plus a few longer monthly copies is a reasonable balance for many companies.

What if the data is personal?

Copies contain personal data and must be protected like live data: encrypted, with limited access and a declared retention. The reverse also holds: a deletion requested today does not rewrite yesterday's copies, and that position must be written down before someone asks.