Skip to main content
PATCH
Update snapshot policy
Requires the IAM action storage:UpdateSnapshotPolicy. See STORAGE permissions for the full list, what each one covers, and an example policy.

Authorizations

Authorization
string
header
required

An OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. This is the recommended way to authenticate.

Get one by exchanging a service account's access key pair at POST /v1/oauth/token with grant_type=client_credentials. It is the standard client-credentials grant, so any OAuth-aware library will obtain and refresh it for you.

Tokens last an hour by default. The same access key pair is separately your AWS SigV4 credential for the S3-compatible object endpoint, which speaks nothing else.

Path Parameters

volume_id
string<uuid>
required

Volume ID

policy_id
string<uuid>
required

Snapshot policy ID

Body

application/json

Names are fixed at creation because they form the CRN used by IAM policies. Sending name in an update, including an unchanged, empty or null value, returns a validation error. PATCH semantics — an omitted field keeps its current value. Changing interval_minutes re-bases the next run off now, so shortening a daily schedule to hourly takes effect within the hour.

description
string
Example:

"Nightly snapshots of the database volume"

enabled
boolean

false pauses the policy, true resumes it. Pausing stops the whole policy — no snapshots are taken and none are deleted, so a paused schedule cannot lose you history. Resuming applies the retention window again on the next run, so anything sitting outside it by then — because you lowered retention_count while paused, say — is reaped on that run.

Example:

false

interval_minutes
integer

Minutes between snapshots — a minimum gap, not an exact cadence. A periodic pass takes whatever has come due and re-bases each policy's next run off the moment it ran, so a snapshot lands at or after interval_minutes and never before, and can land a minute or two later when the pass is busy. A window the pass misses costs one snapshot rather than producing a catch-up burst afterwards.

The floor is one minute, because that pass is what evaluates the schedule and nothing finer can be honoured; the ceiling is 30 days. Sub-hourly intervals multiply snapshot churn and count against the snapshots quota, so pick the largest interval that meets your recovery point objective.

Required range: 1 <= x <= 43200
Example:

1440

retention_count
integer

How many of this policy's snapshots to keep. When a fire takes the count past this, the oldest go first.

Required range: 1 <= x <= 256
Example:

7

retention_days
integer
default:0

Optional age bound, applied on top of retention_count: a snapshot outside EITHER window is reaped. 0 means no age bound. The single newest snapshot is exempt from the age bound, so a volume that could not be snapshotted for longer than the window never loses its whole history.

Required range: 0 <= x <= 3650
Example:

30

tags
object
Example:

Response

Snapshot policy updated

snapshot_policy
object
required

A schedule attached to one volume: take a snapshot every interval_minutes, then keep at most retention_count of the snapshots this policy created.

Retention only ever deletes snapshots the policy itself created (those carrying its snapshot_policy reference) — a snapshot taken by hand is never reaped. It also never deletes a snapshot something depends on: a snapshot a volume was created from, including a restore still in progress, is skipped and re-examined later.