---
title: "Volumes and snapshots: local NVMe, or replicated · Frazer"
description: "Volumes on the server's own NVMe for speed, or replicated across servers so a VM or pod can restart elsewhere. Snapshots, clones and backups as named objects, encrypted per volume."
url: https://frazer.ai/volumes
index: https://frazer.ai/llms.txt
tokens: 2368
---

> For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt.

# Volumes and snapshots: local NVMe, or replicated · Frazer

**Volumes and snapshots**  frazer.ai

# 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.

[Start building](https://frazer.ai/start?product=volumes) [Read the docs](https://frazer.ai/docs)

*The Storage page of the demo cluster acme-production-1: 8 volumes, 1,320 GiB requested, in 4 classes. Databases and embeddings sit on local-nvme on one server each, two volumes are replicated across two servers, the model cache uses the dataset class, and an agent workspace on the shared class waits for its first pod. A banner says a local-nvme volume is deleted when its server is replaced and Postgres copies the data back.*

A cluster's volumes, with the class and server of each product UI, demo organization

01 · How it works Fig. 1

## Speed or mobility.  
Each class keeps its copies differently.

**Fig. 1** Where each class keeps its copies, and what one lost server costs

02 · Classes

## 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.

Volume classes: what each is built on, its copies, its access and what it is for

| 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.

03 · Snapshots and backups

## Snapshots and backups, by name.  
Snapshots stay close. Backups leave the server.

Snapshots and backups compared

|  | 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: 100Gi
```

04 · Designed for

## What 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 volumes are designed to handle, and the test for each

| 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.

05 · What you get

## 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.
    

06 · Controls

## 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.

07 · Pricing

## 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 price](https://frazer.ai/pricing#lines)

Your servers **Included** in the per-core server fee · volumes use your own disks

Backups 100 GB per server included, pooled across the account; then $0.012 per GiB-month

Frazer fleet $0.012 per GiB-month for every class, metered per second

Questions

## Volumes 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.

## More in Data

-   [**Databases** Postgres with PITR](https://frazer.ai/databases)
-   [**In-memory store** Pick the engine and version](https://frazer.ai/memory)
-   [**Frazer Storage** Objects next to servers](https://frazer.ai/storage)
-   [**Secrets** Write-only for people](https://frazer.ai/secrets)

## Pick a class.  
Know what it survives.

[Start building](https://frazer.ai/start?product=volumes) [Read the docs](https://frazer.ai/docs)