This document describes procedures for performing a back up of the Web and SAP BusinessObjects Server system and data files, as well as the procedures to be followed to recover from data loss or hardware failure.
The plan execution requires an experienced SAP BusinessObjects BI professional, operating system administrator,and database administrator.
The backup and recovery process is similar for all environments within a staged system; development, test, and production. Therefore, this document does not refer to any specific environment. It is recommended to backup all environments.
Backup and Recovery Process Concept
A backup and recovery plan consists of precautions to be taken in the event of a full system failure due to a natural disaster or a catastrophic event. The plan aims to minimize the effects of the disaster on the daily operations so that the organization is able to maintain or quickly resume mission-critical functions. It is recommended, as part of a BusinessObjects Enterprise (BOE) disaster recovery plan, to involve an implementation of redundant servers in a back up system, which mirrors the primary system. In the event that the primary system goes down, the back up system is still available and becomes the operational system.
It is a best practice to back up BusinessObjects servers on a daily basis.
The Importance of a Proper Backup Sequence Without backing up the Enterprise system databases and the file repository, no restoration of the environment is possible.
Good backup integrity requires shutting down certain BusinessObjects services prior to capturing the backup. Under certain conditions, failure to follow a proper service shutdown sequence before backing up could result in one or both of the following consequences:
- False sense of security in the quality/integrity of the backup.
- Inability to fully recover BusinessObjects if the backup is of poor integrity.
Types of Backups
A backup can be conducted in multiple ways:
1. Enterprise Content backup vs. server backup
A server backup is the deepest type of backup. Typically, this is a full backup that captures every byte on every local hard disk in a server. This type of backup insures the server’s operating system as well as any applications and data stored on the server’s local drives. Server backups are infrequent, typically only necessary after a stable installation/configuration is achieved and anytime major updates to any of the server components are made.
Enterprise content backup is a subset of a server backup and focuses on the essential components of BOE only. With an Enterprise content back up, one can recover a SAP BusinessObjects environment from scratch on a different hardware environment if necessary.
Enterprise content backup does not insure the operating system or any applications, including the Enterprise executables and DLLs; however, it does insure all of the intellectual content that is created and customized by users of the Enterprise system, which is the most important thing. Content backup also will not insure one against corrupted or deleted Enterprise application DLLs/EXEs or other operating system problems, but these can be resolved by performing a re-installation of operating systems or SAP BusinessObjects BI Backup and Recovery Best Practices.
2. Incremental backup vs. full backup
The choice between incremental backup and full backup is typically a decision made by the disaster recovery team. A full backup captures every targeted byte. Full backups require longer system down time to achieve (in the case of cold backups) but are the safest and least complex type of backup to restore. Because full backups are the slowest and most expensive to capture and maintain,SAP BusinessObjects advises capturing full backups on a weekly basis, where resources allow.
Incremental backups can be performed on a more frequent basis. It begins as a full backup, but each subsequent backup thereafter captures only those files changed since the last backup. They are faster and less expensive to capture than full backups, but are less robust. Because of this, incremental backups are usually acceptable for daily backups.
3. Cold backup vs. hot backup
Using a cold or hot backup strategy is typically dependent on whether a system can tolerate the
downtime required to perform a cold backup. Prior to running a cold backup, the Central Management Server (CMS) service must be stopped so that a backup of the CMS system database and File Repository Server (FRS) can occur. Stopping the CMS will prevent users from accessing the Enterprise system, a factor which must be taken into consideration when scheduling cold backups. This assures an accurate snapshot of the system occurs, since no transactions can occur during the backup procedure.
Cold backups must be done in off peak hours, thereby limiting the frequency at which the backups can occur and sometimes requiring choreography of schedules with other dependencies. Hot backups tend to be the preferred method in global or highly available environments where there is not a feasible window of downtime, as backups can occur while a system is still running, thereby keeping usage of the system unaffected. This enables the narrowing of the gap between the period of time when the last backup was run and when the system experiences failure, as backups can occur more frequently, reducing the amount of work lost in the event of a failure. Because the backup occurs on a live system, a hot back up exposes the possibility that the CMS and FRS will be captured in a state of change; furthermore, the FRS, CMS and PM tables could be captured in an out-of-sync state, a situation which could compromise the integrity and usefulness of the back up.
It is recommended to backup the CMS system database and PM repository once daily with incremental backups and full backup only once per week. The frequency of backups may be revised based on an acceptable amount of time for recovery to satisfy your organization’s requirements. This rest of this paper will focus on the procedures necessary for conducting a backup of enterprise content.
What to Back Up
There are several content-oriented elements that must be backed up daily in order to recover from a disaster. Routinely backing up all of the following content elements will enable you to recover from virtually any type of disaster (virus, hardware failure, natural disaster, and so on).
Database Central Management Server (CMS) System Tables
The CMS contains all the user rights and metadata information about reports and universes, as well as data connection information. The CMS is the heart of the BusinessObjects environment, so it’s critical to frequently back up this database. The environment cannot be restored without a properly backed up CMS database. physical database as the CMS system tables, making it easy to capture during a routine backup of the CMS tables. This database should be captured at the same frequency as the CMS system database.
File Repository Server (FRS)
This is a standard OS file share that contains all the report templates and instances for the environment. The file repository typically ranges in size from 1 GB to 100 GB depending on the size and complexity of the deployment. Since the FRS is designed to exist synchronously with the CMS tables, it should be backed up at exactly the same time as the CMS system tables.
Failure to capture the file repository and CMS system tables simultaneously, when the CMS and FRS services are stopped, could result in poor back up integrity. This is because of the increased risk for orphaned report objects or report pointers in the CMS system database if a database restore becomes necessary. Orphaned report pointers are those records in the CMS system database that do not point to a valid input or output file in the Enterprise Input or Output FRS. If a user were to select a report object or report instance that was orphaned, an error message would occur and they would not be able to access that object or instance. Orphaned input or output files in the file repository are a benign problem compared to orphaned pointers in the CMS tables. Only the Input and Output subfolders need to be backed up (the Temp
folder can be ignored).
Local audit log files
When auditing servers is enabled, each BusinessObjects server writes audit records to a log file local to the server. At regular intervals, the CMS communicates with the audited servers to request copies of records from the local log files.
Auditing Tables
This database contains usage statistics and auditing information for the environment. A back up of this database is not necessary for recovery from a disaster. However, recovery of a CMS database without recovery of the auditing tables from the same backup might result in a corrupt auditing database due to the presence of duplicate event IDs. It’s highly recommended that the auditing tables be included as part of the backup procedure.
Hope you find this useful.
Umang Patel.
+919979084870
SAP BO BI Solution Architect/Consultant
