Attach a policy to a datasource

A policy doesn't run by itself — it runs against the datasources it's attached to. Attach daily-30day to ten databases and all ten back up on that schedule, with that retention, into that destination — each producing its own independent archives and job records.

Attach in the dashboard

The first attachment usually happens during the connect flow — its last step is exactly this (pick a policy card, Complete Setup).

For an existing datasource:

1. Open the datasource's detail page.
2. In the Backup policies card, click Add backup policy.
3. Pick the policy. Each card shows the policy's cron schedule and the destination it writes to — "Pick the policy that matches the schedule + retention + destination you want for this datasource."

The first run fires at the next matching cron time; the Next Run column on the policies table (and Next Backup in the details grid) shows when.

What an attachment carries

Beyond binding the pair, each attachment has its own settings, visible in the datasource's policies table:

• Status (Enabled / Disabled) — the per-pair switch; see Pause and resume.
• Priority — lower number = higher priority. Used when one policy must be chosen for the datasource: Run backup now preselects the highest-priority enabled attachment (marked "(default)" in its picker).

Priority and enabled are set via the CLI or API (PATCH /datasources/{id}/policies/{policyId}).

Attach multiple policies to one datasource

Layering policies is the intended pattern for tiered retention:

• hourly-2day — frequent snapshots on a tight window,
• daily-30day — medium-term recovery,
• monthly-1year — long-term archive.

Each fires independently on its own schedule and writes its own archives; retention is evaluated per policy. Storage costs are additive — you're keeping three tiers' worth of archives.

Detach a policy

In the datasource's Backup policies table, use the row's delete action and confirm. Detaching:

• stops future scheduled runs for this pair from the next tick,
• keeps every existing archive — they continue aging out under the policy's retention,
• keeps historical job records,
• is refused with a conflict if a job for this attachment is currently queued or running — let it finish first.

From the CLI:

nrc snapdb policy list --datasource <id>
nrc snapdb policy detach --datasource <id> --policy <policyId> --yes

Attach and detach events are audited (policy.attached, policy.detached).