Backups in the app
Admin, Backups (/admin/backups). Needs module.backups. Viewing settings
and history requires backup.view; changes, downloads and restores require
backup.manage.
The application takes its own encrypted, scheduled backups. Getting them off the machine is yours.
Whole-school access and archive compatibility
Section titled “Whole-school access and archive compatibility”The changes below are included in the 0.12.0-rc.3 candidate source. Check the deployment status and installed version before using these restore rules.
Backups contain every campus and department in one school. Campus-limited
accounts cannot view or operate them. Once any department is configured,
including a paused department, the account also needs departments.manage.
Membership in several departments does not substitute for that permission.
ICT-only schools with no configured departments retain their existing backup
permissions, provided the account has unrestricted campus access.
New logical archives use format v3, recording unrestricted campus and department scope. The snapshot includes active and paused desks, their tickets, service answers and original question labels, history, attachments stored in the database, membership, schedules, rules and role assignments.
The in-app restore accepts a complete v3 archive for the same school and platform schema. It refuses missing tables, inconsistent row counts or missing relationship links before replacing data. A format v1/v2 archive, including one from an ICT-only school, can still be downloaded and checked for integrity, but cannot be restored from this screen: its completeness was not recorded. Keep those archives and their encryption keys. An operator must validate them against the matching release in an isolated restore drill and plan a maintenance restore. Do not edit a manifest to bypass this check.
A successful restore keeps paused departments paused. If restoring data fails, the database transaction rolls back; existing data and pause settings remain. Existing audit entries are retained and a successful restore adds its own entry. A Verified result checks readability and integrity; it does not override restore compatibility checks or replace a restore drill.
What you can do here
Section titled “What you can do here”Schedule backups to run automatically. Choose the frequency in words: every few minutes, hourly, daily, weekly or monthly. Cron sits underneath and is still available as Custom, and any expression the picker cannot put into words forces Custom on, so you read the expression itself instead of an approximation of it.
Run one on demand, 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.
Without the matching key, the encrypted archive cannot be decrypted or restored. If you instead restore a separate SQL dump or portable export, the database records may return while their connector credentials remain unreadable. Those credentials then require the original key or reconfiguration.
Put a copy in a password manager. Not in a file next to the backup, and not in the same cloud account.
Storage across updates
Section titled “Storage across updates”The 0.12.0-rc.3 candidate adds a dedicated Docker volume mounted at
/app/backups for application archives. Its updater inventories every school’s
configured path, including inactive schools, before replacing an existing API
container. It migrates default-path archives from the old container and refuses
unmounted or read-only custom paths. A successful migration does not create an
off-site copy.
Native candidate updates preserve archives under server/backups when swapping
program directories. Custom paths within replaceable program directories need
an operator migration; move them to persistent storage before updating. An older
installed updater does not acquire new behavior until it has itself been updated.
See updating and check the
candidate deployment status.
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 the database and then the backups.
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”When Alert on failure is enabled, an alert is raised and the backup.failed
email is sent if email is configured. The email
template itself cannot be disabled. In the 0.12.0-rc.3 whole-school backup
update, recipients must have backup management permission, unrestricted campus
access and, when departments exist, school-wide department administration.
Backup toasts use the corresponding viewing permission and the same scope rules.
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 portable export is compressed JSON, not an encrypted archive. Store and
transfer it as sensitive school data. Connector credentials inside it remain
encrypted, so recovering those credentials elsewhere needs the matching keyring.
Use a backup run’s Download action for the encrypted .pbk archive.
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 settings and history |
backup.manage |
Schedule, run, verify, download, export, delete and restore |