Disaster Recovery in SAP Business Objects

In Business Objects XI R2/3.x, there are several recovery options and each one is best suited for a specific situation. Lets talk about each one of them in detail.
Using CMS Database and File Store:
To use this technique, you should have been backing up the CMS database(also known as System database) and the File Store regularly, at the same time. The key here is at the "same time". Failure to backup the CMS database and File Store at the same time will result in orphaned entries(for example CMS database will refer to objects that don't exist in the File Store). Business Objects recommends that the FRS backup should never start before the CMS backup, so keep that in mind while defining your backup strategy. Also, it is important to decide whether you want to do a hot backup or a cold backup. A cold backup is performed by shutting the Business Objects services down prior to taking the backup as opposed to a hot backup which is performed when the services are up and running. Cold backup is the safest type of backup as it avoids the risk of backing up data that may be in the process of being updated. Moreover, it will also prevent the synchronization issue between CMS database and File Store. However, obvious problem with cold backup is that it involves downtime and the downtime window depends on the magnitude of the content in your enterprise system. Though hot backup will let you perform the backup without bringing the services down thereby allowing user activity/development work, there is always a chance that the CMS database and File Store will be out of sync causing integrity problems. So does that mean I should always perform cold backups? Also, how often should I backup? Well, the answer to these questions is dictated by the Recovery Point Objectives(RPOs) and Recovery Time Objectives(RTOs)mentioned in the Service Level Agreement(SLA) that you have negotiated with the business users. Lets go through some scenarios:

• If the RPO is one hour's worth of development work, then you SHOULD back up CMS the database and the File Store every hour. This means you will be doing a hot backup as nobody can afford to bring the services down every hour.
• If the RPO is one day's worth of development, then you SHOULD backup the CMS database and File Store every day. This means you can go with cold backup. However, if the business wants access to the system 24/7(except in case of emergencies), then you have to perform hot backup.
• If you don't have any SLA in place, then use your judgment. If you have a lot of development activity going on all the time, then you might want to backup as frequently as you can. May be everyday if you can.

In the event of a disaster, you simply reverse the process: Restore the CMS database and the File Store. If a hot backup was performed, be sure to run the Repository Diagnostic Tool to fix any missing links between the CMS database and File Store. It would be better to restore the CMS database and Fie Store on a test server, then use Import Wizard to import the contents back to your production server. However, if you don't have a test server, you should create one and restore the CMS database and Fie Store on the new server. If you don't have a test server and you can't afford to create one, then you would have to do the restore on your production server which will be very risky.
Most important than all, you should test your backup strategy. Remember that you don't have a backup strategy until you have done a restore. To put it in other words, a backup is never successful until you restore it successfully. Now how do we test the back strategy? Simple, take the CMS database and File Store backups that you have been backing up as part of your backup strategy, and try to recover it on another server. Run some reports, open up some universes etc to make sure that everything is fine. Please note that this method can do more loss than good if not done properly and is only suitable in the event of a full system failure.
Using a Development/Test server:
Ideally, you should be having a separate development and test server. If you don't, then create a Development and a Test server and mirror it with Production. Use the development server for development work and the test server for testing. The folder structure in development and test server should be same as that of production, of course you will need some more folders in the development server to support the development mess.
The test server will be more uptodate than the production server(because your test server has all the reports/universes that are in production plus the reports/universes that are meant for testing) and the development server will be more uptodate than the test server(because your development server has all the reports/universes that are in production, plus the reports/universes that are promoted to test server for testing, plus the reports/universes that are under development). In short, the most latest and the greatest is your development server and then comes the test server and then your production server.
In the event of a disaster,  you run the Import Wizard with source as your Test or Development server and destination as your production server and then import the required objects(reports, universes etc). This method is best for "selective content recovery", that is, when you intend to restore only a few objects(report, universes etc). You can also use Life Cycle Manager(LCM) to transfer objects from one server to another, I personally prefer Import Wizard.
Since you will have a different security model in your Production, Development and Test server, you can't use this method to import security from Development or Test server into your production server in case of a full system failure. Also, since the Development and Test server will not include adhoc reports, adhoc universes and scheduling information etc created by the business users, you can't use this method to get those objects from Development or Test server into your Production server. You will have to use a BIAR backup of the Production server in conjunction with this method to get everything that exist on the Production server. Therefore, this method is not suitable in case of a full system failure though you can use it in conjunction with BIAR to get close to recovering everything.
Using a BIAR backup:
In this technique you will be backing up the enterprise content in the form of a BIAR file using Import Wizard. Keep in mind though, that BIAR is not always reliable and should not be the only source of your backup strategy. It should be used in conjunction with the above two methods described. How often should you be doing a BIAR backup? As frequently as you can, I would do it everyday after business hours. You don't need to shut the services down to take a BIAR backup. Also, it is better to create multiple BIAR files than dumping everything in one large file to avoid potential issues when restoring. Starting from XI 3.0, you can automate the process of creating a BIAR backup using BIAR Engine Command Line Tool. As said before, BIAR is not 100% reliable(Please refer to this post for more details about BIAR issues and work arounds) but it will be very handy in case when somebody accidentally deletes a single report or a universe or a folder containing reports/universes.
The most important thing to do after implementing the disaster recovery strategy is to test it. Remember, you don't have a solid backup strategy until you have done  a restore. For example,  test your CMS database and File Store backups by restoring them on a separate server - this is the only way you can find flaws in your backup strategy, if any.