This document is to describe the methodology employed and process involved in the backup of the Hyperion system currently operated in the company. This document will be updated and maintained by IT department for access by project members as well as the end-users.
This applies to the following server components of the Hyperion application.
o Application and Web Server (Application)
o Reports Server (Application)
o Essbase Server (Transaction Data)
o Oracle Server (Application Configuration/Reports Definition Data)
These servers are located in the computer room controlled and managed by IT Department.
IT department is responsible for the managed operation of the application, which involves systems installation, systems upgrade, backup, recovery, and technical infrastructure support while the Application Owner is responsible for the maintenance of the models/reports built on the application.
Primary Support Secondary Support
IT Department: …
Application Owner: …
4) Processes & Schedules
4.1) Systems Backup
4.1.1 On completion of the first systems installation, and every subsequent upgrade, “ghost” images of the following Windows NT/2000 server will be performed and put into a tape.
o Application and Web Server (Hy-web)
o Reports Server (Hy-rpt)
o Oracle Server
Mark down the date and time of the backup on the tape. Store the tape in the fireproof electronic safe.
4.1.2 Send the last systems backup tape to the designated off-site location on the first workday of the week.
4.1.3 On receipt of the backup tape at the off-site location, responsible IT support personnel should place it in the fireproof electronic safe. Return the previous one to the office, which will be recycled for the next backup process.
4.1.4 In summary, there will always be two versions of systems backup available. The most recent one is held at the main site, and the second generation is located at the backup site.
4.2) Data Backup
There are two types of data maintained in Hyperion system. One is the actual data automatically or manually imported from the ERP into Hyperion, and one is the model/Report definition/configuration defined for the application built on Hyperion.
The former data is held in the Essbase Server, and the latter is maintained at the Hyperion instance of the Oracle Serve.
The following is the schedule of the backup tasks for various server components in Hyperion.The completion time is an estimate only and may vary from time to time as the database grows.
System will not be available during Essbase backup period. This means that the uptime of the application is from 02:00am to 01:00am next day (23 hours a day, 7 days a week).
|Essbase||01:00am||02:00am||Daily, Tue – Sat||Full Backup: Dedicated task|
|Oracle||01:00am||02:00am||Daily, Tue – Sat||Full Backup: Dedicated task|
|Application/Web||02:00am||04:00am||Daily, Tue – Sat||Full Backup: ArcServe|
|Reports||02:00am||0400am||Daily, Tue – Sat||Full Backup: ArcServe|
4.2.2 Daily Process
Daily Backup will be maintained for ten versions:
The backup taken at the last day of the weekly cycle will be sent to the off-site on the first workday of the week and held at the fireproof electronic safe. The last set of T5 backup tapes will be returned back to the main site for recycling. Therefore, at any one point of time, there will be one set of off-site data backup available (which is 5 days old in the worst scenario) for restoring in the event of a disaster situation. This is considered to be acceptable as the data usually be updated once a month during month-end. Also these data could be recovered from the ERP systems held at various sites should it require to do so.
184.108.40.206 Set up Scripts, Cron jobs, and ArcServe for various backup tasks, one-time exercise only.
|Oracle||All (for instance: HYSL)|
220.127.116.11 Every morning, the responsible IT support personnel will check the status of last night backup by looking at the backup logs of each server, and if there is no problem, then he will eject all backup tapes from last night backup and put in the new tapes in each of the servers. The last night backup will be stored in the fireproof safe.
18.104.22.168 In case the backup has failed, then the responsible IT support will determine the root cause and determine a solution to remedy the problem. Consultation from 3rd party vendors might require if the problem is related to hardware or it is due to software bug.