cancel
Showing results for 
Search instead for 
Did you mean: 

Setup a disaster recovery environment for BO X! R3 server

Former Member
0 Kudos

Hi experts,

I would like to know if there is any good practice to setup a standby BO XI R3 server for disaster recovery.

Currently, I have an Oracle database server to host all datamarts and respository data and a separate BO XI server points to this database server. A standby database server is setup to replicate data via real time sync and a standby BO XI server is intended to setup to fulfill the disaster recovery requirement.

During disaster recovery, the production database server and BO XI server willl be down together with the real time sync. Standby servers are going up to replace the production ones. I would like to know if any pre-requisites and procedures are needed.

Thanks a lot.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Dell,

I would like to know if the following workaround can achieve the business contingency with some shortcomings or not.

All CMS system database, auditing database and reporting database are installed in the same database server and replicated to a standby database server through DB sync. A standby CMS server is also setup for this purpose.

A full backup of these databases and file system including file repository and local audit log files is performed on weekly basis after all user and system services are down.

During disaster recovery, CMS system database and auditing database are restored from weekly backup to the standby database server and also the file system to the standby CMS server.

Using this approach, an up-to-dated user reporting data can be ensured using the database sync. On the other hand, a sync image of CMS and reports can be achieved to avoid corruption of CMS due to orphaned report objects or report pointers with the shortcomings of newly created reports and audit statistics generated after the weekly backup cannot be revoked.

Thanks of your support.

Former Member
0 Kudos

If you're going to restore from a weekly backup, then doing the database synch makes no sense - you will always have up to a week's worth of instances and new reports that will show up in InfoView but will cause errors if you try to open them because the files aren't there.

<p>

To get you closer to where you're trying to go, I suggest the following:

<p>

1. Continue with your weekly full backups.<br>

2. Continue with the db synch<br>

3. Do nightly backups of the FileStore.<br>

<p>

In a disaster recovery situation, you would then just restore the previous night's FileStore backup to the stand-by server. The database will already be synched up. At this point you would just be missing any report instances or new reports that had run since the previous night's FileStore backup.

Once the disaster is over, you will do the following:

1. Shut down BOTH BOE systems.

2. EIther do a FULL backup of the stand-by database or synch the stand-by database back to the production database.

3. Copy the FileStore from the stand-by server back to the production server - this will copy over any new instances that have been run since the DR.

-Dell

Answers (4)

Answers (4)

Former Member
0 Kudos

Hi expert,

During the Disaster Recovery rehearsal test, we have performed the following steps:

1. Stop the Oracle database synchronization between the production and standby server

2. Remove the hosts and TNS of production Oracle server such that standby server cannot connect to production one

3. Stop the SIA in the standby server

4. Copy the Input/Output FRS and Audit Log folder from backup

5. Create a new SIA (with "create CMS on the new node" option and using same port numbers) via CCM in standby server

6. Clone all BO servers such as JobServer to newly created node via CMC in standby server

7. Enable and start all newly created servers

8. Start the new SIA

We have encountered a problem that user cannot login to the standby server after performing the above. Can anyone give some hints for me to solve the problem?

Thanks.

Former Member
0 Kudos

An error is encountered during testing

Former Member
0 Kudos

Hi expert,

We have setup an environment to stimulate the disaster recovery as follows:

1. Shutdown the Standby CMS server by stopping Server Intelligence Agent

2. Copy the Input and Output FRS from backup

3. Resume the Standby CMS server

4. Login the Desktop Intelligence

Note: Since the user and system databases of Standby DB are exactly the same as Production DB via Oracle DB synchronization, there is no database restore to be performed.

However, we have encountered a login error:

Cannot access the repository (USR0013)

during login the Desktop Intelligence in step 4.

Moreover, we discovered that those paths of BO server such as ConnectionServer are still pointing to Prod one.

Please advise if you have any idea to fix this issue.

Thanks in advanced.

Former Member
0 Kudos

Where is your FileStore located? Is it on the server or somewhere on your network? The database just stores pointers to the files in the FileStore, so that has to be available to the stand-by server using the same file path as the production server.

-Dell

Former Member
0 Kudos

Hi Dell,

In the current architecture, Data mart, CMS repository and Audit respository are stored in an Oracle database on Unix machine while BOE XI App Server, including CMS Server and FRS, is installed in a Wintel machine.

We have tried to perform a rehearsal on Disaster Recovery, however, the CMS Server seems to be out of order after the production servers are down and real time data sync is stopped.

Please advise if there are any steps to be performed to configure the standby servers before and after the production servers are down.

Thanks.

Former Member
0 Kudos

Does the stand-by server have the same name as the production server? If not you're going to have to do some configuration things to get this to work.

<p>

You don't mention how you have your stand-by is configured, but I would see if you can "cluster" it with your main server:

<p>

1. On your production machine, go to the CCM, stop the SIA and go to the Configuration tab in its properties. Change the cluster name so that it's not the same as the server name. I usually use something like "ProdReports". Save and re-start the SIA.

<p>

2. After the production system has come back up, go to the CCM on the stand-by machine, stop the SIA and go to the Configuration tab in its properties. Change the database to the same database as your production system (don't worry, we're going to change it back!) and make sure you've joined the cluster. Save and re-start the SIA to make sure everything synchs up.

<p>

3. Once the new data has replicated to the stand-by CMS database, in the CCM on the stand-by machine, stop the SIA and go to its properties again. On the Configuration tab, change the database back to the stand-by database. Start the SIA to make sure that it comes up correctly. You can stop it once you've verified everything.

<p>

Also, you MUST do something about your FileStore. The actual report files are NOT stored in the database, they're stored as files in the FileStore. In order for everything to work correctly, the CMS Repository and the FileStore MUST be in synch. You have two options here:

<p>

1. Move the FileStore to a shared network drive - we usually put ours on a network share on our SAN. On both the Production and the Standby servers, go to the CMC and configure the Input and Output file repositories to read from the same UNC path (mapping drives will NOT work here!) and move ALL of the files from the FileStore on the production server to the network share.

<p>

2. Replicate the FileStore from your Production server to your Standby server. In order to have everything up to date, you'll have to do this in real-time.

<p>

If you do not do this, NOTHING will run because the Standby server will not have access to the files it needs to process reports.

<p>

-Dell

Edited by: Dell Stinnett on Aug 9, 2010 11:38 AM