---
title: "Volumes and snapshots"
description: "Persistent volumes on local NVMe, replicated across servers, shared between pods or backed by object storage, with snapshots, clones and backups as named objects."
url: https://frazer.ai/docs/volumes
index: https://frazer.ai/docs/llms.txt
tokens: 2574
---

> For agents: this page is indexed at https://frazer.ai/docs/llms.txt, and every page at https://frazer.ai/llms.txt. Copy commands from this file exactly.

# Volumes and snapshots

A volume is persistent storage for a pod, a VM disk or a GPU workload, on your servers or the Frazer fleet. You pick a class for each volume: the server’s own NVMe for speed, a replicated volume that survives a server, a shared filesystem, or a dataset backed by object storage. You see what a class survives before you create a volume, and no deploy, migration or maintenance ever deletes a snapshot.

Product overview: [Volumes and snapshots](https://frazer.ai/volumes).

## How it works

The class is the disk type in the API and the `storageClassName` in your manifests. It names what a volume is for, not the engine under it, so Frazer can change an engine without a change to your manifests.

| Class | Built on | Copies | Access | Use |
| --- | --- | --- | --- | --- |
| `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 while in use. Each volume is encrypted with LUKS2 and a key per organization kept in Frazer Secrets; deleting the volume erases its key. Replication traffic runs on its own network, encrypted.

-   **Volume**: a PersistentVolumeClaim in a cluster, a disk of a VM, or a GPU volume.
-   **Snapshot**: a copy of one volume at a point in time, kept next to it.
-   **Backup**: a copy of a whole VM or database in Frazer Storage, off the server.
-   **Clone**: a copy-on-write copy on the thin class; golden images and database branches are clones.
-   **QoS tier**: an IOPS limit per volume, so one busy volume cannot slow its neighbors.

### What a lost server costs

| Class | When its server fails |
| --- | --- |
| `local-nvme` | The volume is lost with the server. Postgres replicas copy the data back from the primary; a VM comes back from its last backup, daily by default |
| `replicated` | The workload restarts on another server with no data loss |
| `shared` | Two other copies keep serving |
| `dataset` | The data is in object storage; only the local cache is lost |

The `replicated` and `shared` classes need at least three servers in the pool, with 25 GbE recommended between them. On a smaller site, use `local-nvme` with backups.

## Create a volume

Volumes in a cluster are declared in its environment repository, so a claim and every later expansion is a change in Git.

1.  Pick a class. Use `local-nvme` when the application keeps its own replicas, `replicated` when the volume must survive a server, `shared` when many pods write the same files, and `dataset` for AI data that many pods read.
    
2.  Add the claim to your environment repository and merge it. Frazer GitOps applies it to the cluster.
    
    ```yaml title="volume.yaml"
    # 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
    ```
    
3.  Start the pod that uses it. The claim stays `Pending` until its first pod is scheduled, then binds on that pod’s server. The cluster’s **Storage** page shows each volume’s class, server, usage and snapshots.
    

VM disks use the same classes; create and attach them with `frazer storage disks` (see [VMs](https://frazer.ai/docs/vms)). GPU volumes attach and detach while a pod runs, allow one writer at a time and many readers, and fill through an S3 gateway (see [AI and GPUs](https://frazer.ai/docs/ai)).

## Snapshot and restore

1.  Take a snapshot before a risky change. It is a named object that stays until you delete it.
    
    ```yaml title="snapshot.yaml"
    # 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
    ```
    
2.  Restore it into a new volume. Point the new claim’s `dataSource` at the snapshot, then move your workload to the new claim.
    
    ```yaml title="restore.yaml"
    # 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
    ```
    

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

> **Caution:** A snapshot is not a backup. A `local-nvme` snapshot restores on the same server only and is lost with it. For a copy off the server, use backups: on by default for VMs with `local-nvme` disks, and always on for [databases](https://frazer.ai/docs/databases).

## Grow a volume

Raise the request in the claim and merge the change. Every class grows online.

```yaml title="volume.yaml"
spec:
  resources:
    requests:
      storage: 150Gi
```

Volumes do not shrink in place. To use less space, copy the data to a new, smaller volume.

## Move a VM disk to another class

A VM disk on `local-nvme` can move to `replicated` while the VM runs. VMs on `replicated` disks then move between servers for maintenance with live migration, while a VM on `local-nvme` stops and restarts. See [VMs](https://frazer.ai/docs/vms).

## Access and audit

| Who | What they can do |
| --- | --- |
| 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 |

-   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 a budget cap, volumes keep serving; writes are blocked only after an invoice is 30 days past due. When Frazer-run compute pauses at a cap, its volumes, snapshots and checkpoints are kept for at least 30 days. Deleting stored data needs a separate 30-day notice.

## Limits and quotas

| Item | Value |
| --- | --- |
| Classes | `local-nvme`, `replicated`, `shared`, `dataset` |
| `replicated` copies | Two, written synchronously, plus a tie-breaker |
| `shared` copies | Three, on three servers |
| `replicated` and `shared` | At least three servers in the pool; 25 GbE recommended |
| `local-nvme` snapshots | Restore on the same server only |
| Resize | Grow online; shrink by copying to a new volume |
| Binding | When the first pod is scheduled |

Volume GiB is an allocation quota of your project; it is released when the data is purged, not when the claim is deleted.

## Pricing

On your own servers, volumes use your own disks and are part of the server fee. Snapshots and backups in Frazer Storage come out of an allowance for every server you bring; on the Frazer fleet, disks bill per GiB-month by class, metered per second.

| Volumes and snapshots | On your servers | On the Frazer fleet |
| --- | --- | --- |
| storage, backups | Your disks · 100 GB backups per server included | $0.012 / GiB-month for objects, volumes of every class and backups |

Every line, with the estimator: [pricing](https://frazer.ai/pricing#lines).

## Troubleshooting

| Symptom | Cause | Fix |
| --- | --- | --- |
| A claim stays `Pending` | Every class waits for its first pod | Start a pod that mounts the claim |
| A volume is gone after a server was replaced | `local-nvme` lives on one server | Use `replicated`, or rely on the app’s replicas and backups |
| A snapshot will not restore on another server | `local-nvme` snapshots restore on their own server | Restore from a backup, or use `replicated` |
| A second pod cannot mount the volume | `local-nvme` and `replicated` take one writer | Use `shared` for files many pods write |
| The `replicated` class is not offered | The pool has fewer than three servers | Add servers, or use `local-nvme` with backups |
| A volume cannot get smaller | Volumes only grow | Copy the data to a new, smaller volume |

## Reference

## Related

-   [Volumes and snapshots product page](https://frazer.ai/volumes)
-   [VMs](https://frazer.ai/docs/vms) for disks, VM snapshots and backups
-   [Kubernetes](https://frazer.ai/docs/kubernetes) for clusters and environment repositories
-   [Databases](https://frazer.ai/docs/databases) for managed Postgres on local NVMe
-   [Frazer Storage](https://frazer.ai/docs/storage) for object storage
-   [AI and GPUs](https://frazer.ai/docs/ai) for GPU volumes and datasets

## Pages in Data

- [Databases](https://frazer.ai/docs/databases.md)
- [In-memory store](https://frazer.ai/docs/memory.md)
- [Frazer Storage](https://frazer.ai/docs/storage.md)
- [Secrets](https://frazer.ai/docs/secrets.md)
- [Volumes and snapshots](https://frazer.ai/docs/volumes.md) (this page)