Chapter 2. Deploying the Block Storage backup service The Block Storage (cinder) backup service is optional. You must include it in your Red Hat OpenStack Platform (RHOSP) overcloud deployment to deploy it on your Controller nodes. 2.1. Deploying your active-active Block Storage backup service Before Red Hat OpenStack Platform (RHOSP) 17.1, the Block Storage backup service was deployed in active-passive mode and was managed by Pacemaker. In RHOSP 17.1, the Block Storage backup service is deployed in active-active mode and therefore runs on each Controller node and is not managed by Pacemaker. Note When you upgrade to RHOSP 17.1, the Block Storage backup service remains in active-passive mode. If you choose to use the Block Storage backup service, then you must include it in your RHOSP 17.1 overcloud deployment. Prerequisites An available storage source for your backup repository that uses one of the following back ends: Object Storage (swift), Red Hat Ceph Storage, NFS, or S3. Procedure Log in to the undercloud host as the stack user. Source the stackrc undercloud credentials file: Add this environment file to the stack with your other environment files: /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml This file deploys the Block Storage backup service in active-active mode and sets all the heat template parameters of this service to their default settings. The default settings configure your backup repository to use the Object Storage (swift) back end and the zlib data compression algorithm. If the default configuration meets your deployment requirements, then you do not need to do anything further and you can deploy the overcloud. If you need to use another back end for your backup repository or to change other default values: Add these parameters and their new values to the parameter_defaults section of either a new or existing environment file. For more information about the parameters that you can change, see Changing the default Block Storage backup service parameter values . For example, a new environment file /home/stack/templates/custom_backup_environment_file.yaml specifies an NFS back end and changes the data compression algorithm to zstd : Add the environment file that contains your specific parameter values to the stack with your other environment files, after the /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml file and deploy the overcloud. In this example: Verification: Ensure that the Block Storage services are running correctly on their hosts and then verify that the Block Storage backup service is deployed successfully. For more information, see Verifying the Block Storage backup service deployment . 2.2. Changing the default Block Storage backup service parameter values When you deploy the Block Storage backup service, it implements default settings for its heat template parameters. For more information, see Deploying your active-active Block Storage backup service . You can provide your deployment specific values for these parameters. Procedure Select and configure the back end for your backup repository. For more information, see Backup repository back-end configuration . Implement the Block Storage backup service configuration supported by your selected back end. For more information, see Block Storage backup service configuration . 2.2.1. Backup repository back-end configuration Select and configure one of the following back ends for your backup repository. 2.2.1.1. OpenStack Object Storage service (swift) back end Parameter Description Value CinderBackupBackend The back end of your backup repository. Note There are no additional parameters for this default back end. swift The default value. 2.2.1.2. NFS back end Parameter Description Value CinderBackupBackend The back end of your backup repository. nfs CinderBackupNfsShare The remote NFS share that you want to mount to store your backups. Ensure that you specify the server name or IP followed by the export. CinderBackupNfsMountOptions Optional: A comma-delimited list of options for mounting your NFS share. 2.2.1.3. Red Hat Ceph Storage back end Parameter Description Value CinderBackupBackend The back end of your backup repository. ceph CinderBackupRbdPoolName The RBD pool name of your Ceph cluster that stores your backups. backups 2.2.1.4. S3 back end Parameter Description Value CinderBackupBackend The back end of your backup repository. s3 CinderBackupS3Bucket The S3 bucket that stores your backups. Note Ensure that you create this bucket on the S3 back end and that you have configured the necessary permissions to write to this bucket, before you deploy the Block Storage backup service. volumebackups CinderBackupS3AccessKey The S3 Access key to connect to your S3 bucket. CinderBackupS3SecretKey The S3 Secret key to connect to your S3 bucket. CinderBackupS3EndpointUrl The URL of your S3 endpoint. 2.2.2. Block Storage backup service configuration You can implement any Block Storage backup service parameter that is supported by your selected back end. Parameter Description Value CinderBackupCompressionAlgorithm If your back end supports it, you can enable the data compression of your backup repository. Data compression requires additional CPU power but uses less network bandwidth and storage space. Note You cannot specify the data compression algorithm for the Red Hat Ceph Storage back end driver. This parameter is ignored for this back end. zlib Alternatives: none , bzip2 , or zstd

Commands:
source ~/stackrc
parameter_defaults: CinderBackupBackend: nfs CinderBackupNfsShare: 192.168.1.1:/var/export/cinder-backup CinderBackupCompressionAlgorithm: zstd
openstack overcloud deploy --templates -e [your other environment files] -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup-active-active.yaml -e /home/stack/templates/custom_backup_environment_file.yaml