Using BOSH Backup and Restore with Redis for Tanzu Application Service

You can use the BOSH Backup and Restore (BBR) command-line tool for backing up and restoring BOSH deployments and on-demand Redis for VMware Tanzu Application Service.

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.

For more information, see Configuring automated service backups and Comparison of the available backup methods.

Only on-demand Redis service instances have support for BBR. For backup and restore of shared instances, see Configuring Automated Backups for Redis for Tanzu Application Service.

Preparing to use BBR

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 Preparing to create your backup in the BBR documentation.

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.

Identify your Redis deployments

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
```
Where:
- REDIS-BOSH-CLIENT, REDIS-BOSH-PASSWORD: To find these in the Tanzu Operations 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 UAA credentials.
- BOSH-DIRECTOR-IP: You retrieved this value in Step 1–6: Preparing 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 Set up your jumpbox.
In the preceding command, BOSH_CLIENT is not a variable.

For example:
```
$ 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
```

Back up using BBR

To back up using BBR:

Back up your BOSH deployments.

This includes backing up your Tanzu Operations Manager installation settings, BOSH Director and TAS for VMs, as detailed in Backing up your Tanzu Operations Manager deployments with BBR.

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

Where:

BOSH-CLIENT, 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.

In the preceding command, BOSH_CLIENT_SECRET is not a variable.

For example:

$ 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 your backup 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.

Restore using BBR

To restore using BBR:

To restore on-demand Redis service instance data, follow the procedure for Restoring Tanzu Operations Manager deployments from backup with BBR in full.

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 following 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

Where PATH-TO-SERVICE-INSTANCE-ARTIFACT is the path to the artifact for the instance that you are currently restoring. By default the artifact directory includes the deployment name and timestamp.

In the preceding command, BOSH_CLIENT_SECRET is not a variable.

For example:

$ 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 Backing up artifact for a non-existent service instance inconsistent state and can skip the restore for that artifact. For more information, see Backing up artifact for a non-existent service instance.

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.

Possible inconsistent states

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.

No backing up artifact for a service instance

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.

Backing up artifact for a non-existent service instance

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 recreate it.