Skip to main content

​
Snapshots

A snapshot is a point-in-time copy of one volume:
Go to Storage → Snapshots and choose Create Snapshot, then pick the Volume and give it a Name. The volume’s own page has a Create Snapshot button that opens the same form with that volume already selected; it is disabled unless the volume is available or in_use.
1

Take it

Allowed against a volume in available or in_use — you do not have to detach to snapshot. The snapshot is created asynchronously (202, status creating).
2

Wait for available

Poll GET /v1/snapshots/{snapshot_id}. available means the snapshot is complete and can be restored from; error means an active error fault — read faults.
Snapshot names are fixed after creation because IAM policies address snapshots by their CRNs. Updates containing name return a validation error, including unchanged, empty or null values. Existing snapshots retain their current names. A snapshot name is unique per volume, so nightly on two different volumes is fine. Snapshot responses separate stored data from the capacity needed to restore: Snapshots share unchanged data. Each snapshot shows its attributed share, and summing the shares gives the total for that volume’s snapshot chain. Deleting a snapshot can move its share to a surviving snapshot. Its displayed size is not a promise of how much space deleting it will free. Measurements run asynchronously; reads do not trigger a storage scan. Snapshots currently depend on their source volume. You must delete its snapshots before deleting the source volume. A snapshot used by a restored volume is also protected from deletion while that dependency exists.
Snapshotting an attached volume captures the device as it is at that instant, including anything the guest has buffered but not yet flushed. For a database or anything else with in-memory state, quiesce or flush inside the guest before taking the snapshot if you need it to be application-consistent.

​
Billing

From 2026-10-16 00:00 UTC, snapshot billing uses measured retained logical data, with unchanged data counted once across a volume’s snapshot chain. Measurements exclude compression and replication effects. A first snapshot’s retained data counts even when it still shares blocks with the live volume. The volume remains billed separately by its provisioned capacity. For example, two identical snapshots containing 10 GiB of written data on a 100 GiB volume retain 10 GiB across their chain. Later overwrites can retain multiple versions of the changed data. For each UTC hour, billing records the first valid measured total for the chain and charges it once after the hour ends. Later changes affect future hours. If an hour has no valid measurement, no snapshot usage is charged for that hour; the volume’s capacity is never substituted for a missing measurement. Snapshot prices remain unchanged. The price catalogue’s GB-month unit uses 1,073,741,824 bytes per GB and the actual number of hours in the UTC calendar month: each hourly quantity contributes retained_bytes / 2^30 / hours_in_month GB-month. Usage before the change keeps the previous capacity-based calculation; previous charges are not recalculated.

​
Restoring from a snapshot

Restoring means creating a new volume from the snapshot. There is no in-place rollback:
On Create Volume, switch Source to From snapshot and choose the Snapshot. Size (GB) must meet the snapshot’s minimum restore capacity, and the Tier is yours to pick — a restore is not tied to the tier the source volume was on.Storage → Snapshots also has a Create volume from snapshot row action that opens the same form with the snapshot filled in.
The snapshot has to be available. The new volume’s size_gb must be at least the snapshot’s restore_size_bytes divided by 2^30 — you can restore onto a larger volume, never a smaller one. The restored volume records source_snapshot as a ResourceRef, which is also what stops retention from reaping a snapshot something still depends on. Snapshot responses include volume and, for scheduled snapshots, snapshot_policy as ResourceRefs with id, crn, and name.

​
Snapshot policies

A policy is a schedule attached to one volume: take a snapshot every interval_minutes, then keep at most retention_count of the snapshots that policy created.
Open the volume’s Snapshot schedules tab and choose Create schedule. Fill in Name, Every (minutes), Keep, and optionally Also delete after (days), then choose Create schedule.Each row has actions to edit, pause or resume, and delete that schedule. Editing opens its settings; Save applies your changes.
​
up to 16 policies per volume
required
Each policy has its own interval, retention settings, and enabled state. Names must be unique within the volume. Different volumes can use the same name. Overlapping schedules create separate snapshots, each counting toward your snapshot quota. Shared stored data is counted once. A seventeenth policy returns 409.
You can also set schedules on each new boot or data volume while launching an instance.
​
1–43200
required
A minimum gap, not an exact cadence. A snapshot lands at or after the interval and never before, and can land a minute or two late when the scheduling pass is busy. The floor is one minute because that is how often the pass evaluates schedules; the ceiling is 30 days.
​
1–256
required
How many of this policy’s snapshots to keep. When a run takes the count past this, the oldest go first.
​
0–3650, default 0
An optional age bound applied on top of the count: a snapshot outside either window is reaped. 0 means no age bound.
The first snapshot lands one interval from now. Attaching a schedule is not itself a request for a snapshot — use POST /v1/snapshots if you want one immediately.
Snapshot-policy names are also fixed after creation: they form the policy’s CRN used by IAM. When editing a schedule, omit name; supplying it, even unchanged, empty or null, returns a validation error. You can still change the interval, retention settings, description, tags and enabled state. Existing policies retain their current names. Scheduled snapshots are named <policy>-<UTC timestamp>, for example nightly-20260115T000000Z, and they inherit the policy’s tags so a listing tells you which schedule produced them without a second lookup.

​
What retention will never delete

A schedule is also an automatic deleter, so the limits on what it can remove matter more than the limits on what it keeps:

Snapshots you took by hand

Retention only matches snapshots carrying this policy’s snapshot_policy. A snapshot a person created has none and is never a candidate, whatever tags it has.

Snapshots something depends on

A snapshot a volume was created from — including a restore still running — is skipped and re-examined on a later run. It becomes reapable once the dependent volume is gone.

The single newest snapshot

The newest snapshot is exempt from the age bound. A volume that could not be snapshotted for longer than the window never loses its whole history that way.

Anything, while paused

enabled: false stops new snapshot runs and retention deletions from being claimed. Work already claimed before the pause may finish. Other policies on the same volume keep running independently.
Resuming a paused policy applies the retention window again on its next run. If you lowered retention_count while it was paused, everything now outside the window is reaped on that run.

​
Reading a schedule’s state

GET /v1/volumes/{volume_id}/snapshot-policies/{policy_id} returns where the policy is in its cycle: faults is the field to check on a schedule that has stopped producing snapshots — it carries reasons like an exhausted snapshots quota, or a volume that was mid-extend when the window came around. Dispatch, execution and retention each have their own code and recover independently. The Snapshot schedules table shows each policy’s next and last run and any active faults, so a stalled schedule can be read without leaving the console.
A missed window costs one snapshot, not one per window missed. next_run_at is re-stamped to now + interval_minutes each time the policy fires, never to previous + interval, so a schedule that could not run for six hours takes a single snapshot when it resumes rather than a catch-up burst. Changing interval_minutes re-bases the next run off now too, so shortening a daily schedule to hourly takes effect within the hour.
Deleting a policy detaches the schedule and keeps every snapshot it already took — they become ordinary snapshots you own outright and are never reaped again. Other policies on the volume and their snapshots are unchanged. Work already claimed before deletion may finish. Delete the snapshots themselves if that is what you meant.

​
Resource references

Use volume with an account-owned volume UUID, CRN, or exact name when creating a snapshot. Snapshot-policy endpoints identify the volume by UUID in the path. Snapshot CRNs include their parent, for example crn:storage:sa-saopaulo-1:my-account:volume/data/snapshot/nightly. List filters use exact name and crn matches. A snapshot name filter requires volume; snapshot_policy accepts a policy UUID or nested CRN, or a policy name when volume is supplied. Restore requests use source_snapshot with a UUID or nested CRN, since they do not pin a source volume. Malformed CRNs return 400; valid CRNs outside the requested account, region, or resource type return an empty page.