Why your Moodle™ backup is probably broken (and how to find out)

Roughly half of the new clients who come to us already have “backups”. About a third of those have backups that work. The other two thirds find out the hard way — usually during a real incident, when the file they thought was a backup turns out to be something else entirely.

This is not a story about lazy admins or bad providers. It’s a story about a class of failure that’s almost invisible by design: backups that appear to be running, appear to be complete, and appear to be safely stored — until you try to restore one.

Here’s how to find out where you actually stand, in about 45 minutes.

The simple test that everyone skips

Set a calendar reminder for one hour next week. In that hour:

Pick your most recent backup.
Spin up a throwaway VM somewhere — a $5/month VPS is plenty.
Restore the backup onto it.
Log in as admin.
Click into a recent course.
Open a recent quiz attempt or assignment.

If all six steps work, your backup is real. If any of them fail, you’ve just learned something important — for free — before it matters.

That’s it. That’s the test.

Most teams have never done it.

The five ways we see backups silently fail

We’ve now done this exercise with dozens of new clients. The same five patterns show up over and over.

1. The database dumps, but `moodledata` is missing

Probably the single most common failure mode. The backup job carefully exports the database — every quiz attempt, every grade, every forum post — and then doesn’t back up the moodledata directory.

Result: you can technically restore the database, and Moodle™ will appear to load. But every uploaded file, every drag-and-drop assignment submission, every profile picture, every file in the question bank, every file resource in every course — all of those live in moodledata, not the database. A “DB-only” backup is roughly half a backup.

How to spot it: look at the size of your backup. If your moodledata directory is 20 GB and your backup file is 200 MB, the backup isn’t backing up your files.

2. The backup is on the same machine

We saw a heartbreaking version of this last year: a college with a meticulously-configured nightly backup job, writing tarballs to /var/backups on the same VM that ran Moodle™. The VM was deleted by the hosting provider after a billing dispute. Both the live site and 18 months of backups went with it.

A backup that lives on the same disk, the same VM, or even the same cloud account as your live site is not a backup. It’s a copy. The difference matters when the underlying thing fails.

How to spot it: look at where your backups are stored. If the answer is anything that contains the words “the server” or “same hosting account”, that’s the problem.

3. The backup ran successfully — for the wrong site

This sounds absurd, but we’ve seen it three times. A backup job was configured years ago for an older Moodle™ install, the install was migrated to a new location, but the backup job kept running against the old one. The “successful” green-tick emails kept coming. The actual current site had no backups at all.

How to spot it: check the timestamp and size of the last backup file. Does the size match the current site? Did it grow at the rate your site is growing? If your site is 40 GB and your backups are 4 GB and have been for two years, something’s wrong.

4. The backup is encrypted with a key nobody has

A modern variant: backups are pushed to S3 with server-side encryption using a KMS key, or the backup tool encrypts them with a passphrase. The site goes down. Someone tries to restore. The passphrase is in the head of a person who left in 2022. The KMS key is in an AWS account that was decommissioned during a cloud-cost rationalisation.

How to spot it: stop your hypothetical disaster-recovery test on step 3 above. Can you decrypt the backup right now, from a new machine, with the credentials available to your current team? If you have to “find the password somewhere”, that’s the failure.

5. The backup is fine, but the restore procedure is fiction

This is the subtlest one. The backup files are present, complete, in the right location, with the right encryption. The restore would work. But nobody on the team has ever actually performed the restore steps. The “documented runbook” is a wiki page last edited four years ago, listing commands for a different Moodle™ version, on an OS we no longer use, referring to a pg_dump flag that was deprecated in PostgreSQL 13.

You’ll find out about this one on the night you need it most.

How to spot it: the test above. Run the restore from a cold start. Time it.

Why this happens

None of this is anyone’s fault, really. Backups exist on the boundary between two teams — the people who run the site and the people who run the infrastructure — and that boundary is where things rot. Both teams reasonably assume the other has it covered.

It’s also boring. Restoring backups isn’t a sprint goal. Nobody gets a promotion for proving that backups work. So nobody does it, until someone has to do it under pressure.

The fix isn’t complicated, it’s just procedural: schedule it. Once a quarter, ideally once a month. Restore a real backup to a sandbox. Log in. Click around. Throw the sandbox away.

That’s the whole programme. It works because it forces the system to either prove itself or fail loudly in a safe environment.

What we do for our backup clients

Because this is so much our job, here’s how we do it for the sites we look after — copy any of it that’s useful:

Daily encrypted off-site snapshots. Database, full moodledata, full codebase. Stored in a different account, in a region the client picks.
Monthly restore verification. Every active client backup is restored into a throwaway sandbox on the 1st of the month. Smoke tests run automatically: admin login, course list, sample quiz attempt, file resource download. If anything fails, a real human is paged before the report is sent.
Quarterly DR drill. Optional for clients who want auditor-friendly evidence. We simulate a total site loss with the client in the room, time the restore, and produce a signed-off RTO/RPO statement.
Runbook in git. Step-by-step restore procedure, version-controlled, updated whenever the stack changes. Reviewed at the quarterly DR drill.

The interesting bit isn’t any single piece of this. It’s that the verification step is non-negotiable. If a restore would fail, we want to learn that in a sandbox at 11 AM on a Tuesday, not at 2 AM on the night before exams.

If you remember one thing

A backup that has never been restored is not a backup. It’s a folder with the right name on it.

Schedule a restore test for sometime in the next two weeks. Block out an hour. Spin up a sandbox. Do the test.

If everything works, you’ll feel briefly excellent. If something fails, you’ll have found out at a time of your choosing — which is the entire point.

Need help with this? If you’d rather not do this yourself, our Moodle™ backup & DR service handles all of it — including a free “audit your current backup” engagement on day one. We’ll tell you honestly whether what you have works.