Volumes

Applications need storage that survives reboots, instance deletions, and infrastructure changes. Volumes provide that: persistent block storage devices that attach to instances, behave like physical disks to the operating system, and exist independently of the instances that use them.

A volume is the cloud equivalent of plugging an SSD into a server, except you can create, resize, snapshot, clone, and move it between instances through an API call.

The Block Storage service is backed by OpenStack Cinder, which manages volume lifecycle, snapshot operations, and integration with the Compute service.

How volumes work#

A volume is a block device. The operating system inside your instance sees it the same way it sees a local disk: you can partition it, format it with any filesystem, and mount it at any path. Under the hood, the platform stores volume data on a distributed storage backend and presents it to the hypervisor as a virtual disk.

Volumes persist independently of the instance root disk, which deletes with the instance unless you snapshot it first. You can detach a volume from one instance and attach it to another; the data comes along.

You own volumes you create within a project. You can transfer volume ownership between projects when workloads move.

Volume lifecycle#

Volumes move through a predictable set of states as you create, use, and retire them.

Create a volume by specifying a size and optionally a source (blank, image, snapshot, or existing volume to clone). The platform allocates storage on the backend and the volume enters the available state.

Attach the volume to a running instance. Cinder communicates with the Compute service to connect the block device. The instance's OS sees a new disk. You format and mount it like any physical drive.

Use the volume for whatever your workload needs: databases, application state, media files, log archives.

Snapshot a volume to capture its state at a point in time. Snapshots are incremental and can be used for backups or to create new volumes with identical data.

Clone a volume or snapshot to create an independent copy, useful for spinning up test environments or scaling out read replicas with pre-loaded data.

Detach the volume when you need to move it to a different instance or decommission the current one. The data remains intact on the storage backend.

Delete the volume when you no longer need the data. Deletion is permanent. No recycle bin exists.

When to use volumes vs. root disk vs. object storage#

Use volumes when your application needs a filesystem with random read/write access and you want the data to survive instance replacements. Use the root disk for the OS and ephemeral scratch space. Use object storage when you need HTTP-accessible, scalable storage for large datasets or backup archives.

Volumes on Quake AI#

All volumes use NVMe flash storage; there are no spinning-disk tiers. Volume sizes range from 1 GiB to 29,800 GiB. You can extend a volume after creation (increase size only; shrinking is not supported).

Volumes support encryption, providing an additional layer of protection for sensitive data at rest. Multi-tenancy isolates volumes and snapshots between projects; other tenants cannot access your storage.

You interact with volumes through the Console, CLI (openstack volume commands), or the Block Storage API. All three support the full lifecycle: create, attach, detach, snapshot, clone, extend, transfer, and delete.

Snapshots and clones#

Snapshots capture the state of a volume at a specific moment. They are incremental: only changed blocks since the last snapshot are stored, so they are space-efficient for regular backup schedules. You can create a new volume from a snapshot to restore data or provision a new environment with known state.

Clones create a full independent copy of a volume or snapshot. A clone is a standalone volume you can attach and use immediately. Use clones to spin up test environments from production data or scale out database replicas.

Ownership and transfers#

Volumes belong to the project that created them. When you reorganize workloads or hand off environments, you can transfer ownership of a volume to another project without moving the data; the storage backend stays the same, and only the ownership metadata changes.

Operational considerations#

Plan for snapshots. Regular snapshots protect against accidental data loss and give you restore points before risky operations like database migrations. Automate snapshot schedules with How to schedule volume snapshots and restore data or the API and CLI.

Size volumes appropriately. You can extend volumes, but you cannot shrink them. Start with enough headroom for growth, and monitor usage to extend before your application runs out of space.

Detach before snapshot for consistency. For best results, quiesce the filesystem or stop writes before snapshotting. A snapshot of an actively written volume captures a crash-consistent state, acceptable for many workloads, but database-level consistency requires application-level coordination (e.g., FLUSH TABLES WITH READ LOCK for MySQL).

Clean up unused volumes. Volumes consume quota whether attached or not. Detached volumes sitting in the available state still count against your storage allocation. Delete volumes you no longer need and remove old snapshots that have been superseded.

Further reading#

On this platform:

• Create a volume: step-by-step volume creation via Console, CLI, and API
• Create a volume snapshot: capture a point-in-time copy
• How to schedule volume snapshots and restore data: cron or CI-driven snapshot schedules
• Clone a volume: create an independent copy
• Extend volume storage capacity: increase volume size
• Transfer block storage ownership: move a volume between projects
• Instances: how volumes connect to compute instances

External resources:

• OpenStack Cinder documentation: upstream Block Storage service architecture and admin reference
• Linux block device management: lsblk and related tools for managing attached volumes inside instances