Back Up and Restore: Version 21.2 and Later

In releases 21.2 and later, Oracle-scripted backups are for a single Essbase instance. This means that you can use Oracle scripts to perform backups even if you deployed multiple Essbase instances using a single Autonomous Database.

The Oracle-provided scripts support only Autonomous Database deployments (Autonomous Transaction Processing or Autonomous Data Warehouse).

Note:

If you didn't deploy with Autonomous Database, you cannot use the Oracle scripts to back up your Essbase instance. Instead, follow the same instructions provided for prior releases in Non-Oracle-Scripted Backup and Restore.

We’ve made some assumptions to limit the size and scope of this chapter. All examples assume that:

Autonomous Transaction Processing is the relational database into which Essbase schemas are deployed.
Oracle Identity Cloud Service (IDCS) is the security provider for the Essbase deployment.
The Essbase system admin user name (stored in WebLogic; it is the only non-IDCS user in the system) is the same between the source and the target Essbase stacks.
At the time of restore, the source instance backup has at least one valid Oracle Identity Cloud Service user with an Essbase system administrator role.

Oracle-Scripted Backup of an Essbase Instance

The Oracle-provided scripts perform the following tasks:

Configure your database to work with your object storage.
Stop the Essbase services.
Back up your database.
Back up your Essbase data block volume.
Start the Essbase services.

Before beginning a backup, gradually disconnect active user sessions, using MaxL alter application disable commands and/or connects (to prevent any new user activity), followed by alter system logout session and/or kill request (if you need to terminate any active sessions that don't need to complete). If you use disable commands in the application, remember to re-enable commands for that application after performing the backup.

To initiate a backup of an Essbase instance deployed using an Autonomous Database, schedule the backup for a convenient time when users are not in the system and follow these steps:

Note:

If using a private IP, provision an Oracle Cloud Infrastructure Bastion Service instance and use it as a proxy.

Ensure that the required policies to manage backups are in place.
ssh to your Essbase compute (as opc user).
Switch to the oracle user.
```
sudo su oracle
```
Change directories to /u01/vmtools/backup/.
```
cd /u01/vmtools/backup/
```
Run the script to configure your database to work with object storage. This is a one-time action per Essbase instance.
```
./configure-backup-storage.sh
```
After you launch the script, you are prompted for three inputs:
1. Enter database admin password:
  Type the clear text password. Because the password is protected information, you will not see the text as you type at the command prompt.
2. Enter OCI Username:
  To find the Oracle Cloud Infrastructure username:
  1. In Oracle Cloud Infrastructure, go to the upper right hand corner and click the profile menu icon .
  2. Click on the user.
  3. Copy the profile name at the top of the page.
    Copy the full username including oracleidentitycloudservice/ (not just the e-mail address).
  4. Go back to the command prompt, paste and press Enter.
3. Enter OCI Token:
  Enter the auth token. Because the auth token is protected information, you will not see the text you type or paste at the command prompt.
Run the backup script, run-backup.sh. This script also backs up the data block volume.

Note:
This backup script does NOT back up data and files in object storage if the stack catalog was configured with object storage in 21.4 or higher. You must take a backup of the data and files.

You are prompted for the database admin password if the vault option is not provided. Enter the clear text password. Because the password is protected information, you will not see the text as you enter it at the command prompt.

The syntax is as follows:
```
./run-backup.sh [--vault | -V] [--cpu n | -C n] [--parallel n]
```
Example:
```
./run-backup.sh --vault
```
The script has the following options:

--vault or -V sets the script to take the required credentials (admin password) stored in the vault, accessed using the OCID, instead of prompting you for the password.

--parallel sets the degree of paralleling for the backup. The default is to use all available parallel processes. This parameter is supported only for stacks created in Essbase 21.4+.

--cpu or -C also sets the degree of paralleling for the backup; this parameter is shown here only for backward compatibility.

If option --vault or -V is not used, you are prompted to enter the database admin (clear text) password. The protected password is not displayed as you enter it.

Note:
Essbase services are stopped by the backup.sh script and restarted after it finishes.
Capture object storage native URI.
At the end of the backup script, there will be two "moving export file" entries. You can copy and save the first one, which contains your object storage native URI. The object storage native URI is required when you issue the Data Pump Import command during restore. You must modify the moving export file entry to replace the .dmp file name with essbase%u.dmp.

Restore an Essbase Instance Using an Oracle-Scripted Backup

If you haven't done so already, install and configure Oracle Instant Client and tools. You will need to run Data Pump and SQL*Plus.

When recovering from disaster, you'll need to deploy a new target Essbase instance before you can restore a non-Oracle-scripted backup. The new target instance should be the same version that was deployed on your failed compute. After your new target instance is deployed, you can recover from backup using the target.

If you have not experienced a disaster, but want to migrate or roll back your source instance (same host recovery), use the restore steps below with these exceptions:

Skip steps 1 through 6.
Do not include the REMAP_SCHEMA=<sourceEBprefix>_ESSBASE:<targetEBprefix>_ESSBASE parameter in step 8b.
Because you are recovering on the same host from which you took your backup, the target instance referenced in the steps below will be your source instance.

The following steps will allow you to restore a single Essbase instance without impacting other Essbase instances that may be deployed in the same Autonomous Database.

Note:

If using a private IP, provision an Oracle Cloud Infrastructure Bastion Service instance and use it as a proxy.

Deploy a target Essbase stack using Oracle Marketplace.
- Use the source Oracle Identity Cloud Service confidential application.
- Use the source Autonomous Database and password. Optionally, create a new Autonomous Database. This is necessary if you are restoring in a new region.
- Use the source virtual cloud network and application subnet. Optionally, use a new network. This is necessary if you are restoring in a new region.
- If your source stack has a load balancer, do not deploy a target load balancer. You can change the backend set after deploying the target stack. Optionally, create a new load balancer. This is necessary if you are restoring in a new region.
- If your source stack has a bastion, deploy a bastion with the target stack (the source bastion can be deleted after successful recovery).
- Use the same Essbase system admin user name and password in the target as you used in the source.
- Use the same Oracle Identity Cloud Service Essbase admin user in the target stack as you used in the source stack. If this is not possible, make sure the source Essbase instance has at least one valid Oracle Identity Cloud Service user with the Essbase system administrator role. After you restore, you must log in to the target instance as a valid Oracle Identity Cloud Service user who had Essbase system administrator role on the source instance.
Manage the target instance log in URL:
1. If you have a source load balancer, manage its 'essbase’ backend set for use with the target compute. After allowing the load balancer time to refresh its connection to the target compute, log in to the Essbase web interface to make sure your target instance is deployed correctly before proceeding to restore from backup.
  1. Remove the source compute backend.
  2. Add the target compute backend. Use port 443.
  There is no need to update the Oracle Identity Cloud Service confidential application URLs, as the same load balancer IP is now routing to the target Essbase instance.
2. If your source stack did not have a load balancer, update your Oracle Identity Cloud Service Confidential Application Redirect and Post Logout Redirect URLs with the target IP address.
ssh to your target Essbase compute (as opc user).
Switch to the oracle user.
```
sudo su oracle
```
Change directories to /u01/vmtools/backup/.
```
cd /u01/vmtools/backup/
```
Run the script to configure your database to work with object storage. This is a one-time action per Essbase instance.
Execute the configure-backup script for the target.
```
./configure-backup-storage.sh [--vault | -V]         
```
where --vault or -V option will pull the required credentials from the vault instead of prompting for the password. By specifying this, the script will automatically take the password / OCID secret stored in the vault. The vault is identified to the instance from the metadata.
After you launch the script, you are prompted for three inputs:
1. Enter database admin password:
  Type the clear text password. Because the password is protected information, you will not see the text as you type at the command prompt.
2. Enter OCI Username:
  To find the Oracle Cloud Infrastructure username:
  1. In Oracle Cloud Infrastructure, go to the upper right hand corner and click the profile menu icon .
  2. Click on the user.
  3. Copy the profile name at the top of the page.
    Copy the full username including oracleidentitycloudservice/ (not just the e-mail address).
  4. Go back to the command prompt, paste and press Enter.
3. Enter OCI Token:
  Enter the auth token. Because the auth token is protected information, you will not see the text you type or paste at the command prompt.
4. Record the directory name and the credential name, which will be printed on the screen after the script has finished executing.
Stop the target Essbase services (as oracle user). Do not stop the node manager or the Essbase compute in Oracle Cloud Infrastructure
Restore the target database schema from source schema backup that was taken by the backup.sh script.
When restoring the Autonomous Database for your target stack, you will import your source schema backup into the target Essbase schema using the REMAP_SCHEMA option.
1. Make sure your Instant Client is configured to point to the Autonomous Database containing your target Essbase schemas.
2. Using the Oracle Instant Client, issue the following Data Pump import command
```
impdp admin@<database name>_high directory=<directory name> credential=<credential name> dumpfile=<object storage native URI> REMAP_SCHEMA=<source essbase prefix>_ESSBASE:<target essbase prefix>_ESSBASE table_exists_action=replace
```
  Notes:
  - The <database name> is the name of the database to which you connect to do the import.
  - The <directory name> is the directory name you recorded after running the configure-backup-storage.sh script.
  - The <credential name> is the credential name you recorded after running the configure-backup-storage.sh script.
  - The <object storage native uri> is the same one you captured during backup:
    - The namespace (/n/) is your tenancy’s namespace.
    - The bucket (/b/) is the source instance object storage bucket.
    - The object (/o/) is the <backup folder name>/<dump file name> of the source instance object storage. The.dmp file name used in the impdp statement should be essbase%u.dmp. The %u is a wildcard that will pick up multiple .dmp files, in case more than one is created.
After the schema import finishes, audit your data using a database client like SQL Developer. You can look at the ESSBASE_APPLICATION table within the <targetprefix>_ESSBASE schema and see that the target schema (which was empty prior to schema import) has the source applications.
Temporarily disable the /etc/fstab data block volume entry.
1. ssh to target compute (as opc user).
2. sudo vi /etc/fstab
3. Insert a # in front of the /u01/data entry.
4. Save the file.
Detach data block volume from the target Essbase compute. Note the iSCSI caution and be sure to unmount and disconnect the volume before detaching using the Oracle Cloud Infrastructure console.
1. To unmount:
  1. ssh to target compute (as opc user).
  2. lsblk
  3. sudo umount /u01/data
2. To disconnect iSCSI:
  1. In the Oracle Cloud Infrastructure console, select the target compute.
  2. Select resources > attached block volumes.
  3. From the Actions menu for the data block volume select iSCSI Commands & Information.
3. Copy iSCSI commands for disconnect.
4. ssh to the target compute (as opc user).
5. Paste the disconnect command you copied and press enter.
6. To detach:
  1. In the Oracle Cloud Infrastructure console, select the target compute.
  2. Select resources > attached block volumes.
  3. From the Actions menu for the data block volume select Detach.
Restore data block volume from source data block volume backup. Be sure to select the same Availability Domain as your target compute instance.
Attach the data volume using the following OCI CLI command (as opc user)
```
oci compute volume-attachment attach-iscsi-volume --instance-id $instanceid --volume-id $datavolumeid --display-name data-volume --auth instance_principal
```
where instanceid is the OCID of the compute instance and datavolumeid is the OCID of the data volume. The --display-name parameter must be provided with this value.
Use the iSCSI commands listed in the OCI console to connect your newly attached target block volumes.
Update /etc/fstab /u01/data entry and mount the new data block volume.
1. ssh to the target compute (as opc user).
2. lsblk to identify the name of the newly attached config and data volumes.
3. sudo blkid and record the UUID of the newly attached data volume.
4. sudo vi /etc/fstab
5. Uncomment the data block volume entries.
6. Replace the UUID in the existing data volume entry with the UUID of the newly attached data volume. Be sure not to change the mount point /u01/data. See Traditional fstab Options.
7. After saving the /etc/fstab file, issue the following commands:
  1. sudo systemctl daemon-reload
  2. sudo mount -a
8. lsblk to verify the mount points.
Start the Essbase services (as oracle user).

Note:

After successfully recovering into the target Essbase stack, you can delete the failed source compute node and do further cleanup to unneeded data block volumes and backups.