Backup

Backup

Plum can export the whole instance to a single JSON file, on demand or on a schedule, and push it to any S3-compatible bucket. Settings → Backup (owner only). Backup is instance-level — one database, so its schedule and target live on the organisation, not on a project.

What's in a backup

• The organisation name, logo and session timeout — so a restore doesn't reset them
• Every project, with its settings, its framework, and who is a member of it
• Test suites, cases and steps
• Test runs and recorded manual results
• Users, including their password hashes, so people can sign in again after a restore
• Runner definitions, without the live node token — nodes re-issue one on the next plum node start
• Schedules (cron jobs)

Never included: reports, their session recordings, and failure screenshots — they're large, and there's no toggle to add them. pg_dump the Postgres volume (plus the data/screenshots/ folder) for a full physical backup that does include report history.

Also keep the data/ folder beside docker-compose.yml. It holds .plum-jwt-secret and .plum-node-secret, and neither is in the database dump. Lose the first and every session is invalidated on the next start; lose the second and nodes can no longer re-register. Both are regenerated silently, so a restore that skips data/ looks fine until people are logged out.

On demand

• Download — get the JSON file now.
• Import — restore from a file. Existing records are overwritten; cron jobs are re-scheduled after import.

A restore matches what it already has rather than trusting the ids in the file: projects by slug, suites and cases by their TS-/TC- display id within that project, users by email. So a file restores cleanly into the instance it came from and into a fresh one, and a project in the file that this instance doesn't have is created (keeping its framework). Test cases keep their display ids, and the counters that issue the next one come across too, so nothing is handed a number that is already taken.

A file written before Plum understood more than one project carries no project information, so everything in it restores into your first project. Re-download a backup after upgrading to get one that keeps its projects apart.

Scheduled to S3

Fill in the S3 target and enable the schedule:

Field	Notes
Enabled	on/off
Schedule (cron) + Schedule Timezone	default 0 2 * * * (2 AM). Timezone is set here, independent of any project.
Endpoint	leave blank for real AWS S3; set it for Cloudflare R2, Backblaze B2, MinIO or on-prem (Plum then uses path-style addressing)
Region	auto if blank
Bucket, Access key, Secret key
Prefix	optional key prefix, e.g. plum/backups/

Each run uploads <prefix>plum-backup-YYYY-MM-DD.json. The last run's time and status show on the page.

Restore from S3

Restore from S3 pulls a backup already in the bucket and restores it directly — no manual download. Existing records are overwritten; cron jobs are re-scheduled.

Moving to a new server, or recovering a lost one

1. On the old server (if it's still reachable): Settings → Backup → Download (tick Include reports if you want history).
2. Stand up a fresh server (plum server start) and open the UI.
3. On the first-run setup page, click "Recovering a lost server? Restore from a backup instead" and upload the file — no need to create a throwaway owner account first, this works precisely because none exists yet. It only stays open while the server has zero users; once any account exists, restoring falls back to Settings → Backup → Import, owner-only, same as normal.
4. Re-register runner nodes — node tokens are not carried in a backup.

Restoring from S3 still needs a logged-in owner, since the bucket/keys are typically only known to a fresh server if you re-enter them in Settings → Backup first.