Backups You Have Actually Restored

A backup you have never restored is a hope, not a plan. Most businesses find out which one they have on their worst day. Four habits make sure yours is a plan.

Why do backups fail on the day you need them?

Because they fail quietly, months before anyone looks. These are the usual ways:

• The backup job stopped running, and nobody got an alert.
• It still copies the old folder, but the important files moved to a new one.
• The copy exists but won't open, or it needs software nobody has any more.
• The backup sat next to the original, so both were deleted or encrypted together.
• It works, but the one person who knew how to restore it has left.

AWS's Well-Architected Framework makes a sharp point about this. In a traditional office, testing proves that systems work, but it is rarely used to prove that recovery works. Its advice is to test the recovery itself, on purpose, before a real failure tests it for you.

1. How much can you afford to lose?

It depends on the system, so answer two questions for each one you rely on before choosing any backup tool. How much recent work could you lose and still cope? And how long could you manage without it? Engineers call these the recovery point and the recovery time. AWS's advice is to set both from what the business needs, not from what the software happens to offer.

Here is an example for a small shop:

System	Can lose at most	Must be back within
Orders and invoices	1 hour of entries	The same working day
Customer list	1 day of changes	1 day
Website	Last week's edits	A few hours
Shared staff files	1 day of changes	The next morning

The first number sets how often you back up: if you can lose at most an hour, you back up at least every hour. The second sets how fast a restore must be. Tighter numbers cost more, so spend where losing data would really hurt.

2. What should you back up, and where should the copies live?

Everything you would need to rebuild, on a schedule, with one copy out of reach of your everyday passwords.

A backup that depends on someone remembering will be skipped in the busiest week of the year. Set it to run on a schedule, and make sure a failed run sends someone an alert.

AWS's guidance is to back up data, applications and configuration, not only the files. A database copy is not much use if nobody remembers how the app around it was set up.

Then keep at least one copy where your everyday passwords can't reach it. If an attacker or a ransomware infection gets into your main account, any backup in that account can be deleted or encrypted along with everything else. A widely used rule is 3-2-1: three copies, on two kinds of storage, with one kept somewhere else.

On AWS, that looks like this:

• AWS Backup schedules backups across services, copies them to a separate account or region, and can lock them so nobody can delete them before their retention period ends.
• S3 versioning keeps earlier versions of each file, so an accidental deletion or overwrite can be undone.
• Encryption on every backup, so a stolen copy is useless to whoever took it.

3. How do you know a backup works?

Only by restoring it. AWS's guidance is to back up regularly and test the backups, so you know you can recover from both mistakes and hardware failures. Once a quarter, put an hour in the calendar:

1. Pick something real. A random customer record, last Tuesday's invoices, or one team's folder.
2. Restore it into a separate test space, never over the live system.
3. Check it with the person who uses it daily. Is it complete, and is it as recent as it should be?
4. Time it, from "we need it" to "it's back", and compare that with the recovery time you set.
5. Write down each step, so someone else can do it next time.

Once a year, go further and rebuild a whole system from backups, such as the website or the main database. That is when you find the missing password, the setting nobody wrote down, or the backup that stopped running in March.

4. Who does what when something breaks?

Write it down before it happens. When something breaks, the first hour is lost to questions: who decides, who do we call, where are the backups? AWS's incident response guide recommends writing the answers down in advance as short step-by-step guides, then practising them. One page is enough for a small business:

• Who decides it is an emergency, and who stands in if they are away.
• Who to call: your developer or IT partner, your hosting provider's support line, and your bank if payments are involved.
• Where the backups are, and how to reach them if the main login is lost.
• The restore steps from your quarterly test.
• What you will tell customers, and who tells them.

Keep a printed copy somewhere other than the computer it describes. Once a year, gather the people on the page and talk through a scenario: "the website was wiped this morning, what happens now?" The gaps tend to show up fast.

Even large organisations let this slip. In 2022, Canada's Auditor General found that government-wide cyber incident exercises had run about once every 17 months, against a recommended minimum of once a year.

What about a website built with Quantum Accord?

You can keep your own copy. Once you have bought a site, the Download button in the Builder or your dashboard gives you its files, and downloading it again costs nothing. Save a fresh copy somewhere other than your computer after each big change. Edits made with Quantum Tune are not included in the download.

If you run anything on AWS as well, our 20-minute security check covers the backup settings there, and if you are not on Quantum Accord yet, building a site is free with an account.