Hyperion Enterprise Backup Options Summary

(1)

Hyperion Enterprise Backup Options Summary

DISCLAIMER: Your company’s specific business requirements, infrastructure or implementation may not fall within the tested scenarios. Alui has provided these recommendations as a general

guideline without having access to your company’s environment. Alui cannot be held responsible for any use of this information which exceeds these limitations.

No portion hereof may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or information storage or retrieval systems, for any purpose other than the recipient’s personal use, without the express permission of Alui.

The information contained herein is subject to change without notice. Alui shall not be liable for errors contained herein or consequential damages in connection with furnishing, performance, or use hereof.

(2)

Summary:

The vast majority of Hyperion Enterprise implementations use a proprietary file-based database, which in Enterprise terminology is referred to as the application. This document outlines some important things to consider when backing up a file-based Enterprise application.

Below is listed a summary of the various backup methods and the pros and cons of each. Following this summary are the details of what is involved in implementing each method.

Alui provides an alternative to the annual technical support you currently receive from Oracle on Hyperion Enterprise. Our support offering, at 50% of your current fee, encompasses technical support, application support and ad hoc remote consulting. Our support team is staffed by not only technical specialists but also qualified accountants who can help you get the best from the software on not only technical issues but also accounting/commercial issues as well. Our customers vary in size from S&P 500 publicly quoted companies with hundreds of users through to medium sized privately held corporations.

IT backup of application

IT will do a copy of the application directory to another location and then stored for varied lengths of time.

Pros: This method provides a consistent backup dependent on scheduling.

Cons: If users are in the system, it will not be a usable backup. Also, the finance department is dependent on IT to get this type of backup restored. The timing may not be aligned with critical events to the system.

Copy of application directory

This requires a copy of the application directory to another folder, frequently on the same server.

Pros: This method can be done by Finance and restored by Finance. This is a complete backup of everything under the application directory including reports.

Cons: If users are in the system, it will not be a usable backup. Extracting the application

To extract the application, the user will need the rights to do this task. It is a several step process of creating text files that hold the metadata and data of the application.

Pros: This method can be done by Finance and restored by Finance.

Cons: This is a more manual process. If you lock parent entities, you may not be able to rebuild your application using these extracts and get the same results.

(3)

Backup Procedure within Enterprise version 6.5.x

The procedure built within Enterprise can be scheduled as needed and provides a means to restore the application through the same backup utility.

Cons: This does require you to be upgraded to version 6.5.x.

Many factors need to be taken into account when determining the best method of backing up the application. Frequently more than one option is used. For example, you may decide you need the consistency of the IT backup, but also do additional backup within Finance immediately following a month end close or preceding changes to the application.

(4)

Hyperion Enterprise Backup Options

When running a file-based application one must allow specific times when no users access the system to be able to take valid backups (this is the case for versions prior to Hyperion Enterprise 6.5). If users are in the system at the time of a backup the entire application will most likely not be backed up, and there is a risk of corruption. (Please see Alui’s ApplicationCorruption_Alui.pdf for further details on corruptions.) Therefore, it is vital to educate the users about when the regular backups are scheduled so they are not in the system during this process. (Please see Appendix A for some advice if you are using Citrix or Terminal Server.) Rather than backing up the production application directly from its location, take a copy of it and run the backup routine on this copy. This is beneficial as taking a copy is much faster than running a backup routine, so as soon as the copy has been taken you can let the users back into the system.

A Hyperion Enterprise application can be backed up using several different methods. There are a couple of approaches outside the backups performed by IT. The IT backups are done on a regular basis and are very important. The IT backups may not always be performed at times when it might be recommended to do a backup. Some examples of times where backups would be recommended:

• Changes have been done to your application and/or data

• Install software upgrades

• Month-end Closings

• Rollovers

There are several methods of backing up your application:

• IT backup of application – copying application onto another medium

• Copy of application directory

• Extracting application

• Version 6.5.x backup

Conclusion

However you decide to perform your backups, please make sure that you test it thoroughly in a test environment before going live. This is crucial when you aim to find a backup routine that works best in your specific scenario and environment.

(5)

1. IT backup of application

This is where your IT department does backups of all servers. This is typically scheduled at set intervals on a regular basis. Generally this is where they copy from the servers onto another medium that is then stored for varied lengths of time.

The only recommended way to create a complete backup is to include the entire application folder (i.e., the main folder which contains all the application’s subfolders and files). Incremental backups and similar are not supported, as these can lead to incorrect or missing data and/or metadata (e.g., entities and accounts). Why is this? If you do not keep the system files and data files together there is a risk that the application’s internal signatures will be mixed up. The internal signatures make sure that the correct data is displayed for every combination of metadata, so if you copy a data folder from a backup and paste it into the production application you might not see the desired data due to a mismatch of these signatures.

Pros: This method is consistent dependent on scheduling.

Cons: If users are in the system, it will not be a usable backup. Also, the finance department is

dependent on IT to get this backup restored. The timing may not be aligned with critical events to the system.

2. Copy of application directory

Let us look at an example to clarify what it means to back up the entire application folder. In this example the Enterprise application is called PROD:

a. Ensure that no users are in the system

b. Take a copy of the entire application folder and paste it into another location. If the PROD application is stored in the following location, \\FileServer\EnterpriseApps\PROD, then that is the PROD folder you need to make a copy of. This PROD folder will contain at least the following folders and files (depending on what modules you use it may contain additional files), which will be copied as you copy the entire folder:

• The four system files: PROD.EXA, PROD.LOK, PROD.USE, and PROD.INI

• The DATA folder which contains all the application’s data categories

• The REPORTS folder, containing all your reports and books

• The INBOX and OUTBOX folders, typically containing your load and extract files

• The application’s error log file (ERROR.LOG)

(6)

Pros: This method can be done by Finance and restored by Finance. This is a complete backup of everything under the application directory including reports.

Cons: If users are in the system, it will not be a usable backup.

3. Extracting the application

Another means to have a backup of your application is to extract the application and data into text files that can be loaded back into either the same application or a new application shell. You may want to create a directory to store the Extracted files (ex: HYPENT_BACKUP). Below are the steps to follow to extract your application and data (please note that it is possible to automate these extracts for example by setting up and scheduling Hyperion AutoPilot taskflows).

a. To extract the application:

Application Extract - Go into the Application Module

• From the toolbar select Task, select Extract Application

• Use the Browse button to find the HYPENT_BACKUP subdirectory

• Type in a file name

• Uncheck the Execute on Server button (If the option is available)

• Select OK

Security Extract - Stay in the Application Module

• From the toolbar select Navigate, select Security

• From the Security toolbar select Task, select Extract Security

• Select OK

• Exit out of the Security module and application module and return to desktop

Formulas Extract – Go into the Formulas Module

• Select OK to open any method to get into the Formulas Module (Chart is the default)

• From the toolbar select Task, select Extract Formulas

(7)

• Check Extract all formulas

• Select OK

• Exit out of the Formulas module and return to the desktop

b. To extract the data:

You need to have an Entity List that contains all your Entities that allow inputting of data. Go into the Database Module

• Change your point of view to the PARENT entity that you wish to extract

• From the toolbar select View / Entity List

• Click on the Entity List with all input entities and click OK (this will show the names in the drop

down box above the months)

• Highlight the months you wish to extract

• From the toolbar select Task, select Extract Data

• Include the Global Rates by checking the box

• Use the Browse button to find the \HYPENT_BACKUP subdirectory

• Click on the Edit Button and enter the number of decimals your exchange rate go to in Decimal

Places

• Select OK

Repeat the above steps for all categories that have data you want backed up.

c. Go into the Journals Module. Extract all journals for all periods and all categories.

d. Using Explorer copy all ....REP files from the report subdirectory under your application directory. Repeat for all .BOK files also under the report subdirectory.

(8)

• Go into Entity translation (Entity Icon)

• Open the .LNT translation file

• Export the file as a .TRN to the \HYPENT_BACKUP subdirectory

Repeat Open the .LNT and Exporting as a .TRN for each Entity translation you want to backup.

• Go into Account translation (Account Icon)

• Open the .LAT translation file

• Export the file as a .TRA to the \HYPENT_BACKUP subdirectory

Repeat Open the .LAT and Exporting as a .TRA for each Account translation you want to backup

4. Backup Procedure within Enterprise version 6.5.x

The option of the Application Backup is available in Hyperion Enterprise 6.5.x. This automated process allows you to schedule a backup while users are in the application. You can create a regular schedule for backing up your application depending on your needs or you can do a one-time backup.

For more detailed information on the Application Backup, you can look to the New Features or ReadMe documentation for the product.

(9)

Appendix A: Back Up Enterprise Application In Citrix Environment

When running a file-based application, such as Hyperion Enterprise’s proprietary database, one must allow specific times when no users access the system to be able to take valid backups (this is the case for versions prior to Hyperion Enterprise 6.5). If users are in the system at the time of a backup the entire application will most likely not be backed up, and what is even worse, there is a risk of corruption (please see Alui’s ApplicationCorruption_Alui.pdf for further details on corruptions). To find a time when no users will be in the system can be difficult, especially for a company that has sites globally. Therefore, many clients choose to implement some sort of automated backup-script.

Although we cannot recommend any specific backup-script, the following will hopefully be helpful when you consider your own approach to backups. Although this example is regarding a Citrix environment, the principle will also apply to a Terminal Server implementation for example:

1. Educate your users regarding the importance of not being in the system whilst a backup is taken

2. Schedule a time for regular backups when the fewest users are likely to be accessing the system.

Inform your users about the time that the backups will be taken

3. In Citrix, automate messages to go out to the users warning them about the backup and prompting

them to logout of the system well in advance

4. In Citrix, disable the ability to logon, preventing new users from accessing the system

5. Even though users have been prompted to logout there might still be some in the system. Therefore,

just before the backup is due to start, disconnect any users in the system e.g. by rebooting the file server (i.e. where the file-based application is hosted). Please note that there is no safe way to disconnect users as this might cause corruptions. From experience, the reboot seems to be less risky than a Citrix disconnect. You would need to test in your specific environment and usage to see what seems to be safest

6. Rather than backing up the production application directly from its location, take a copy of it (this is of course also automated) and run the backup routine on this copy. This is beneficial as taking a copy is much faster than running a backup routine, so as soon as the copy has been taken you can let the users back into the system