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 You can use the following storage back ends for Block Storage backups: 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 . Object Storage service (swift) NFS S3 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 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 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: Replace <number_of_replicas> with a value greater than 1 . Update the control plane: Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 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 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 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. Table 5.1. Configuration options for backup drivers Option Description Value type Default 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 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: Update the control plane: Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 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 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. 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 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: Update the control plane: Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 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. Configuring a Ceph RBD back end for Block Storage backups 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 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 . Procedure 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: Update the control plane: Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 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.7. Configuring an Object Storage service (swift) back end for backups 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 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: Update the control plane: Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 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 You can configure the Block Storage service (cinder) backup service with NFS 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 . Procedure Create a secret CR file, for example, cinder-backup-nfs-secrets.yaml , and add the following configuration for your NFS share: Replace <192.168.1.2:/Backups> with the IP address of your NFS share. Replace <optional> with the mount options for your NFS share. 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: Update the control plane: Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 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 You can configure the Block Storage service (cinder) backup service with S3 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 . Procedure 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: Update the control plane: Wait until RHOCP creates the resources related to the OpenStackControlPlane CR. Run the following command to check the status: 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 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.

Commands:
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane metadata: name: openstack spec: ... cinder: template: cinderBackup: | replicas: <number_of_replicas>
oc apply -f openstack_control_plane.yaml -n openstack
oc get openstackcontrolplane -n openstack
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
oc apply -f openstack_control_plane.yaml -n openstack
oc get openstackcontrolplane -n openstack
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
oc apply -f openstack_control_plane.yaml -n openstack
oc get openstackcontrolplane -n openstack
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
oc apply -f openstack_control_plane.yaml -n openstack
oc get openstackcontrolplane -n openstack
apiVersion: core.openstack.org/v1beta1 kind: OpenStackControlPlane spec: cinder: template: cinderBackup customServiceConfig: | [DEFAULT] backup_driver = cinder.backup.drivers.nfs.SwiftBackupDriver networkAttachments: - storage replicas: 1
oc apply -f openstack_control_plane.yaml -n openstack
oc get openstackcontrolplane -n openstack
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>
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
oc apply -f openstack_control_plane.yaml -n openstack
oc get openstackcontrolplane -n openstack
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
oc apply -f openstack_control_plane.yaml -n openstack
oc get openstackcontrolplane -n openstack