Backup policies

Backup policies

Reusable schedule + retention rules attached to your data sources.

Not verified yet

A backup policy is a named template that combines:

  • A cron schedule for when backups run.
  • A timezone the schedule is interpreted in.
  • A retention rule – keep for N days, or keep the last N backups, or both (whichever cap is hit first).

Define a policy once and attach it to many data sources. Pull all production databases under daily-7day; pull dev databases under weekly-1week.

Why policies are separate from data sources

Most teams want the same schedule across many databases. Defining the schedule once and reusing it means:

  • Changing a retention window updates every attached database.
  • Reviewing your overall backup posture is one screen, not one per database.
  • Onboarding a new database is two clicks (connect + attach), not a fresh policy each time.

Schedule

Standard 5-field cron (min hour day month weekday):

0 3 * * *        every day at 03:00
0 */6 * * *      every 6 hours
30 1 * * 1       every Monday at 01:30

The form translates the expression back to English so you can sanity-check before saving.

Timezone

The schedule is interpreted in the timezone you pick. 0 3 * * * in Europe/Prague and the same schedule in America/Los_Angeles fire at different UTC times. Pick the timezone your team operates in.

DST shifts move the schedule with the clock, so "every day at 03:00 local" genuinely means 03:00 local in every season.

Retention

Two caps you can combine:

  • Days – keep backups for at least N days; delete anything older.
  • Last N – keep the most recent N backups regardless of age.

The retention worker runs daily and applies both caps. A backup is deleted only when both allow it (i.e., it's older than the day cap and not in the last-N window).

The retention worker writes an audit entry for every deletion (with the reason and bytes freed), feeding storage billing.

Behaviour and edge cases

  • Editing a policy applies immediately to every attached data source. Retention changes affect future cleanup runs; existing backups are re-evaluated against the new rule on the next worker pass.
  • Detaching a policy from a data source stops new runs for that pair but keeps existing backup files in storage until they age out per the policy's retention rule.
  • Two policies attached to the same data source is allowed. Useful for e.g. a hourly-1day and a daily-30day policy on the same database. Each policy creates its own backup files on its own schedule.

On this page