Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 5. Configuring the Block Storage backup service

You can use the optional backup service of the Block Storage service (cinder) to create and restore full or incremental backups of Block Storage volumes. Configure the backup service in the cinderBackup section of your OpenStackControlPlane CR.

5.1. Prerequisites
Copy link

  • You have the oc command line tool installed on your workstation.
  • You are logged on to a workstation that has access to the RHOSO control plane as a user with cluster-admin privileges.
  • You have enabled the backup service for the Block Storage service in your OpenStack Control Plane.

You can configure different storage back ends for Block Storage backups, including Red Hat Ceph Storage RBD, the Object Storage service (swift), NFS, and S3.

Red Hat Ceph Storage RBD is the default back end when you use Red Hat Ceph Storage. For more information, see Configuring the control plane to use the Red Hat Ceph Storage cluster.

For information about other back end options for backups, see OSP18 Cinder Alternative Storage.

You can use the backup service to back up volumes that are on any back end that the Block Storage service (cinder) supports, regardless of which back end you choose to use for backups. You can only configure one back end for backups, whereas you can configure multiple back ends for volumes.

Back ends for backups do not have transport protocol requirements for the RHOCP node. However, the backup pods need to connect to the volumes, and the back ends for volumes have transport protocol requirements.

5.3. Setting the number of replicas for backups
Copy link

You can run multiple instances of the Block Storage backup component in active-active mode by setting replicas to a value greater than 1. The default value is 0.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the cinder template to set the number of replicas for the cinderBackup parameter: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
   …
   cinder:
      template:
        cinderBackup: |
          replicas: <number_of_replicas>
...
    • Replace <number_of_replicas> with a value greater than 1.

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

Some features of the Block Storage backup service like incremental backups, the creation of backups from snapshots, and data compression can reduce the performance of backup operations.

By only capturing the periodic changes to volumes, incremental backup operations can minimize resource usage. However, incremental backup operations have a lower performance than full backup operations. When you create an incremental backup, all of the data in the volume must first be read and compared with the data in both the full backup and each subsequent incremental backup.

Some back ends for volumes support the creation of a backup from a snapshot by directly attaching the snapshot to the backup host, which is faster than cloning the snapshot into a volume. If the back end you use for volumes does not support this feature, you can create a volume from a snapshot and use the volume as backup. However, the extra step of creating the volume from a snapshot can affect the performance of the backup operation.

You can configure the Block Storage backup service to enable or disable data compression of the storage back end for your backups. If you enable data compression, backup operations require additional CPU power, but they use less network bandwidth and storage space overall.

Note

You cannot use data compression with a Red Hat Ceph Storage back end.

The cinderBackup parameter inherits the configuration from the top level customServiceConfig section of the cinder template in your OpenStackControlPlane CR. However, the cinderBackup parameter also has its own customServiceConfig section.

The following table describes configuration options that apply to all back-end drivers.

Expand
Table 5.1. Configuration options for backup drivers
OptionDescriptionValue typeDefault value

debug

When set to true, the logging level is set to DEBUG instead of the default INFO level. You can also set debug log levels for the scheduler dynamically without a restart by using the dynamic log level API functionality.

Boolean

false

backup_service_inithost_offload

Offload pending backup delete during backup service startup. If set to false, the backup service remains down until all pending backups are deleted.

Boolean

true

storage_availability_zone

Availability zone of the backup service.

String

nova

backup_workers

Number of processes to launch in the backup pod. Improves performance with concurrent backups.

Integer

1

backup_max_operations

Maximum number of concurrent memory, and possibly CPU, heavy operations (backup and restore) that can be executed on each pod. The number limits all workers within a pod but not across pods. Value of 0 means unlimited.

Integer

15

backup_native_threads_pool_size

Size of the native threads pool used for backup data-related operations. Most backup drivers rely heavily on this option, and you can increase the value for specific drivers that do not rely on it.

Integer

60

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the cinder template to set configuration options. In this example, you enable debug logs, double the number of processes, and increase the maximum number of operations per pod to 20.

    Example: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
   …
   cinder:
      template:
        customServiceConfig: |
          [DEFAULT]
          debug = true
        cinderBackup:
          customServiceConfig: |
           [DEFAULT]
           backup_workers = 2
           backup_max_operations = 20

...

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

5.6. Enabling data compression for volume backups
Copy link

Select a compression algorithm for your backups to reduce storage space and network bandwidth usage. Backups use zlib compression by default, but you can change algorithms or disable compression.

Data compression requires additional CPU power but uses less network bandwidth and storage space.

You can change the data compression algorithm of your backups or disable data compression by using the backup_compression_algorithm parameter in your OpenStackControlPlane CR.

The following options are available for data compression.

Expand
Table 5.2. Data compression options

Option

Description

none, off, or no

Do not use compression.

zlib or gzip

Use the Deflate compression algorithm.

bz2z or bzip2

Use Burrows-Wheeler transform compression.

zstd

Use the Zstandard compression algorithm.

Note

You cannot specify the data compression algorithm for the Red Hat Ceph Storage back end driver.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameter to the cinder template to enable data compression. In this example, you enable data compression with an Object Storage service (swift) back end: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  cinder:
    template:
      cinderBackup
        customServiceConfig: |
          [DEFAULT]
          backup_driver = cinder.backup.drivers.nfs.SwiftBackupDriver
          backup_compression_algorithm = zstd
        networkAttachments:
        - storage

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

You can configure Red Hat Ceph Storage RADOS Block Device (RBD) as the storage back end for your Block Storage backups. RBD provides efficient incremental backups when combined with Ceph RBD volumes.

For more information about Ceph RBD, see Configuring the control plane to use the Red Hat Ceph Storage cluster.

Prerequisites

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the cinder template to configure Ceph RBD as the back end for backups: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  cinder:
    template:
      cinderBackup
        customServiceConfig: |
          [DEFAULT]
          backup_driver = cinder.backup.drivers.nfs.CephBackupDriver
          backup_ceph_pool = backups
          backup_ceph_user = openstack
        networkAttachments:
        - storage
        replicas: 1

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

You can configure the Object Storage service (swift) as the storage back end for your Block Storage backups. The Object Storage service provides scalable object storage with customizable containers for backup data.

Prerequisites

  • You have planned networking for storage to ensure connectivity between the storage back end, the control plane, and the Compute nodes on the data plane. For more information, see Storage networks in Planning your deployment and Preparing networks for Red Hat OpenStack Services on OpenShift in Deploying Red Hat OpenStack Services on OpenShift.
  • Verify that the Object Storage service is active in your Red Hat OpenStack Services on OpenShift (RHOSO) deployment.

The default container for Object Storage service back ends is volumebackups. You can change the default container by using the backup_swift_container configuration option.

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the cinder template to configure the Object Storage service as the back end for backups: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  cinder:
    template:
      cinderBackup
        customServiceConfig: |
          [DEFAULT]
          backup_driver = cinder.backup.drivers.nfs.SwiftBackupDriver
        networkAttachments:
        - storage
        replicas: 1

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

You can configure NFS as the storage back end for your Block Storage backups. NFS provides network-accessible file storage with flexible mount options for backup data.

Prerequisites

Procedure

  1. Create a secret CR file, for example, cinder-backup-nfs-secrets.yaml, and add the following configuration for your NFS share: 

    apiVersion: v1
kind: Secret
metadata:
  labels:
    service: cinder
    component: cinder-backup
  name: cinder-backup-nfs-secrets
type: Opaque
stringData:
  nfs-secrets.conf: |
    [DEFAULT]
    backup_share = <192.168.1.2:/Backups>
    backup_mount_options = <optional>
    • Replace <192.168.1.2:/Backups> with the IP address of your NFS share.
    • Replace <optional> with the mount options for your NFS share.

  2. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the cinder template to add the secret for the NFS share and configure NFS as the back end for backups: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  cinder:
    template:
      cinderBackup
        customServiceConfig: |
          [DEFAULT]
          backup_driver = cinder.backup.drivers.nfs.NFSBackupDriver
        customServiceConfigSecrets:
        - cinder-backup-nfs-secrets
        networkAttachments:
        - storage
        replicas: 1

  3. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  4. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

You can configure the Block Storage service (cinder) backup service with S3 as the storage back end.

Prerequisites

Procedure

  1. Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the cinder template to configure S3 as the back end for backups: 

    apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
spec:
  cinder:
    template:
      cinderBackup
        customServiceConfig: |
          [DEFAULT]
          backup_driver = cinder.backup.drivers.s3.S3BackupDriver
          backup_s3_endpoint_url = <user supplied>
          backup_s3_store_access_key = <user supplied>
          backup_s3_store_secret_key = <user supplied>
          backup_s3_store_bucket = volumebackups
          backup_s3_ca_cert_file = /etc/pki/tls/certs/ca-bundle.crt
        networkAttachments:
        - storage

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack

  3. Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 

    $ oc get openstackcontrolplane -n openstack

    The OpenStackControlPlane resources are created when the status is "Setup complete".

    Tip

    Append the -w option to the end of the get command to track deployment progress.

When you create a backup of a Block Storage volume, the metadata for this backup is stored in the Block Storage service database. The Block Storage backup service uses this metadata when it restores the volume from the backup.

Important

To ensure that a backup survives a catastrophic loss of the Block Storage service database, you can manually export and store the metadata of this backup. After a catastrophic database loss, you need to create a new Block Storage database and then manually re-import this backup metadata into it.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top