"That will never happen to us" is probably the most repeated phrase among institutions that later went through some kind of data loss. Hardware failures, human error, ransomware attacks, or simply a badly applied update at an inopportune moment — the reasons vary, but the outcome is usually the same: entire courses, grades and years of pedagogical content lost within minutes.
Technology systems fail — that's a known statistical fact, not a pessimistic opinion on the matter. The question every institution should ask isn't "could this happen to us?", but rather "when it happens — and it will, sooner or later — exactly how much time and data will we lose in the process?"
A backup that only covers the database, without the corresponding moodledata folder, is an incomplete backup in practice — it would be like recovering only the "list" of submitted assignments, without the files actually attached to each submission.
A full backup copies everything, from scratch, every time it runs — safer, but slower and heavier. An incremental backup copies only what changed since the last backup (of any type) — faster, but restoring requires the complete chain of increments. A differential backup copies everything that changed since the last full backup. Mature providers tend to combine these strategies to balance speed, storage space and ease of restoration.
Weekly backups might seem sufficient until you actually calculate how many assignments, grades and pedagogical interactions are generated — and potentially lost — in an entire week of normal activity. For active educational institutions, daily backup is the minimum acceptable standard — and specific moments in the term, like concentrated assessment periods, may justify an even higher frequency than that.
There's no point in having a daily backup if each copy is overwritten the very next day, with no accumulated history. It's important to keep a history of at least a few weeks — because not every problem is noticed immediately. Sometimes an error is only noticed days after it happened, and at that point you need to be able to go back to a specific point before the problem, not just to the previous day.
Having a backup and never having actually tested restoring it is like keeping an expired fire extinguisher in a closet — it looks like real protection, but it can simply fail exactly when you most need it to work. Testing the restore periodically, in a separate environment, is what turns a backup from "theoretical hope" into practical, proven guarantee.
Beyond the obvious cost of recreating lost content — hours of teachers' work redoing material, students resubmitting assignments they shouldn't have had to resubmit — there's a trust cost that's harder to reverse: once an institution visibly loses data, the perception of seriousness and professionalism takes a hit, even if the problem is technically fixed afterward.
Having a solid backup routine doesn't mean teachers and students can be careless — important files sent outside Moodle (by email or USB drive, for example) remain vulnerable to losses that no platform backup can recover. Automatic backup protects what's inside the system; good usage practices protect what stays outside it.
In many cases, the institution assumes — mistakenly, and without ever having confirmed it in writing — that "the hosting already takes care of that automatically," simply because it seems reasonable to assume so. It's worth directly asking your current provider, in writing: how often are backups actually performed, for how long are they available for restoration, and has there ever been a real, documented test of a full restore.
LMSHost offers Moodle hosting with high availability, daily backups and specialized support — the right size and the right price for your institution. We're in pre-launch with 50% off for 6 months for anyone who signs up now.