---
title: "Block Storage in India — Attachable Cloud Volumes for Nodes & Kubernetes"
description: "E2E Block Storage: attachable, expandable volumes for compute and GPU nodes in Indian data centers. Per-volume snapshots and restore, Kubernetes CSI dynamic provisioning, import/export — standard block semantics, INR billing."
url: "https://www.e2enetworks.com/block-storage"
canonical: "https://www.e2enetworks.com/block-storage"
provider: "E2E Networks Limited"
type: "Service"
keywords: ["block storage india", "ssd block storage cloud", "attachable cloud volumes india", "cloud block storage for databases"]
priceCurrency: "INR"
taxNote: "Prices exclude GST"
region: "India (Delhi NCR, Chennai)"
generated: "2026-09-11"
---

# Block Storage in India — Attachable Cloud Volumes for Nodes & Kubernetes

> E2E Block Storage: attachable, expandable volumes for compute and GPU nodes in Indian data centers. Per-volume snapshots and restore, Kubernetes CSI dynamic provisioning, import/export — standard block semantics, INR billing.

Canonical page: https://www.e2enetworks.com/block-storage

Volumes that follow your workload, not the other way round. Create a volume, attach it to any compute or GPU node, snapshot it before the risky migration, grow it when the database does. Standard block semantics with a Kubernetes CSI — managed from one console, billed in INR.

## At a glance

Note: Indicative — see the live rate card for current pricing.

- **Attach / detach** — Move volumes between nodes
- **Snapshots** — Per-volume, with restore
- **CSI** — Kubernetes dynamic provisioning
- **₹10/GB*** — Per month, INR billing

## Platform capabilities

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

1. **Create** — Pick a size and region from MyAccount › Storage, or POST to the Block Storage API. The volume exists independently of any node.
2. **Attach & format** — Attach to a running node, then format and mount like any local disk — databases, data directories, scratch space.
3. **Protect** — Snapshot before schema migrations and upgrades; restore in place if it goes sideways. Schedule node snapshots with auto-expiry for routine protection.
4. **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:

```yaml
# 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-sc
```

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

## Volume capabilities

| Capability | Documented | Detail |
| --- | --- | --- |
| Create / delete volumes | Yes | Console + Block Storage REST API |
| Attach / detach to nodes | Yes | vm-attach / vm-detach API operations |
| Expand volume | Yes | In-place upgrade; no shrink |
| Snapshots + restore | Yes | Per-volume create/list/delete/restore; scheduled node snapshots with retention & lock |
| Kubernetes CSI | Yes | StorageClass csi-rbd-sc, static & dynamic provisioning |
| Import / export | Yes | Import block storage; export to image |
| Encryption at rest | Yes | LUKS on platform disks, creation-time enablement |
| IOPS / throughput | No | Scales with volume size and node plan — ask an engineer to size it |
| Per-GB rate | No | Billed in INR* — see pricing |

## Common use cases

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

### Can I move a volume between nodes?

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.

### How do snapshots interact with saved images?

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.

### What performance should I expect?

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.

### Can I shrink a volume I over-provisioned?

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.

### Is this the right storage for shared training data?

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.

## Get started

Create, attach and snapshot your first volume in minutes. Pricing: https://www.e2enetworks.com/pricing · Talk to sales: https://www.e2enetworks.com/contact-sales

- [Start Free](https://myaccount.e2enetworks.com/accounts/signup)
- [Talk to an Engineer](https://www.e2enetworks.com/contact-sales)

---

This Markdown is generated from the same data that renders https://www.e2enetworks.com/block-storage. Provider: E2E Networks Limited (NSE: E2E), India. Site index for AI agents: https://www.e2enetworks.com/llms.txt