restore

Note: restore can't be run if start, stop, restart, backup, publish-config, or reshape-nodes is currently running.

To restore the backed up cluster, run the following from the Admin Server on the target cluster:

./bdd-admin.sh restore [option] <file>

Where <file> is the absolute path to the backup file.

restore supports the following options.

Option	Description
`-f, --full`	Performs a full restoration, which restores all BDD data and configuration information. If this option isn't specified, the script will perform a data-only restoration, which doesn't include configuration. For more information, see Restoration types below.
`-l, --local-tmp <path>`	The absolute path to the temporary directory on the Admin Server used during the restore operation. If this option isn't specified, `BACKUP_LOCAL_TEMP_FOLDER_PATH` will be used. Before restoring, verify that this location contains enough free space. For more information, see Space requirements below.
`-d, --hdfs-tmp <path>`	The absolute path to the temporary directory in HDFS used during the restore operation. If this option isn't specified, `BACKUP_HDFS_TEMP_FOLDER_PATH` will be used. Before restoring, verify that this location contains enough free space. For more information, see Space requirements below.
`-v, --verbose`	Enables debugging messages.

Note that restore makes a copy of the current Dgraph databases directory in DGRAPH_INDEX_DIR/.snapshot/old_copy, which should be deleted if the restored version is kept.

For detailed instructions on restoring your cluster, see Performing a full BDD restoration and Restoring BDD to a new cluster.

Prerequisites

Before running restore, verify the following:

You have an existing backup TAR file created by the backup command.
You can provide the script with the usernames and passwords for all component databases. You can either enter this information at runtime or set the following environment variables. Note that if you have HDP, you must also provide the username and password for Ambari.
- BDD_STUDIO_JDBC_USERNAME: The username for the Studio database
- BDD_STUDIO_JDBC_PASSWORD: The password for the Studio database
- BDD_WORKFLOW_MANAGER_JDBC_USERNAME: The username for the Workflow Manager Service database
- BDD_WORKFLOW_MANAGER_JDBC_PASSWORD: The password for the Workflow Manager Service database
- BDD_HADOOP_UI_USERNAME: The username for Ambari (HDP only)
- BDD_HADOOP_UI_PASSWORD: The password for Ambari (HDP only)
Both the source and target clusters have the same minor version of BDD; for example, 1.4.0.37.xxxx.
Both clusters have the same type of database, either Oracle or MySQL. Hypersonic isn't supported.
The database client is installed on the Admin Server. For MySQL databases, this should be MySQL client. For Oracle databases, it should be Oracle Database Client, installed with a type of Administrator. The Instant Client isn't supported.
For Oracle databases, the ORACLE_HOME environment variable must be set to the directory one level above the /bin directory that the sqlplus executable is located in. For example, if the sqlplus executable is located in /u01/app/oracle/product/11/2/0/dbhome/bin, ORACLE_HOME should be set to /u01/app/oracle/product/11/2/0/dbhome.
For MySQL databases, the lower_case_table_names system variable has the same value on both clusters. If it doesn't, be sure to change it accordingly on the current cluster or the restoration will fail. For more information, see Troubleshooting MySQL database restorations.
The temporary directories used during the restore operation contain enough free space. For more information, see Space requirements below.

Restoration types

restore supports two types of restoration: data-only and full.

Data-only restorations are performed by default. They restore the following to the target cluster:

The Dgraph databases
The databases used by Studio and the Workflow Manager Service
The user sandbox data in the location defined by HDFS_DP_USER_DIR in bdd.conf
The HDFS sample data in $HDFS_DP_USER_DIR/edp/data/.collectionData

Note that data-only restorations don't include any configuration information. Because of this, they can be performed on any BDD cluster that meets the criteria described in Prerequisites. It can be different from the one that was originally backed up and can even have a different topology than the original. For example, you can restore data from an eight-node cluster to a new six-node one.

Full restorations restore the data listed above and the following configuration data:

$BDD_HOME/BDD_manager/conf/bdd.conf
The Hadoop TLS/SSL certificates (if TLS/SSL is enabled)
Studio configuration from portal-ext.properties and esconfig.properties
The DP CLI blacklist and whitelist (cli_blacklist.txt and cli_whitelist.txt)
The OPSS files cwallet.sso and system-jzn-data.xml

Because full restorations include configuration information, they can only be performed on the original cluster that was backed up.

Space requirements

When the script runs, it verifies that the temporary directories it uses contain enough free space. These requirements only need to be met for the duration of the restore operation.

The local-tmp directory on the Admin Server must contain enough space to store the Dgraph databases, $HDFS_DP_USER_DIR, and the edpDataDir (defined in edp.properties) at the same time.
The hdfs-tmp directory in HDFS must contain free space equal to the largest of these items, as it will only store them one at a time.

If these requirements aren't met, the script will fail.

Examples

The following command performs a data-only restoration using the /tmp/bdd_backup1.tar file:

./bdd-admin.sh restore /tmp/bdd_backup1.tar

The following command performs a full restoration using the /tmp/bdd_backup1.tar file:

./bdd-admin.sh restore -f /tmp/bdd_backup1.tar