Backup and restore considerations for a two data center deployment

Points to consider when backing up and restoring a two data center disaster recovery (DR) deployment on Kubernetes and OpenShift.

Full instructions about backing up and restoring your API Connect deployment are contained in the following topics:

Configuring backup settings for fresh install of the Management subsystem (10.0.1.1-eus or later)
Backing up and restoring the Developer Portal in a Kubernetes environment

Follow the steps in these topics to back up and restore your two data center DR deployment. However, there are some additional considerations to bear in mind if you have a two data center DR deployment, and these considerations are listed in the General considerations section that follows.

For general information about two data center disaster recovery in API Connect, see A two data center deployment strategy on Kubernetes and OpenShift.

General considerations

Best practice is to take regular, scheduled backups of the subsystems in the primary (active) data center, as this is the data center that contains the most valid data.
The subsystems in the secondary (passive) data center should be backed up only when key updates are made, for example when first deploying a passive data center, and then again before and after applying fix packs. This ensures that all of the endpoints in the deployment remain consistent.
If a subsystem or entire data center needs to be restored, the data will be retrieved from the backups of the subsystems in the active data center.
If a passive data center fails, you can either restore before you enable multiSiteHA mode on that site. Or, restore your passive data center, then trigger a re-sync of the databases.
Important: If the passive data center is offline for more than 24 hours, there can be issues with the disk space on the active data center so you must revert your deployment to a single data center topology. To revert to a single data center topology, you must remove the multi-site HA CR section from the active data center. When the passive site has been redeployed, the multi-site HA CR can be reapplied to the active site. For more information, see Removing a two data center deployment.
You can trigger the passive data center to re-sync its databases with the active data center by removing the multi-site HA section from the passive data center CR, and then adding the multi-site HA section back in again. This action triggers a re-sync with the active data center, to ensure that the passive data center contains the latest data.

On Kubernetes, this involves the following steps:

Remove the multiSiteHA section from the subsystem CR on the passive data center.
Apply the updated CR file to the subsystem on the passive data center, for example:
```
kubectl apply -f subsystem_cr.yaml -n <namespace>
```
Where subsystem_cr.yaml is the file name of the subsystem CR, and <namespace> is the target installation namespace in the Kubernetes cluster for the passive data center.

Add the multiSiteHA section back into the subsystem CR on the passive data center, for example:

multiSiteHA:
  mode: passive
  replicationEndpoint:
    annotations:
      cert-manage.io/issuer: ingress-issuer
    hosts:
    - name: mgrreplicationraleigh.cluster2.example.com
      secretName: raleigh-mgr-replication-worker-1
  replicationPeerFQDN: mgrreplicationdallas.cluster1.example.com
  tlsClient:
    secretName: mgr-replication-client

Apply the updated CR file to the subsystem on the passive data center again, for example:
```
kubectl apply -f subsystem_cr.yaml -n <namespace>
```