How to run a Canvas restore drill (step by step)

Most institutions have a backup of their Canvas courses somewhere. Almost none have restored one and checked that the course actually came back. The gap between those two facts is where recovery quietly fails, and it tends to show up at the worst possible time: after a course is wiped, or when an auditor asks for evidence that recovery works.

A restore drill closes that gap. It is the deliberate act of taking a backup, bringing it back into a working Canvas environment, and confirming what came back against what should have. You can run one by hand, on a single course, in about thirty minutes. At the end you have two things you did not have before: a clear answer to "does our recovery actually work," and a written record that proves you tested it.

This is the manual version of what a backup and verification service automates and counter-signs on a schedule. Running it once by hand is the fastest way to see where your recovery really stands, and exactly where it falls short.

Before you start

You need a few things in place:

• Canvas administrator access, or an account that can export a course and import into a test course.
• A test environment. Use your Canvas Beta instance or a dedicated sandbox course. Never restore into production. A restore overwrites or duplicates content, and doing that to a live course is its own incident.
• One real course that matters. A current diploma or unit is a far better test than an empty shell, because the things that break on a restore tend to be the things a real course is full of.
• Somewhere safe to keep the export file, and a change window if your institution requires one for Beta or sandbox activity.

One thing to know before you begin, because it is a property of the Canvas export format and not a fault in your process: a Common Cartridge export contains course content, the structure, pages, files, assignments and quizzes, but it does not contain student enrolments, submission history, or the gradebook. Write that down now, so it is documented rather than discovered later. We come back to it at the end.

Step 1. Export the course

In Canvas, open the course, go to Settings, then Export Course Content, and choose Course (Common Cartridge). Canvas builds the export and gives you an .imscc file to download.

Record three things in your log as you go: the course name and ID, the date and time of the export, and the file size. If you want integrity evidence, compute the file's SHA-256 hash now and write it down too. That hash is what lets you prove later that the file you restored is the file you exported, unchanged.

Step 2. Record the source state

This is the step most people skip, and it is the one that turns "it imported" into "it came back complete." Before you restore anything, open the source course and count what is in it:

• Modules
• Pages
• Files
• Assignments
• Quizzes
• Instructors listed

Write the numbers down. These are your expected results. Without them you have nothing to check the restored course against, and "the import finished" is not the same as "everything came back."

Step 3. Restore into the test environment

In your Beta or sandbox course, go to Settings, then Import Course Content, and choose Common Cartridge 1.x Package. Upload the .imscc and start the import.

Note the start and finish time, because a large course can take several minutes. And say it to yourself plainly while it runs: you are restoring into a test environment on purpose. The drill is about whether the data comes back, and it is also about being able to practise the recovery without touching anything live.

Step 4. Verify against your source counts

When the import finishes, go through the restored course and check it against the numbers you recorded in Step 2. Tick each one:

• The course is present in the test environment
• Module count matches
• Page count matches
• File count matches
• Assignment count matches
• Quiz count matches, if the source had quizzes
• At least one media file opens and does not return a 404, if the source had media
• The instructors from the source course are present
• The export file's SHA-256 still matches what you recorded, if you took a hash

This is the heart of the drill. A count that does not match is not a failure of the exercise. It is the exercise doing its job, telling you something now instead of during an incident.

Step 5. Classify the outcome and log it

Give the result a plain classification, the same way a verification report would:

• Successful: the import completed and every check passed.
• Partially successful: the import completed but one or two non-critical items failed, like a single broken media link. Note the gap. It does not mean the drill failed.
• Failed: the import did not complete, or more than a couple of checks failed. This is the result you most want a drill to find, because the alternative is finding it for the first time when a real course is already gone.

Write the outcome, the date, who ran it, and any notes into a restore log.

Step 6. Produce the record

Pull the drill into a one-page record you can file. It should state what was tested (course name and ID, export date), where (the test environment, not production), the integrity hash if you took one, the source-versus-restored counts, the checklist results, the limitations, and the outcome, signed off by whoever ran it.

Then write one line mapping it to the obligation you are meeting. That single sentence is what turns a technical exercise into compliance evidence.

Why the record is the point

The drill proves recovery to you. The record proves it to everyone else.

The compliance frameworks that apply to Australian education do not ask whether you have a backup. They ask whether restoration has been tested, and whether there is evidence of it.

• The ASQA Standards for RTOs require records to be securely retained, and to be retrievable and transferable to the regulator. A restore drill is how you find out, in advance, whether "retrievable" is actually true.
• 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 drill is that exercise.
• ISO 27001 Annex A 8.13 asks for information backup that is tested for restoration.

A signed restore log is the kind of record those requirements have in mind. It is the thing you can put in front of an auditor when they ask to see evidence that your recovery works.

What the drill cannot tell you

Be honest with yourself about the limits, because an auditor will be. A Common Cartridge restore proves the course content comes back. It does not prove the enrolments, submissions, or gradebook come back, because the export format does not carry them. If those records matter to you, and for most institutions they matter a great deal, recovering them needs a different data source than a Common Cartridge export. Record that limitation in every drill, so the gap is documented rather than quietly assumed away.

Recovery is a decision you rehearse

The rehearsal happens in calm weather. The first time you run a restore should not be the day a course is gone.

A customer told me about an outage of a core scheduling system once. The database cluster behind it had failed in a way the team had not seen before, and they spent five or six hours troubleshooting it before they decided to restore from backup. The restore itself took minutes. The slow part was the hours spent fighting the wrong battle before someone made the call to recover.

The capability was sitting on the shelf the whole time. What was missing was the rehearsed decision to use it. A restore drill is that rehearsal. The first time you run it should not be the day a course is gone.

If you want a checklist to work from, we publish a free Canvas Restore Drill Template with the steps, the verification list, and a restore log laid out to fill in. And if you would rather this ran automatically and produced the signed record on a schedule, that is what we are building. We are taking on a small number of design partners now.