Moodle Backup: The Essential Routine That Safeguards Your UK Organisation

Moodle backup is the routine nobody praises — until the day it saves the term. A lecturer deletes the wrong module, an upgrade crashes, a disk fails the day before exams. The difference between a twenty-minute scare and a three-week crisis was decided months earlier, in the routine you set up (or failed to set up).

I write as a full-stack developer, Moodle-certified, and founder of Agathas Web, managing Moodle production environments since 2008 — including installations with thousands of concurrent students. This text is the conversation about Moodle backup I have with every VLE manager in our first technical meeting: what to copy, how often, how to test, and where costs can spiral.

TL;DR — The Essentials

• A complete Moodle backup has three components: database, moodledata, and code. Missing one, you have a file, not a backup.
• Course backup (.mbz) does not replace a full Moodle site backup. It doesn't even include user passwords.
• A Moodle backup that has never been restored is a hypothesis, not a guarantee. Test restoration every month, with a stopwatch.
• In Sophos's State of Ransomware in Education 2026 report, 77% of primary and secondary education institutions and 69% of higher education institutions recovered encrypted data from backups. The average recovery cost in the sector was US$2.26 million.
• Under UK GDPR and the Data Protection Act 2018, you have 72 hours to report a personal data incident to the ICO. Discovering your backup is unusable on the third day is too late.

The Three Pillars of Moodle Backup (and why two aren't enough)

The official Moodle documentation is direct: a site backup has three components. Those who copy only one discover the flaw too late.

1. The Database

It's the heart of your Moodle backup and where everything that isn't a file lives: users, enrolments, grades, quiz attempts, forums, logs, configurations, and the structure of each course. Without it, moodledata files become nameless, ownerless blobs.

The documentation's warning bears repeating: a dump with incorrect encoding will result in garbled characters in any non-English content. Use UTF-8 explicitly and check before you trust.

2. The moodledata Directory

This is the directory outside the webroot where Moodle stores uploaded files, submissions, course images, cache, and sessions. In an average institution's Moodle backup, it is, by far, the largest portion of volume — and the one that grows most without anyone noticing.

3. The Code and Plugins

The core code can be re-downloaded from the official site. What you cannot re-download are config.php, custom themes, third-party plugins in their exact running versions, and any manually applied patches. A Moodle backup without the code directory forces you to reconstruct the environment through 'digital archaeology' — and that's when your RTO is exceeded.

Course Backup (.mbz) is Not a Site Backup

It's the most costly misconception I encounter in Moodle backup audits. A lecturer exports the course, saves the .mbz to a cloud drive, and considers the matter resolved. It isn't.

The .mbz is, by default, a TGZ with the course structure (you can use ZIP with $CFG->usezipbackups = true; in config.php). It's excellent for moving a course between sites, cloning a module, or recovering a deleted activity. But it's poor as a disaster recovery plan, for three reasons:

• Passwords are not included in the backup, even if 'include enrolled users' is selected. Restoring to another server means everyone resetting their password.
• Not everything is included. The official backup and restoration FAQ lists exclusions such as unused questions, unused scales, and unawarded badges.
• It ignores the site. Global settings, plugins, authentication, integration with the student information system, themes — none of this is in the .mbz.

Practical rule: .mbz is a pedagogical and portability tool. Moodle backup as a platform is infrastructure — and resides elsewhere.

Define RPO and RTO Before Choosing Your Tool

Before writing the first line of script, answer in numbers the two questions that define Moodle backup in your institution. RPO (Recovery Point Objective) is how much content you are willing to lose, in terms of time. RTO (Recovery Time Objective) is how long you can tolerate being offline.

The answer changes the entire design. A corporate Moodle with static content might tolerate a 24-hour RPO. A Moodle used for graded online exams cannot tolerate 15 minutes — losing in-progress attempts means nullifying the assessment for hundreds of students.

Scenario	Acceptable RPO	Acceptable RTO	Solution
Lecturer deleted an activity	Last night	1 hour	Automated course backup (.mbz)
Version upgrade failed	Pre-upgrade moment	2 hours	Full snapshot + rehearsed rollback
Disk / server lost	15 min to 24 h	4 to 8 hours	Offsite dump + replicated moodledata
Ransomware	24 h (immutable copy)	1 to 3 days	Offline/immutable copy outside the domain
Error discovered 20 days later	30 days retention	1 day	Long retention + versioning

This table is a board-level discussion, not solely for IT: sizing your Moodle backup is a business decision, and each reduction in acceptable loss costs storage and maintenance windows.

How to Configure Automated Course Backups in Moodle

Moodle includes a native course backup routine that runs via cron, under Site administration → Courses → Backups → Automated backup setup (backup_auto_active). It's the first step in Moodle backup for any institution — provided you understand its limits.

Step-by-step configuration:

1. Activate the routine and choose days of the week and execution time.
2. Point the destination outside the Moodle disk. The documentation recommends choosing a path "on another machine or a different drive from where Moodle is located". Leaving it in the default moodledata quickly fills the disk.
3. Adjust the scope filters: Skip hidden courses (default: yes) and Skip courses not modified since (default: 30 days). These save processing — and are the reason why that archived course never appeared in the backup.
4. Calibrate retention, which is where almost everyone slips up.
5. Confirm that cron actually runs. Without an active cron, the configuration looks good on screen but doesn't generate a single file. From the command line: php admin/cli/automated_backups.php.

The Retention Trap

Three settings interact without Moodle validating the combination: backup_auto_max_kept (maximum per course), backup_auto_delete_days (deletes anything older than X days), and backup_auto_min_kept (minimum that is never removed). If the minimum is greater than the actual count per course, cleanup doesn't happen — and the disk silently fills until Moodle stops writing. When adjusting these values, re-do the arithmetic.

The Window Trap

The documentation warns: running the routine across all courses is processor-intensive and should not happen with many students online. In a UK institution, the worst time is typically between 7 PM and 10 PM — when students who work during the day log onto the platform. Scheduling it for 8 PM is self-sabotage.

The Infrastructure Backup Moodle Doesn't Do For You

The native routine handles courses. Moodle backup as a platform is the responsibility of the server administrator — and this is where generic hosting leaves institutions in the lurch. Without a dedicated sysadmin, this gap is precisely what managed Moodle hosting closes. The minimum setup I use in production:

• Logical database dump, daily and consistent: mysqldump --single-transaction --default-character-set=utf8mb4 moodle > moodle.sql (in PostgreSQL, pg_dump -Fc). The single transaction avoids locking InnoDB tables during the copy.
• Binlog for point-in-time recovery. The daily dump provides a 24-hour RPO; the binlog reduces this to minutes, reconstructing the database up to the moment before the error.
• moodledata via incremental rsync, with hard links between generations to avoid duplicating unchanging terabytes.
• Code versioned in Git, with config.php and credentials outside the repository, stored in a vault.
• 3-2-1 Rule: three copies, two media, one offsite. Against ransomware, add an immutable copy — an attacker with valid credentials can delete the backup before encrypting the server. Not coincidentally, 85% of ransomware attacks on the education sector used identity-based techniques, according to Sophos (226 IT leaders in 17 countries).
• Encryption at rest at the offsite destination. Moodle backups contain personal identification details, email, grades, and history: this is personal data under UK GDPR, including for minors.

Restoration is the Only Test That Matters

Untested Moodle backup is faith, not a process. If you discover a corrupted dump on the day of a disaster, your Moodle backup never existed — only the illusion of one.

Four Moodle backup restoration pitfalls that have caught me out:

Target Version. The official rule is clear: restore to a Moodle version equal to or newer than the source — a 5.1 backup on a 4.5 site will fail. If you are planning a version jump, it's worth reading what changes in the VLE upgrade to the current LTS beforehand. Plugin incompatibility is discovered in staging, not during an emergency.

Timeout on Large Courses. Restoring a course with many GBs of attachments via the web will exceed PHP's timeout limit. For this, the CLI exists: php admin/cli/restore_backup.php --file=/path/to/course.mbz --categoryid=1.

User Conflict Between Sites. When restoring to another installation, accounts with the same username but different email addresses will collide. Define the matching policy beforehand, not mid-process.

Misunderstood Partial Restoration. Recovering content accidentally deleted rarely requires restoring the entire site — it's usually a case for selective course restoration. The case of UFOP, which I analysed in content deletion and how to save the backup, illustrates the difference between planned cleanup and accidental loss.

The Monthly Drill, in 40 Minutes

Set aside a monthly window: take down a test environment, restore the most recent dump, upload the moodledata, point config.php to the restored database, log in as administrator, and check three courses, a grade, and an uploaded file. Time it. That number is your real RTO — not the one in your contract.

When NOT to Back Up the Way You're Thinking

Not every copy is useful, and some Moodle backup routines are actively detrimental:

• Do not use .mbz as an institutional archive. It doesn't preserve the site context and ages poorly between versions. For academic records, export reports and grades in an open format.
• Do not store backups on the same disk or server. Disk failure takes both. Ransomware does too.
• Do not schedule full backups during peak hours. You trade risk of loss for certainty of slowdown.
• Pre-upgrade backup does not replace staging. The snapshot allows you to roll back; it doesn't reveal that the enrolment plugin has broken. Only testing in staging shows this — as I discussed when analysing the deadlines and backup routine for UnB's VLE.
• Do not retain backups indefinitely 'for safety'. Each older generation carries personal data that UK GDPR requires to be erased when its purpose ends. Define retention periods in writing.

Real Costs: What Fills the Disk and the Bill

Moodle backup has three cost centres that only become apparent later. The first is volume: automatic backups saved to moodledata are the number one reason for full disks. The second is egress traffic from offsite storage, which never makes it into the spreadsheet and only hurts on restoration day, when you download everything at once. The third is senior staff time: the monthly drill costs hours of those who know what they're doing.

There's also a calendar cost. Moodle 4.5 LTS was released on 7 October 2024 and receives security fixes until 4 October 2027; the next LTS, 5.3, is scheduled for 5 October 2026, according to the official release calendar. The migration window is approaching, and no migration begins without a validated Moodle backup. Anyone reaching October without a tested routine postpones the upgrade — and postponing LTS accumulates security debt.

For comparison: Sophos reports 26% of educational institutions taking one to three months to recover after ransomware. Storage is cheap by comparison.

How Agathas Web Solves This

With managed Moodle hosting from Agathas Web, Moodle backup isn't a checklist item: it's a routine operated and verified by us, with an SLA in contract. What's included:

• Daily database backup + incremental binlog every 15 minutes, which brings RPO down to minutes.
• AES-256 encrypted offsite storage, separate from the production server.
• Contractual RTO of up to 4 hours for the last 24 hours, via point-in-time recovery and snapshots.
• Monthly restoration test, performed by us and reported in the executive summary — because a backup that doesn't restore isn't a backup.
• Calibrated native course routine: retention, filters, and window adjusted to your academic calendar, not factory defaults.
• LTS upgrade within 90 days of release, with staging and rollback, maintaining the old environment for 30 days.
• Zero lock-in: if you decide to leave, we deliver the complete backup in a standard format.

How to engage: request a free diagnostic of your current platform via WhatsApp or the form on our page. Within three working days, we'll provide an assessment with bottlenecks, continuity risks, and a proposal. If migration is needed, it's assisted within five working days, with staging approval and cut-over during an overnight or weekend window. Monthly contracts, no long-term commitment.

An honest caveat: if you already have a dedicated sysadmin and a tested disaster recovery routine, you don't need us for this — just check that the monthly drill actually happens. The service makes sense for those running VLEs without a server team, which is most medium-sized institutions in the UK.

Conclusion: The Routine That Safeguards Your Organisation

Moodle backup isn't a product you buy and forget. It's a process with four obligations: copy the three components (database, moodledata, and code), define RPO and RTO in numbers agreed with the board, store a copy offsite, and actually restore it, every month, with a stopwatch. Those who do all four transform disaster into an incident. Those who do two discover the difference on the worst possible day.

If you don't know which of these four points is failing today, request a free diagnostic on the Agathas Web Moodle hosting page. We respond within three working days with a technical assessment — the same three working days the ICO would give you to explain an incident.