Should you back up your EPM Development environment?

  • Date: May 8, 2020
  • Article by: Joe Malewicki

Taking regular backups of a Development Oracle EPM environment is a task many companies neglect to perform, yet is a critical step towards insuring the investment in time and money an EPM implementation requires. In a new Hyperion environment, we assume server and relational database backups are being taken, however we do find businesses in which Development servers are not regularly backed up, as they are deemed to be non-essential by the IT portion of the business. Failure of these servers would mean losing not just the Development data, but the Oracle EPM infrastructure would have to be re-built as well! At later stages of the Oracle EPM application creation and deployment process, the assumption that Development is not critical may be true – you have copies of applications, data and objects in Production, QA or Stage you may recover from. However, the early development stages of Oracle EPM applications can be the most costly in terms of consultant time and dollars. Perhaps Production is not yet built, or there may be a new application that is not yet ready for promotion to the Stage environment.  A loss of Development data in this case would mean a substantial set-back for the team. 

There will be two types of backups discussed in this article: external storage and local storage. External storage is defined as a backup that is taken by a 3rd party such as a NetBackup group, that is stored outside of the Oracle EPM server environment. Often, operating system backups are regularly scheduled but exclude the application disk drives. Generally, the Oracle EPM application/infrastructure groups are not in control of these backups directly, but may give directions regarding what to include and exclude from these regularly-scheduled backups.

Local storage is defined as those stored backups that the Oracle EPM application/infrastructure teams create themselves, and are normally located on one or more servers within the Oracle EPM environment. The Oracle EPM team is able to schedule or run these backups at will, and has control over what is backed up and where those backups will be moved to within the Oracle EPM server environment. These backups include exports of Reports, Level0 exports of Essbase, LCM extracts of security, among others. 

iArch Solutions strongly recommends both external and local storage backups be implemented in all environments, including the Development environment, as a critical safety net to keep your investment in Oracle EPM applications safe.

The most common backup sequence looks like this:

  1. Local storage backups are taken by the Hyperion apps/infrastructure team – Essbase Level0 backups are taken while the apps are running, and stored in another local folder. Essbase is then taken down and the remainder of the Essbase-specific files are copied to the same local folder as the Level0 backups. Essbase is then restarted.
  2. Essbase backup files are zipped and moved to a location on another server for safekeeping. This location may be in the same environment or in a different datacenter, depending on the needs of the business.
  3. A weekly full backup, or a daily incremental/differential backup is taken of the Essbase local backup directory, as well as the Essbase /app/epm/Oracle filesystem, with the exclusion of the Essbase /app and /bin directories.

After this procedure completes, there will be three locations from which to retrieve Essbase application backups (local storage, the remote server, and external storage) that are no older than 24 hours. With the current scripts we would have yesterday’s backup, as well as the backup taken the day before that. Should one need Essbase application files from a date prior to those stored by local storage backups, they are available via the external storage backups.

Share me

Back By Popular Demand

  • Date: Feb 22, 2021
  • Article by: Jeff Henkel
Read More

Issues with 11.2.x LCM and Financial Reports? Try This!

  • Date: Jan 22, 2021
  • Article by: Jeff Henkel
Read More

Leave a Reply

Your email address will not be published. Required fields are marked *