The Ultimate Moodle Backup Policy for 2026

Most Moodle backup failures are policy failures before they are technical failures. A team creates nightly course backups, assumes the site is protected, then learns during an outage that grades, users, authentication settings, plugins, and uploaded files cannot be restored as a complete system.

This guide was re-audited in May 2026 to remove unsupported SLA and compliance claims. Use it as a practical backup policy template, then confirm exact recovery guarantees, retention periods, and compliance obligations with your hosting contract, legal team, and data protection officer.

Course Backups Are Not A Site Backup

Moodle course backups are useful. They help you copy a course, preserve course content, or restore selected course activities. They are not a full disaster recovery plan.

Moodle's own site backup documentation says a Moodle system has three major parts:

The database, which stores users, roles, enrolments, grades, logs, activity data, and settings.
Uploaded files, usually under moodledata, which store course files, submissions, generated files, caches, and temporary working data.
Moodle code, including core files, custom plugins, themes, configuration, and local changes.

A .mbz course backup does not automatically recreate the full production environment. It cannot replace a tested site-level restore plan after database corruption, ransomware, storage loss, accidental deletion, or a failed upgrade.

What Your Backup Policy Must Cover

1. Database Backups

The database is the source of truth for grades, enrolments, quiz attempts, activity settings, logs, and most operational state. Back it up on a schedule that matches your tolerance for data loss.

For MySQL or MariaDB, use a consistent dump method such as mysqldump --single-transaction for transactional tables, or a database-native hot backup tool for larger installations. For PostgreSQL, use pg_dump, logical replication, snapshots, or a managed database backup feature appropriate to your scale.

Minimum policy questions:

How often is the database backed up?
Are backups transactionally consistent?
Are backup files encrypted at rest and in transit?
Who can access backup files?
How quickly can a database backup be restored to staging?

2. Moodledata Backups

The moodledata directory is usually the largest and fastest-growing part of a Moodle site. It includes uploaded course materials, assignment submissions, forum attachments, generated files, caches, temporary files, and sometimes sessions.

Moodle's file API stores files under filedir by content hash, so you cannot safely manage Moodle files by browsing human-readable filenames on disk. Your backup process should preserve the whole data directory structure and permissions.

Minimum policy questions:

Does the backup capture moodledata and the database from compatible points in time?
Does the copy process preserve permissions, ownership, and symlinks where relevant?
Are caches and temporary files handled intentionally rather than accidentally?
Are large uploads and backup temp directories excluded only when you know they are safe to exclude?

For storage sizing, see Understanding and Planning Your Moodle Storage Needs in 2026.

3. Moodle Code, Config, And Operational Context

Moodle core can be downloaded again, but your running site is not just Moodle core. Your restore plan must include:

config.php and any environment-specific settings.
Installed plugins and exact plugin versions.
Custom themes, local plugins, and code patches.
Scheduled task and cron configuration.
Web server and PHP configuration.
Authentication, mail, LTI, payment, video, repository, and SSO integration settings.
Secrets management and credential rotation steps.

Do not store secrets carelessly in a backup archive. A backup policy should say how secrets are backed up, encrypted, rotated, and recovered.

Set Clear RPO And RTO Targets

Your backup policy should define two recovery targets:

Recovery Point Objective (RPO): The maximum amount of data you can afford to lose.
Recovery Time Objective (RTO): The maximum time your Moodle service can be unavailable before recovery is expected.

Typical targets vary by risk:

Site profile	Example RPO	Example RTO	Notes
Pilot or sandbox	24 hours	24-48 hours	Lower cost, lower urgency
Standard academic site	12-24 hours	Same business day	Works for many schools outside exam periods
Active assessment or compliance training site	1-4 hours	2-8 hours	Requires stronger automation and tested runbooks
Mission-critical enterprise learning	Minutes to 1 hour	Under 2 hours	Usually needs managed infrastructure, replication, and formal incident response

These are planning ranges, not universal promises. Your actual targets depend on budget, traffic, assessment windows, compliance needs, and contract terms.

Apply 3-2-1, Then Add Restore Tests

The classic 3-2-1 rule still applies:

Keep at least 3 copies of important data.
Store copies on at least 2 different storage systems or media types.
Keep at least 1 copy off-site or isolated from the primary environment.

For modern Moodle operations, add two more controls:

Isolation: Backups should not be writable from the same compromised account that can delete production data.
Restore testing: A backup is not proven until you restore it and validate Moodle behavior.

If ransomware encrypts both production and the backup bucket, the number of backup copies does not matter. If your team has never restored a full Moodle site, your RTO is a guess.

Test Restores Like Production Work

Schedule restore tests at least twice a year, and more often for high-stakes sites. A useful restore test should validate the complete learning workflow, not just the presence of files.

Test these items:

Administrator, teacher, and student login.
Course visibility and enrolments.
Assignment submissions and feedback files.
Quiz attempts and gradebook data.
Forums, messages, notifications, and cron tasks.
Theme assets, plugin pages, and custom reports.
SSO, LTI, payment, video, repository, and mail integrations.
File permissions and uploaded-file access.

Document the exact time from "restore begins" to "users can log in and complete learning workflows." Compare that result with your RTO. If the result is worse than the target, change the architecture, change the runbook, or change the expectation before the outage happens.

Retention Should Match The Risk

Retention policy controls how far back you can recover. A simple baseline is:

7 daily restore points for recent mistakes.
4 weekly restore points for delayed discovery.
3-12 monthly restore points for audit, term, or compliance needs.

Do not copy this blindly. Student record obligations, privacy rules, data minimization requirements, and contractual commitments vary by jurisdiction and customer. A backup policy should explicitly say which data is retained, for how long, where it is stored, and who can authorize deletion or restoration.

DIY Versus Managed Backups

Self-hosting can work well when you have the engineering capacity to maintain it. The usual failure mode is underestimating the ongoing work:

Monitoring backup job health.
Testing restores.
Updating scripts after database, storage, or Moodle upgrades.
Protecting credentials and backup storage.
Maintaining staging infrastructure for restore drills.
Responding during off-hours incidents.

Managed Moodle hosting can reduce that burden, but you still need to read the details. A provider saying "we take backups" is not enough.

Ask any provider these questions:

What exactly is backed up: database, moodledata, code, config, and secrets?
How often are backups taken?
How long are restore points retained?
Are backups off-site, encrypted, immutable, or logically isolated?
Can customers download full-site backups?
Are restore tests performed, and can you see evidence?
What RPO and RTO are contractually guaranteed?
What support channel applies during an outage?
Are backups included in the plan or billed separately?

Where MooDIY Fits

MooDIY's current public support materials list database backups, full site backups, course backup and restore, SSL certificate installation, CDN, cron support, and hosting platform support. MooDIY's hosting page also lists full site backup downloads and says customers can export and download site data on demand.

That is enough to position backup handling as part of the managed Moodle hosting offer. It is not enough to invent universal public guarantees about recovery speed, compliance certification, or restore-test reporting unless those are published in current plan documents or written into your contract.

When evaluating MooDIY or any other host, use this rule:

Marketing copy tells you what the service is designed to do. The contract and support process tell you what the service is obligated to do.

If your organization has formal audit requirements, ask for the current backup architecture, retention policy, restore process, and contractual recovery targets before migration.

The Ultimate Moodle Backup Policy for 2026 ​

Course Backups Are Not A Site Backup ​

What Your Backup Policy Must Cover ​

1. Database Backups ​

2. Moodledata Backups ​

3. Moodle Code, Config, And Operational Context ​

Set Clear RPO And RTO Targets ​

Apply 3-2-1, Then Add Restore Tests ​

Test Restores Like Production Work ​

Retention Should Match The Risk ​

DIY Versus Managed Backups ​

Where MooDIY Fits ​

Related Reading ​

Sources Checked May 2026 ​

Related Topics