devan05

CA DLP Tuesday Tip: BusinessObject backup and restore overview for DLP

Discussion created by devan05 Employee on Jan 24, 2012
Latest reply on Jan 25, 2012 by Chris_Hackett
CA DLP Tuesday Tip for January 22nd 2012 by Andrew Devine, Sr. Support Engineer

You may already be using CABI/ BusinessObjects Enterprise XI (BOE) to provide reporting functionality for other other CA products and have an appropriate DR (Disaster Recovery) strategy in place, however if the DLP integration is the first time that you have encountered CABI/ BusinessObjects Enterprise you should give some consideration to backing up your data.

There are several content-oriented elements that must be backed up regulary in order to recover rapidly from a disaster.

BusinessObjects Central Management Server (CMS) System Tables

The Business Objects 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.

Performance Management (PM) System Tables

The PM database stores metrics, key performance indexes (KPI), metadata, and key relationships that drive dashboards and scorecards. In many Enterprise environments, theses tables will be stored in the same 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).

A cold backup is the recommended approach to backups by BusinessObjects, as it is the most straightforward way to ensure a complete backup occurs. A cold backup requires a shutdown of the BOE services, thereby making the system unavailable. As such, cold backups should be scheduled during off peak hours. All parties affected should receive communication of the timeframe in which the system will be unavailable, thereby avoiding potential loss of productivity with the system.

A cold backup strategy requires the shutting down of BusinessObjects services prior to capturing the back up. The high-level sequence for backup is

1. Stop the Central Management Server (CMS) and all job-processing and Performance Management (PM) servers, preferably using an automated script. This will:

i. Release the connection of the CMS to the system database
ii. Release PM’s connection to its tables in the CMS system database
iii. Prevent users from accessing BOE.
iv. Prevent report jobs/analytics from executing and terminate any report job/analytics already in execution
v. Assure the continued integrity of the FRS.

If the sequence is not followed the result can be a false sense of security in the quality/integrity of the backup or an inability to fully recover Business Objects if the back up is of poor integrity.

Recovery of BOE in the event of a failure is relatively straightforward

High Level Recovery Sequence

In the event a recovery is necessary, follow these steps to restore BOE:
1. If necessary, rebuild and restore the system, ensuring that the number and size of disk volumes are the same or larger than the previous system. If you must rebuild a system by starting with an empty hard drive, install the OS on the same disk as before, then recreate the partitions and volumes as they were on the damaged system. If recovering only BOE content, make sure to install BOE on the same drive as on the original system.
2. Restore the backup of the CMS system database.
3. Restore the backup of the PM repository.
4. Install/configure the data source client software to point to the restored database and report source.
5. Restore the Input and Output File Repositories (FRS)
6. Run the Repository Diagnostic Tool

The Repository Diagnostic Tool

BOE XI 3.x provides a Repository Diagnostic Tool (RDT) for BI administrators to keep the CMS and FRS in a stable/consistent state, thus helping to reduce down time. The RDT is a command line tool that is run by the administrator to scan, diagnose, and repair inconsistencies that may occur between the CMS and the FRS. RDT scans the CMS system database and identifies inconsistencies, repairs the logged inconsistencies, and reports the repair status and completed actions. It can be run against a live system, but in a recovery situation, it should be used after a restoration and prior to starting the BOE services to make sure no inconsistencies exist, especially in situations where a recovery is being performed from a hot backup. This allows for the restoration of the backed up CMS and FRS with no downtime and with consistent behavior.

Outcomes