Create a backup policy

The policy form field by field — schedule, timezone, retention, destination — plus editing and deleting.

A policy bundles a schedule, retention rules, and a storage destination — separate from any datasource so you can reuse it across many.

In the dashboard

Open Backup policies

Backup → Backup Policies → New Policy.

Fill in the form

Policy name — daily-7day, hourly-prod, weekly-archive — something you'll recognise in a picker. Unique within the organization.
Keep last n — the retention floor: "Number of most recent backups to keep. Must be at least 1."
Timezone — the timezone the schedule is interpreted in. Pick any IANA timezone from the searchable list; it defaults to your browser's timezone, so 0 2 * * * fires at your local 2 a.m.
Schedule (cron) — a 5-field cron expression, validated against what the scheduler can actually run (ranges like 1-5, lists like 0,30, and 7 for Sunday are all accepted). A plain-English translation appears under the field as you type (0 2 * * 1-5 → "At 02:00 AM, Monday through Friday").
Number of retention days — "Number of days to retain backups. Must be at least 1."
Storage destination — where every archive under this policy lands: a Norcube-managed destination or a BYO destination you've registered, each shown with its bucket name. "Every datasource attached to this policy writes archives here."

How keep last n and retention days combine — deletion only when both agree — is explained in Retention.

Create

Click Create policy. The policy exists but runs nothing until it's attached to a datasource.

In Backup Policies, use the row's edit action. Same form, and the dialog is explicit about the semantics: "Update the schedule and retention rules for this policy. Changes apply to future backup runs only."

Cron / timezone changes take effect at the next scheduler tick — attached datasources move to the new schedule immediately.
Retention changes are applied by the next hourly retention pass, which re-evaluates every existing backup under the new rules. Tightening retention deletes newly-out-of-policy backups on that pass; loosening it can't restore anything already deleted.
The destination — pick a different one and future backups land there; archives already written stay in the old destination and age out under this policy's retention.

Delete a policy

Use the row's delete action. Deletion is refused with a conflict while the policy is attached to any datasource — detach it from each one first. Historical job records created under the policy survive its deletion.

Policy creation, updates, deletion, and every attach/detach are recorded in the audit log (policy.created, policy.updated, policy.deleted, policy.attached, policy.detached).

Choosing sensible values

Scenario	Schedule	Keep last n	Retention days
Production, moderate change rate	`0 3 * * *` (daily)	7	30
Production, high change rate	`0 /6 * *` (6-hourly)	12	14
Staging / dev	`0 4 * * 1` (weekly)	2	30
Long-term archive (layer on top of daily)	`0 5 1 * *` (monthly)	12	365

Layering two policies on one datasource (short-retention frequent + long-retention sparse) is often better than one policy trying to do both — see Attach multiple policies.