1. Essbase Stack Deployment on Oracle Cloud Infrastructure
  2. Back Up and Restore Essbase
  3. Back Up and Restore an Essbase Instance

Back Up and Restore an Essbase Instance

Use Essbase instance backups to restore all applications on your instance to a common point in time. Instance backups are primarily for disaster recovery, but are also appropriate when you want to migrate or restore all applications at once.

Backup and restore should be performed on the same version of Essbase.

Certain components from every Essbase stack you create contain information that makes your Essbase deployment unique. You will need to back up these unique stack components at appropriate intervals to meet your recovery objectives.

In the event of an Oracle Cloud Infrastructure compute or availability domain failure, you can recover your Essbase instance by building a new stack and restoring into it your Essbase backup. The newly deployed stack should be the same version of Essbase as the instance that failed. You may need to use GitHub to restore to the same version if you have not migrated versions in a timely manner.

For Essbase on Oracle Cloud Infrastructure, restoring from disaster necessitates deploying a new Essbase stack and attaching to it the appropriate block volume and relational database schema backups. Think of the pre-restore Essbase stack as a source (of block volumes, block volume backups, relational database schemas, relational database backups) and the post-restore Essbase stack as a target. Your restored target instance should reflect the source instance as of some point in time.

Backups of Essbase on Oracle Cloud Infrastructure depend on some details of your Essbase stack. A complete backup must protect all information that makes your Essbase deployment unique. Items you may be instructed to back up include:

  • Relational database schemas for every Essbase stack, which store some application, user and configuration information.
    • A single database schema for Essbase, called <instance prefix>_Essbase.
    • Eight database schemas for WebLogic, with the same <instance prefix>_<schemaname>.
  • Essbase application and database information stored on a block volume mounted as /u01/data.
  • WebLogic domain and configuration information stored on a block volume mounted as /u01/confg. (Essbase is a managed service within a WebLogic domain.)

Make sure that your backup strategy captures information at appropriate intervals to align with your RTO/RPO use case. As Essbase is not an autonomous database, Essbase services are stopped during backup.