# Block Storage (Volumes) FAQ

Source: https://docs.quake.ai/docs/block/faq
Markdown: https://docs.quake.ai/docs/block/faq.md
> Frequently asked questions about Quake AI Block Storage (Volumes): creating and attaching volumes, snapshots, clones, resizing, ownership transfers, migration from other providers, and troubleshooting.

---

{/*
--- FAQ: Block Storage (Volumes) service ---
Confidence tiers:

  T1  High-confidence: direct restatement of canonical content.
  T2  Medium-confidence: synthesized across multiple pages or implied.
  T3  Validation-needed: pricing, quotas, SLA, support escalation. Every T3
      carries an Action: line pointing to the missing canonical page.

Every answer ends with a Source: line citing 1-4 markdown links reviewers can
check in seconds.
*/}

# Block storage FAQ

Frequently asked questions about persistent block storage on Quake AI. For conceptual background, see the [Volumes concept page](/docs/block/concepts/volumes). For step-by-step instructions, see the [Block Storage how-to guides](/docs/block/how-to/create-volume). For troubleshooting stuck or failing volumes, see the [Volume troubleshooting runbook](/docs/operate/runbooks/volume-troubleshooting). For a service-by-service mapping from your current provider, see the [Coming from AWS](/resources/migration/coming-from-aws), [Coming from GCP](/resources/migration/coming-from-gcp), [Coming from Azure](/resources/migration/coming-from-azure), [Coming from DigitalOcean](/resources/migration/coming-from-digitalocean), or [Coming from Hetzner](/resources/migration/coming-from-hetzner) pages.

---

## Getting started





### Q: What is a volume on Quake AI? [T1]


A volume is a persistent block storage device that you attach to an instance. The operating system inside the instance sees it exactly as it would a physical 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.

The key distinction from an instance's **root disk** is lifecycle: the root disk is tied to the instance and deleted with it (unless you snapshot it first). A volume persists independently. You can detach it from one instance, attach it to another, and the data comes along.

The Block Storage service is backed by [OpenStack Cinder](https://docs.openstack.org/cinder/latest/).

---





### Q: What storage technology backs Quake AI volumes? [T1]


All volumes use **premium NVMe flash storage**. There is one storage tier: **Flash_Premium**: and it applies to all volumes regardless of size. No spinning-disk tiers or separate IOPS SKUs exist; performance characteristics are uniform across the offering.

---





### Q: What size range is supported for volumes? [T1]


Volume sizes range from **1 GiB to 29,800 GiB**. You set the size when you create the volume. You can extend a volume after creation (increase size only; shrinking is not supported).

---





### Q: How do I create a volume and attach it to an instance? [T1]


You can create a volume from the console, CLI, or API. With the CLI:

```bash
# Create a blank 50 GiB volume
openstack volume create --size 50 my-volume

# Attach it to a running instance
openstack server add volume my-instance my-volume
```

After attaching, the volume appears as a new block device (for example, `/dev/sdb`) inside the instance. You must format and mount it before use. In the console, go to **Storage** > **Volumes** > **Create Volume**, then attach via **Compute** > **Instances** > **More** > **Attach Volume**.

A volume can also be created from an existing image or snapshot at creation time, which pre-populates it with data.

---





### Q: When should I use a volume vs. the root disk vs. object storage? [T1]


| | Volumes | Root disk | Object storage |
|---|---|---|---|
| **Persistence** | Independent of instance lifecycle | Deleted with instance (unless snapshotted) | Independent; accessible from anywhere via HTTP |
| **Access model** | Block device: filesystem, random I/O | Block device: boots the OS | HTTP API: whole-object reads/writes |
| **Best for** | Databases, application state, logs, media needing filesystem access | OS and ephemeral scratch space | Backups, archives, static assets, data lakes |
| **Performance** | NVMe: low latency, high IOPS | NVMe: same backend | High throughput, higher latency |
| **Size** | 1 GiB – 29,800 GiB | Set by flavor | Practically unlimited |

Use volumes when your application needs a filesystem with random read/write access and you want the data to survive instance replacements.

---





## Core concepts





### Q: Volume snapshot vs. volume clone vs. instance snapshot: which do I want? [T1]


These three concepts are related but serve different purposes:

- **Volume snapshot**: a point-in-time copy of an individual storage volume, stored incrementally (only changed blocks since the last snapshot). It depends on the source volume for deletion: you must delete dependent snapshots before you can delete the source volume. Use volume snapshots for scheduled backups and restore points for specific data disks.

- **Volume clone**: a new, fully independent volume created from an existing volume or snapshot. Unlike a snapshot, a clone is a standalone volume you can attach and use immediately. Changes to the clone do not affect the source, and vice versa. Use clones to spin up test environments from production data or to scale out database replicas with pre-loaded data.

- **Instance snapshot**: captures the full state of a running instance's **root disk** (not attached Cinder volumes) and stores the result as a new image in the Image service. It is immutable once created and can be used to launch new instances. Use instance snapshots when you need the complete machine image, not the data from a single attached disk.

Choose instance snapshots for full VM images. Choose volume snapshots or clones to protect data on specific attached volumes independently of the instance.

---





### Q: What are the volume lifecycle states? [T1]


A volume moves through a predictable set of states:

| State | Meaning |
|---|---|
| `creating` | Volume is being provisioned, wait before performing other operations |
| `available` | Ready to attach or use as a snapshot/clone source |
| `attaching` | Cinder is connecting the volume to an instance |
| `in-use` | Attached to a running instance |
| `detaching` | Cinder is disconnecting the volume from an instance |
| `extending` | Resize operation in progress |
| `error` | An operation failed, delete or reset state after diagnosis |
| `error_deleting` | Deletion failed, reset state or escalate to support |

Operations are only valid from certain states. Attempting an operation from the wrong state returns a `409 Conflict` API error. If a volume is stuck in a transitional state for more than about 10 minutes, see the troubleshooting runbook.

---





### Q: Are volume backups available? [T1]


Quake AI does not offer native Cinder volume backups. Use **volume snapshots** for point-in-time recovery or **volume clones** for full independent copies.

---





### Q: Does a volume support encryption? [T1]


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

---





## Operations and lifecycle





### Q: How do I extend (resize) a volume? [T1]


You can extend a volume while it is either **available** (detached) or **in-use** (attached). Extending an attached volume online requires Cinder API microversion 3.42 or later: set `OS_VOLUME_API_VERSION=3.42` (or pass `--os-volume-api-version 3.42`) before you run the resize.

```bash
# Extend an attached volume to 100 GiB (online, microversion 3.42+)
OS_VOLUME_API_VERSION=3.42 openstack volume set --size 100 my-volume
```

**Important:** Extension is irreversible. You can only increase size, never decrease it. After extending the volume at the platform level, resize the filesystem inside the instance to use the new space:

```bash
# For ext4 (online, while mounted)
sudo resize2fs /dev/sdb

# For XFS (online, while mounted)
sudo xfs_growfs /dev/sdb
```

Replace `/dev/sdb` with the actual device path inside your instance. Quake AI attaches volumes over virtio-scsi, so they appear as `/dev/sdX`, not `/dev/vdX`.

---






Online extend of an attached (`in-use`) volume requires Cinder API microversion 3.42 or later. At the CLI default microversion or at any microversion earlier than 3.42, an in-use extend fails with:

```text
Failed to set volume size: Volume is in in-use state, it must be available before size can be extended
```

Set the microversion and run the resize while the volume stays attached:

```bash
# Online extend on the attached volume (microversion 3.42+)
OS_VOLUME_API_VERSION=3.42 openstack volume set --size 100 MY_VOLUME_NAME

# Grow the filesystem inside the instance, no unmount needed
sudo resize2fs /dev/sdb   # ext4
sudo xfs_growfs /dev/sdb  # XFS
```

If you cannot pin microversion 3.42 or later, use the legacy detach, extend, re-attach sequence:

```bash
# Legacy fallback (pre-3.42): detach, extend, re-attach
openstack server remove volume MY_INSTANCE_NAME MY_VOLUME_NAME

# Wait for the volume to reach 'available'
openstack volume show MY_VOLUME_NAME -c status

# Extend, then re-attach
openstack volume set --size 100 MY_VOLUME_NAME
openstack server add volume MY_INSTANCE_NAME MY_VOLUME_NAME
```

After re-attaching, grow the filesystem inside the instance with `resize2fs /dev/sdb` (ext4) or `xfs_growfs /dev/sdb` (XFS), substituting the actual device path. Extension is irreversible; you can only increase size, never decrease it.

---





### Q: How do I take a point-in-time snapshot of a volume? [T1]


```bash
# Snapshot a detached (available) volume
openstack volume snapshot create --volume my-volume my-snapshot

# Force a snapshot of an attached (in-use) volume
openstack volume snapshot create --volume my-volume --force my-snapshot
```

For the most consistent snapshot, quiesce write activity or flush buffers before taking a snapshot of an actively attached volume. A snapshot of an actively written volume captures a **crash-consistent** state, acceptable for many workloads, but database-level consistency requires application-level coordination (for example, `FLUSH TABLES WITH READ LOCK` for MySQL).

Snapshots are incremental: only changed blocks since the last snapshot are stored, making them space-efficient for regular backup schedules.

---





### Q: How do I clone a volume? [T1]


Cloning creates a new, fully writable, independent volume. The clone size must be equal to or larger than the source:

```bash
openstack volume create \
  --source SOURCE_VOLUME_ID \
  --size 50 \
  my-cloned-volume
```

In the console, go to **Storage** > **Volumes**, select the volume, then choose **More** > **Data Protection** > **Clone Volume**.

---





### Q: How do I transfer volume ownership to another project? [T1]


Transferring ownership moves a volume from one Quake AI project to another without physically moving the data, only the ownership metadata changes. The volume must be in **Available** status (not attached) before the transfer.

The process is two-step:

**Step 1: Source project creates the transfer:**
```bash
openstack volume transfer request create --name my-transfer my-volume
# Returns a Transfer ID and Auth Key, share both securely with the recipient
```

**Step 2: Target project accepts the transfer:**
```bash
source ~/path/to/target-project-openrc.sh
openstack volume transfer request accept --auth-key AUTH_KEY TRANSFER_ID
```

The source project can cancel a pending transfer before acceptance with `openstack volume transfer request delete TRANSFER_ID`.

---





### Q: What operational practices should I follow for volumes? [T1]


- **Size with headroom.** You can extend volumes but not shrink them. Start larger than your current minimum and monitor usage.
- **Store growing data on volumes, not the root disk.** The root disk size follows the instance flavor and cannot be extended the way a Cinder volume can.
- **Detach before snapshot when consistency matters.** Quiesce writes or stop the application before snapshotting for database-level consistency.
- **Clean up unused volumes.** Detached volumes sitting in the `available` state still consume quota. Delete volumes and old snapshots you no longer need.
- **Avoid rapid attach/detach loops.** Wait for each operation to reach a stable state before starting the next.
- **Automate snapshot schedules.** Regular snapshots protect against accidental data loss; automate them via the CLI or API.

---





## Troubleshooting





### Q: Why do Block Storage API curl examples fail with an unset `OS_VOLUME_URL` or `OS_TOKEN`? [T2]


Application-credential `openrc` files export Keystone auth variables but not `OS_TOKEN` or the project-scoped Cinder URL. API tab examples that call `$OS_VOLUME_URL/volumes` fail until you export both values in the same shell:

```bash
OS_TOKEN=$(openstack token issue -f value -c id)
OS_VOLUME_URL="https://volume.${OS_REGION_NAME}.rumble.cloud/v3/$(openstack token issue -f value -c project_id)"
```

Re-run those exports after you source a different project's openrc so the token and volume URL match the project you are testing.





### Q: Why is my volume stuck in `attaching` or `detaching`? [T1]


A volume stays in a transitional state when the API operation timed out (for example HTTP 504), the storage backend encountered an error, Nova–Cinder coordination broke down, or a Heat stack changed volume state mid-operation.

**Diagnosis:**
```bash
openstack volume show VOLUME_ID -c status -c attachments
```

If `attachments` is empty but `status` is still `attaching` or `detaching`, reset to a stable state:

```bash
openstack volume set --state available VOLUME_ID
```



`openstack volume set --state` overrides the volume's recorded state **without verifying the storage backend**. Use it only after you have confirmed the backend operation has completed or failed. Forcing state on a volume that is still mid-operation can cause data loss. Contact support if you are unsure.



If a stale attachment row exists but the instance no longer exists, remove it first:
```bash
openstack volume attachment list --volume VOLUME_ID
openstack volume attachment delete VOLUME_ID ATTACHMENT_ID
openstack volume set --state available VOLUME_ID
```

If the state reset does not clear the stuck state, or attachments reappear after deletion, open a support ticket with the volume ID and UTC timestamps.

---





### Q: Why can't I delete my volume? [T1]


`openstack volume delete` fails with **in-use** or dependency errors when one or more of the following conditions applies:

- The volume is **still attached** to an instance
- An orphaned attachment record exists after the instance was deleted
- **Snapshots** of the volume exist: Cinder requires you to delete all dependent snapshots before deleting the source volume
- The volume belongs to a consistency group

**Resolution steps:**

1. Check for attachments and snapshots:
```bash
openstack volume show VOLUME_ID -c attachments -c status
openstack volume snapshot list --volume VOLUME_ID
```

2. Detach from a live instance:
```bash
openstack server remove volume SERVER_NAME_OR_ID VOLUME_ID
```

3. Delete snapshots first:
```bash
openstack volume snapshot delete SNAPSHOT_ID
```

4. If an orphaned attachment remains (instance gone), delete the attachment record and reset state:
```bash
openstack volume attachment delete VOLUME_ID ATTACHMENT_ID
openstack volume set --state available VOLUME_ID
```

5. Retry deletion.

---





### Q: Why is my volume snapshot stuck in `creating` or failing? [T1]


Snapshot creation fails or stalls when:

- The source volume is in a transitional state (`creating`, `attaching`, `detaching`, `extending`): Cinder requires it to be `available` or `in-use`
- The storage backend is under concurrent load
- Volume or gigabyte quota is exhausted

**Diagnosis:**
```bash
openstack volume show VOLUME_ID -c status
openstack quota show --usage
```

If the source volume is in a transitional state, wait until it settles, then retry. If the snapshot remains `creating` for more than about 10 minutes after the source volume is stable and quota is healthy, delete the stuck snapshot and retry. If failures persist, open a support ticket. You may need operator action on the backend.

**Prevention:** Do not start snapshots during resize, attach, or detach operations.

---





### Q: Why is my instance's disk full? [T1]


When `df -h` shows the root filesystem (or another mount) at 100%, applications log write errors or crash, and SSH may become slow or unresponsive.

**Identify what is consuming space:**
```bash
df -h
sudo du -sh /var/log/* 2>/dev/null | sort -h
```

**Common fixes:**

- Trim systemd journal:
```bash
sudo journalctl --vacuum-size=100M
```
- Remove rotated/compressed old logs (accept data loss):
```bash
sudo rm /var/log/*.gz
```
- Clear safe temporary directories.
- For durable extra capacity, attach a Cinder volume for application data and move large directories there.

**Note:** The root disk size is set by the instance **flavor** and cannot be extended the way a Cinder volume can. If root disk growth is the underlying problem, attach a volume for large, growing data directories instead of relying on the root disk.

If SSH is unavailable, use the instance console:
```bash
openstack console url show SERVER_NAME_OR_ID
```

---





### Q: What information should I collect before opening a support ticket? [T1]


Gather the following before contacting support for volume issues:

| Item | Command |
|---|---|
| Volume ID, status, attachments | `openstack volume show VOLUME_ID -c id -c status -c attachments` |
| Attachment list | `openstack volume attachment list --volume VOLUME_ID` |
| Snapshots for volume | `openstack volume snapshot list --volume VOLUME_ID` |
| Related instance | `openstack server show SERVER_NAME_OR_ID -c id -c status` |
| Quota usage | `openstack quota show --usage` |
| In-guest disk use | `df -h` and `sudo du -sh /var/log/*` |
| Timestamps | Operation start and failure times in **UTC** |

---





## Migration from other providers





### Q: What is Quake AI's equivalent of AWS EBS? [T1]


A **Cinder volume** on Quake AI is the direct equivalent of an AWS EBS volume. The lifecycle operations are the same: create, attach to one instance at a time, format, mount, snapshot, detach, and delete.

The key difference: AWS segments EBS into multiple types (gp3, io2, st1, sc1) with provisioned IOPS tiers and per-GB/per-IOPS billing. Quake AI exposes **Cinder volumes backed by NVMe at every tier**: there are no separate IOPS SKUs, no provisioned throughput options, and no per-second metering.

For the full AWS-to-Quake AI mapping table and migration guidance, see [Coming from AWS: Block storage](/resources/migration/coming-from-aws).

---





### Q: What is Quake AI's equivalent of DigitalOcean Block Storage (Volumes)? [T1]


A **Cinder volume**. The attach lifecycle matches DigitalOcean Block Storage closely enough that existing operational runbooks port with API surface changes only. Both platforms back block storage with NVMe at all tiers; on Quake AI you do not pick separate performance SKUs.

The API layer changes from DigitalOcean's proprietary API to the OpenStack Cinder API (`openstack volume` commands). Capacity and attachment limits still apply per project.

---





### Q: What is Quake AI's equivalent of GCP Persistent Disks? [T1]


A **Cinder volume**. You create a volume, attach it to one instance, format, mount, snapshot, and detach, the same workflow as GCP Persistent Disks.

The key difference: GCP segments Persistent Disks into pd-standard, pd-balanced, pd-ssd, and pd-extreme with provisioned IOPS tiers. Quake AI exposes **Cinder volumes backed by NVMe** with the same attach/detach workflow and no separate IOPS tiers.

---





### Q: What is Quake AI's equivalent of Azure Managed Disks? [T1]


A **Cinder volume**. You create a disk, attach it to one VM, format, mount, snapshot, and detach, the same workflow as Azure Managed Disks.

The key difference: Azure offers Premium SSD, Standard SSD, Standard HDD, and Ultra Disk with provisioned IOPS. Quake AI exposes **Cinder volumes backed by NVMe** with no separate IOPS tiers: Premium/Standard SSD distinctions collapse into a single NVMe tier.

---





### Q: What is Quake AI's equivalent of Hetzner Volumes? [T1]


A **Cinder volume**. Hetzner and Quake AI use the same create/attach/detach/snapshot model, and both back block storage with NVMe. The operational difference is the API layer: Hetzner uses `hcloud`, Quake AI uses OpenStack Cinder (`openstack volume` commands).

---





### Q: Is there a migration guide specifically for block volumes from another cloud? [T2]


The corpus has no dedicated per-provider block volume migration guide. The general migration pattern for block data is:

1. Provision a new Cinder volume on Quake AI.
2. Attach it to a Quake AI instance.
3. Transfer data from the source instance using `rsync`, `dd`, or standard database dump/restore tools.

For full VM migrations (including root disk data), refer to the [Compute migration guides](/docs/compute/migration), which cover the rebuild-and-rsync approach for AWS EC2, GCP, Azure VMs, DigitalOcean Droplets, and Hetzner Servers. Block data moves as part of that workflow.

---





## Pricing, quotas, availability, and support





### Q: What regions and availability zones is Block Storage available in? [T2]


Block Storage runs in all three Quake AI regions: `us-east-1`, `us-east-2`, and `us-west-1`. Each region is an independent failure domain; a volume created in one region cannot be attached to an instance in another. Quake AI uses regions, not availability zones, so volume placement does not require an AZ choice; a volume attaches to any instance in the same region. See [Regions](/docs/platform#regions) for the current region table and console URLs.

---





### Q: What is the SLA for Block Storage? [T2]


The contractual availability target and credit schedule are published as part of Quake AI's commercial terms at [rumble.cloud/legal](https://rumble.cloud/legal). The [Service Level Agreement page](/docs/account/sla) explains how to read those terms and how to file a credit claim. Volumes are zonal storage: a single volume lives in one region and is not automatically replicated across regions. For data durability beyond the SLA's protection, pair regular volume snapshots with application-level replication and (where appropriate) object-storage backups in a second region.

---





### Q: How do I get help if a volume operation is failing? [T2]


For most problems, start with the relevant runbook or reference:

- [Volume troubleshooting runbook](/docs/operate/runbooks/volume-troubleshooting): stuck volumes, delete failures, snapshot failures, disk exhaustion
- [Block storage API error reference](/reference/block-storage/api-errors): HTTP status codes, state machine errors, and recovery steps

If the runbook does not resolve the issue, [open a support ticket](https://rumble.cloud/support) with the volume UUID, the region, the UTC time window for the failing operation, the last commands you ran, and the output of `openstack volume show VOLUME_ID -c id -c status -c attachments` and `openstack quota show --usage`. See [Support ticket evidence collection](/docs/operate/troubleshooting/support-ticket-evidence) for the full evidence checklist and [Get help](/docs/get-help) for the canonical decision tree by symptom.

---





## See also

- [Volumes concept page](/docs/block/concepts/volumes): full background on the volume model, lifecycle, and operational considerations
- [Create a block storage volume](/docs/block/how-to/create-volume): console, CLI, and API
- [Create a volume snapshot](/docs/block/how-to/create-snapshot): point-in-time copy
- [Clone a volume](/docs/block/how-to/clone-volume): independent copy
- [Extend a block storage volume](/docs/block/how-to/extend-volume): increase capacity
- [Transfer block storage ownership](/docs/block/how-to/transfer-ownership): move a volume between projects
- [Volume troubleshooting runbook](/docs/operate/runbooks/volume-troubleshooting): symptom → cause → fix for stuck volumes, delete failures, snapshot failures, and disk exhaustion
- [Block storage API error reference](/reference/block-storage/api-errors): HTTP status codes, state machine, and delete conflict resolution
- [Instance Snapshots](/docs/compute/concepts/snapshots): how volume snapshots differ from instance snapshots
- [Coming from AWS](/resources/migration/coming-from-aws): [Coming from GCP](/resources/migration/coming-from-gcp), [Coming from Azure](/resources/migration/coming-from-azure), [Coming from DigitalOcean](/resources/migration/coming-from-digitalocean), [Coming from Hetzner](/resources/migration/coming-from-hetzner), provider-to-Quake AI block storage mapping for migrators