Using BOSH Backup and Restore
Note: Pivotal Platform is now part of VMware Tanzu. In v2.4 and later, Redis for Pivotal Platform is named Redis for VMware Tanzu Application Service.
Page last updated:
This topic describes how to use the BOSH Backup and Restore (BBR) command-line tool for backing up and restoring BOSH deployments.
BBR offers a standardized way to backup and restore the BOSH Director and BOSH Deployments that support it. If you have already set up BBR for your VMware Tanzu Application Service for VMs (TAS for VMs) deployment, you might find it easier to use BBR to back up your Redis service instances, in addition to, or instead of, using automated service backups.
Note: Only on-demand Redis service instances have support for BBR, for backup and restore of shared instances see Configuring Automated Backups for Redis for VMware Tanzu Application Service.
To take a backup of BOSH deployments and On-Demand Redis for Tanzu Application Service, BBR must be installed. If you do not already have it installed, follow the instructions in Prepare to Create Your Backup in the BBR documentation.
Note: When deciding on the disk size for the jumpbox remember that the Redis backup artifact is roughly 1/10 of the RAM usage of the Redis instance.
Record the BOSH Director IP and path to server certificate.
You need the names of your Redis service instances to back up and restore them.
To obtain the instance deployment names:
Run the following from your jumpbox, and record the resulting names.
$ BOSH_CLIENT=REDIS-BOSH-CLIENT \ BOSH_CLIENT_SECRET=REDIS-BOSH-PASSWORD \ bosh -e BOSH-DIRECTOR-IP \ --ca-cert PATH-TO-BOSH-SERVER-CERTIFICATE \ --column name \ deployments
REDIS-BOSH-PASSWORD: To find these in the Ops Manager Installation Dashboard, click the Redis for Tanzu Application Service tile, navigate to the Credentials tab, and click UAA Client Credentials. Note the
Redis BOSH UAAcredentials.
BOSH-DIRECTOR-IP: You retrieved this value in Step 1–6: Prepare to Create Your Backup.
PATH-TO-BOSH-SERVER-CERTIFICATE: This is the path to the Certificate Authority (CA) certificate for the BOSH Director. For more information, see Ensure BOSH Director Certificate Availability.
Note: In the command above,
BOSH_CLIENTis not a variable.
$ BOSH_CLIENT=p-redis-eb12345cb7a123450f08 \ BOSH_CLIENT_SECRET=338b012345d987bb24b5f \ bosh -e 10.0.0.5 \ --ca-cert /var/example/workspaces/default/root_ca_certificate \ --column name \ deployments
To back up using BBR:
Back up your BOSH deployments.
This includes backing up your Ops Manager installation settings, BOSH Director and TAS for VMs, as detailed in Backing Up Deployments with BBR.
Note: For a full restore of Redis service instances to be valid, you must have a backup of the BOSH Director and TAS for VMs.
Backup each Redis service instance:
From your jumpbox run the following.
$ BOSH_CLIENT_SECRET=BOSH-CLIENT-PASSWORD \ bbr deployment \ --target BOSH-DIRECTOR-IP \ --username BOSH-CLIENT \ --ca-cert PATH-TO-BOSH-SERVER-CERTIFICATE \ --deployment REDIS-SERVICE-INSTANCE-DEPLOYMENT-NAME \ backup
BOSH-CLIENT-PASSWORD: These are the client credentials you retrieved in Preparing to Use BBR.
REDIS-SERVICE-INSTANCE-DEPLOYMENT-NAME: This is the deployment name for the on-demand Redis service instance you are backing up.
Note: In the above command,
BOSH_CLIENT_SECRETis not a variable.
$ BOSH_CLIENT_SECRET=KJsdgKJj12345ljk83Hufy12345b6-34n4 \ bbr deployment \ --target 10.0.0.5 \ --username ops_manager \ --ca-cert /var/example/workspaces/default/root_ca_certificate \ --deployment service-instance_40b123e4a-be1c-1232-ad31-123e01b7d169 \ backup
Follow the steps given in the After Taking the Backups step of the BBR documentation.
Ensure you do this for the backup artifacts for all of your service instances and your BOSH Director and TAS for VMs.
To restore using BBR:
To restore on-demand Redis service instance data, follow the procedure for Restoring Deployments from Backup with BBR in full.
Note: Ensure that as part of Step 6: Transfer Artifacts to Jumpbox you transfer your Redis service instance artifacts.
For each Redis service instance artifact run the below command from your jumpbox:
$ BOSH_CLIENT_SECRET=BOSH-CLIENT-PASSWORD \ bbr deployment \ --target BOSH-DIRECTOR-IP \ --username BOSH-CLIENT \ --ca-cert PATH-TO-BOSH-SERVER-CERTIFICATE \ --deployment REDIS-SERVICE-INSTANCE-DEPLOYMENT-NAME \ restore --artifact-path PATH-TO-SERVICE-INSTANCE-ARTIFACT
PATH-TO-SERVICE-INSTANCE-ARTIFACTis the path to the artifact for the instance that you are currently restoring. By default the artifact directory includes the deployment name and timestamp.
Note: In the above command,
BOSH_CLIENT_SECRETis not a variable.
$ BOSH_CLIENT_SECRET=KJsdgKJj12345jk83Hufy12345b6-34n4 \ bbr deployment \ --target 10.0.0.5 \ --username ops_manager \ --ca-cert /var/example/workspaces/default/root_ca_certificate \ --deployment service-instance_40b12e4a-be1c-1232-ad31-12345e01b7d123 \ restore --artifact-path /tmp/service-instance_40b12e4a-be1c-1232-ad31-12345e01b7d169_1234503T141538Z
If a restore fails because there is no deployment of the name specified, then you are likely in the Backup Artifact for a Non-Existent Service Instance inconsistent state and can skip the restore for that artifact. For more information, see Backup Artifact for a Non-Existent Service Instance below.
Note: If you have a backup artifact (a
dump.rdb file) from any source besides a BBR backup, you can also use it in this restore procedure.
Because the Redis On-Demand broker is not locked during the backup process, the backups of the TAS for VMsand service instances can be out of sync if an app developer creates or deletes an on-demand Redis service between the TAS for VMsbackup and Redis service instance backups.
If an on-demand Redis service was deleted in between the backup of the TAS for VMsand the Redis service instances, there is no backup artifact for a deployed service instance. Resolve this by deleting the service, which had already been deleted during the backup process so presumably is not wanted.
If an on-demand Redis service was created between the backup of the TAS for VMsand the Redis service instances, there is a backup artifact which has no corresponding deployed service instance. In this case, the only action you need to take is to skip the restore of this artifact. The app developer who created the service can re-create it.