Performing a full BDD restoration

You can use the bdd-admin script to perform a full restoration, which restores all BDD data, metadata, and configuration information to your cluster.

Because this includes configuration data, you must restore to the same cluster that was backed up. If you want to restore to a different cluster, see Restoring BDD to a new cluster.

Before restoring your cluster, verify that:

You are restoring to the same cluster that was backed up.
You have a backup TAR file created by the bdd-admin script's backup command.
You can provide the bdd-admin 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.
The database client is installed on the Admin Server. For MySQL databases, this should be MySQL client. For Oracle databases, this 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.

For more information on the restore command, see restore.

Important: The script will overwrite the data on your current cluster with the backed up data and won't roll the restoration back if it fails. Because of this, if your current cluster contains any important data, you should back it up before restoring.

To restore your cluster:

On the Admin Server, go to $BDD_HOME/BDD_manager/bin.
Stop your cluster if it's running:
```
./bdd-admin.sh stop [-t <minutes>]
```
Run the restore command:
```
./bdd-admin.sh restore -f <file>
```
Where <file> is the absolute path to the backup TAR file you want to restore from.
Enter the usernames and passwords for the component databases, if prompted. If you have HDP, you must also provide the username and password for Ambari.
When restoration completes, restart your cluster:
```
./bdd-admin.sh start
```
Verify that the restoration was successful:
1. On the Admin Server, go to $BDD_HOME/BDD_manager/bin and perform a healthcheck:
```
./bdd-admin.sh status --health-check
```
2. Log in to Studio and verify that the project data is consistent with the original cluster.
3. Load a new data set to make sure file upload is working.
4. Perform a simple transform.

The restore operation created a copy of your Dgraph database directory in DGRAPH_INDEX_DIR/.snapshot/old_copy. You should delete this if you decide to keep the restored version of the Dgraph databases.

If you have a MySQL database and the restoration failed during database migration, see Troubleshooting MySQL database restorations.