Oracle-Scripted Backup and Restore

When a single Essbase instance is deployed to an Autonomous Transaction Processing database, you can use scripts provided by Oracle to back up the entire database and the Essbase block volumes.

Oracle-Scripted Backup of an Essbase Instance

These 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 and config block volumes.
Start the Essbase services.

Before beginning a backup, you may want to gracefully bring users off the system. Because the script stops your Essbase services. See Alter Application (especially enable/disable) and Alter System (especially logoff/ kill). If you use disable commands, you must reverse them with enable commands after completing your backup.

To initiate a backup of a single instance deployed using a single Autonomous Transaction Processing database, schedule the backup for a convenient time when users are not in the system and follow these steps:

Note:

If Essbase node has no Public IP, use the Bastion as a proxy.

Ensure that the required policies to manage backups are in place.
Using the Oracle Cloud Infrastructure console main menu, navigate to your source compute and record the Internal FQDN and Hostname from the compute’s Instance Details page. Should your source compute be unreachable at the time you restore, you will need this information.
ssh to your Essbase compute (as opc user).

Note:
If a Bastion is used, you may need to extend the default session length of 3 hours to meet the backup time needed for your quantity of data, or run the backup in background.
Run sudo su - oracle.
Run cd /u01/vmtools.
Run the script to configure your database to work with object storage. This is a one-time action.
```
./configure-backup-storage.sh
```
After you launch the script, you are prompted for three things:
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.
  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.
This backs up the data and config block volumes.
```
./backup.sh
```

Note:

The Essbase services are stopped by the backup.sh script and restarted after it finishes.

Restore an Essbase Instance from an Oracle-Scripted Backup

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 your backup was taken using the scripts provided by Oracle, you can easily recover from disaster. Simply use the following steps to restore your entire database and your block volumes to a new target instance.

Note:

If Essbase node has no Public IP, use the Bastion as a proxy.

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 the following exceptions:

Skip steps 1, 2, and 11.
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.

Deploy a target Essbase stack using Oracle Marketplace.
- Use the source Oracle Identity Cloud Service confidential application.
- Use the source Autonomous Transaction Processing database and password.
- Use the source virtual cloud network and application subnet.
- 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.
- 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 login 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 login 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, login 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 with the new Redirect and Post Logout Redirect URLs with the target IP address.
  Login to Oracle Identity Cloud Service and edit the source confidential application to ensure that the target IP address is substituted for the source IP address that was previously used.
Stop the target Essbase services first (as oracle user) and then stop the WebLogic services and the Node Manager (as opc user). Do not stop the Essbase compute in Oracle Cloud Infrastructure.

Note:
If you are simulating recovery, make sure you also stop the source compute’s Essbase services.
Restore the source Autonomous Transaction Processing database from backup.
Be sure to select a source Autonomous Transaction Processing backup that was taken during a time when your source Essbase services were stopped; also, be sure that you have a source Essbase block volume backup from the same time.

After the restore finishes, audit your data using a database client like SQL Developer. For example, you can look at the ESSBASE_APPLICATION table within the <targetprefix>_ESSBASE schema to verify the restored applications.
Temporarily disable /etc/fstab config and data block volume entries.
1. ssh to target compute (as opc user).
2. sudo vi /etc/fstab
3. Insert a # in front of the /u01/config and /u01/data entries.
4. Save the file.
Detach data and config block volumes from the target Essbase compute. Note the iSCSI caution and be sure to unmount and disconnect each volume before detaching using the OCI console.
1. To unmount:
  1. ssh to target the compute (as opc user).
  2. lsblk
  3. sudo umount /u01/config
  4. Repeat these steps to unmount the data block volume.
2. To disconnect iSCSI:
  1. In the OCI console, select the target compute.
  2. Select resources > attached block volumes.
  3. From the Actions menu for the config block volume, select iSCSI Commands & Information.
  4. Copy iSCSI commands for disconnect.
  5. ssh to the target compute (as opc user).
  6. Paste the disconnect commands you copied and press enter.
  7. Repeat these steps to disconnect the data volume.
3. To detach:
  1. In the OCI console, select the target compute.
  2. Select resources > attached block volumes.
  3. From the Actions menu for the config block volume select Detach.
  4. Repeat these steps to detach the data block volume.
Restore data and config block volumes from source block volume backup. Be sure to select the same Availability Domain as your target compute.
Attach block volumes created in the previous step to the target compute. The volume Attachment Type should be iSCSI.
Use the iSCSI commands listed in the OCI console to connect your newly attached target block volumes.
Update /etc/fstab entries and mount the new block volumes.
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 two newly attached volumes.
4. sudo vi /etc/fstab
5. Uncomment the config and data block volume entries.
6. Replace the UUID in the existing config and data volume entries with the UUID of the newly attached data and config volumes. Be sure not to change the mount points /u01/config and /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.
Manage hosts:
1. As opc user, update the target compute /etc/hosts file to map the source domain information to the target.
  Determine the fully qualified domain name of your source compute:
  1. Using the OCI console main menu, navigate to your source compute and record the Internal FQDN and Hostname from the compute's Instance Details page. If the source compute is not accessible, retrieve the record you saved during backup. See step 2 in Oracle-Scripted Backup of an Essbase Instance.
  2. Edit the /etc/hosts file on the target compute and append the source domain information to the entry containing the target compute.
```
sudo vi /etc/hosts
```
    The entry will have the format:
    
    <Target Compute IP> <target compute FQDN> <target compute hostname> <source compute FQDN> <source compute hostname>
2. As opc user, update the target compute /etc/oci-hostname.conf file. Set the PRESERVE_HOSTINFO setting to 3.
```
sudo vi /etc/oci-hostname.conf
```
Start the node manager (as opc user) first, and then 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 un-needed block volumes and backups.