Overview of Hyperion Backup and Recovery Procedure – Easy Steps to Follow

Hyperion Backup and Recovery Procedure Explained

Hyperion Backup is the most crucial part of the EPM System and necessary for the non-disruptive running of the EPM System. How about if you wake up one morning and realize that you’ve lost all the data in your application that you’ve been creating over the months and there is no way you can recover it back? Frustrating, isn’t it???

Well, Backup and Recovery are a critical part of any organization irrespective of the application they’re dealing with. Even if a developer is completely well versed with the application and possesses good expertise in writing the code from scratch, there’s nothing more frustrating than losing the entire written code. Every organization designs a set of processes that help build a piece of code solely responsible for backing up an application and recovering from any disasters within the system.

It becomes extremely critical when it comes to dealing with financial systems. Over the years, Hyperion has become a critical tool for organizations looking to manage their financial and transactional systems. With a large user base and applications spread across multiple domains, the Backup and Recovery of Hyperion systems is a critical setup that every organization is putting in place.

This article tends to provide complete information about what Hyperion Backup and Recovery is and what the tasks involved in it are.

Database Backup Types

You can use several types of database backup, depending on your computing environment. See http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm for more information on Hyperion backup and recovery for Oracle databases.

Physical Backup

Physical backups are copies of physical database files. For example, a physical backup might copy database content from a local disk drive to another secure location.

A physical backup can be hot or cold:

• Hot backup—Users can modify the database during a hot backup. Log files of changes made during the backup are saved, and the logged changes are applied to synchronize the database and the backup copy. A hot backup is used when a full backup is needed and the service level does not allow system downtime for a cold backup.
• Cold backup—Users cannot modify the database during a cold backup, so the database and the backup copy are always synchronized. Cold backup is used only when the service level allows for the required system downtime.

You can perform a full or incremental physical backup:

Note: A cold full physical backup is recommended.

• Full—Creates a copy of data that can include parts of a database such as the control file ,transaction files (redo logs), archive files, and data files. This backup type protects data from application error and safeguards against loss by providing a way to restore original data. Perform this backup weekly, or biweekly, depending on how often your data changes. Making full backups cold, so that users cannot make changes during the backups, is recommended.

Note: The database must be in archive log mode for a full physical backup.

• Incremental—Captures only changes made after the last full physical backup. The files differ For databases, but the principle is that only transaction log files created since the last backup are archived. Incremental backup can be done hot, while the database is in use, but it slows database performance.

In addition to Hyperion backups, consider using clustering or log shipping to secure database content. See the Oracle Enterprise Performance Management System Installation and Configuration Guide and the RDBMS Documentation.

Logical Backup

A logical backup copies data, but not physical files, from one location to another. A logical backup is used to move or archive a database, tables, or schemas and to verify database structures.

A full logical backup enables you to copy these items across environments that use different components, such as operating systems:

• Entire applications
• Data repositories such as the Oracle Hyperion Shared Services Registry and Oracle Essbase Cubes.
• Individual artifacts such as scripts, data forms, and rule files.

A logical export backup generates necessary Structured Query Language (SQL) statements to obtain all table data that is written to a binary file. A logical export backup does not contain database instance-related information, such as the physical disk location, so you can restore the same data on another database machine. Periodic logical export backups (at least weekly) are recommended in case physical backups fail or the database machine becomes unavailable.

Backup with Lifecycle Management

You can use Oracle Hyperion Enterprise Performance Management System Lifecycle Management for Hyperion backup, which is provided with Oracle Hyperion Foundation Services, to perform logical backups. See the Oracle Enterprise Performance Management System Lifecycle Management Guide.

File System Backup Types

A complete file system backup includes an entire system directory. For example, in order for an effective Hyperion backup in place, you must consider backing up the EPM Oracle home directory back up all installed EPM System products. You can also perform file-system backups of these types and frequencies:

• Post-installation—Directories created or modified if you reconfigure products
• Daily incremental—New directories or files or those modified since the previous day (including repository content and log files)

• Weekly full—All files in the directories for which you perform daily incremental backups
• As needed—Data that is modified infrequently.

Recovery Sequence

Restore Oracle Hyperion Shared Services and the components that you backed up for Shared Services, before restoring other products.

Caution! It is imperative that backup and restore operations for EPM System components be synchronized because EPM System components continually read and write information to the Shared Services repository. When restoring Shared Services from a backup, for example, you must also restore registered EPM System components from backups that were made at the same time.

Common Backup Tasks

Preparing for Hyperion Backup

Complete these tasks before starting a cold backup:

• Stop products and ensure that all users have logged off.
• Stop all related services. See “Starting and Stopping EPM System Products” in the Oracle Enterprise Performance Management System Installation and Configuration Guide.
• Back up the Foundation Services database.

Note: You can also perform hot backups on EPM System products, with some limitations for individual products as described later in this document. These backups must be performed at the same time.

Database Backup

Back up these databases:

• Databases that store EPM System application data
• The Shared Services repository.

The Shared Services repository contains the Shared Services Registry, which stores most product configuration settings. It also contains Native Directory, provisioning information, and Oracle Hyperion Enterprise Performance Management Workspace preferences. Oracle recommends a physical full backup immediately after installation and configuration. For instructions on backing up an individual EPM System component, see the section of this guide that is specific to the component. Also back up any database, using the vendor documentation, that you use to store or extract data for use in product applications. Regular backups of database content are recommended for these EPM System components:

• l Foundation Services
• l Oracle Hyperion Disclosure Management
• l Oracle Hyperion Calculation Manager
• l Oracle Hyperion Dashboard Development Services
• l Oracle Data Relationship Management
• l Oracle Hyperion EPM Architect
• l Oracle Hyperion Financial Management
• l Oracle Hyperion Financial Close Management
• l Oracle Hyperion Performance Scorecard
• l Oracle Hyperion Planning
• l Oracle Hyperion Profitability and Cost Management
• l Oracle Hyperion Reporting and Analysis
• l Oracle Hyperion Financial Data Quality Management
• l Oracle Hyperion Financial Data Quality Management Enterprise Edition
• These products do not use repository databases:
• l Oracle Hyperion SQR Production Reporting
• l Oracle Hyperion Smart View for Office
• l Oracle Hyperion Provider Services
• l Disclosure Management

Hyperion File System Backup

Regular file system backups are recommended for these EPM System products:

• l Oracle Hyperion Foundation Services
• l Dashboard Development Services
• l Data Relationship Management
• l Disclosure Management
• l FDM
• l Financial Management
• l Performance Management Architect
• l Oracle Hyperion Performance Scorecard
• l Planning
• | Common Backup Tasks
• l Profitability and Cost Management
• l Reporting and Analysis
• l Oracle Hyperion Strategic Finance
• l Oracle Hyperion SQR Production Reporting

Oracle recommends daily backup of these items:

• l EPM_ORACLE_INSTANCE/config (to back up the configuration and reconfiguration settings written to the Shared Services Registry)
• l MIDDLEWARE_HOME/user_projects/domains/domain name (EPM System WebLogic domain directory)

Note: This item applies only to products that require a Web application server.

• l EPM_ORACLE_INSTANCE/import_export (where Oracle Hyperion Enterprise Performance Management System Lifecycle Management content is located)
• l Product applications and application data
• l In Windows environments:

       Windows registry: HKEY_LOCAL_MACHINE and all of its subkeys

Note: For some EPM System components, you need only back up specific subkeys, as described in the procedures for backing up those components.

Not applicable for these products:

• Oracle Hyperion SQR Production Reporting Server
  • Smart View
  • Provider Services
  • %CommonProgramFiles%/InstallShield/Universal
  • %USERPROFILE%//oracle.instance, which enables you to add, remove, reinstall, and upgrade products.
• In UNIX environments:
  • .oracle.instances, which enables you to add, remove, reinstall, and upgrade products.
  • $HOME/InstallShield/Universal
  • $HOME/oraInventory
  • Any files such as user profiles, kernel tuning parameters, or .init files that have been edited
  • /etc (system-level settings)
  • User home directories (user-level settings in hidden files and subdirectories)
  • /usr, /lib, and /platform (static system information)
  • /var (system logs and spool)

You must back up user home directories and application-specific directories or file systems. Oracle recommends periodically testing the restoration procedure.

Back up the EPM Oracle home directory (to back up all installed products) if you install a new product or apply a patch. Back up directories and files by copying them to another location. You can also use utilities provided with your OS (such as the Windows 2003 Backup Utility) or other third-party backup utilities. In case of failure, restore these directories and files by returning the copy to the original location.

Backing Up OS Settings

Windows registry settings and specific system variables in Windows and UNIX environments should be backed up.

Backing Up Windows Registry Settings

Backing up the Windows registry (HKEY_LOCAL_MACHINE and its subkeys) enables system recovery if Windows is reinstalled.

Note: For some EPM System components, you need only back up specific subkeys, as described in the procedures for backing up those components. You can use the Windows regedit command to create registry files to back up system and product components. If a failure occurs, you can run the registry files to restore the components.

Note: The following procedure does not apply to Oracle Hyperion SQR Production Reporting Server, Smart View, or Provider Services.

To back up a component with regedit:

1 Select Start and then Run.

2 Enter regedit, and click OK.

3 Right-click the subkey for the component in the left panel, and select Export.

4 Select a location for saving the registry file, enter a file name with the .reg extension, and click Save.

System Variable Backup – An Essential Part of Hyperion Backup

Oracle recommends backing up the HYPERION_HOME and EPM_ORACLE_HOME system variables.

Note: This recommendation does not apply to Smart View.

Read another similar article about the Backup and Recovery Process of Foundation Components.