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.
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.
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
If the service instance no longer exists, you must re-create it. For example:
cf create-service postgres
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?
You can configure the tile to enable online and scheduled backup on service instances at the time of installation by taking the following steps:
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.
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:
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
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
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.