Disaster Recovery in Ops Manager

Page last updated:

This topic provides an overview of the options and considerations for disaster recovery in Ops Manager.

Operators have a range of approaches for ensuring they can recover Ops Manager, apps, and data in case of a disaster. The approaches fall into the following two categories:

Back Up and Restore Using BOSH Backup and Restore (BBR)

What is BBR?

BOSH Backup and Restore (BBR) is a CLI for orchestrating backing up and restoring BOSH deployments and BOSH Directors. BBR triggers the backup or restore process on the deployment or BOSH Director, and transfers the backup artifact to and from the deployment or BOSH Director.

Use BBR to reliably create backups of core Ops Manager components and their data. These core components include CredHub, UAA, BOSH Director, and VMware Tanzu Application Service for VMs (TAS for VMs).

Each component includes its own backup scripts. This decentralized structure helps keep scripts synchronized with the components. At the same time, locking features ensure data integrity and consistent, distributed backups across your deployment.

For more information about the BBR framework, see BOSH Backup and Restore in the open-source Cloud Foundry documentation.

Backing Up Ops Manager

Backing up Ops Manager requires backing up the following components:

  • Ops Manager settings
  • BOSH Director, including CredHub and UAA
  • TAS for VMs
  • Data services

For more information, see Backing Up Ops Manager with BBR. With these backup artifacts, operators can re-create Ops Manager exactly as it was when the backup was taken.

Restoring Ops Manager

The restore process involves creating a new Ops Manager deployment starting with the Ops Manager VM. For more information, see Restoring Ops Manager from Backup with BBR.

The time required to restore the data is proportionate to the size of the data because the restore process includes copying data. For example, restoring a 1 TB blobstore takes 1,000 times as long as restoring a 1 GB blobstore.


Unlike other backup solutions, using BBR to back up Ops Manager enables:

  • Completeness: BBR supports backing up BOSH, including releases, CredHub, UAA, and service instances created with an on-demand service broker. With Ops Manager v1.12, Ops Manager export no longer includes releases.

  • Consistency: BBR provides referential integrity between the database and the blobstore because a lock is held while both the database and blobstore are backed up.

  • Correctness: Using the BBR restore flow addresses container-to-container networking and routing issues that can occur during restore.

API Downtime During Backups

Apps are not affected during backups, but certain APIs are unavailable. The downtime occurs only while the backup is being taken, not while the backup is being copied to the jumpbox.

In a consistent backup, the blobs in the blobstore match the blobs in the Cloud Controller database. To take a consistent backup, changes to the data are prevented during the backup. This means that the Cloud Foundry API (CAPI), Routing API, Usage service, Autoscaler, Notification Service, Network Policy Server, and CredHub are unavailable while the backup is being taken. UAA is in read-only mode during the backup.

Backup Timings

The first three phases of the backup are lock, backup, and unlock. During this time, the API is unavailable. The drain and checksum phase starts after the backup scripts finish. BBR downloads the backup artifacts from the instances to the BBR VM, and performs a checksum to ensure the artifacts are not corrupt. The size of the blobstore significantly influences backup time.

The table below gives an indication of the downtime that you can expect. Actual downtime varies based on hardware and Ops Manager configuration. These example timings were recorded with TAS for VMs deployed on Google Cloud Platform (GCP) with all components scaled to one and only one app pushed.

Backup Timings
API State Backup phase Duration for External Versioned S3-Compatible Blobstore Duration for External Unversioned S3-Compatible Blobstore Duration for Internal Blobstore
API unavailable lock 15 seconds 15 seconds 15 seconds
backup <30 seconds Proportional to blobstore size 10 seconds
unlock 3 minutes 3 minutes 3 minutes
API available drain and checksum <10 seconds <10 seconds Proportional to blobstore size

Blobstore Backup and Restore

Blobstores can be very large. To minimize downtime, BBR only takes blob metadata during the backup. For example, in the case of internal blobstores such as WebDav and NFS, BBR takes a list of hard links that point to the blobs. After the API becomes available, BBR makes copies of the blobs.

Unsupported Products

  • Data services: The Pivotal data services listed below do not support BBR. Operators of these services should use the automatic backups feature of each tile, available within Ops Manager.

    • MySQL for Ops Manager
    • Pivotal Cloud Cache for Ops Manager
    • RabbitMQ for Ops Manager
    • Redis for Ops Manager
  • External blobstores and databases: BBR support for backing up and restoring external databases and blobstores varies across Ops Manager versions. For more information, see Supported Components and External Storage Support Across Ops Manager Versions in Backing Up Ops Manager with BBR.

Best Practices

This section describes best practices for backing up your Ops Manager deployment.

Frequency of Backups

VMware recommends that you take backups in proportion to the rate of change of the data in Ops Manager to minimize the number of changes lost if a restore is required. VMware recommends starting with backing up every 24 hours. If app developers make frequent changes, you should increase the frequency of backups.

Retention of Backup Artifacts

Operators should retain backup artifacts based on the timeframe they need to be able to restore to. For example, if backups are taken every 24 hours and Ops Manager must be able to be restored to three days prior, three sets of backup artifacts should be retained.

Artifacts should be stored in two data centers other than the Ops Manager data center. When deciding the restore timeframe, you should take other factors such as compliance and audit-ability into account.


VMware recommends that you encrypt artifacts and store them securely.

Disaster Recovery by Re-Creating the Deployment

An alternative strategy for recovering Ops Manager after a disaster is to have automation in place so that all the data can be re-created. This requires that every modification to Ops Manager settings and state is automated, typically through the use of a pipeline.

Recovery steps include creating a new Ops Manager, re-creating orgs, spaces, users, services, service bindings and other state, and re-pushing apps.

For more information about this approach, see the Cloud Foundry Summit presentation Multi-DC Cloud Foundry: What, Why and How? on YouTube.

Disaster Recovery for Different Topologies

This section describes disaster recovery strategies for different Ops Manager deployment topologies.


To prevent app downtime, some Pivotal customers run an active-active deployment, where they run two or more identical Ops Manager deployments in different data centers. If one Ops Manager deployment becomes unavailable, traffic is seamlessly routed to the other deployment. To achieve identical deployments, all operations to Ops Manager are automated so they can be applied to both Ops Manager deployments in parallel.

Because all operations have been automated, the automation approach to disaster recovery is a viable option for an active-active deployment. Disaster recovery requires re-creating Ops Manager, then running all the automation to re-create state.

This option requires discipline to automate all changes to Ops Manager. Some of the operations that need to be automated are:

  • App push, restage, scale
  • Org, space, and user create, read, update, and delete (CRUD)
  • Service instance CRUD
  • Service bindings CRUD
  • Routes CRUD
  • Security groups CRUD
  • Quota CRUD

Human-initiated changes always make their way into the system. These changes can include quotas being raised, new settings being enabled, and incident responses. For this reason, VMware recommends taking backups even when using an automated disaster recovery strategy.

Using BBR Backup and Restore Versus Recreating a Failed Ops Manager Deployment in Active-Active

The following table compares backing up and restoring using BBR to recreating a failed Ops Manager deployment in active-active:

Disaster Recovery
Restore the Ops Manager Data Re-create the Ops Manager Data
Preconditions IaaS prepared for Ops Manager install IaaS prepared for Ops Manager install
  1. Re-create Ops Manager
  2. Restore
  3. Apply changes to make restored Ops Manager match the other active Ops Manager
  1. Re-create Ops Manager
  2. Trigger automation to re-create orgs, spaces, etc.
  3. Notify app developers to re-push apps, re-create service instances and bindings
RTO (Recovery Time Objective)
Platform Time to re-create Ops Manager Time to re-create Ops Manager
Apps Time to restore Time until orgs, spaces, etc. have been re-created and apps have been re-pushed
RPO (Recovery Point Objective)
Platform Time of the last backup Current time
Apps Time of the last backup Current time


Instead of having a true active-active deployment across all layers, some Pivotal customers prefer to install a Ops Manager or Ops Manager deployment on a backup site. The backup site resides on-premises, in a co-location facility, or the public cloud. The backup site includes an operational deployment, with only the most critical apps ready to accept traffic should a failure occur in the primary data center. Disaster recovery in this scenario involves:

  1. Switching traffic to the passive Ops Manager, making it active.

  2. Recovering the formerly-active Ops Manager. Operators can choose to do this through automation, if that option is available, or by using BBR and the restore process.

The RTO and RPO for re-creating the active Ops Manager are the same as outlined in the table above.

Reducing RTO

Both the restore and re-create data disaster recovery options require standing up a new Ops Manager, which can take hours. If you require shorter RTO, several options involving a pre-created standby hardware and Ops Manager are available. The following table outlines these options:


Public cloud environment ready for Ops Manager installation, no Ops Manager installed. This saves both IaaS costs and Ops Manager instance costs. For on-premise installations, this requires hardware on standby that is ready to install on, which might not be a realistic option.


Ops Manager installed on standby hardware and kept up to date, VMs scaled down to zero (that you spin up each time there is a platform update), no apps installed, no orgs or spaces defined.

Active-inflate platform

Bare-minimum Ops Manager installation, either with no apps, or a small number of each app in a stopped state. On recovery, push a small number of apps or start current apps, while simultaneously triggering automation to scale the platform to the primary node size, or a smaller version if large percentages of loss are acceptable. This mode allows you to start sending some traffic immediately, while not paying for a full non-primary platform. This method requires data seeded, but it is usually acceptable to complete data sync while platform is scaling up.

Active-inflate apps

Non-primary deployment scaled to the primary node size, or smaller version if large percentages of loss are acceptable, with a small number of Diego Cells (VMs). On fail-over, scale Diego Cells up to primary node counts. This mode allows you to start sending most traffic immediately, while not paying for all the AIs of a fully-fledged node. This method requires data to be there very quickly after failure. It does not require real-time sync, but near-real time.

There is a trade-off between cost and RTO: the less the replacement Ops Manager needs to be deployed and scaled, the faster the restore.

Automating Backups

BBR generates the backup artifacts required for Ops Manager, but does not handle scheduling, artifact management, or encryption. You can use the starter Concourse pipeline from the BBR PCF Pipeline Tasks repository on GitHub to automate backups with BBR.

You can also use Stark & Wayne’s Shield as a front end management tool using the BBR plugin.

Validating Backups

To ensure that backup artifacts are valid, the BBR tool creates checksums of the generated backup artifacts, and ensures that the checksums match the artifacts on the jumpbox.

However, the only way to be sure that the backup artifact can be used to successfully re-create Ops Manager is to test it in the restore process. This is a cumbersome, dangerous process that should be done with care. For instructions, see Step 11: (Optional) Validate Your Backup in Backing Up Ops Manager with BBR.