Volumes on local NVMe.
Or replicated, when they must move.
Pick a class for each volume: local-nvme for the speed of the server's own disk, replicated for a second copy on another server, shared when many pods write the same files. You see what a class survives before you create a volume, and no deploy, migration or maintenance deletes a snapshot.
Speed or mobility.
Each class keeps its copies differently.
Four classes, one API.
The class is the disk type.
A volume's class names what it is for, not the engine under it, so an engine can change without a change to your manifests.
| Class | Built on | Copies | Access | Use it for |
|---|---|---|---|---|
local-nvme | Local volumes on the server's own NVMe | One, on the server under the node | Block or filesystem, one pod or VM | Databases that replicate themselves, caches, fast scratch |
replicated | Synchronous block replication | Two on two servers, written synchronously, plus a tie-breaker | One writer; shared block for VM live migration | VM disks and stateful apps that must survive a server |
shared | Frazer Storage shared file system | Three, on three servers | Many pods read and write | Shared volumes and agent workspaces |
dataset | A file system on object storage, with a local NVMe cache | In object storage | Many pods, read-mostly | AI datasets, checkpoints and model files |
Every class waits for its first pod before it picks a server, and every class grows online.
Snapshots and backups, by name.
Snapshots stay close. Backups leave the server.
| Snapshot | Backup | |
|---|---|---|
| Covers | One volume | A whole VM, every disk with its configuration, or a whole database |
| Lives | Next to the volume; a local-nvme snapshot stays on its server | In Frazer Storage, off the server, with an optional off-site copy |
| Consistency | Crash-consistent, or app-consistent with a guest-agent freeze | The same |
| Restore | A new volume, or the disk of a stopped VM | A new VM, or the disks of a stopped VM after a typed confirmation |
# A volume that survives a server: two copies, written synchronously
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: chat-history-0
namespace: acme-data
spec:
storageClassName: replicated # or local-nvme, shared, dataset
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 100Gi# A named snapshot of the volume
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: chat-history-0-before-upgrade
namespace: acme-data
spec:
source:
persistentVolumeClaimName: chat-history-0# Restore: a new volume from the snapshot
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: chat-history-0-restored
namespace: acme-data
spec:
storageClassName: replicated
dataSource:
apiGroup: snapshot.storage.k8s.io
kind: VolumeSnapshot
name: chat-history-0-before-upgrade
accessModes: [ReadWriteOnce]
resources:
requests:
storage: 100GiWhat a volume is designed to take.
And the test that checks each line.
Each line names what the storage is designed to handle and how we test it: fio in a VM for latency and IOPS, CSI timestamps for snapshots, a power cut for lost writes.
| What | Designed to handle | Tested with |
|---|---|---|
| replicated · 4k sync write, queue depth 1 | p50 ≤ 0.3 ms, p99 ≤ 1 ms | fio in a VM: randwrite, bs=4k, iodepth=1, fsync=1, direct=1 |
| replicated · IOPS per volume | ≥ 150k read, ≥ 60k write | fio, queue depth 32 × 4 |
| local-nvme · 4k random read, encrypted | ≥ 500k IOPS per VM; p99 ≤ 0.15 ms at queue depth 1 | fio |
| Snapshot · restore · clone, 100 GiB | ≤ 1 s · ≤ 30 s · Ready ≤ 20 s | CSI timestamps |
| A server's power pulled during writes | No acknowledged write lost; the VM runs elsewhere within 2 min | fio verify, power cut |
| A noisy neighbor | A capped volume's p99 within +20 % of running alone | fio next to an unlimited volume |
What we do not claim: durability across zones, or the top IOPS tier of the largest hosted network disks.
Disks you can reason about.
And the tools around them.
One API, four classes
The class is the disk type, so the engine under it can change without an API change.
Grow online
Every class expands while in use; shrink by copying to a new volume.
Encrypted per volume
LUKS2 with a key per organization; deleting a volume erases its key.
Copy-on-write clones
Golden images and database branches clone in place on the thin class.
IOPS limits per volume
QoS tiers, so one busy volume cannot slow its neighbors.
GPU volumes
Attach and detach while running, one writer at a time, filled through an S3 gateway.
Change a disk's class online
Move a VM disk from local-nvme to replicated without stopping it.
Live migration
VMs on replicated disks move between servers for maintenance.
Who changes a volume.
And what happens at the cap.
Who may do what
- Your team
- Claims and expansions are changes in the cluster's environment repository, made through Git.
- Agents
- Use the same API as MCP tools, never beyond their ceiling.
- Deleting
- Disks are soft-deleted with a restore window; deleting a VM offers a final backup.
What is logged
- Every create, resize, snapshot, restore and delete is a plan with an audit entry.
- Snapshots and backups are named objects; no deploy, migration or maintenance deletes one.
- Volumes are counted in the hourly inventory that billing reconciles.
At the cap
- At a budget cap, volumes keep serving; writes are blocked only after 30 days past due.
- When Frazer-run compute pauses, its volumes, snapshots and checkpoints are kept at least 30 days.
- Deleting stored data needs a separate 30-day notice.
No fee per volume on your servers.
Backups by the GiB-month.
On your own servers, volumes use your own disks. Backups that Frazer keeps in Frazer Storage come out of an allowance for every server you bring, then cost one rate per GiB-month. On the Frazer fleet a volume of any class costs that same rate.
See every priceVolumes and snapshots, answered.
Which class should I pick?
local-nvme for databases that replicate themselves, caches and scratch: it is the server's own disk. replicated for VM disks and apps that must survive a server. shared when many pods write the same files, and dataset for AI data that many pods read.
What happens to a local-nvme volume when its server fails?
It is lost with the server. That is why databases run three instances on three servers and copy themselves back, and why VMs on local-nvme take a daily backup by default and return from it.
Is a snapshot a backup?
No. A snapshot covers one volume and lives next to it, so a local-nvme snapshot is lost with its server. A backup covers a whole VM or database and lives in Frazer Storage, off the server.
Can a volume grow or shrink?
Every class grows online. To shrink, copy the data to a new, smaller volume.
Is my data encrypted?
Yes. Each volume is encrypted with LUKS2 and a key per organization, and deleting the volume erases its key. Replication traffic runs on its own network, encrypted.
What runs underneath?
Local volumes on the server’s NVMe, synchronous block replication between two servers for replicated volumes, Frazer Storage’s shared file system for shared ones and a file system on object storage for datasets. The API names the class, not the engine.