OpenStack is a powerful open-source cloud computing platform designed as an infrastructure-as-a-service (IaaS) solution. It offers comprehensive management of compute, network, and storage resources. The platform includes various services, such as Nova for compute, Neutron for networking, and several storage options. For backup and recovery, the platform can be enhanced using Trilio, an agentless solution natively integrated into OpenStack.
OpenStack supports both ephemeral storage, which is temporary and tied to the lifecycle of a virtual machine, and persistent storage, which remains independent of machine lifecycles. The storage services in OpenStack feature Cinder for block storage, Swift for object storage, Glance for image storage, and Manila for file storage.
Cinder plays a critical role in managing persistent storage for virtual machines. It provides on-demand, scalable block storage volumes that can be attached to instances, enabling users to store data beyond the lifecycle of individual virtual machines. Cinder abstracts the underlying storage infrastructure, supporting a wide range of storage backends, including traditional SANs and software-defined storage solutions.
In this article, we explore the features and architecture of Cinder, OpenStack’s block storage service, and examine how it integrates with other OpenStack components. We also present major Cinder storage operation use cases using the OpenStack CLI and Dashboard. Lastly, we will discuss how we can address the limitations of Cinder backups with the application-aware and granular recovery solution of Trilio for OpenStack.
Summary of key features of OpenStack Cinder
Feature | Description |
Persistent storage | Provides block storage volumes that persist independently of compute instances, even during instance termination or failure |
Volume types | Supports multiple types of backend storage options like local hypervisor storage with LVM, CEPH cluster, or dedicated SAN via iSCSI or FC drivers |
Snapshots and Backups | Enables snapshots for point-in-time volume copy for quick recovery or cloning into a new volume and backups stored on external backends for long-term data retention. |
Volume management | Enables a core set of administrative operations for managing block storage in OpenStack |
API and CLI access | Offers a RESTful API and command-line interface for programmatic management of Cinder resources |
Quota management | Allows setting limits on the amount of storage resources that projects and users can consume |
Automated OpenStack & OpenShift Data Protection & Intelligent Recovery
Enjoy native OpenStack integration, documented RESTful API, and native OpenStack CLI
Restore Virtual Machines with Trilio’s One-Click Restore
Select components of your build to recover via the OpenStack dashboard or CLI
Introduction to OpenStack Cinder
Cinder is OpenStack’s block storage service, designed to provide highly available, flexible, and high-performance storage for cloud workloads. It offers storage volumes that function like raw disk devices, which can be attached to or detached from virtual machines as needed. Users can install a file system on these volumes and manage their data accordingly.
Following is a high-level overview of storage provisioning for a virtual machine instance running on an OpenStack Compute host.
- The Cinder service running on an OpenStack Control host requests volume provisioning from a storage device via an API interface.
- Once the volume is provisioned, it is connected to the Compute host via a storage network using a protocol such as NFS, iSCSI, or Ceph RBD. The choice of protocol depends on the backend and configuration. Finally, the volume is attached to the virtual machine instance, appearing as a local storage device to the VM.
Cinder storage overview (source)
Key features of Cinder
OpenStack Cinder provides logical storage disks called volumes that are connected with virtual machines on OpenStack called instances. The key features of this storage provisioning are as follows.
Persistent storage
Cinder provides flexible and persistent storage volumes that are not tied to the lifecycle of virtual machines. It can independently create volumes and attach to or detach from VMs, providing high flexibility.
Volume types
Cinder can use different types of backend storage depending on performance, cost, and scalability needs. It can use local hypervisor storage with an LVM backend and can also connect with CEPH storage using RBD, which provides high scalability and data replication. For VMs requiring high performance and IO throughput, Cinder can connect with a dedicated SAN using iSCSI or FC drivers.
Snapshots and backups
Cinder, OpenStack’s block storage service, offers two key data protection mechanisms for existing volumes: snapshots and backups.
Snapshots are point-in-time copies that serve as quick recovery options or for creating clones. They are ideal when you need to revert to a previous state after making changes, or when you want a duplicate of an existing volume for testing or development environments. Snapshots are typically stored on the same storage backend as the original volume, making them fast for local recovery.
Cinder Backups, on the other hand, are designed for long-term data retention and disaster recovery. These can be stored on an external or different backend, providing an offsite copy of your data. While backups and their recovery are generally slower than snapshots, they are highly recommended for meeting compliance requirements and for robust offsite storage strategies.
While Cinder backups provide a foundational capability, Trilio enhances and extends OpenStack’s native data protection features, particularly for comprehensive backup, recovery, and migration of entire OpenStack workloads. Trilio offers an OpenStack-native solution that goes beyond individual Cinder volume backups to protect entire workloads, including their associated compute instances, networks, and configurations. This provides a more holistic and enterprise-grade approach to data protection and disaster recovery within OpenStack environments, complementing Cinder’s capabilities for mission-critical applications.
Volume management
Cinder allows you to perform various actions on storage volumes, such as creating, deleting, attaching, and detaching them. You can create new volumes and delete them when not required, and you can attach or detach volumes from instances. You can resize volumes as well; if the backend supports it, you can extend the volumes while they are in use, otherwise you need to detach the volume of the instance before resizing. For data integrity reasons, the volume size can be extended but not reduced.
API and CLI access
Cinder supports API and CLI access for management operations and interaction with its services. Both API and CLI require authentication via Keystone before you can perform any action. API is typically used for integration into a dashboard or automation system. The command-line interface can be used for manual administrative actions and quick operations.
Quota management
Quotas can be set for the maximum number of volumes or snapshots as well as total storage size. OpenStack provides multi-tenancy via a logical grouping of resources called projects. The projects can be created for hosting multiple customers or resources of different teams. With multi-tenancy, there is a typical requirement of setting up quota limits for the amount of resources a tenant can consume (number of instances, storage allocation, etc). Cinder provides the administrator the ability to limit a project to a specific number of volumes and snapshots and the maximum storage size allocation.
Learn how Trilio’s partnership with Canonical helps better protect your data
Cinder architecture
Cinder has been designed to be highly scalable, fault-tolerant, and flexible using a component-based architecture. The table below describes its main components.
Component | Function | Description |
cinder-api | Provides a RESTful API service that receives requests and routes them to the appropriate backend service | The API requires an authentication token via Keystone included in the headers of the API requests. The API supports HTTP requests like GET for retrieving information, POST to create resources, PUT to update volume information, and DELETE to remove volumes. |
cinder-scheduler | Decides which backend handles the required volume operations | When a user requests a new volume, Cinder-API passes the requests to the Scheduler, which uses filter criteria like storage capacity, availability zones, and performance tier to match the user request to the best-suited backend. |
cinder-volume | Manages the actual lifecycle of the storage volume | This includes creating, deleting, attaching, detaching, and managing snapshots of volumes. It listens for messages from the Scheduler and interacts with the storage backends. Each backend has a storage driver, and Cinder-Volume uses these drivers to translate high-level operations to low-level specific commands. The volume service is also responsible for managing the snapshots. |
cinder-backup | Backup and restoration of cinder volumes | The service supports full and incremental backups on various backends. Trilio extends this by providing OpenStack-native backup and recovery. It protects entire workloads and optimizes storage, enabling advanced features for enterprise disaster recovery and migration. |
Cinder integration with OpenStack
The Cinder components discussed above interact with different OpenStack services for end-to-end cloud operations:
- The Horizon (Dashboard) connects with the Cinder-API via a RESTful interface for managing volumes. The API converts the commands and communicates with other components via a messaging queue or HTTP/API interface.
- cinder-volume connects with Nova-API (Compute) via a RESTful interface to attach and detach volumes to and from instances.
- cinder-api connects with Keystone (Identity) via a REST API for authentication and authorization.
- Cinder allows users to create bootable volumes from images stored in Glance. Cinder can also export snapshots as images back into Glance. For image operations, cinder-api connects with Glance-API.
Cinder block Storage Service (Source)
cinder-volume handles storage provisioning by interacting with the backend storage through specific API interfaces and storage drivers. Once the volume is provisioned, the nova-compute service connects the host hypervisor and the volume over the storage network. The hypervisor then presents the volume as a local hardware device to the compute instance.
Cinder operations via the OpenStack CLI
The OpenStack cloud has a CLI client that can be used to perform different operations related to instances, storage volumes, networks, security groups, and more. The CLI is a Python-based package that can be installed on Linux, MAC OS X, or Windows by following the official installation guide.
The OpenStack CLI interacts with Cinder through APIs and can perform different operations. You can get the list of all available commands available for cinder volumes as follows:
$ openstack volume --help
Command "volume" matches:
volume attachment complete
volume attachment create
volume attachment delete
volume attachment list
volume attachment set
volume attachment show
volume backend capability show
volume backend pool list
volume backup create
volume backup delete
volume backup list
.
.
The CLI client needs to authenticate with Keystone before executing any operation. This can be done by sourcing an OpenStack RC file.
$ source openstackprojectrc.sh
After setting the OpenStack environment variables and authentication via the RC file, you can perform administrative operations via the OpenStack CLI. Here are some of them.
- List all available Volume types:
$ openstack volume type list
+---------------------------------+-------------------+-----------+
| ID | Name | Is Public |
+---------------------------------+-------------------+-----------+
| 94ae8702-f31c-4124-b030-59dfc4f | Flash-Storage | True |
| 653dd206-eb43-4064-bdee-1813784 | __DEFAULT__ | True |
+---------------------------------+-------------------+-----------+
- Create a 10 GB volume (if you do not specify the type, it is created as “DEFAULT”):
$ openstack volume create --size 10 datavolume
+---------------------+--------------------------------------------+
| Field | Value |
+---------------------+--------------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2025-01-21T14:31:30.906401 |
| description | None |
| encrypted | False |
| id | 2d9e14b1-92c1-42d8-8559-981c5946d990 |
| multiattach | False |
| name | datavolume |
| properties | |
| replication_status | None |
| size | 10 |
| snapshot_id | None |
| source_volid | None |
| status | creating |
| type | __DEFAULT__ |
| updated_at | None |
| user_id | ee63514e64a91464f11ee29e5efef63abcd098308d |
+---------------------+--------------------------------------------+
- List all available volumes and their status:
$ openstack volume list --max-width 70
+--------------+-------------+--------------+------+----------------+
| ID | Name | Status | Size | Attached to |
+--------------+-------------+--------------+------+----------------+
| 2d9e14b1- | datavolume | available | 10 | |
- Attach a volume to an instance named “webserver”:
$ openstack server add volume webserver datavolume
+-----------------------+--------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------+
| ID | 2d9e14b1-92c1-42d8-8559-981c5946d990 |
| Server ID | 6c4768e8-33a4-4d1e-b18e-f41676020867 |
| Volume ID | 2d9e14b1-92c1-42d8-8559-981c5946d990 |
| Device | /dev/vdb |
| Tag | None |
| Delete On Termination | False |
+-----------------------+--------------------------------------+
Learn about the features that power Trilio’s intelligent backup and restore
- List volumes to verify status and attachment:
$ openstack volume list --max-width 80
+--------------+------------+--------+------+-----------------------+
| ID | Name | Status | Size | Attached to |
+--------------+------------+--------+------+-----------------------+
| 2d9e14b1-92c1| datavolume | in-use | 10 | Attached to webserver |
- Detach a volume from an Instance:
$ openstack server remove volume webserver datavolume
$
$ openstack volume list --max-width 80
+------------------+-------------+----------+------+----------------+
| ID | Name | Status | Size | Attached to |
+------------------+-------------+----------+------+----------------+
| 2d9e14b1-92c1- | datavolume | available| 10 | |
- Take a snapshot:
$ openstack volume snapshot create --volume datavolume datavol-snap1
+-------------+--------------------------------------+
| Field | Value |
+-------------+--------------------------------------+
| created_at | 2025-02-01T02:26:22.590004 |
| description | None |
| id | 838e1fbb-aced-4245-b026-c199b56cea5a |
| name | datavol-snap1 |
| properties | |
| size | 10 |
| status | creating |
| updated_at | None |
| volume_id | 26cc41d5-4ace-49fc-84d1-f067f9d1f36b |
+-------------+--------------------------------------+
- List snapshots:
$ openstack volume snapshot list --max-width 70
+---------------+---------------+-------------+-----------+------+
| ID | Name | Description | Status | Size |
+---------------+---------------+-------------+-----------+------+
| 70a9cb0e- | datavol-snap1 | None | available | 10 |
- Create a new volume from a snapshot:
$ openstack volume create --snapshot datavol-snap1 datavol-restored
+---------------------+--------------------------------------------+
| Field | Value |
+---------------------+--------------------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2025-02-01T03:30:07.100071 |
| description | None |
| encrypted | False |
| id | 689b66d6-85e5-4046-8224-609ce9663a5a |
| multiattach | False |
| name | datavol-restored |
- Increase the size of the existing volume to 20 GB:
$ openstack volume set --size 20 datavol-restored
- Get volume details:
$ openstack volume show datavol-restored --max-width 70
+------------------------------+-----------------------------------+
| Field | Value |
+------------------------------+-----------------------------------+
| attachments | [] |
| availability_zone | nova |
| bootable | false |
| consistencygroup_id | None |
| created_at | 2025-02-01T03:30:07.000000 |
| description | None |
| encrypted | False |
| id | 689b66d6-85e5-4046-8224- |
| multiattach | False |
| name | datavol-restored |
| os-vol-tenant-attr:tenant_id | c84cbade401a42aba06de9415eb4f34d |
| properties | |
| replication_status | disabled |
| size | 20 |
- Delete a snapshot:
$ openstack volume snapshot delete datavol-snap1
- Delete a volume:
$ openstack volume delete datavol-restored
Cinder operations via OpenStack Dashboard
The OpenStack CLI is a highly flexible interface that is ideal for advanced users and administrators because it allows for complex operations and automation, but it requires knowledge of OpenStack commands and syntax. OpenStack also provides Horizon (Dashboard) as a graphical user interface to perform various cloud operations, like managing instances, volumes, networks, and more. The dashboard is suitable for both administrators and end users.
The end user can log into the OpenStack dashboard and perform Cinder volume operations by accessing the menu under Projects > Volumes. Here are some of the Cinder volume operations accessible through the Dashboard:
- Create a 10GB volume of type “DEFAULT”: Select Project > Volumes > Volumes > Create Volume. Select the type and availability zone. Enter the volume name and optional description and press Create Volume.
- List available volumes: Select Project > Volumes > Volumes.
- Attach the volume to an instance: Select Project > Volumes > Volumes. Select Manage Attachments under Actions (last column) of the volume listing for the specific volume. Select the instance from the drop-down and select Attach Volume.
- Create snapshot: Select Create Snapshot from the Actions column. Provide a snapshot name and optional description. Select Create Volume Snapshot.
- Create volume from snapshot: Select Project > Volumes > Snapshots. Under the Actions column press Create Volume. Provide the volume name, confirm the snapshot source from the drop-down and press Create Volume.
Addressing Cinder’s limitations with Trilio
Cinder’s snapshot functionality provides a much-needed basic level of data protection. However, these snapshots are often tied to the specific storage backend, limiting portability and potentially causing vendor lock-in.
Trilio offers a storage-agnostic backup and recovery solution that provides greater flexibility and avoids vendor lock-in. Trilio for OpenStack is designed to perform granular, application-centric restores, helping you significantly reduce downtime and simplify recovery. The table below shows how OpenStack enhances Cinder’s built-in capabilities.
Feature | Cinder (built-in) | Trilio for OpenStack |
Application centric | Limited/backend-dependent. Consistency often relies on the storage backend’s capabilities and may require manual scripting or quiescing. | Comprehensive, agentless. Provides application-centric backups by integrating with OpenStack APIs and understanding workload components without needing agents inside VMs. |
Granular recovery | Limited to full volumes. Typically, you restore the entire volume snapshot, even if you only need a single file or application component. | File-level and full Workload. Enables users to restore individual files or entire workloads as needed, minimizing downtime. |
Multi-cloud support | No. Cinder snapshots are generally tied to the specific OpenStack cloud and its underlying storage infrastructure. | Yes. Supports backup and restore across multiple OpenStack clouds and even to/from other OpenStack clusters or distributions. |
Centralized management | Basic. Management is primarily through Horizon or the Cinder CLI, typically focused on individual volumes and snapshots. | Advanced, multi-cluster. Provides a single management interface for backup and recovery for an OpenStack and Kubernetes cluster. |
Snapshot capabilities | Yes. Provides basic snapshot functionality for creating point-in-time copies of volumes. | Yes. Offers advanced snapshot capabilities, including incremental backups, and retention policies, optimized for OpenStack. |
Backup scheduling | Basic. Scheduling is typically handled through external tools or cron jobs, not integrated directly into Cinder’s core functionality. | Policy-based. Allows defining flexible backup schedules and retention policies through a user-friendly interface or declarative configuration. |
Data encryption | Dependent on backend. Encryption capabilities are a function of the specific storage backend and its configuration. | Yes. Provides end-to-end encryption of backup data, both in transit and at rest, independent of the underlying storage backend. |
Disaster recovery (DR) | Limited. Cross-region replication and failover capabilities are often dependent on the storage backend and may require complex manual configuration. | Comprehensive. Facilitates disaster recovery with features like cross-cluster and cross-distro. |
Volume migration | Supported within the same deployment, sharing the same Cinder API, scheduler service, and messaging queue. | Supports migration across tenants, availability zones, different regions, and different volume types.. |
Reporting and monitoring | Basic. Provides limited built-in reporting and monitoring. Often requires integration with external monitoring tools. | Advanced. Offers detailed reporting, dashboards, and alerts for backup and recovery operations, providing greater visibility and control. |
Find out how Vericast solved K8s backup and recovery with Trilio
Last thoughts
OpenStack Cinder offers a powerful and flexible way to manage block storage. Its open-source nature and support for diverse storage backends provide significant cost advantages and prevent vendor lock-in.
But what happens when your backup and recovery needs become more complex? What if you need to restore a single application, not just an entire volume? What if you need to move your workloads between different OpenStack clouds, or even to a public cloud? You need more.
Engineered specifically for the challenges of OpenStack-based VMs, Trilio extends Cinder’s capabilities with features designed for enterprise-grade data protection to tenants on a self-service basis and across the entire OpenStack Cloud. Ready to see the difference? Book a free demo.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content