Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 5. Configuring the Block Storage backup service

The Block Storage service (cinder) provides an optional backup service that you can deploy in your Red Hat OpenStack Services on OpenShift (RHOSO) environment.

Users can use the Block Storage backup service to create and restore full or incremental backups of their Block Storage volumes.

A volume backup is a persistent copy of the contents of a Block Storage volume that is saved to a backup repository.

You can configure the backup service under the cinderBackup section of the glance template in your OpenStackControlPlane CR.

Prerequisites

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

5.1. Storage back ends for backups
Copy link

You can use the following storage back ends for Block Storage backups:

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.2. 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>
...
    Copy to Clipboard Toggle word wrap
    • Replace <number_of_replicas> with a value greater than 1.

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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.3. Backup performance considerations
Copy link

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.

5.4. Setting options for backups
Copy link

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

...
    Copy to Clipboard Toggle word wrap

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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.5. Enabling data compression
Copy link

Backups are compressed by default with the zlib compression algorithm.

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
    Copy to Clipboard Toggle word wrap

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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 Red Hat Ceph Storage RADOS Block Device (RBD) as the storage back end.

Note

If you use Ceph RBD as the back end for backups together with Ceph RBD volumes, the performance for incremental backups is efficient.

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
    Copy to Clipboard Toggle word wrap

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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 the Object Storage service (swift) as the storage back end.

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
    Copy to Clipboard Toggle word wrap

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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.8. Configuring an NFS back end for backups
Copy link

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

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>
    Copy to Clipboard Toggle word wrap
    • 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
    Copy to Clipboard Toggle word wrap

  3. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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.9. Configuring an S3 back end for backups
Copy link

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
    Copy to Clipboard Toggle word wrap

  2. Update the control plane: 

    $ oc apply -f openstack_control_plane.yaml -n openstack
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    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.10. Block Storage volume backup metadata
Copy link

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.

Back to top
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

© 2025 Red Hat