Block storage that behaves like block storage should
Every operation below is a documented console and REST API action — scriptable end to end.
Attach anywhere
Volumes are independent of any node. Attach to a node, detach, re-attach to a bigger one — your data outlives every instance decision, including plan upgrades.
Expand in place
Upgrade a volume to a larger size via a single documented operation. One honest rule inherited from distributed block stores: volumes grow, they don't shrink.
Snapshots & restore
Per-volume snapshot create, list, delete and restore. At node level, schedule snapshots with retention windows, lock critical ones against deletion, and mint reusable images from any snapshot.
Kubernetes CSI
The block storage CSI backs Persistent Volumes in E2E Managed Kubernetes — StorageClass csi-rbd-sc, static or dynamic provisioning, standard PVC workflow.
Import & export
Documented import of block storage and export to images — bring disks in, take machine images out. Standards-based portability instead of a one-way door.
Encryption at rest
E2E documents LUKS encryption at rest across platform disks — enabled at creation time, with an optional passphrase.
How it works
The lifecycle of a volume, start to finish.
Create
Pick a size and region from MyAccount › Storage, or POST to the Block Storage API. The volume exists independently of any node.
Attach & format
Attach to a running node, then format and mount like any local disk — databases, data directories, scratch space.
Protect
Snapshot before schema migrations and upgrades; restore in place if it goes sideways. Schedule node snapshots with auto-expiry for routine protection.
Grow or move
Expand the volume as data grows, or detach and re-attach to a new node during a plan change. Export to an image when you need portability.
Dynamic provisioning in Kubernetes
Once the StorageClass is enabled (create one PV from the console — a documented one-time step), every PVC is self-service. This manifest is straight from the E2E Kubernetes storage guide:
# E2E Kubernetes persistent storage — full guide at docs.e2enetworks.com
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-dynamic-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: csi-rbd-scPods reference the claim, the CSI provisions the volume, and the data survives every pod reschedule. Need shared multi-pod volumes instead? That's Parallel File Storage / SFS territory.
What's documented vs. what to verify
| Capability | Status | Detail |
|---|---|---|
| Create / delete volumes | Documented | Console + Block Storage REST API |
| Attach / detach to nodes | Documented | vm-attach / vm-detach API operations |
| Expand volume | Documented | In-place upgrade; no shrink |
| Snapshots + restore | Documented | Per-volume create/list/delete/restore; scheduled node snapshots with retention & lock |
| Kubernetes CSI | Documented | StorageClass csi-rbd-sc, static & dynamic provisioning |
| Import / export | Documented | Import block storage; export to image |
| Encryption at rest | Documented | LUKS on platform disks, creation-time enablement |
| IOPS / throughput | Verify | Scales with volume size and node plan — ask an engineer to size it |
| Per-GB rate | Verify | Billed in INR* — see pricing |
*Indicative — current pricing on the live rate card. Portal sizes are entered in GB and reported by Kubernetes in GiB — the docs call this out, so we do too.
Where block storage earns its keep
Single-writer, low-level disk semantics — the workhorse tier of the storage lineup.
Databases
PostgreSQL, MySQL, MongoDB on compute nodes — snapshot before migrations, expand as tables grow. Prefer not to run it yourself? DBaaS handles the ops.
Boot & data volumes
Root disks grow via the documented increase-root-storage action; data volumes attach and detach independently, so a node upgrade never means a data migration.
AI node scratch & state
Model caches, vector stores and stateful services beside your GPU nodes, TIR training runs and inference stacks — with runtime images pulled from the Container Registry. Shared training data belongs on PFS; artifacts on Object Storage.
Frequently Asked Questions
Everything you need to know about Block Storage.
Block Storage
Yes. Detach from one node and attach to another — both are documented API operations (vm-detach, vm-attach). This is the standard pattern for upgrading a node without touching the data disk.
They're layered: per-volume snapshots protect a single disk and support in-place restore, while node-level snapshots can be scheduled with retention (auto-delete after a set number of days), locked against accidental deletion, and converted into saved images you can launch new nodes from.
Block volume performance depends on volume size, node plan, and access pattern. The storage layer is Ceph RBD (Kubernetes StorageClass csi-rbd-sc), designed for consistent performance under mixed workloads. The fastest way to a real number for your workload is a quick fio run — or talk to an engineer about sizing.
No — volumes grow but don't shrink, a rule the docs state explicitly for Kubernetes PVs and which applies to block volumes generally. Start small and expand; expansion is a single in-place operation.
Usually not — a block volume is single-writer by nature (ReadWriteOnce in Kubernetes terms). For datasets shared across many GPU nodes use Parallel File Storage; for durable artifacts and backups use Object Storage. All three sit in the same Indian data centers.
Give your data a disk that keeps up
Create, attach and snapshot your first volume in minutes.