# Exoscale Documentation — Block Storage > Block Storage: redundant, distributed block volumes for Compute instances, with snapshots and performance for latency-sensitive workloads. --- url: https://community.exoscale.com/product/storage/block-storage/ --- # Block Storage - [Quick Start - Block Storage](https://community.exoscale.com/product/storage/block-storage/quick-start/index.md) - Get started quickly with a guided setup to achieve your first successful use of the service, including the required steps and configuration. - [Overview - Block Storage](https://community.exoscale.com/product/storage/block-storage/overview/index.md) - Terminology and key features at a glance, learn the core concepts, capabilities, and options of this service before you dive deeper. - [How-To - Block Storage](https://community.exoscale.com/product/storage/block-storage/how-to/index.md) - Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Service Boundaries - Block Storage](https://community.exoscale.com/product/storage/block-storage/service-boundaries/index.md) - Service boundaries: quotas, limits, and the guaranteed service levels (SLA) for this product, including key constraints to plan and operate reliably. - [Reference - Block Storage](https://community.exoscale.com/product/storage/block-storage/reference/index.md) - Reference documentation for API, CLI, and tools, browse comprehensive details, parameters, commands, and integration notes. --- url: https://community.exoscale.com/product/storage/block-storage/quick-start/ --- # Quick Start - Block Storage ## Prerequisites Update to the latest Exoscale CLI (minimum version: 1.74.5). For installation, visit [Exoscale CLI Installation](https://github.com/exoscale/cli#installation). ## Block Storage Volumes ### Create ```bash exo compute block-storage create volume-test-1 --size 100 --zone ch-gva-2 ``` ### List ```bash exo compute block-storage list --zone ch-gva-2 ``` ### Attach ```bash exo compute block-storage attach volume-test-1 my-instance --zone ch-gva-2 ``` ### Detach ```bash exo compute block-storage detach volume-test-1 --zone ch-gva-2 ``` --- url: https://community.exoscale.com/product/storage/block-storage/overview/ --- # Overview - Block Storage Block Storage is a redundant and distributed block device implementation for Exoscale Compute instances which provides rapid data access and retrieval to support your most demanding workloads with exceptional performance for latency-sensitive applications. Effortlessly meeting growing storage demands, and easily store containerized applications. High Data Durability : Multiple data copies are maintained at all times on separate servers. Snapshots are retained indefinitely. Ultra-Low Latency for High-Performance Workloads : Experience outstanding performance fueled by the latest generation NVMe SSDs—ideal for latency-sensitive applications such as databases. Flexible Storage Capabilities : Add volumes to your instances anytime, enabling you to scale capacity as your needs evolve seamlessly. ## Terminology Volume : A single storage device that is partitioned and formatted to store directories and files. Snapshot : A storage snapshot is the state of a volume at a particular point in time. It provides the ability to create new volumes with the state of the current volume at that specific point in time. ## Features Block Storage volumes feature a fixed 4KiB block size and replicate data at least twice within the same Zone for durability. They support snapshots—enabling the creation of new volumes (“forking”)—though exporting or downloading snapshots is impossible. Access is _ReadWriteOnce_, allowing only a single instance to attach a volume at any given time; however, volumes can be detached from one instance and reattached to another within the same Zone. IOPS : Enjoy 5,000 IOPS per volume for read and write operations—no sharing involved. Built-In Feature : Use Block Storage alongside Compute Instances or Managed Kubernetes. Easy Snapshots : Take a snapshot of any volume via an API call. Create new volumes from snapshots whenever needed. Five Volumes per Instance : You can attach up to five Block Storage volumes to each instance, with a maximum capacity of 10 TiB per volume. Easy Scaling : Create a Block Storage volume in seconds using the Exoscale Portal, CLI, API, or Terraform provider. Detach and reattach volumes to move them between Instances. Exoscale CSI Driver : Interact seamlessly with Block Storage from Kubernetes using our Exoscale CSI Driver. (Read more) Two-Times Replication : Data is replicated twice across multiple nodes, ensuring availability even if a disk fails. Secure Data Storage in Europe : As a fully European cloud provider, all data remains in your chosen zone and is fully GDPR-compliant. Encryption at Rest : Block Storage volumes are transparently encrypted using AES-256 in XTS mode at the hypervisor layer, with a unique key per volume and no configuration required. Snapshots inherit the data encryption of their parent volume. With its unique features, Block Storage suits mission-critical, I/O-intensive applications. Use it for relational and transactional databases, time series, container volumes, or hypervisor file systems. Because volumes are directly connected to an instance, their I/O speeds are often significantly faster than alternative storage solutions like Object Storage. Flexibility for Containerized Applications : As containers are flexible, scalable, and efficient, so is our Block Storage. Containers benefit from Block Storage’s speed and the native ability to mount multiple volumes on a single host. Migrate seamlessly between servers, locations, and operating systems. Discover the Best Cost-to-Performance Ratio : Our Block Storage offers a fair and transparent cost-to-performance ratio. With a simple pricing structure, you’ll have predictable monthly expenses—no cumbersome IOPS provisioning or pay-per-use variability. Persistent Volumes : Create persistent volumes for critical information, databases, or other essential data to retain it over extended periods. These volumes can be --- url: https://community.exoscale.com/product/storage/block-storage/how-to/ --- # How-To - Block Storage Step-by-step guides to configure the service and use specific features, with clear instructions for common tasks and problem solving. - [Use Persistent Volume](https://community.exoscale.com/product/storage/block-storage/how-to/per-vol/index.md) - Enable Exoscale CSI for SKS, create PVs and PVCs, take snapshots, and understand block storage limits and resizing rules. - [Use Snapshot](https://community.exoscale.com/product/storage/block-storage/how-to/snapshot/index.md) - Create Block Storage snapshots and restore volumes from them to improve durability beyond fsync-backed local storage. --- url: https://community.exoscale.com/product/storage/block-storage/how-to/per-vol/ --- # Use Persistent Volume We recommend using the Exoscale CSI Driver add-on to create `Persistent Volumes` (PVs). CSI (short for _Container Storage Interface_) is a critical component that enables Kubernetes to provision block storage volumes and manage them as PVs. > [!NOTE] > The source code for the [Exoscale CSI Driver](https://github.com/exoscale/exoscale-csi-driver) > is open source and can be installed manually. However, we strongly encourage all users to take > advantage of our CSI add-on, which will automatically install and manage the CSI Driver for you. ## Enabling Persistent Storage Here is an overview of enabling persistent storage via the Exoscale Container Storage Interface (CSI). You can activate CSI either when creating or updating an SKS cluster—through the Exoscale CLI, the Exoscale Portal, or Terraform. Once enabled, CSI provides a seamless way to deploy and manage volumes within your cluster, ensuring that workloads have reliable, persistent data storage. ### From the CLI When creating a new cluster: ```bash exo compute sks create \ --zone ch-gva-2 \ --nodepool-size <2 or more> \ --exoscale-csi \ ``` On an existing cluster: ```bash exo compute sks update \ --zone ch-gva-2 \ --enable-csi-addon \ ``` ### From the Portal To enable the CSI on a new cluster, navigate to "COMPUTE" > "SKS" > "ADD" and tick the "exoscale-container-storage-interface" option. To enable the CSI on an existing cluster, navigate to "COMPUTE" > "SKS" > Select the cluster you would like to update > click the "..." on the top right > "Update Cluster" and tick the "exoscale-container-storage-interface" option. ### Through Terraform Persistent storage can be enabled through the [exoscale_csi](https://registry.terraform.io/providers/exoscale/exoscale/latest/docs/resources/sks_cluster#exoscale_csi) property of the `exoscale_sks_cluster` resource. ## Using the CSI ### Storage Classes If you enable the CSI add-on through any of the methods above, a `StorageClass` named `exoscale-sbs` will be created in your cluster. Note that the `reclaimPolicy` is set to `Delete` which means, that if you delete a `PersistentVolumeClaim` (PVC) the backing block storage volume will be deleted automatically. If this is not the behavior you expect, you will need to create and use your own `StorageClass` with `reclaimPolicy` set to `Retain`. ### Creating Volumes To create a PVC that is backed by a block storage volume you may now apply a manifest similar to the following: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc namespace: my-namespace spec: accessModes: - ReadWriteOnce resources: requests: storage: 200Gi storageClassName: exoscale-sbs ``` Only sizes that are exact multiples of 1 GiB are permissible and make sure that the size is within the [limits of Block Storage](https://community.exoscale.com/product/storage/block-storage/overview/index.md#limitations). ### Taking Snapshots The following will create a Block Storage Snapshot of the volume created above: ```yaml apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshot metadata: name: my-snapshot namespace: my-namespace spec: volumeSnapshotClassName: exoscale-snapshot source: persistentVolumeClaimName: my-pvc ``` ### Restoring from a Snapshot It's possible to create a new volume from the snapshot created above: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc-from-snapshot namespace: my-namespace spec: accessModes: - ReadWriteOnce resources: requests: storage: Gi dataSource: name: my-snapshot kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io storageClassName: exoscale-sbs ``` ### Using an existing Block Storage Volume If you would like to use an already existing Block Storage Volume in your cluster you will need to find out its UUID, size and zone. With the CLI you can find this information like this: exo compute block-storage list --zone ch-gva-2 Or if you know the name of the volume: exo compute block-storage show --zone ch-gva-2 Now apply a manifest with the information you found: ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: my-existing-volume-pv spec: accessModes: - ReadWriteOnce storageClassName: exoscale-sbs capacity: storage: Gi csi: driver: csi.exoscale.com volumeHandle: / ``` You may now create a PVC that references this PV: ```yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: namespace: my-namespace name: my-pvc spec: storageClassName: exoscale-sbs volumeName: my-existing-volume-pv accessModes: - ReadWriteOnce resources: requests: storage: Gi ``` ## Limitations ### Can I Disable the CSI Add-on? No. We do not support disabling SKS add-ons after they have been enabled. ### Volumes Can Be Attached to Only One Node Because Kubernetes `Deployments` are stateless by design, volumes attach to only one node at a time. This creates issues for workloads that need persistent storage. To address this, consider using `StatefulSets` for pods requiring a `PersistentVolume`. If you use a Deployment with PVCs (short for `PersistentVolumeClaim`), moving workloads between nodes will require downtime. For example, if your Deployment runs a single pod on `node-A` and you need to relocate it to `node-B`, Kubernetes attempts a `RollingUpdate` by creating a new pod on `node-B` and waiting for it to become ready before removing the old pod on `node-A`. However, the new pod remains stuck in the `ContainerCreating` state, attempting to attach the volume to both nodes. To resolve this, consider using the `Recreate` strategy instead. This approach terminates the existing pod first, detaching the volume before creating a new pod on the target node. > [!NOTE] > This limitation is not unique to Exoscale. ### Online Resizing of PersistentVolumes Is Not Supported Attached volumes cannot be resized while in use. To change a volume’s size, you must first detach it from the node. ### Resizing PersistentVolumeClaims (PVCs) in Kubernetes Follow these steps to expand an Exoscale Block Storage PVC: 1. __Ensure the PVC is unused__: Remove or delete all Deployments referencing the PVC. 2. __Update the PVC manifest__ (Expansion Only): Edit the PVC to set the new, larger size. Downsizing is not supported. Here's an example manifest snippet with the updated size: ```yaml spec: accessModes: - ReadWriteOnce resources: requests: storage: 200Gi # Update the value here (e.g., for 200 GiB) ``` 3. __Reapply the Manifest__: Apply the updated manifest containing the increased size. 4. __Resume PVC Usage__: Use the resized PVC in new deployments. > [!NOTE] > The size increase only takes effect after the PVC is used in a new deployment. ### Non-graceful node shutdown handling When a node shuts down in a way that is not __detected by kubelet__, the pods belonging to a `StatefulSet` may become stuck in a `Terminating` state. Additionally, the associated `VolumeAttachments` (PVCs) for this node will not be removed, preventing the block storage volumes from being attached to another node. There are three ways to recover from this situation: 1. The node is healthy and can be restarted: If the node is restarted and rejoins the cluster, kubelet will report the node status. At that point, the stuck pods will be terminated, and the corresponding `VolumeAttachments` will be removed. 2. The node is broken and needs to be tainted with `out-of-service`: Adding the following taint to the node will force the pods to terminate and remove the `VolumeAttachments`: ```shell kubectl taint nodes NODE_NAME node.kubernetes.io/out-of-service=nodeshutdown:NoExecute ``` 3. The node is broken and is not part of the cluster anymore: Force the `StatefulSet` pods to terminate and delete the `VolumeAttachments` attached to this node ```shell kubectl -n NAMESPACE delete pod POD_NAME --force kubectl get volumeattachments.storage.k8s.io | grep NODE_NAME kubectl delete volumeattachments.storage.k8s.io VOLUME_ATTACHMENT --force ``` This operation is safe from a platform standpoint, as safeguards ensure that a volume will not be attached to another node unless it is properly detached. For more details, see the [Kubernetes documentation on non-graceful node shutdown](https://kubernetes.io/docs/concepts/cluster-administration/node-shutdown/#non-graceful-node-shutdown) ## Self-managed installation If you wish to set up and manage the CSI yourself, please follow [these instructions](https://github.com/exoscale/exoscale-csi-driver/blob/main/README.md). --- url: https://community.exoscale.com/product/storage/block-storage/how-to/snapshot/ --- # Use Snapshot ## Take a Snapshot of a Volume ```bash exo compute block-storage snapshot create volume-test-1 --zone ch-gva-2 ``` ## Block Storage Durability and Snapshots By default Block Storage offers the same level of durability as locally attached storage. When the system acknowledges an `fsync`, the data is reliably stored on redundant hypervisor local storage. The data is then asynchronously replicated to other systems. The durability of data can be further improved by taking snapshots: as part of taking a snapshot we ensure that all data is fully replicated to multiple systems in addition to the local hypervisor storage. Writes acknowledged by fsync : We guarantee the same durability for fsync'd writes as we do for local storage. This means that while the data is written to the hypervisor's local disk, it is not immediately replicated off-hypervisor. In the event of a hypervisor failure before a snapshot is taken, some fsync'd data might be lost. Snapshotted Writes : For snapshotted data, we guarantee 99.999999999% of durability, the same level we do for object storage. Once a snapshot is successfully created, all data up to the point of the snapshot is redundantly stored in 3 different copies and protected against hypervisor-level failures. > [!NOTE] > This design constraint is fundamental to the Block Storage system and should be considered > when designing your data durability strategy. For maximum data durability, regular snapshots > are highly recommended. ## Create a Volume from a Snapshot ```bash exo compute block-storage create volume-test-from-snapshot --snapshot --zone ch-gva-2 ``` ## Take a Snapshot of a Volume ```bash exo compute block-storage snapshot create volume-test-1 --zone ch-gva-2 ``` --- url: https://community.exoscale.com/product/storage/block-storage/service-boundaries/ --- # Service Boundaries - Block Storage - [Limits and Quotas - Block Storage](https://community.exoscale.com/product/storage/block-storage/service-boundaries/limits-and-quotas/index.md) - Block Storage Limitations and Quotas - [SLA - Block Storage](https://community.exoscale.com/product/storage/block-storage/service-boundaries/sla/index.md) - Block Storage Service Level Agreement - [Pricing ↗︎](https://www.exoscale.com/pricing/#block-storage) --- url: https://community.exoscale.com/product/storage/block-storage/service-boundaries/limits-and-quotas/ --- # Limits and Quotas - Block Storage ## Limits The following table shows which limits are enforced on Block Storage usage. It also highlights some of the characteristics of the product: | Usage | Limit | | :------ | :------ | | Maximum number of volumes attached to an instance | 5 | | Maximum number of snapshot per volume | 20 | | Maximum volume size | 10 TiB | | Minimum volume size | 1 GiB | | Maximum read IOPS per volume | 5K | | Maximum write IOPS per volume | 5K | | Maximum bandwidth per volume | 200 MiB/s | | Minimum instance size to attach a volume | Small | | Supported service offerings | All | | Block storage durability on snapshot guarantee | Full durability of data only when the volume is snapshotted | > [!NOTE] > As block storage volumes expose a block size of 4KiB, some software that incorrectly assume a smaller block size might not work. > This issue can be circumvented by using a compatibility layer in your instance like [dm-ebs](https://docs.kernel.org/admin-guide/device-mapper/dm-ebs.html) on linux. ## Quotas The default Organization Quotas are set and can be expanded upon request: | Usage | Quota | | :------ | :------: | | Volumes per Organization | 1000 | | Overall Provisioned Volume Size | 20 TiB | ## Availability Block Storage is available in all zones. --- url: https://community.exoscale.com/product/storage/block-storage/service-boundaries/sla/ --- # SLA - Block Storage These product-specific SLAs define the Service Availability Target for Exoscale Block Storage. It applies to each Client using the Service. Capitalized terms used herein but not defined herein shall have the meanings set forth in the Exoscale Terms and Conditions or EUSA, whichever applies. ## SLA Definitons | Metric | Target | Definition | | -------- | -------- | ------------ | | Service Availability | >=99.95% | The percentage of total minutes in a calendar month during which Exoscale Block Storage is available and operational for use. This objective ensures consistent access to your virtual machines, with a monthly overall availability of 99.95%. This objective is designed to ensure consistent access to your data and high performance for attached compute instances. | | Snapshot Data Durability | >=99.999999999% | Block Storage only guarantees the full durability of data when the volume is [snapshotted](https://community.exoscale.com/product/storage/block-storage/how-to/snapshot/index.md). For maximum data durability, regular snapshots are highly recommended. | | Data Durability | >=99.99% | Data durability of Block Storage when the volume is not snapshotted. | ## Product Specifications For detailed product features, technical specifications, and tutorials, please refer to the [Exoscale documentation](https://community.exoscale.com/product/storage/block-storage/index.md). ## Client Responsibilities While Exoscale is responsible for the availability and operation of the Block Storage service infrastructure, Client remains responsible for the management and protection of all data stored on their volumes, including but not limited to: * File system creation, configuration, and integrity on attached volumes. * Data stored on Block Storage volumes, including data classification, retention, and deletion. * Backup strategy, snapshot creation, restore validation, and disaster recovery planning. * Access control to Block Storage volumes, including user accounts, roles and credentials. * Monitoring of storage usage, performance, and costs. * Client defined encryption and recovery keys. Snapshot durability guarantees apply only to volumes that are explicitly snapshotted. Block Storage persistence and durability do not replace Client-managed backup and recovery processes. Clients are responsible for defining appropriate snapshot schedules and regularly validating restore procedures. The Service Level Agreement applies solely to the availability and durability of the Block Storage service as defined above and does not cover file system corruption, application behavior, data integrity within the operating system, or Client workload configuration. For a complete explanation of the shared responsibility framework between Exoscale and Clients, please see the [Exoscale Shared Responsibility Model documentation](https://community.exoscale.com/platform/compliance/shared-responsability-model/index.md). ## Exclusions No compensation shall be granted to the Client if the failure to comply with the Block Storage Service Level Objective is due to any of the following reasons: * Unavailability of components under the client's control, such as client-side software, applications, or operating system configurations installed on the Block Storage volumes. For the complete list of SLA exclusions, please refer to the [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/). ## Retribution The standard retribution and SLA credit schemes apply for this product as described under [General Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or [EUSA](https://www.exoscale.com/eusa/) whichever applies. In the event that the Monthly Uptime Percentage for Exoscale Block Storage falls below the committed Service Level Objective, the Client will be eligible for service credits as follows: | Monthly Uptime Percentage | Service Credit Percentage of Monthly Service Fees for Affected Resources | | -------- | -------- | | from 99.95% to 98.3% | 50% | | below 98.3% | 100% | ### Claim Service Credit To request a service credit, refer to the Service Unavailability Credit section of the [Exoscale Terms and Conditions](https://www.exoscale.com/terms/) or the [EUSA](https://www.exoscale.com/eusa/), whichever applies. --- url: https://community.exoscale.com/product/storage/block-storage/reference/ --- # Reference - Block Storage - [API Block Storage](https://community.exoscale.com/reference/api/block-storage/index.md) - All operations on Block Storage. (external) - [CLI Block Storage](https://community.exoscale.com/reference/cli/exo/compute/block-storage/index.md) - All commands on Block Storage. (external)