How to Back Up Moodle to Backblaze B2 with restic (2026 Technical Guide)

Why Moodle backups are non-negotiable

A Moodle site is not just files on a disk. It is years of courses, every learner's grades and certificates, forum history, uploaded assignments, and configuration that took real effort to get right. Lose the server and, without a good backup, you lose all of it — and "the server" fails in more ways than people expect: a bad Moodle upgrade, a corrupt database, a fat-fingered DROP TABLE, a hosting account suspended, a disk that dies, or ransomware that encrypts everything including whatever "backup" sat on the same machine.

The uncomfortable truth is that a backup on the same server, or a snapshot in the same hosting account, is not a backup — it's a convenience copy that dies with the thing it was meant to protect. Real protection means an offsite, encrypted, automated, tested copy. This guide walks through exactly how we do that for the Moodle fleet we run — using restic to back up to Backblaze B2 — with example commands you can adapt, a cost comparison, and the trade-offs to plan for. (All keys, buckets and paths below are dummy placeholders.)

The 3-2-1 rule (the only backup strategy worth following)

The industry-standard rule is simple: keep 3 copies of your data, on 2 different types of media, with at least 1 copy offsite. For a Moodle site that usually means: the live site (copy 1), a local or provider snapshot for fast rollback (copy 2), and an offsite copy in object storage like Backblaze B2 (copy 3). The offsite copy is the one that saves you when the whole server is gone — and it's the one most institutions are missing.

What actually needs backing up in Moodle

Newcomers often back up one part and miss another, then discover at restore time that the pieces don't fit. A complete Moodle backup is three things, and you need all three from the same moment in time.

Miss the database and you have files nobody can log into. Miss moodledata and every uploaded assignment is a broken link. Miss config.php and you can't reconnect the site. For how these pieces sit on a real server, see our guide on Moodle hosting and server architecture.

Why Backblaze B2 for the offsite copy

Backblaze B2 is S3-compatible object storage priced for exactly this job. The headline reasons we chose it: storage is roughly $6 per TB per month, and — crucially for backups — egress (downloading your data back) is free up to three times your stored amount each month. That matters because the whole point of a backup is that one day you'll download it in a hurry, and providers that charge steep egress punish you precisely when you're already having a bad day. B2 also supports Object Lock, which makes snapshots immutable for a set period — ransomware can't delete or encrypt what it can't overwrite.

Why restic (not tar, rsync, or a plain S3 copy)

Restic is a modern backup tool built for object storage. Four properties make it the right engine:

Client-side encryption. Everything is encrypted with AES-256 before it leaves your server, so Backblaze only ever stores an opaque blob. It's zero-knowledge — your data is useless to anyone without your repository password.

Deduplication. Restic splits data into chunks and only ever stores each unique chunk once. Back up a 20 GB moodledata folder every 12 hours and you're not storing 20 GB each time — you store the handful of chunks that changed. This is what keeps the B2 bill tiny.

Incremental snapshots. Every backup is a full, browsable snapshot, but only new data is uploaded. You can restore any point in time without juggling "full vs incremental" chains.

Integrity checking. Restic can verify that what's in B2 is intact and restorable — so you find out about corruption on your schedule, not during a disaster.

The golden rule: never file-copy a live database

This is the single most common way DIY Moodle backups go wrong. Copying the MySQL/MariaDB data directory while the database is running gives you a torn, inconsistent snapshot that may not restore at all. Always take a logical dump with a consistent-read flag, which captures the database as it was at one instant without locking your site:

# MySQL / MariaDB — consistent dump, no long table locks on InnoDB
mysqldump --defaults-file=/opt/moodle-backup/db-backup.cnf \
  --single-transaction --quick --databases moodle \
  > /var/backups/moodle-dumps/moodle-db.sql

Use a dedicated read-only database user for backups — it only needs to read, never write:

CREATE USER 'moodlebackup'@'localhost' IDENTIFIED BY 'a_dummy_password';
GRANT SELECT, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES ON *.* TO 'moodlebackup'@'localhost';

Store its credentials in a MySQL option file (never on the command line, where they'd leak into the process list). One hard-won gotcha: that .cnf file must contain no # characters in the password line (a # starts a comment and silently truncates the password), no quotes, and no Windows line endings.

Setting it up: from zero to first backup

Install restic and point it at a Backblaze B2 bucket. We use one bucket for the fleet and one folder per VM, so each server's snapshots stay cleanly separated.

# 1) Install restic
sudo apt-get update && sudo apt-get install -y restic

# 2) Point restic at your B2 bucket (dummy values shown)
export RESTIC_REPOSITORY="b2:moodle-backups:moodle-vm-01"
export B2_ACCOUNT_ID="your_b2_key_id"
export B2_ACCOUNT_KEY="your_b2_application_key"
export RESTIC_PASSWORD_FILE="/opt/moodle-backup/.restic-pass"   # chmod 600

# 3) One-time: create the encrypted repository
sudo -E restic init

Now take the first snapshot — the DB dump, moodledata, and code together, tagged so you can find them later, with Moodle's throwaway cache directories excluded:

sudo -E restic backup \
  /var/backups/moodle-dumps/moodle-db.sql \
  /var/moodledata \
  /var/www/moodle \
  --tag site=learn.example.com --tag type=full \
  --exclude /var/moodledata/cache \
  --exclude /var/moodledata/localcache \
  --exclude /var/moodledata/temp

A tiny wrapper script that dumps the database and then runs that restic backup is all the "automation" you need — a few dozen lines of shell. That's the whole point: robust backups don't require a heavy product, just a couple of simple, well-tested scripts.

Scheduling with cron

Backups only protect you if they run without anyone remembering to run them. A single cron entry gives you a full backup every 12 hours:

# /etc/cron.d/moodle-backup  —  full backup at 00:00 and 12:00
0 */12 * * *  root  /opt/moodle-backup/cron-backup.sh

Point the script at a healthcheck/monitoring URL so you get alerted when a backup does not run — a silent cron failure is how people discover, months later, that they haven't had a backup since spring.

Retention and pruning

You don't want infinite snapshots, but you do want depth. Restic's policy language keeps a sensible ladder — recent days, then weeks, then months — and prunes the rest, reclaiming space in B2:

# Keep 7 daily, 4 weekly, 6 monthly snapshots, then prune the storage
sudo -E restic forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
  --prune

Note: if you enabled Object Lock, prune can't free space until the lock period expires — a deliberate trade-off for ransomware immunity.

Verifying and restoring — the part most people skip

A backup you have never restored is a hope, not a backup. Restic makes verification and point-in-time restore straightforward:

# List snapshots (each is a point in time you can restore)
sudo -E restic snapshots --tag site=learn.example.com

# Prove the repository is intact and restorable
sudo -E restic check

# Restore the whole site to a staging directory (non-destructive)
sudo -E restic restore latest --target /srv/restore --tag site=learn.example.com

# Load the database dump back into MySQL/MariaDB
sudo mariadb moodle < /srv/restore/var/backups/moodle-dumps/moodle-db.sql

For a full server loss, disaster recovery is the same commands pointed at a fresh VM: install restic with the same repository, B2 key and password, restore the files and the dump, recreate the site's real database user (the read-only backup user can't own the live DB), fix ownership, and repoint DNS. Because restic stores each snapshot as a complete point in time, you can also roll back to before a bad upgrade — pair this with our Moodle upgrade guide so you always have an escape hatch.

Cost comparison

The economics are why this approach scales across a fleet. Figures are directional 2026 list prices — check current pricing before you commit.

Because restic deduplicates, a typical small-to-mid Moodle site's ongoing storage is a few GB to low tens of GB, so the real-world B2 bill is often a rounding error — a few cents to a couple of dollars a month per site.

How EDZLMS runs this across a fleet

We operate this exact system for the Moodle sites we host — a config-driven kit where each site is one small config file, backups run every 12 hours to Backblaze B2, retention and integrity checks run automatically, and restores are drilled so we know they work. As a Bengaluru-based Moodle and eLearning company serving 400+ clients and 18,000+ learners, disaster recovery isn't optional for us. If you'd rather not build and babysit this yourself, our DevOps & support team sets it up, monitors it, and owns the restore when it matters. Explore the wider platform on our LMS page.

Running Moodle without a tested offsite backup is a bet you don't want to lose. Book a Free Demo and we'll set up restic-to-Backblaze backups and a drilled disaster-recovery plan for your Moodle — so a dead server is an inconvenience, not a catastrophe.