Backups in the app
Admin, Backups (/admin/backups). Needs module.backups and the
backup.manage permission.
The application takes its own encrypted, scheduled backups. Getting them off the machine is yours.
What you can do here
Section titled “What you can do here”Schedule backups to run automatically, with a retention policy.
Run one on demand, which is what you want before anything risky.
Verify a backup, which reads it back and confirms it decrypts and parses. A backup that has never been read is a hypothesis.
Export a portable per-tenant copy, for moving an institution’s data or handing it over.
The one rule
Section titled “The one rule”SECRETS_MASTER_KEY must be backed up somewhere that is not the server it
protects.
Backups are encrypted with it. A backup cannot be restored without that key.
The failure looks like this: you restore successfully, everything is there, you sign in, and every connector reports a decryption error. The data is fine and the vault cannot be opened. Every integration has to be reconfigured from scratch, assuming you still have the original credentials.
Put a copy in a password manager. Not in a file next to the backup, and not in the same cloud account.
Retention
Section titled “Retention”Set it. A retention policy that is not set means backups accumulate until the disk fills, and a full disk stops PostgreSQL and stops backups in that order.
Balance how far back you might need against how much disk you have. Nightly for a fortnight plus weekly for a term suits most schools.
Verification
Section titled “Verification”Verifying reads a backup back and checks it. Do it regularly, and schedule it if you can.
Verification is not the same as a restore drill. Verification proves the file is intact. A restore drill proves your process works, and that is a different and more valuable thing. See backups and restore.
When one fails
Section titled “When one fails”An alert is raised and the backup.failed [email](/configuration/email-
messages/) is sent to staff who can manage backups. That message cannot be
switched off, because the alternative is finding out during a restore.
The usual causes, in order:
- Disk full.
- Retention not pruning, so the disk filled.
- Permissions, after somebody changed the service account.
- The database was unreachable at that moment.
Run one on demand once you have fixed it, rather than waiting for the schedule to prove the fix.
What a backup contains
Section titled “What a backup contains”| Included | Not included |
|---|---|
| Every database table for the tenant | The master key itself |
| Encrypted connector credentials | Files in external object storage |
| Configuration, roles, workflow, templates | The application binaries |
| Audit log, within retention |
If you use external S3 for logos, photos and exports, back that bucket separately.
Portable export
Section titled “Portable export”Exports a per-tenant copy you can take elsewhere. It is a normal feature rather than a support request, which matters on managed hosting: getting your data out does not require anybody’s cooperation.
The export includes encrypted connector credentials, so restoring it elsewhere
needs the matching SECRETS_MASTER_KEY.
Managed hosting
Section titled “Managed hosting”Backups are taken and tested for you, including a restore drill. This screen still works, and the portable export is still yours to run whenever you like.
To request a restore, see support, restores and exits.
Permissions
Section titled “Permissions”| Permission | Allows |
|---|---|
backup.view | See backup history |
backup.manage | Schedule, run, verify and export |