You can use the BOSH Backup and Restore (BBR) command-line tool for backing up and restoring BOSH deployments and on-demand VMware Tanzu for Valkey on Cloud Foundry.
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 Valkey 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 Valkey service instances have support for BBR. For backup and restore of shared instances, see Configuring Automated Backups for Tanzu for Valkey on Cloud Foundry.
To take a backup of BOSH deployments and on-demand Tanzu for Valkey on Cloud Foundry, 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 Valkey backup artifact is roughly 1/10 of the RAM usage of the Valkey instance.
Record the BOSH Director IP and path to server certificate.
You need the names of your Valkey 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=VALKEY-BOSH-CLIENT \
BOSH_CLIENT_SECRET=VALKEY-BOSH-PASSWORD \
bosh -e BOSH-DIRECTOR-IP \
--ca-cert PATH-TO-BOSH-SERVER-CERTIFICATE \
--column name \
deployments
Where:
VALKEY-BOSH-CLIENT
, VALKEY-BOSH-PASSWORD
: To find these in the Tanzu Operations Manager Installation Dashboard, click the Tanzu for Valkey on Cloud Foundry tile, navigate to the Credentials tab, and click UAA Client Credentials. Note the Valkey 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
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 Valkey service instances to be valid, you must have a backup of the BOSH Director and TAS for VMs.
Backup each Valkey 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 VALKEY-SERVICE-INSTANCE-DEPLOYMENT-NAME \
backup
Where:
BOSH-CLIENT
, BOSH-CLIENT-PASSWORD
: These are the client credentials you retrieved in Preparing to Use BBR.VALKEY-SERVICE-INSTANCE-DEPLOYMENT-NAME
: This is the deployment name for the on-demand Valkey 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.
To restore using BBR:
To restore on-demand Valkey 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 Valkey service instance artifacts.
For each Valkey 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 VALKEY-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.
Because the Valkey 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 Valkey service between the TAS for VMsbackup and Valkey service instance backups.
If an on-demand Valkey service was deleted in between the backup of the TAS for VMsand the Valkey 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 Valkey service was created between the backup of the TAS for VMsand the Valkey 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.