Disaster Recovery

Disaster Recovery

Introduction

Using the Disaster Recovery, you can restore your Service Instances in case the whole system is not available anymore. The only requirements are the Instance's GUID, the encryption password provided by the Backup Manager, and having access access to the Backup Store where the backups are saved.

Overview

The scenario considers two different sites, with both of them having a complete installation of Cloud Foundry and the a9s Data Service PCF Tile each. The sites are defined as a Primary Site and a Secondary Site, with the latter being ready to take over whenever the Primary Site is going through a disaster.

This gives you the following possibilities:

One Backup Store for each site

In order to be able to recover from most catastrophic scenarios, each Backup and each WAL file archive are stored in a Backup Storage (e.g., Azure Storage or AWS S3) on the same site where deployment is currently running (Primary). The Backup Storage is then replicated to another site (Secondary).

When a recovery is executed, the a9s Backup Manager reads the data stored within the Secondary Site, which has the necessary information in the backup's metadata file to recreate the Service Instance with the most recent data available:

service-dashboard

Each site has a completly independent setup, meaning that the Backup Storage for the Secondary Site can have a different set of credentials from the ones used by the Primary Backup Storage.

In this case neither site is aware of the other one in any way. Therefore, to be able to carry out a disaster recovery, the Primary Backup Storage from each site replicates itself into an independent Backup Storage on the Secondary Site. Here the underlying infrastructure will take over the replication between the Primary and Secondary Backup Storage. Afterwards, the Secondary Backup Storage is set to read-only on the storage provider.

When this setting is used the configuration will look like in the examples shown below:

For the Secondary Backup Store configuration:

config:
...
  plugin_configuration:
    disaster_recovery_backup_store:
      name:
        backup: "fog"
        restore: "fog"
      provider: "AWS"
      aws_access_key_id: MK1LBRQ2I5LLO1OGAHYP
      aws_secret_access_key: qN1Do2TUw+qnyGM37zVmVB2UsVWV1DNJClb+vB6Y
      container: backup-test-disaster-recovery

For the Primary Backupstore configuration:

config:
...
  plugin_configuration:
   ...
    fog:
      name:
        backup: "fog"
        restore: "fog"
      provider: "AWS"
      aws_access_key_id: LO1OGAHYPMK1LBRQ2I5L
      aws_secret_access_key: M37zVmVB2UsVWV1DNJClb+vB6YqN1Do2TUw+qnyG
      container: backup

One Backup Store for both sites

It is also possible to use only one Backup Store. In which case, the credentials for the Primary and Secondary Backup Store will be the same.

service-dashboard

When this setting is used the configuration will look like in the examples shown below:

For the Secondary Backup Store configuration:

config:
...
  plugin_configuration:
    disaster_recovery_backup_store:
      name:
        backup: "fog"
        restore: "fog"
      provider: "AWS"
      aws_access_key_id: LO1OGAHYPMK1LBRQ2I5L
      aws_secret_access_key: M37zVmVB2UsVWV1DNJClb+vB6YqN1Do2TUw+qnyG
      container: backup-test-disaster-recovery

For the Primary Backupstore configuration:

config:
...
  plugin_configuration:
   ...
    fog:
      name:
        backup: "fog"
        restore: "fog"
      provider: "AWS"
      aws_access_key_id: LO1OGAHYPMK1LBRQ2I5L
      aws_secret_access_key: M37zVmVB2UsVWV1DNJClb+vB6YqN1Do2TUw+qnyG
      container: backup

Notice how the Backup Stores share the credentials, endpoint, and backup/restore name.

Configure Backup Stores

Both the Primary and Secondary Backup Stores can be configured within the Backup Manager Manifest.

The Primary Backup Store is automatically configured with the details set to the Output Plugin. In order to use the Secondary Backup Store it is necessary to add its credentials to the Manifest. Even though setting a Secondary Backup Store is optional, it is useful if a separation between the Backup Stores is desired.