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.

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.

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

Snapshot and restore

1. Take a snapshot before a risky change. It is a named object that stays until you delete it.

   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.

   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.

Grow a volume

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

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.

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.

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
• VMs for disks, VM snapshots and backups
• Kubernetes for clusters and environment repositories
• Databases for managed Postgres on local NVMe
• Frazer Storage for object storage
• AI and GPUs for GPU volumes and datasets