Instance Snapshots
Coming from another cloud?
▸AWS·Amazon Machine Images (AMIs)
This Quake AI feature maps to AWS’s Amazon Machine Images (AMIs).
▸Azure·Snapshots
Snapshots
- Snapshots of managed disks (Microsoft.Compute/snapshots), billed on used size, separate from volumes unlike Cinder volume snapshots integration.
- Supports incremental snapshots for efficiency, ZRS storage in zones.
- API /providers/Microsoft.Compute/snapshots vs Nova/Cinder volume snapshot APIs.
- Primarily for disks, not full instances; instance snapshots via images instead.
▸DigitalOcean·Volume Snapshots
Volume Snapshots
- Proprietary API /v2/volumes/{volume_id}/snapshots instead of OpenStack /v3/{project_id}/snapshots.
- Explicitly crash-consistent only, no automatic filesystem consistency (requires manual power-off/sync); OpenStack snapshots can use quiescing drivers for apps like databases.
- Snapshots billed separately based on block-level used size (may exceed filesystem due to trim); OpenStack typically similar. See the DigitalOcean pricing page for current rates.
- Can create new volumes only in same region as snapshot; OpenStack snapshots more flexible for cross-region with upload/download.
▸Google Cloud·Machine Images (full VM state capture)
OS images
- Public images shareable across projects (e.g. debian-cloud); OpenStack typically tenant-private.
- Image families point to latest version; no OpenStack equivalent.
- Custom images stored in Cloud Storage with licensing fees for premium OS.
▸Hetzner·N/A (No equivalent)
N/A (No equivalent)
- No support for volume snapshots in API or console; explicitly stated 'we do not provide Backups or Snapshots for Volumes' and server snapshots exclude volumes.
- Workarounds like rsync/dd to new volume required, unlike Cinder's create/delete/get/manage_snapshot API.
- Recent confirmations (2026) show no addition of feature.
- Created as Image type='snapshot' via server action; stored under /images.
Instance snapshots
Instance snapshots capture the full state of a running instance (root disk data, memory, and configuration) as an image you can store, clone from, or restore to. They are part of the Compute service and are stored in the Images service (OpenStack Glance) once created.
What a snapshot contains#
When you create a snapshot, the platform communicates with the hypervisor to capture everything on the instance's root disk along with relevant state information. The result is stored as an image in Glance, where you can list it, inspect its metadata, share it, or delete it, like any other image.
Snapshots are immutable once created. You cannot modify a snapshot; you can only create a new one or delete an existing one.
When to use snapshots#
Take a snapshot before a risky change: an OS upgrade, a major application deployment, or a configuration overhaul. If something breaks, you can launch a new instance from the snapshot to restore the previous state.
Snapshots also serve as cloning tools. Launch multiple instances from the same snapshot to create identical environments for testing, staging, or horizontal scaling. For migration between hosts or regions, a snapshot provides a portable image of your workload.
How snapshots fit the storage picture#
Instance snapshots capture the full VM state including the root disk. Volume snapshots capture only an individual storage volume at a point in time and depend on the original volume. Volume clones create a new identical volume you can attach to another instance immediately.
Choose instance snapshots when you need the complete machine image. Choose volume snapshots or clones when you need to protect data on specific attached disks independently of the instance itself.
Practices for snapshot management#
Snapshots consume storage in the image repository. Clean up old snapshots you no longer need to avoid unnecessary storage use. Establish a naming convention (include the date and purpose) so you can identify what each snapshot represents months later.
Because snapshots are immutable, there is no risk of accidental modification, but there is also no way to update one. If the instance has changed, take a fresh snapshot instead of trying to patch the old one.
Further reading#
On this platform:
- Create an instance snapshot: step-by-step snapshot creation
- Images: how snapshots become reusable images
- Volumes: volume snapshots for persistent storage protection
- Instance snapshot console: Console reference for snapshot management
- Instance snapshots CLI reference:
openstack server image createcommands
External resources:
- OpenStack Glance documentation: upstream Image service that stores and manages instance snapshots