LATEST VERSION: 1.10 - CHANGELOG
Pivotal Cloud Foundry v1.7

Backing Up Pivotal Cloud Foundry

Page last updated:

This topic describes the procedure for backing up each critical backend Elastic Runtime component. Pivotal recommends frequently backing up your installation settings before making any changes to your PCF deployment, such as configuration of any tiles in Ops Manager.

To back up a deployment, export installation settings, download the BOSH Deployment Manifest, temporarily stop the Cloud Controller, create and export backup files for each critical backend component, and restart the Cloud Controller. It is also important to record your Cloud Controller Database encryption credentials which you will need if you contact Pivotal Support for help restoring your installation.

To restore your backup, see the Restoring Pivotal Cloud Foundry from Backup topic.

Record the Cloud Controller Database Encryption Credentials

From the Installation Dashboard, select Pivotal Elastic Runtime > Credentials and locate the Cloud Controller section. Record the Cloud Controller DB Encryption Credentials. You must provide these credentials if you contact Pivotal Support for help restoring your installation.

Ccdb encrypt creds

Export Installation Settings

Pivotal recommends that you back up your installation settings by exporting frequently. Always export an installation before following the steps in the Import Installation Settings section of the Restoring Pivotal Cloud Foundry from Backup topic.

Note: Exporting your installation only backs up your installation settings. It does not back up your virtual machines (VMs) or any external MySQL databases.

From the Installation Dashboard in the Ops Manager interface, click the gear icon and select Export installation settings. This option is only available after you have deployed at least one time.

Export installation settings exports the current PCF installation settings and assets. When you export an installation, the exported file contains the base VM images, all necessary packages, and references to the installation IP addresses. As a result, an exported installation file can exceed 5 GB in size.

Action

Note: For versions of Ops Manager 1.3 or older, the process of archiving files for export may exceed the timeout limit of 600 seconds and result in a 500 error. To resolve this issue, you can manually increase the timeout value, or assign additional resources to the Ops Manager VM to improve performance. For more information, see the Pivotal Support Knowledge Base.

Target the BOSH Director

  1. Install Ruby and the BOSH CLI Ruby gem on a machine outside of your PCF deployment.

  2. From the Installation Dashboard in Ops Manager, select Ops Manager Director > Status and record the IP address listed for the Director. You access the BOSH Director using this IP address.

  3. Click Credentials and record the Director credentials.

  4. From the command line, run bosh target to log into the BOSH Director using the IP address and credentials that you recorded:

        $ bosh target 192.0.2.3
        Target set to `microbosh-1234abcd1234abcd1234'
        Your username: director
        Enter password: ********************
        Logged in as `director'
    

    Note: If bosh target does not prompt you for your username and password, run bosh login.

Download BOSH Manifest

  1. Install Ruby and the BOSH CLI Ruby gem on a machine outside of your Pivotal Cloud Foundry (PCF) system deployment.

  2. From the Installation Dashboard in Ops Manager, select Ops Manager Director > Status and record the IP address listed for the Director. You access the BOSH Director using this IP address.

  3. Click Credentials and record the Director credentials.

  4. From the command line, target the BOSH Director using the IP address and credentials that you recorded:

    $ bosh target 10.0.0.3
    Target set to `microbosh-1234abcd1234abcd1234'
    Your username: director
    Enter password: ********************
    Logged in as `director'
    

    Note: If bosh target does not prompt you for your username and password, run bosh login.

  5. Run bosh deployments to identify the name of your current BOSH deployment:

    $ bosh deployments
    +-------------+--------------+-------------------------------------------------+
    | Name        | Release(s)   | Stemcell(s)                                     |
    +-------------+--------------+-------------------------------------------------+
    | cf-example  | cf-mysql/10  | bosh-vsphere-esxi-ubuntu-trusty-go_agent/2690.3 |
    |             | cf/183.2     |                                                 |
    +-------------+--------------+-------------------------------------------------+
    

  6. Run bosh download manifest DEPLOYMENT-NAME LOCAL-SAVE-NAME to download and save each BOSH deployment manifest. You need this manifest to locate information about your databases. For each manifest, you will need to repeat these instructions. Replace DEPLOYMENT-NAME with the name of the current BOSH deployment. For this procedure, use cf.yml as the LOCAL-SAVE-NAME.

    $ bosh download manifest cf-example cf.yml
    Deployment manifest saved to `cf.yml'
    

Back Up Critical Backend Components

Your Elastic Runtime deployment contains several critical data stores that must be present for a complete restore. This section describes the procedure for backing up the databases and the servers associated with your PCF installation. For more information about which data stores you might be using, see Backing Up and Restoring PCF.

If you are running PostgreSQL and are on the default internal databases, follow the instructions below for backing up the Cloud Controller database, the UAA database, the Apps Manager database, MySQL server, and the NFS server.

If you are running your databases on the internal MySQL database only, follow the instructions below for backing up the MySQL server and the NFS server.

If you are running your databases or filestores externally, disregard instructions for backing up the Cloud Controller, UAA, and Apps Manager Databases and ensure that you back up your external databases and filestores, as well as the NFS server.

Note: To follow the backup instructions below, your network must be configured to allow access to the BOSH Director VM from your local machine. If you do not have local administrator access, use the scp command to copy the TAR file to the BOSH Director VM. For example: scp vcap@192.0.2.10:nfs.tar.gz \ and vcap@192.0.2.3:/nfs.tar.gz

Stop Cloud Controller

  1. From a command line, run bosh deployment DEPLOYMENT-MANIFEST to select your PCF deployment. The manifest is located in /var/tempest/workspaces/default/deployments/ on the Ops Manager VM. For example:

    $ bosh deployment /var/tempest/workspaces/default/deployments/cf-bd784.yml
    Deployment set to '/var/tempest/workspaces/default/deployments/cf-bd784.yml'
    

  2. Run bosh vms CF-DEPLOYMENT-NAME to view a list of VMs in your PCF deployment. CF-DEPLOYMENT-NAME corresponds to the name of your PCF release deployment, which is also the filename of your manifest file without the .yml ending. For example:

    $ bosh vms cf-bd784
    +-------------------------------------------+---------+----------------------------------+--------------+
    | Job/index                                 | State   | Resource Pool                    | IPs          |
    +-------------------------------------------+---------+----------------------------------+--------------+
    | ccdb-partition-bd784/0                    | running | ccdb-partition-bd784             | 10.85.xx.xx  | 
    | cloud_controller-partition-bd784/0        | running | cloud_controller-partition-bd784 | 10.85.xx.xx  |
    | cloud_controller_worker-partition-bd784/0 | running | cloud_controller-partition-bd784 | 10.85.xx.xx  |
    | clock_global-partition-bd784/0            | running | clock_global-partition-bd784     | 10.85.xx.xx  |
    | nats-partition-bd784/0                    | running | nats-partition-bd784             | 10.85.xx.xx  |
    | router-partition-bd784/0                  | running | router-partition-bd784           | 10.85.xx.xx  |
    | uaa-partition-bd784/0                     | running | uaa-partition-bd784              | 10.85.xx.xx  |
    +-------------------------------------------+---------+----------------------------------+--------------+
    

  3. Run bosh stop SELECTED-VM for each Cloud Controller VM. For example, stop the cloud_controller-partition-bd784 and cloud_controller_worker-partition-bd784 VMs.

    $ bosh stop cloud_controller-partition-bd784
    Acting as user 'director'...
    You are about to stop cloud_controller-partition-bd784/0
    Detecting deployment changes
    ----------------------------
    Stop cloud_controller-partition-bd784/0? (type 'yes' to continue)
    
    $ bosh stop cloud_controller_worker-partition-bd784
    Acting as user 'director'...
    You are about to stop cloud_controller_worker-partition-bd784/0
    Detecting deployment changes
    ----------------------------
    Stop cloud_controller_worker-partition-bd784/0? (type 'yes' to continue)
    

    Do not stop the ccdb-partition VM, which is the backend database for Cloud Controller if you opted to use PostgreSQL in your database deployment.

Back Up the Cloud Controller Database

Note: Follow these instructions only if you are using a PostgreSQL database.

  1. In the BOSH deployment manifest, locate the Cloud Controller database (CCDB) component under the ccdb key and record the IP address:

    ccdb:
        address: 192.0.2.96
        port: 2544
        db_scheme: postgres
    
  2. From the Installation Dashboard in Ops Manager, select Elastic Runtime and click Credentials > Link to Credential. Record the Cloud Controller database VM credentials.

    Ccdb creds

  3. SSH into the Cloud Controller database VM as the admin using the IP address and password recorded in the previous steps.

    $ ssh vcap@192.0.2.96
    Password:***********
    
  4. Run find /var/vcap | grep 'bin/pg_dump' to find the locally installed psql client on the CCDB VM. For example:

    $ root@192.0.2.96:~# find /var/vcap | grep 'bin/pg_dump'
    /var/vcap/data/packages/postgres/5.1/bin/pg_dump
    

  5. Run pg_dump from the locally installed psql client to export the database:

    $ /var/vcap/data/packages/postgres/5.1/bin/pg_dump -h 192.0.2.96 -U admin -p 2544 ccdb > ccdb.sql
    

  6. Exit from the Cloud Controller database VM.

  7. Run scp to copy the exported database to your local machine.

    $ scp vcap@192.0.2.96:~/ccdb.sql .
    

Back Up the UAA Database

Note: Follow these instructions only if you are using a PostgreSQL database.

  1. In the BOSH deployment manifest, locate the uaadb component and record the IP address:

    uaadb:
          address: 192.0.2.101
          port: 2544
          db_scheme: postgresql
    
  2. From the Installation Dashboard in Ops Manager, select Elastic Runtime and click Credentials > Link to Credential. Record the UAA database VM credentials.

    Uaadb creds

  3. SSH into the UAA database VM as the admin using the IP address and password recorded in the previous steps.

  4. Run find /var/vcap | grep 'bin/pg_dump' to find the locally installed psql client on the UAA database VM.

    $ root@192.0.2.101:~# find /var/vcap | grep 'bin/pg_dump'
    /var/vcap/data/packages/postgres/5.1/bin/pg_dump
    

  5. Run pg_dump from the locally installed psql client to export the database:

    $ /var/vcap/data/packages/postgres/5.1/bin/pg_dump -h 192.0.2.101 -U root -p 2544 uaa > uaa.sql
    

  6. Exit from the UAA database VM.

  7. Run scp to copy the exported database to your local machine.

    $ scp vcap@192.0.2.101:~/uaa.sql .
    

Back Up the Apps Manager Database

Note: Follow these instructions only if you are using a PostgreSQL database.

  1. In the BOSH deployment manifest, cf.yml, locate the databases component and record the IP address and password:

     databases:
       address: 192.0.2.104
       port: 2544
       db_scheme: postgresql
       roles:
        - tag: admin
         name: root
          password: *****************
        databases:
       - tag: console
         name: console
    
  2. From the Installation Dashboard in Ops Manager, select Elastic Runtime and click Credentials > Link to Credential. Record the Apps Manager database VM credentials.

    Appsmgr creds

  3. SSH into the Apps Manager database VM as the admin using the IP address and password recorded in the previous steps.

  4. Run find /var/vcap | grep 'bin/pg_dump' to find the locally installed psql client on the Apps Manager database VM.

    $ root@192.0.2.104:~# find /var/vcap | grep 'bin/pg_dump'
    /var/vcap/data/packages/postgres/5.1/bin/pg_dump
    

  5. Run pg_dump from the locally installed psql client to export the database:

    $ /var/vcap/data/packages/postgres/5.1/bin/pg_dump -h 192.0.2.104 -U root -p 2544 console > console.sql
    

  6. Exit from the Apps Manager database VM.

  7. Run scp to copy the exported database to your local machine.

    $ scp vcap@192.0.2.104:~/console.sql .
    

Back Up NFS Server

  1. In the BOSH deployment manifest, locate the nfs_server component and record the address:

    nfs_server:
      address: 192.0.2.10
      network: 192.0.2.0/24
    syslog_aggregator:
      address:
      port:
    
  2. From the Installation Dashboard in Ops Manager, select Elastic Runtime and click Credentials > Link to Credential. Record the NFS Server VM credentials.

    Nfs creds

  3. SSH into the NFS server VM and create a TAR file:

    $ ssh vcap@192.0.2.10 'cd /var/vcap/store && tar cz shared' > nfs.tar.gz
    

    Note: The TAR file that you create to back up NFS server might be large. To estimate the size of the TAR file before you create it, run the following command: ssh vcap@192.0.2.10 tar -cf - /dir/to/archive/ | wc -c

Back Up Pivotal MySQL Server

Note: The Elastic Runtime deploy contains an embedded MySQL Server that serves as the data store for the Application Usage Events, Notifications, and Autoscaler services. If you are not using Postgres, and in Elastic Runtime tile>Database you selected to use an Internal Database - MySQL, then the MySQL server also hosts your databases for Cloud Controller, UAA, and Apps Manager.

There are two ways to backup the MySQL Server:

Backing up MySQL Server Manually

Note: The procedure to manually backup MySQL below does not cover steps that are specific to a particular IaaS. It is important to tailor these instructions based on your infrastructure and configuration requirements.

Prerequisites
  • Locate the IP address for the MySQL node in the Status tab. Mysql server ip

  • Locate the root password for the MySQL server in the Credentials tab. Mysql root password

  1. Spin up a virtual machine (VM) to use for your MySQL backup and restore. Ensure the VM has sufficient disk space to receive the data dump. Configure network access to your p-mysql deployment.

  2. Install the mysqldump client of your choice.

  3. In a terminal window, execute the following command. To backup all databases in the MySQL deployment, use --all-databases:

    $ mysqldump -u root -p -h $MYSQLNODEIP --all-databases > user_databases.sql

    To backup a single database, specify the database name:

    $ mysqldump -u root -p -h $MHQL_NODE_IP $DB_NAME > user_databases.sql

    Note: The backup data you obtain from running the command above is not encrypted or compressed. Pivotal recommends encrypting the backup artifact, before storing it off-site.

  4. Store the backup in a different location than the MySQL primary storage, preferably off-site.

Start Cloud Controller

  1. Run bosh vms to view a list of VMs in your selected deployment. The names of the Cloud Controller VMs begin with cloud_controller.

    $ bosh vms
    +-------------------------------------------+---------+----------------------------------+--------------+
    | Job/index                                 | State   | Resource Pool                    | IPs          |
    +-------------------------------------------+---------+----------------------------------+--------------+
    | cloud_controller-partition-bd784/0        | failing | cloud_controller-partition-bd784 | 10.85.xx.xx  |
    | cloud_controller_worker-partition-bd784/0 | running | cloud_controller-partition-bd784 | 10.85.xx.xx  |
    | clock_global-partition-bd784/0            | running | clock_global-partition-bd784     | 10.85.xx.xx  |
    | nats-partition-bd784/0                    | running | nats-partition-bd784             | 10.85.xx.xx  |
    | router-partition-bd784/0                  | running | router-partition-bd784           | 10.85.xx.xx  |
    | uaa-partition-bd784/0                     | running | uaa-partition-bd784              | 10.85.xx.xx  |
    +-------------------------------------------+---------+----------------------------------+--------------+
    

  2. BOSH indicates a stopped VM with the state: failing. Run bosh start SELECTED-VM for each stopped Cloud Controller VM.

    $ bosh start cloud_controller-partition-bd784
    Processing deployment manifest
    ------------------------------
    Processing deployment manifest
    ------------------------------
    You are about to start cloud_controller-partition-bd784/0
    Processing deployment manifest
    ------------------------------
    Detecting deployment changes
    ------------------------------
    Start cloud_controller-partition-bd784/0? (type 'yes' to continue): yes
    Performing `start cloud_controller-partition-bd784/0'...
    Director task 1428
    Started preparing deployment
    Started preparing deployment > Binding deployment. Done (00:00:00)
    Started preparing deployment > Binding releases. Done (00:00:00)
    Started preparing deployment > Binding existing deployment. Done (00:00:01)
    Started preparing deployment > Binding resource pools. Done (00:00:00)
    Started preparing deployment > Binding stemcells. Done (00:00:00)
    Started preparing deployment > Binding templates. Done (00:00:00)
    Started preparing deployment > Binding properties. Done (00:00:00)
    Started preparing deployment > Binding unallocated VMs. Done (00:00:00)
    Started preparing deployment > Binding instance networks. Done (00:00:00)
     Done preparing deployment (00:00:01)
    Started preparing package compilation > Finding packages to compile. Done (00:00:01)
    Started preparing dns > Binding DNS. Done (00:00:00)
    Started preparing configuration > Binding configuration. Done (00:00:13)
    Started updating job cloud_controller-partition-bd784/0 > cloud_controller-partition-bd784/0 (canary)^@. Done (00:01:44)
    Task 1428 done
    Started     2015-02-25 17:54:28 UTC
    Finished    2015-02-25 17:56:27 UTC
    Duration    00:01:59
    cloud_controller-partition-bd784/0 has been started
    

Follow the steps in the Restoring Pivotal Cloud Foundry from Backup topic to restore a backup, import an installation to restore your settings, or to share your settings with another user.

Create a pull request or raise an issue on the source for this page in GitHub