Backup vs. tested restore: why 'backed up' isn't a control

A customer said something to me recently that has stuck with me.

"I don't think I've got a backup unless I've tested it."

He runs automated restore testing against his backups, so the system itself confirms the data can actually be brought back. Not that the backup job finished. That the data restores.

Most teams stop one step earlier, and for an understandable reason. The backup job ran overnight, the tool reported success, and everyone moves on. The tool is telling the truth: a copy was written. But "a copy was written" and "the copy can be read back into a working system" are two different facts. The backup software confirms the first by default. The second takes a deliberate, separate effort that nothing forces you to do, right up until the day you need it or an auditor asks. So it quietly doesn't happen.

In a compliance setting, the gap between those two facts has a name. The thing auditors and frameworks care about is a control: something that demonstrably works, and that you can show works. A backup nobody has restored fails both halves of that test. You cannot demonstrate it works, because no one has tried. And you have no evidence to show, because an untested backup produces none. That is why "we back it up" is not an answer to "is recovery a control."

What the frameworks actually ask

Read the requirements closely and they are not asking whether a backup exists. They are asking whether restoration has been tested, and whether there is a record of it.

• The ASQA Standards for RTOs require records to be securely retained, and to be retrievable and transferable to the regulator. Retrievable is the operative word. A record you cannot get back is not retrievable, whatever the backup log says.
• The Essential Eight, maintained by the Australian Cyber Security Centre, treats backups as a control only when restoration is tested as part of a recovery exercise. The presence of a backup is not the control. The tested restore is.
• ISO 27001 Annex A 8.13 asks for information backup that is tested for restoration.

The common thread is testing. None of these frameworks accept "a backup exists" as evidence. They ask for evidence that it comes back.

The Canvas version of the gap

In a Canvas setting this usually looks like a Common Cartridge export sitting in a folder or on a network drive, made some months ago by someone who has since moved on. It feels like a backup. It has never been restored.

Two problems hide in that file. The first is that no one has confirmed it imports cleanly into a working course. The second is quieter and worse: a Common Cartridge export captures course content, the structure, pages, files, assignments and quizzes, but it does not capture student enrolments, submission history, or the gradebook. That is how the format works. It is not a fault in anyone's process. But if the working assumption is "the export is our backup," there is a gap in it nobody has seen, and the place it tends to surface is the worst one: after a course is wiped, or in the middle of an audit.

The only way to find both problems is to restore the thing and look.

A backup is the extinguisher. A tested restore is the service tag.

A backup is the extinguisher on the wall. Necessary, and on its own it proves nothing.

Think about fire safety in an office building. There are extinguishers on the walls, sprinklers in the ceiling, fire wardens, marked exits. None of it is left to chance. The extinguishers are serviced and tagged on a schedule. The wardens are trained. Staff walk a drill so the route is muscle memory, not a sign they read for the first time in smoke.

The extinguisher on the wall is the backup. It is necessary, and on its own it proves nothing. The dated service tag, the record that someone checked it and it works, is the tested restore. The drill is the practice that means the capability actually gets used when it counts, instead of being argued about while the impact grows.

An untested backup is an extinguisher nobody has checked. It might be fine. A fire is a poor time to find out.

What good looks like, and it is cheap

The fix is not a bigger budget or a new platform. It is a tested restore with a record.

Pick one real course that matters, a current diploma or unit, not an empty shell. Export it. Restore it into a test environment, never production. Before you start, write down what a correct result looks like: the count of modules, pages, files, assignments and quizzes. After the import, check the restored course against those numbers. Then write down what you tested, when, where, and whether it passed.

That written record is the whole difference between a backup and a control. It is the evidence the frameworks ask for, and it is the thing you can put in front of an auditor. The first run takes about thirty minutes, and it will tell you two things you cannot learn any other way: whether your recovery actually works, and exactly where it falls short.

We publish a free step-by-step version of this, the Canvas Restore Drill Template, if you want a checklist to work from.

The point

You do not rise to the occasion. You fall to your level of practice.

The teams that come through a data loss well are rarely the best funded. They are the ones who tested the restore before they needed it, and kept the record that proved it. A backup is where that work starts. It is not where it finishes, and on its own it is not a control.

If proving your Canvas recovery before you need it is on your list, that is the problem we are built to solve. We are taking on a small number of design partners now.