Configuring backups for IBM® Cloud Private Cloud Foundry

Backups are sent to a customer-hosted NFS (Network File System) server, or backups remain on the nfs_WAL_server, depending on the configuration. You can manage the backups that are hosted on NFS in terms of available space. You can also encrypt the backups if that is part of its security rules.

About backups

Backups of the UAADB, CCDB, Director, and the deployments are scheduled. The backups are taken and posted locally on the nfs_WAL_server. The configuration can specify if the backups need to be moved to a customer-hosted NFS server.

See Component: User Account and Authentication (UAA) Server Open in a new tab and Component: Cloud Controller for more information. You can also back up your own deployment if you implement the scripts that are described in BOSH Backup and Restore .

UAADB/CCDB backups

Backups are taken every hour and kept for 6 hours on the nfs_WAL_server. Set the db_nfs_copy attribute in the uiconfig file to copy Backups on a customer-hosted NFS server. See Installing IBM Cloud Private Cloud Foundry for details. The copy process runs every hour and backups from 7 days are kept on the customer hosted NFS.

Director backups

Set the bbr_backup attribute in the uiconfig file to configure the backup schedule. See Installing IBM Cloud Private Cloud Foundry for details. The bbr_backup attribute has default values. They can be moved to a customer hosted NFS server if provided in the bbr_backup attribute. After the attribute is transferred to the customer-hosted NFS server, they are removed from the nfs_WAL_server.

If no customer hosted NFS server is provided, or the customer hosted NFS server is not available, then a number of backups, which are defined in the bbr_backup attribute, are kept on the nfs_WAL_server.

You can verify if the backup is working by checking the /var/vcap/store/bbr_backup/directordirectory, or your NFS server if you setup one for the director backup.

Restore your procedure:

Ensure that you have the backup .tgz file. If the backup is on the nfs_WAL_server, transfer it to the inception container.
Delete the director virtual machine.
Rename the /data/gen-vmware_micro_boshinit-state.json file.

Reinstall the director. Run the following command:

./cm engine reset
./cm states set-status-by-range -f deploy-director --status SKIP #This set all states after deploy-director to SKIP
launch_deployment.sh...

Launch restore, either from inception or from the nfs_wal_server. Launching from inception is useful if your backup is not anymore on the nfs_WAL_server.
- To launch restore from the nfs_wal_server, complete the following procedure:
  1. Log in to the nfs_wal_server remotely with the following command: ssh vcap@<nfs_WAL_ip> or bosh -e IBMCloudPrivate -d Bluemix ssh <nfs_WAL_server_name>. Run bosh -e IBMCloudPrivate vms to find the <nfs_WAL_ip> and <nfs_WAL_server_name>.
  2. Run tar xvf <file> to uncompress the backup either from the nfs /local_backup/director directory, or from the local disk /var/vcap/store/cfp-backup/director.
  3. To restore, run the following command: /var/vcap/packages/bbr-1.2.0/bbr director --host 192.168.247.2 --username director_backup --private-key-path /var/vcap/sys/run/cfp-backup/director_backup.key restore --artifact-path <uncompressed file>.
- To launch restore from inception, complete the following procedure:
  1. Copy your backup to the inception using for example docker cp <backup_file> cfp-inception-<environment_name>:/tmp
  2. Connect to inception with the following command: ./connect.sh -n <your environment name>.
  3. Run the following command to install bbr 1.2.0:
```
wget https://github.com/cloudfoundry-incubator/bosh-backup-and-restore/releases/download/v1.2.0/bbr-1.2.0.tar
tar xvf bbr-1.2.0.tar
chmod +x releases/bbr
```
  4. Run the following command to retrieve private key:
```
cat /data/CloudFoundry/certificates.yml
```
  5. Search for the director_backup group attribute.
  6. Copy in a file the key->data content. Ensure that each line starts at column one.
  7. Run tar xvf <file> to uncompress the backup either from the directory where you copied the backup.
  8. To restore, run the following command:
```
<BBR_INSTALLATION_PATH>/bbr director --host 192.168.247.2 --username director_backup --private-key-path <BACKUP_KEY_PATH>/director_backup.key restore --artifact-path <uncompressed file>.
```

Deployment backups

Bluemix deployment

As the director backup, the Bluemix (schedule, customer hosted NFS server and number of backup to keep) backup can be configured in the bbr_backup attribute. Only the Bluemix manifest is backed up.

You can verify if the backup is working by checking the directory /var/vcap/store/bbr_backup/deployments/Bluemix or your NFS server, if you setup an NFS server for the director backup.

Your customized deployment

If your deployment implements BOSH Backup and Restore Open in a new tab , then you can set the cf_custom attribute to automatically and periodically backup your deployment.

  cf_custom: |+
    properties:
      bbr_backup:
        deployment_backup:
          deployments:
          - (( grab bmxconfig.bbr_backup.deployments_backup.deployments.0 )) #This to continue to backup the Bluemix
          - name: YourDeployment
            schedule: "* 3 * * *"
            nb_backups: 15
            nb_logs: 15
            max_log_size: 10000

You can verify if the backup is working by checking the directory /var/vcap/store/bbr_backup/deployments/<YourDeploymentName> or your NFS server, if you setup one for the director backup.