Scheduling Backups

A schedule runs a backup on a cron pattern. A schedule is one row in Postgres, and that row is the scheduler — its next_run_at column is what makes it fire. There's no registration anywhere else that could fall out of step with it.

Manage them from the Schedules page.

Creating a schedule

Below those sit the same pg_dump flags as a one-off backup — see the flag reference.

Presets and cron

The presets cover the common cases and write the cron expression for you:

Choose Custom to write the expression yourself. pgbr requires exactly five fields — minute hour day month weekday — and validates the expression before saving, so a malformed pattern is rejected rather than silently never firing.

┌───────────── minute (0–59)
│ ┌─────────── hour (0–23)
│ │ ┌───────── day of month (1–31)
│ │ │ ┌─────── month (1–12)
│ │ │ │ ┌───── day of week (0–6, Sunday = 0)
│ │ │ │ │
* * * * *

The form shows a plain-English description of whatever expression is in the field, which is the fastest way to catch a cron you've misread.

Timezones

Schedules store an IANA timezone and the cron fires in that zone, so a "daily at 2am" schedule stays at 2am local across DST changes rather than drifting by an hour twice a year.

The form defaults to your browser's timezone. The database column defaults to UTC.

Retention

Keep last bounds growth. With 7, each successful backup from that schedule prunes anything beyond the newest 7 — deleting both the row and the artifact. The range is 1–365. Leave it unset to keep everything forever.

What retention does not touch:

• Failed backups are always kept. A schedule that has been failing for a week shouldn't quietly erase the evidence.
• Manual backups — pruning only ever considers backups from the same schedule.
• The lifetime backup counter, which only counts up.

Pruning runs after each successful backup from that schedule. A retention failure is logged but never fails the backup — an unpruned bucket is a smaller problem than a lost backup.

Enabling and disabling

The toggle sets or clears next_run_at. A disabled schedule keeps its row and its history and simply doesn't run; enabling it computes the next occurrence from now.

Deleting

Deleting removes the schedule row, and that's the whole operation. Backups it created are kept — their scheduleId becomes null and their artifacts stay. You lose the schedule, not its output.

Once unlinked, those backups are no longer pruned by anything. Retention only ever applies through a live schedule, so delete a schedule and its old backups become yours to manage.

How schedules fire

Every 30 seconds a worker takes a transaction-scoped advisory lock — so exactly one replica ticks, however many you run — and, for each enabled schedule whose next_run_at has passed, queues a backup and computes the next occurrence. Both writes are in the same transaction: a schedule cannot fire without being rescheduled, or be rescheduled without firing.

Because the schedule row is the only state involved, there is nothing to reconcile and nothing that can drift. Creating, editing, enabling, or disabling a schedule is a single write to a single row.

Related