07 / 13
Schedules & retention
cron schedules, freshness thresholds, pause semantics, retention policy
Schedules
Per database, in the "Schedule & heartbeat" drawer:
- Cron expression: standard five fields (minute hour day month weekday) or
@daily-style aliases; empty = manual only. Timezone: IANA names (e.g.Europe/Berlin). - Freshness threshold (hours): the newest successful backup older than
this marks the database EXPIRED;
0disables. - Pause: suspends scheduled runs and stops new expiry events for that database (already-queued notifications still deliver); manual "Back up now" keeps working.
- First enable: the cursor starts at zero, so the first tick after saving fires immediately rather than waiting for the next cron instant.
A due run whose database already has a pending/running job is skipped (one job per database); the log states the cursor did not advance and the slot re-fires once the in-flight run finishes.
Retention (two tracks)
Local: the newest SB_LOCAL_KEEP ciphertexts per database; the newest
successful backup and the newest restore-verified backup are always protected.
Artifacts of failed/canceled/interrupted jobs are reclaimed after
SB_FAILED_ARTIFACT_TTL_HOURS.
Remote: days/copies set per destination, subject to the same two anchors:
- the newest committed backup (the anchor) is never auto-deleted;
- the newest restore-verified backup is never auto-deleted.
Remote retention never performs destructive cleanup without an anchor (no
successful commit ever). The failed-artifact TTL reclamation is NOT anchor-
protected, though: if every backup failed to upload, their local ciphertext is
still reclaimed after the grace window — export what matters first, or set
SB_FAILED_ARTIFACT_TTL_HOURS=0.
Last updated