Backup and restore with Bosh Backup and Restore

This topic describes how to use BOSH Backup and Restore (BBR) to back up and restore a BOSH deployment. If you have deployed a high availability (HA) deployment, then only the instances other than the “monitor” node can be backed up.

Backup

Back up a BOSH deployment

Run the BBR pre-backup check to confirm that your BOSH Director is reachable and has a deployment that you can back up with BBR:
```
bbr deployment -d postgres_service_instance_deployment pre-backup-check
```
If the pre-backup check command fails, run the command again adding the –debug flag to enable debug logs:
```
bbr deployment -d postgres_service_instance_deployment pre-backup-check --debug
```

If the pre-backup check succeeds, run the BBR backup command to back up your BOSH deployment:

bbr deployment -d postgres_service_instance_deployment backup --artifact-path <name-backup>

Backup step creates 2 files: a backup artifact, and a metadata file that looks like this:

    instances:
    - name: postgres-instance
    index: "0"
    artifacts:
    - name: postgres-backup
        checksums:
        ./pgdump: ae407e4d9ada961f1e12f96e7e88c80b5f838f22067519eeea92c2eb6f3c948c
    backup_activity:
    start_time: 2023/08/03 15:20:33 IST
    finish_time: 2023/08/03 15:20:39 IST

Both files must be saved together in the same directory for restore to use them.

Restore

You can only restore by using files from your local machine/jumpbox with access to the service instance’s network. The backup files must be those you downloaded by running the bbr command.

If the service instance no longer exists, you must re-create it. For example:

cf create-service postgres -w

After this, edit the metadata file’s “index” fields corresponding to each artfact. To get the index of an instance, look at the “index” column in the output from the following command:
```
bosh -d <service instance deployment> instances -i
```
To restore a BOSH deployment, ensure that the BOSH deployment backup artifact is in the directory from which you run BBR.
```
bbr deployment -d postgres_service_instance_deployment restore --artifact-path <PATH-TO-DEPLOYMENT-BACKUP?
```

Scheduled backup

You can configure the tile to enable online and scheduled backup on service instances at the time of installation by taking the following steps:

In the On Demand Service Settings section, select Allow Outboud Internet access.
In the Backups section, select Upload backups to S3 and fill in all the fields. The Access key and Bucket values are validated by accessing the AWS S3 APIs when you click Save. The Cron Schedule field is used to schedule the backups.
The Endpoint URL must be filled in this format: “https://s3.us-east-1.amazonaws.com”. Substitute your region for us-east-1.

You can manually trigger an online backup by using the postgres-backup errand. For example:

```
bosh -d postgres_service_instance_deployment run-errand postgres-backup --instance postgres-instance/3e977542-d53e-4630-bc40-72011f853cb5
```

This takes a backup of the Postgres database “postgres” running in the current service instance and uploads it to the S3 bucket configured in the preceding step 2.

Structure of S3 scheduled backup artifacts

For example: If you take a backup of your HA service deployment, service-instance_ffde758f-093d-4877-ba69-a5307a9884db, on time, 20231018T16:29:17UTC, which has 1 monitor instance and 3 postgres instances, one of which is primary and the other 2 replication nodes, then ALL 3 nodes’ data are fully backed up. This is despite duplication of data.

The reason for this choice is that the “Primary” role can switch from the current instance VM to another at the time of restore. You can’t keep other instance VM’s backup data empty/dummy because it’s possible that between the time of backup and restore, one of the replication nodes has become primary.

If you set the S3 prefix to be pg-test-2 at the time of Tile configuration, and if you open your S3 bucket containing the backup artifacts, you can see the following structure:

Non-HA Backup:

pg-test-2
├── service-instance_ffde758f-093d-4877-ba69-a5307a9884db
    ├──postgres-instance
        ├── 7dd4cf9f-6fa0-44ef-a63d-4875e8690fba
            ├── 20231018T16:29:17UTC
                ├── metadata
                ├── postgres-instance-0-postgres-backup.tar

HA backup:

pg-test-2
├── service-instance_ffde758f-093d-4877-ba69-a5307a9884db
    ├──postgres-instance
        ├── 7dd4cf9f-6fa0-44ef-a63d-4875e8690fba
            ├── 20231018T16:29:17UTC
                ├── metadata
                ├── postgres-instance-0-postgres-backup.tar
        ├── 52be4e9b-28eb-42be-b295-40ee01ea5607
            ├── 20231018T16:29:17UTC
                ├── metadata
                ├── postgres-instance-1-postgres-backup.tar      
        ├── ea47f481-6fb3-47dd-aef5-12245fc5d143
            ├── 20231018T16:29:17UTC
                ├── metadata
                ├── postgres-instance-2-postgres-backup.tar

Restoring from S3 backup artifacts

You can use the Amazon S3 scheduled backup files that originate from a non-HA service as a source for the bbr restore directly, without any modification. Download the backup artifacts from the S3 bucket and run the bbr restore command as described in the restore section.

To restore an HA service instance using an S3 scheduled backup artifacts folder, which should have originated from another HA service instance, see Sample App for Postgres for TAS.