This topic describes component availability while you back up VMware Tanzu Application Service for VMs (TAS for VMs) using BOSH Backup and Restore (BBR). To ensure the correctness of backups, each component that requires a backup of its database has its own set of scripts.
The Cloud Controller is unavailable during backup. Apps and services continue to run as normal, but you cannot perform operations that require the Cloud Controller API. This includes:
Pushing new apps or creating new services
Modifying existing apps or services
Using the clients of the Cloud Controller API, such as:
The following table describes the backup process for the Cloud Controller:
Stage | Description |
---|---|
1: Pre-backup lock | The processes running on the Cloud Controller Worker, Cloud Controller, and Clock Global VMs are stopped. |
2: Backup | The BBR SDK backup script runs to back up the Cloud Controller database (CCDB), which contains state information for apps on your deployment. |
3: Post-backup unlock | The processes start again on the Cloud Controller Worker, Cloud Controller, and Clock Global VMs. |
For more information, see the Cloud Controller API documentation.
UAA remains available in read-only mode during backup. This means that you cannot perform write operations for clients, users, groups, identity providers, or zone configuration. However, you can continue performing read operations, such as generating, validating, and revoking tokens. Additionally, UAA continues to authenticate users and authorize requests for users and clients.
The read-only behavior during backup applies to all of the following ways of accessing UAA: the UAA API, the UAA CLI, cf CLI, login screens, and services such as the Single Sign-On for VMware Tanzu Service tile.
The following table describes the backup process for UAA:
Stage | Description |
---|---|
1: Pre-backup lock | UAA enters read-only mode. |
2: Backup | The BBR SDK backup script runs to back up the UAA database, which contains TAS for VMs user credentials. |
3: Post-backup unlock | UAA exits read-only mode. |
The Routing API remains available during backup. However, you cannot perform write operations using the Routing API because the routing database is locked. All read operations offered by the Routing API remain available.
The BBR SDK backup script for the Routing API backs up its database, which contains router groups, routes, and internal implementation information.
For more information, see the Routing API documentation in the Routing API repository on GitHub.
The Usage service is unavailable during backup. You cannot access the API as described in Reporting app, task, and service instance usage. Additionally, you cannot view usage and accounting reports as described in Reporting instance usage with Apps Manager.
The following table describes the backup process for Usage service:
Stage | Description |
---|---|
1: Pre-backup lock | The Usage service apps in the system org stop. This lock occurs before the Cloud Controller and UAA components lock. |
2: Backup | The BBR SDK backup script runs to back up the Usage service database. |
3: Post-backup unlock | The Usage service apps in the system org start again. This unlock occurs after the Cloud Controller and UAA components unlock. |
The Usage service runs as a set of TAS for VMs apps in the system
org.
The App Autoscaler service is unavailable during backup. You cannot access the UI or API. For any apps configured to use the App Autoscaler, the service does not scale these apps during backup.
The following table describes the backup process for App Autoscaler:
Stage | Description |
---|---|
1: Pre-backup lock | The Autoscaler apps in the system org stop. This lock occurs before the Cloud Controller and UAA components lock. |
2: Backup | The BBR SDK backup script runs to back up the App Autoscaler database. |
3: Post-backup unlock | The Autoscaler apps in the system org start again. This unlock occurs after the Cloud Controller and UAA components unlock. |
The App Autoscaler service runs as a set of TAS for VMs apps in the system
org.
For more information, see Using App Autoscaler to scale apps in TAS for VMs.
The NFS Service Broker backup scripts rely on the locking of the Cloud Controller to stop traffic to its service. This is because the Cloud Controller is responsible for invoking the NFS Service Broker.
When the Cloud Controller locks during backup, you cannot create or delete new instances or bindings of a volume service. However, apps already bound to a volume service continue to operate normally during backups.
The NFS Service Broker backup script performs a backup of the database used to store service instances and service bindings for the NFS Service Broker.
The Notification Service is not available during backup with BBR due to its dependency on the Cloud Controller. Notifications cannot be sent while the Cloud Controller is unavailable.
The Network Policy Server is unavailable during backup. While existing policies are still enforced, you cannot use the cf CLI to add or remove policies for container networking as described in Configuring container-to-container networking.
Runtime CredHub is unavailable during backup. If the binding credentials for an app are stored in CredHub, the app cannot fetch those credentials during backup. In some cases, apps might not start if they cannot fetch credentials for a service instance binding.