Scheduled backups run automatically on a cron-style schedule and keep a rolling set of recent backup files, so a recent configuration exists to restore from without you having to remember to export one manually.
Before you begin#
- Access to the backup rules area of Settings.
- A destination path to store backups, if you're not using the default location (not available on Docker builds: Docker deployments use the default location only).
- A sense of how many recent backups you want retained.
Create a backup rule#
- Open the backup rules area and create a new rule.
- Enter a Rule Name.
- Set Include secrets or Exclude secrets: this controls whether the connection secret vault is bundled into each backup this rule produces.
- Set the Cron Schedule: pick a frequency preset (Daily, Weekly, Monthly, Yearly) or build a custom schedule. A human-readable summary of the schedule is shown as you build it.
- Set the Backup Path, if you want somewhere other than the default location.
- Set a Backup Name Pattern: this supports date/time substitutions (year, month, day, hour, minute, second) so successive backups get distinct filenames.
- Set Number of Backups to Keep: a count from 1 to 100. Once a rule has produced more backups than this, the oldest are removed automatically. Retention is count-based only: there's no separate age-based expiry.
- Save, and enable the rule.
Select Run Now on any rule to trigger a backup right away, independent of its schedule: useful before a risky change, or to confirm a new rule actually works.
Monitor whether backups are succeeding#
Each rule's card shows its schedule summary, Last successful run (or Never), how many files it's currently keeping, and (only if its most recent run failed) a Last run error message. There's no separate per-run history log beyond this: a rule with no error shown and a recent Last successful run date is working; a file actually appearing in Previous Backups is itself confirmation that run succeeded.
Restore from a backup#
Open Previous Backups, find the file you want (each entry shows its size, timestamp, and version), and select Restore backup. The confirmation step that follows shows the archive's version, export date, and whether it includes secrets before you commit.
Warning
Restoring is a real, immediate action: it replaces current configuration and restarts the server. There's no dry-run, test-restore, or integrity-check step before it happens. Confirm you have the right file before selecting it.
If you get stuck#
What you see | What to try |
|---|
A rule shows Last run error. | Read the error message on the rule's card: check the backup path is reachable and writable, and that the schedule and retention settings are valid. |
Backups aren't appearing on schedule. | Confirm the rule is enabled, not just created: a disabled rule won't run. |
You're not sure a rule actually works. | Select Run Now and confirm a new file appears in Previous Backups. |
You want to verify a backup is restorable before you need it. | There's no built-in test-restore: the only way to confirm is a real restore, which replaces current configuration. Plan accordingly, for example by testing against a non-production instance. |
Old backups aren't being cleaned up. | Check Number of Backups to Keep: cleanup is count-based, so a high number keeps files around longer than you might expect. |
Where to go next#
