Backups (self-host)

Backup orchestration is a Hosted-only feature. For Self-Host deployments you own the backup story end-to-end — your data, your infrastructure, your retention policy.

What needs backing up

• Tenant databases. One Postgres database per Moodle pod (hub plus each spoke). Back up via your provider's native snapshot tooling or pg_dump on a cron. Aim for at least daily snapshots with a 30-day rolling window.
• Tenant moodledata. One PVC per Moodle pod. Back up via your CSI driver's snapshot mechanism, your storage backend's native replication, or a Velero-style cluster backup tool.
• Control-plane database. Single Postgres instance shared across the deployment. Same approach as tenant DBs but typically smaller and lower-RPO requirement.

What ships in the chart

The nucleus-moodle chart includes an opt-in CronJob that creates VolumeSnapshot resources against the moodledata PVC on a schedule, with retention pruning by label selector. Enable it via Helm values:

backups:
  enabled: true
  schedule: "0 2 * * *"   # 2am daily
  retention: 30           # keep 30 most recent

The CronJob needs a StorageClass with VolumeSnapshot support and a VolumeSnapshotClass named csi-snapshotter (or override the name via values). It does not back up the Moodle database — that's on you, since database snapshots and PVC snapshots have different semantics and you almost always want them coordinated.

Restore drills

Run a tenant-restore exercise quarterly so you know the procedure works before you need it. The recommended pattern:

1. Pick a non-production tenant.
2. Snapshot the current state (so you can roll back the drill).
3. Restore from a backup taken yesterday.
4. Verify the tenant is reachable, courses are intact, and federation reconnects.
5. Document the time-to-recover.

Support can review your runbook on request.

Hosted alternative

The hosted product includes managed backups (daily snapshots, 30-day retention on Standard / 90-day on Dedicated, cross-region replication on Dedicated, 1h–24h RPO depending on tier) and a documented DR playbook. See hosted backups. The hosted design is also a useful reference if you're modelling your own backup story along similar lines.