Snapshots
Capture volume recovery points and restore them into new volumes.
Snapshots capture a volume's block state at a point in its operation history. They support short-term rollback and cloning within the source region.
Consistency modes
Crash-consistent capture requires readable storage and represents a block state similar to an unclean shutdown. Guest-assisted capture requires a responsive guest agent and freezes participating filesystems during capture.
Application-coordinated capture also uses the workload's prepare and resume hooks. The application procedure establishes which checkpoint or backup mode makes its data recoverable; a generic filesystem freeze cannot establish that boundary for every database.
A filesystem freeze does not establish database consistency by itself. Use application backup hooks or a documented database recovery procedure when a workload needs a coordinated recovery point.
Create a snapshot
Open Volume → Snapshots → Create snapshot, select a consistency mode, and name the recovery point. Guest-assisted snapshots require the volume to be attached to a responsive guest with the required agent capability.
Infra records the requested mode, capture time, source volume ID, and operation ID. The snapshot becomes Ready after its metadata and required storage state are available. A requested snapshot is not a usable recovery point while its operation is incomplete.
A failed prepare or freeze hook stops that snapshot attempt. Resume hooks run after capture or failure when the guest remains reachable. An operator should verify application and filesystem state if the guest becomes unreachable during a freeze interval.
Multiple volumes
Select a consistency group for an application that spans several volumes. Its membership revision pins the required recovery set. Infra coordinates the group's capture operation and records a common group ID. If a required member cannot be captured, the recovery point is incomplete and cannot be selected as a complete application restore.
Applications that span multiple guests still need an application-level coordination procedure. Grouping volume IDs does not establish transaction consistency between independent databases.
Restore and clone
Select a ready snapshot and choose Create volume. The new volume belongs to the same project and region unless an allowed ownership transfer is selected. It receives a new ID and retains the captured data.
Infra does not overwrite an attached volume during restore. Validate the new volume on an isolated droplet before replacing the original attachment. Keep the original until application verification and rollback requirements are met.
Retention and capacity
Snapshots retain changed blocks under the source storage policy. Their displayed logical size is not necessarily the physical space retained. A small amount of new guest data can cause additional block retention across many snapshots.
Deleting a snapshot removes its recovery reference. Physical capacity becomes available after dependent snapshots and cleanup permit it. A snapshot used by an image or retention lock cannot be deleted until that dependency is removed.
Snapshots in the same pool share its failure risks. Use backups to copy recovery data to an independent destination and Disaster recovery to validate restoration.