Moodle Backup and Disaster Recovery: What a Managed Hosting Contract Should Include

The short answer is that a managed Moodle provider should commit to more than taking copies of data. Your contract should define what is protected, how much recent work could be lost, how quickly each critical service will be restored, how recovery is tested, who makes the decision during an incident and what evidence you will receive.

That distinction matters. A nightly backup is a technical activity; disaster recovery is the managed capability to return learners and staff to a safe, usable Moodle service after a serious failure. One can exist without the other. A provider that cannot explain the route from a disrupted platform to a tested recovery outcome is selling storage, not resilience.

This guide helps UK organisations compare managed Moodle hosting proposals or review a current contract.

The Short Answer: What to Put in Writing

Ask a prospective provider to commit to these seven points:

• the Moodle components, data and environments covered by backup and recovery;
• an RPO for each agreed service tier, expressed as the maximum acceptable data loss in time;
• an RTO for restoring that tier, including the point from which the clock starts;
• backup frequency, retention, protection, monitoring and separation from the production environment;
• a tested recovery procedure for both a single course problem and a wider platform failure;
• named decision-makers, communications, escalation and evidence during an incident; and
• a usable handover of data, files, configuration records and recovery documentation at exit.

Swift Learn’s view is that the right objective is not the smallest number a supplier can advertise. It is the objective that protects the learning events your organisation cannot easily repeat. A missed overnight forum update may be tolerable; lost assessment submissions or unavailable compliance training may not be. Buy the level of recovery your actual risk requires, then require evidence that it works.

If the wider service is still vague, start with our Moodle hosting SLA buyer's guide. The SLA, support scope and recovery plan need to describe the same service boundary.

Backup, Restore and Disaster Recovery Are Different Promises

These terms are often bundled together, which makes a proposal sound complete while leaving the hardest questions unanswered.

• Backup is a protected copy of agreed data and configuration at a point in time.
• Restore is the technical act of retrieving a copy and making the selected item usable again.
• Disaster recovery is the people, process, infrastructure and decision-making needed to restore a defined service after a major loss of availability or integrity.

Moodle’s Backup API documentation, checked on 19 October 2026, describes a subsystem for backing up and restoring course data. That is valuable, but it should not be confused with recovery of an entire hosted service. A platform recovery can also depend on the database, moodledata, application code, themes, plugins, storage, cache settings, scheduled tasks, identity integration, email configuration and the infrastructure that makes them available.

Ask the provider to draw the boundary. Which elements are backed up by it, which are held by another supplier, and which remain your responsibility? A clear answer may reveal that single-course restoration is included but a full-environment rebuild is not, or that an identity provider sits outside the RTO. Neither arrangement is automatically wrong. The risk is assuming that a broad phrase such as “daily backups included” covers components it does not.

Define the Recovery Scenarios Before the Solution

Set each scenario before choosing a solution: accidental course deletion, corrupted content, a faulty deployment, platform failure, compromised access or loss of a critical integration. For each, agree whether the expected action is restore, rollback, rebuild, failover or a manual workaround. A course restore and a full-platform recovery are not the same promise.

Set RPO and RTO From Learning Impact

An RPO answers: “If recovery is required, how much recent data might we lose?” An RTO answers: “How long may the agreed service remain unavailable while it is restored?” They are related, but they are not interchangeable.

Start with the learner and business consequences. Map periods such as enrolment deadlines, assessment windows, mandatory compliance completion, live teaching, reporting cycles and planned upgrades. Then decide the largest loss of recent activity and the longest interruption that each period can tolerate. Record assumptions about weekends, evenings and supplier response coverage as well as the headline objectives.

During high-stakes assessments, you may need short objectives; a small internal knowledge base may accept longer ones. Faster objectives normally require more frequent protection, recovery capacity, operational cover and testing. The lower-cost option carries more accepted risk.

Be exact about the service tier attached to each number. “Four-hour recovery” should state whether it means a technical environment is running, administrators can sign in, or learners can complete an agreed set of journeys. It should also say when timing begins: at monitoring detection, customer report, incident classification or recovery approval. A target without a start point, end point and evidence source is difficult to manage when it matters.

Do Not Let a Recovery Target Hide an Approval Delay

Name who can authorise recovery, disable a faulty integration, communicate an outage or accept a workaround. Agree primary and deputy contacts, authority limits and an out-of-hours channel. A technically achievable RTO can still be missed when no one can make a decision.

Specify What Is Protected and How It Is Kept Recoverable

The contract should contain a recovery inventory rather than a generic backup sentence. At a minimum, ask how it covers:

• Moodle application code, approved themes, plugins and local customisations;
• the production database and any reporting or integration data the provider owns;
• moodledata, uploaded course files and other file storage;
• infrastructure and environment configuration needed to reconstruct the service;
• scheduled-task configuration, monitoring and deployment records; and
• the restore runbook, access controls and ownership information required during an incident.

The inventory needs a retention policy too. Retention is not only about how long copies exist; it affects how far back you can return after a problem is discovered late. Ask whether copies are versioned or immutable where appropriate, how accidental deletion is handled, and who can delete or alter recovery material. Also establish whether backups are stored separately enough from production to remain available after the kind of incident you are planning for.

Encryption, access control and auditability belong in the answer. A backup that can be read or erased by an unnecessarily broad set of accounts can create a new risk. Conversely, recovery credentials locked behind one unavailable person can turn a minor outage into a lengthy incident. The provider should show a controlled, documented access model and a way to use it under pressure.

For an explanation of who normally owns backup operations, monitoring, patching and changes in the broader service, compare the Moodle support contract guide. The contract should name each responsibility once; duplicated or unowned tasks are both warning signs.

Require Restore Tests and Evidence, Not a Reassuring Assertion

The most important question is not “Do you take backups?” It is “When did you last prove that this recovery path meets our agreed scope and objective?”

Ask for a restore-test schedule and a representative result. The evidence does not need to expose sensitive production data. It should show the scenario tested, the environment, the copy used, the start and finish times, checks performed, variances, issues and corrective actions. A test that only proves a file can be downloaded is not equivalent to a test that proves a learner can sign in, open a course, submit activity and see appropriate completion or grading behaviour.

Tests should match the risks. A frequent, narrow test might restore a representative course or verify the integrity of protected copies. A less frequent, more substantial exercise might rebuild a service in a recovery environment and run agreed learner journeys. The right cadence depends on the platform’s criticality and rate of change, but the provider should have a rationale and a process for remediation when a test fails.

Ask specifically about changes. New plugins, a revised identity integration, large file-storage changes or an infrastructure move can invalidate an old recovery assumption. The recovery plan needs a trigger to review scope after material changes, not merely an annual document review.

Link Recovery Controls to Security and Data Protection

Resilience is a security issue as well as an availability issue. The National Cyber Security Centre’s Cloud Security Principles, version 2.1 reviewed on 7 June 2023 and checked for this article on 19 October 2026, tells cloud buyers to assess provider evidence across resilience, operational security, identity, supply chains and customer audit information. Use that as a prompt to request evidence rather than relying on assurances in a sales presentation.

For a Moodle hosting proposal, ask how the provider protects backup access, patches the supporting estate, monitors abnormal activity, manages privileged accounts, notifies customers of security incidents and governs any sub-processors. It should also explain how recovery material is secured during a test or an incident.

The ICO’s guide to data security, checked on 19 October 2026, explains that UK GDPR security measures should be appropriate to risk and should enable timely restoration of access and availability after a physical or technical incident. It also notes that data processors have relevant security obligations. This is not legal advice, but it is a useful reason to involve your data-protection and security leads when setting recovery scope, access rights, locations and processor terms.

Do not accept compliance language as a substitute for engineering evidence. Ask which control protects which recovery outcome, who owns it and how it is tested.

Compare Providers on the Same Recovery Boundary

Two quotes can contain the word “backup” while offering materially different services. Normalise proposals before comparing price. Give each bidder the same scenarios, service tiers and acceptance questions, then ask for an explicit included/excluded response.

Score the answers against:

1. Scope clarity — Is every relevant Moodle component, environment and dependency named?
2. Objectives — Are the RPO and RTO defined by service tier with an unambiguous clock and outcome?
3. Technical design — Does the proposal describe protection, retention, separation, monitoring and controlled access without hand-waving?
4. Test evidence — Will you receive meaningful restore-test results and follow-up on failures?
5. Operational ownership — Are incident authority, communications, support hours and third-party escalation clear?
6. Exit and portability — Can you obtain usable data, files and records without an emergency negotiation?

The supplier that offers the lowest infrastructure price may still be the best choice for a low-risk learning service. It is not the best choice if its omission of testing, recovery capacity or out-of-hours authority simply creates an uninsured internal obligation. Make that trade-off visible before signature.

Use our questions for a UK Moodle hosting provider alongside this checklist so that recovery answers line up with the provider’s people, service desk, hosting architecture and support model.

Red Flags to Resolve Before You Sign

Pause and seek a written clarification when a proposal includes any of these:

• “backups included” with no recovery scope, retention or test evidence;
• one RTO for every incident, regardless of the scale of recovery;
• a recovery target that ends when a server starts rather than when Moodle is usable;
• no distinction between a course restore and a full-platform recovery;
• a test plan that cannot identify recent results, known failures or corrective actions;
• unclear responsibility for identity, storage, integrations, plugins or custom code;
• security controls that protect production but say nothing about backup access; or
• exit wording that omits data, files, configurations and recovery documentation.

None of these points proves that a provider is unsuitable. They identify decisions that should be made deliberately, priced transparently and recorded in the agreement.

The Swift Learn Verdict

Managed Moodle backup and disaster recovery should buy confidence that learning can resume after a serious problem, not merely confidence that copies exist somewhere. The strongest contract makes the recovery inventory visible, sets objectives around real learner impact, tests the full route to usability and keeps accountability clear when time is short.

Start with the disruption you cannot accept. Define the service that must return, the data loss and delay you can tolerate, the dependencies outside the provider’s control and the evidence you need. Then compare providers on that same boundary. That approach usually produces a more honest price and a much safer service.

Need a Moodle Recovery Scope Review?

Bring us your current hosting arrangement, learner-critical periods, integrations and draft provider proposal. Swift Learn can map the recovery boundary, test the assumptions and help you specify a managed Moodle service that fits your operational risk.