Non-Oracle-Scripted Backup and Restore

If you did not use Autonomous Transaction Processing for your RCU schemas or have multiple Essbase instances deployed with a single Autonomous Transaction Processing database, you cannot use the Oracle-provided backup scripts. You will need to individually back up the <Essbase prefix>_Essbase schema and data block volume for each instance.

Non-Oracle-Scripted Backup of an Essbase Instance

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.

Back up the Essbase Schema Using Data Pump and Oracle Cloud Infrastructure Console:

Configure your Autonomous Transaction Processing instance to work with your object storage.
Use a database client application to configure your Autonomous Transaction Processing instance for use with your Oracle Cloud Infrastructure account and a default object storage bucket. SQL Developer is a nice choice for a database client, because it allows Cloud Wallet connections and can connect to multiple Autonomous Transaction Processing instances at the same time, if needed.
1. Create a connection to your Autonomous Transaction Processing instance using SQL Developer (consider your proxy needs if connected via a corporate network).
2. Create an Auth Token using the Oracle Cloud Infrastructure Console.
  Copy and record the token value in a secure location. You will not be able to retrieve it again.
  
  Note:
  Previously, after this step, backups were manually configured for Autonomous Database from the OCI console. This manual operation is no longer in use.
Stop the Essbase services. You do not need to stop the node manager. (Do not stop the Essbase compute in Oracle Cloud Infrastructure.)
Back up the Essbase schema from your Autonomous Transaction Processing instance using Data Pump.
Each Essbase instance has nine associated schemas in your Autonomous Transaction Processing database. All nine schemas have a common rcu_schema_prefix, which is reported in the outputs of the Oracle Resource Manager (ORM) apply job. When using Oracle Identity Cloud Service for security, you only need to back up the <prefix>_ESSBASE schema that corresponds to the Essbase instance you want to back up. Remember that your Autonomous Transaction Processing instance may have Essbase schemas from multiple instances.
1. Make sure your TNS_ADMIN variable points to the wallet location of the Autonomous Transaction Processing instance from which you are exporting. Use Oracle Instant Client to issue the following Data Pump command:
```
$ expdp admin_<database name>_low directory=data_pump_dir schemas=<source schema prefix>_ESSBASE logfile=<logfile name>.out dumpfile=<dump file name>.dmp
```
  Note:
  The Autonomous Transaction Processing prefix in the connection information may not be the same as the schema prefix for the Essbase schema that you are backing up if you have deployed multiple Essbase instances to the same Autonomous Transaction Processing database.
2. Schema backups are physically stored on disk in the Data Pump directory of your Autonomous Transaction Processing database.
Use the PUT OBJECT procedure to move the .dmp file to Oracle Cloud Infrastructure object storage.
1. Move the .dmp file into an Object Storage bucket of your choosing (use SQL Developer, unless you installed the Instant Client SQL*Plus package). The /o/xxxxxxxxxx.dmp portion of the Put Object uri indicates the name you want to assign for the .dmp file in your Object Storage. The file_name must match the .dmp filename you assigned when you created the export on disk using data pump.
  
  Note:
  The object storage bucket name is case sensitive.
```
BEGIN DBMS_CLOUD.PUT_OBJECT(credential_name => <your credential name>, object_uri => <your object uri>, directory_name => <your data pump directory name>, file_name => <your data pump export file name>); END;/
```
2. Refresh your Object Storage Bucket to see the .dmp file.
Back up the Essbase data volume. Make sure you back up the block volume attached to the Essbase instance for which you just exported the Essbase schema. See Overview of Block Volume Backups and Backing Up a Volume. For step 2 under Using the Console in Backing Up a Volume, instead of selecting the block volume, use the menu and select Create Manual Backup.

Note:
Block Volume Backups are snapshots, so you can restart your Essbase services as soon as the Autonomous Transaction Processing schema backup is complete and the block volume backup has been initiated. You don’t need to wait for the block volume backup to complete before restarting your Essbase services.
Take note of the timestamp of your Autonomous Transaction Processing .dmp file in object storage and block volume backups. Because your Essbase services were stopped, these backups can be used to consistently restore Essbase if the need arises.
Start the Essbase services.

Restore an Essbase Instance from a Non-Oracle-Scripted Backup

If you have experienced a disaster, you'll need to deploy a new target Essbase instance before you can restore a non-Oracle-scripted backup. After deploying a new target instance, you can restore the Essbase schema and data block volume from backup. The new target instance should be the same version that was deployed on your failed compute. If you haven’t upgraded recently, you may need to retrieve an image from GitHub. After your new target instance is deployed, you can recover from backup using the target.

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

Skip steps 1 and 2.
Do not include the REMAP_SCHEMA=<sourceEBprefix>_ESSBASE:<targetEBprefix>_ESSBASE parameter in step 4b.
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 Transaction Processing database. These steps are also appropriate if you did not use Autonomous Transaction Processing for your database schemas.

Note:

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

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. Optionally, create a new Autonomous Transaction Processing 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.
- 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 (as oracle user). Do not stop the node manager or the Essbase compute in Oracle Cloud Infrastructure.

Note:
We assume that the Essbase services on the source compute are stopped, because this use case involves source compute server or hardware failure. If you are simulating these steps, make sure you also stop the source compute’s Essbase services.
Restore the target database schema from source schema backup.
When restoring the Autonomous Transaction Processing database for your target stack, you will import your source schema backup into the target Essbase schema using the REMAP_SCHEMA option.

Be sure to select a source schema backup that was taken during a time when your source Essbase services were stopped. Also, be sure that you have the source Essbase data block volume from the same time.

Note:
If you used the same Autonomous Transaction Processing database for your target instance as you had used for your source instance, then it is already configured for use with object storage. If you created a new Autonomous Transaction Processing database, then you will need to configure it for use with object storage. See step 1. in the Non-Oracle-Scripted Backup of an Essbase Instance section above.
1. Make sure your Instant Client is configured to point to the Autonomous Transaction Processing 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=data_pump_dir credential=<yourcredname>dumpfile=<your object storage native URI> REMAP_SCHEMA=<sourceEBprefix>_ESSBASE:<targetEBprefix>_ESSBASE table_exists_action=replace
```
  Note:
  The object (/o/) in your Object Storage Native URI will be the .dmp file name of your source backup in your object storage.
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 OCI 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 OCI 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 OCI console, select the target compute.
  2. Select resources > attached block volumes.
  3. From the Actions menu for the data block volume select Detach.
Restore the source data block volume from backup. Be sure to select the same Availability Domain as your target compute.
Attach the block volume 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 data block volume.
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 data volume.
3. sudo blkid and record the UUID of the newly attached data volume.
4. sudo vi /etc/fstab
5. Uncomment the data block volume entry.
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 un-needed block volumes and backups.