Disks and persistent storage
Explanation · Updated Jun 2026
Coming from another cloud?
▸AWS·Amazon EBS volumes
Amazon EBS volumes
- Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
- Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
- Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
- API via EC2 CreateVolume; differs from Cinder create_volume.
▸Azure·Managed Disks
Azure Managed Disks
- Azure Managed Disks are fully managed with automatic redundancy (3 replicas, 99.999% SLA); Cinder durability depends on backend.
- Predefined disk types (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) with fixed performance tiers; Cinder uses volume types with configurable QoS.
- Disks billed on provisioned size regardless of use; Cinder billing typically on provisioned size too but varies by provider.
▸DigitalOcean·Volumes
Volumes
- Uses proprietary /v2/volumes API instead of OpenStack Cinder /v3/{project_id}/volumes; actions like attach/detach/resize via undocumented POST /volumes/{id}/actions rather than /os-volume-attach etc.
- Enforces single-instance attachment only (one Droplet at a time); OpenStack supports multi-attach volumes.
- Volume names must be globally unique per region; OpenStack uses IDs primarily with optional display names.
- Size specified in GiB (binary) with 1 GiB to 16 TiB range; OpenStack typically GiB but flexible.
▸Google Cloud·Persistent Disk
Persistent Disk
- Uses Google Compute Engine REST API instead of OpenStack Cinder API.
- Offers multiple performance tiers (pd-standard HDD, pd-balanced SSD, pd-ssd, pd-extreme) with performance scaling linearly with provisioned size, unlike Cinder's backend-dependent performance.
- Supports regional disks replicated synchronously across 2 zones for higher availability (better than 99.9999% durability), while Cinder volumes are typically zonal unless using replication features.
- Online resize to increase size without detaching; no manual striping/RAID needed as GCP handles distribution automatically.
▸Hetzner·Cloud Volumes
Cloud Volumes
- Provisioned via Hetzner CSI driver (csi.hetzner.cloud), ReadWriteOnce only, min 10GB, NVMe-based.
- Billed €0.044/GB/month until deleted, no pause; attach/detach via CSI, unlike Cinder's broader access modes (RWX via Manila).
- Snapshots supported but no volume encryption at rest by default; location-specific (e.g., fsn1).
- Proprietary REST API at https://api.hetzner.cloud/v1/volumes using Bearer token auth, not OpenStack Cinder API (v3 JSON over Keystone). Endpoints like POST /volumes/{id}/actions/attach, POST /volumes/{id}/actions/resize (upsize only). No /v3/{project_id}/volumes/{volume_id}/action os-extend.
Disks and persistent storage
When guides say disk, persistent disk, or block storage, they usually mean a detachable volume that survives instance reboots. On Quake AI that object is a volume in the Block Storage service (OpenStack Cinder).
Ephemeral root disk space comes from the instance flavor. Durable application data typically lives on a separate volume you attach to the instance.
Mapping provider terms#
| Elsewhere | On Quake AI |
|---|---|
| AWS EBS volume | Volume |
| Azure managed disk | Volume |
| GCP persistent disk | Volume |
| DigitalOcean volume | Volume |
| Hetzner volume | Volume |
| Root disk only | Flavor-defined ephemeral disk on the instance |
Volume snapshots and clones are Cinder operations distinct from instance snapshots (Nova/Glance). See Snapshots (instance vs volume).
What to read next#
- Volumes: attach, detach, extend, snapshot, and clone
- Create a volume: first block volume
- Create block volume tutorial: end-to-end attach workflow
Before this
Quick answers
Was this page helpful?