"Daily backups": the five questions to ask before you believe it

We have been called in after the bad hour more times than we would like. A site compromised, a database table dropped by a plugin update, a server lost to a provider outage. In every case the business had been told it had backups. In most cases, in the sense that mattered, it did not. The backup was on the same server that died, or had silently stopped running eight months earlier, or restored into a state nobody could use.

The word "backups" tells you nothing. The five questions below do. Ask them of your current provider, and if any answer is "I'm not sure", you have found your risk.

1. Where do the backups physically go?

A backup stored on the same server, or in the same account, as the thing it protects is not a backup. It is a copy that dies with the original. A failed disk, a ransomware infection that encrypts every mounted volume, or a provider closing your account for a billing mistake takes both at once.

The minimum acceptable answer is a different physical location with a different provider or at least a different region, reached with different credentials. The better answer adds append-only or immutable storage, meaning the production server can write new backups but cannot delete or overwrite old ones. That single property is what defeats ransomware, which specifically looks for reachable backups to destroy before it announces itself.

Ask: "If the server was wiped and its credentials stolen, could the attacker reach the backups?" The answer must be no.

2. How long are they kept, and is that written down?

Retention is the quiet trade-off nobody discusses. Short retention is cheap and fine for "I broke the site this morning". It is useless for "we have just discovered that a form has been silently dropping orders since July", or for a compromise that went unnoticed for weeks, where every recent backup contains the attacker's changes too.

Retention should be chosen on purpose, written down, and matched to what the business could be asked to recover. The ranges we use:

Note the last row. If a client contract or a regulation names a retention period, your backup retention has to at least match it, and you need to be able to show that it did. "The host keeps backups" will not satisfy anyone who asks.

3. Who can delete them?

This is the question almost nobody asks and the one that has caused the worst losses we have seen. Backups are deleted by: expiry rules nobody reviewed, a provider cancelling an account, an engineer tidying up storage, and attackers. The right answer involves two things: immutability for the retention window, so that even an administrator cannot shorten it in a panic, and separation of credentials, so the person or system that writes backups is not the one that can purge them.

Ask: "Who, exactly, has the ability to delete a backup before its retention expires?" Then ask whether that list is written anywhere.

4. When was one last restored, and did it work?

A backup that has never been restored is a rumour. Backup jobs fail quietly: a disk fills up, a credential rotates, a database grows past a timeout, and the job either stops or produces files that cannot be opened. The only way to know a backup works is to restore it, on a schedule, somewhere that is not production, and to write down the result.

Good providers do this as a matter of routine and can tell you the date of the last successful test restore and how long it took. Bad providers will tell you the backups "run every night", which is a statement about a schedule, not about recoverability.

5. What do you actually lose in a bad hour?

Two numbers describe the real promise. The recovery point objective, or RPO, is the most data you can lose: with daily backups at 2 a.m., an outage at 1 a.m. loses 23 hours of orders, sign-ups and content. The recovery time objective, or RTO, is how long until you are back: a restore that takes "a few hours during business hours" is a full working day if the failure happens on Friday evening.

Most businesses have never been told their RPO and RTO, and would be alarmed by them. For a store taking orders through the day, a daily backup means a bad hour can cost a day of transactions. That is why busier sites move to hourly backups and to continuous, point-in-time recovery for the database, which brings the RPO down to minutes.

Ask: "If the server disappeared at 4 p.m. on a Friday, what would we have lost and when would we be back?" If the provider cannot answer in numbers, the numbers are worse than you think.

Putting it on paper

Whatever the answers, write them down in one place: where backups go, how often, how long they are kept, who can delete them, when the last restore test was and what the RPO and RTO are. This one page is what an insurer, an auditor or an enterprise customer's security questionnaire is really asking for when it asks "do you have backups?". It is also what you will want in your hand during the bad hour.

Every Innovations GRC plan produces that page automatically, every month, as part of the evidence pack, because we would rather answer the five questions before anyone needs to ask them. If you want to know where your current setup stands, the free audit covers backups from the outside and tells you which of the five you cannot yet answer.