Introduction
Every time we are implementing WebCenter Sites, the question of disaster recovery (DR) always comes up. To setup disaster recovery for WebCenter Sites is fairly simple. Typically, WebCenter Sites has an Editorial and a Delivery system. Delivery is the place where web site visitors come and browse the web site. Editorial is used by content authors to create, manage, approve content and finally to publish the content to Delivery. The procedure to set up DR procedures for Delivery and Editorial systems are different. The DR procedure for Delivery utilizes “dual publishing”, while the DR procedure for Editorial utilize periodic system backup and restore.
Disaster Recovery for Delivery
Disaster Recovery for Delivery requires that you have a system identical to Delivery for DR. The DR system should have the same software as the software installed on Delivery, including the same patch levels. The DR procedures rely on “dual publishing” to keep DR system synchronized with Delivery. Whenever you publish content from Editorial to Delivery, the system automatically publishes the same Content to DR system also.
WebCenter Sites can publish to multiple destinations in the single publish session. This is done by deploying a custom Transporter as given in the WebCenter Site’s Developer Guide at: http://docs.oracle.com/cd/E29542_01/doc.1111/e29634/realtimehooks.htm#WBCSD6197. The full code listing is given in the section 49.2.5.
This solution is fairly simple, and requires that on the management environment customize real-time publishing using the hooks that WebCenter Sites provides out of the box. Subsequently, when assets are approved to a single publishing target (e.g. “LiveDelivery”) they are dual published to both the delivery environment and also the delivery DR environment. If any one of the target environments is down publishing does not stop, the multi-transporter continues to publish content to the servers that are up during the publish session. An asset is marked as successfully published only if it was published to all the servers configured on the publishing target. So the assets will remain in queue until they are published to all servers. Thus once the down server is brought back on-line, the content gets synchronized automatically.
If the target environment is down for a long duration the Publish Queue can get flooded with lots of assets. In such a case the down environment should be removed from the publish destination. Once the server is up, it will need to be manually synchronized with the delivery/on-line server.
There is a very useful blog about how this method is implemented for www.oracle.com including how to pass the encrypted password. This blog can be seen at:
https://blogs.oracle.com/pdit-cas/entry/delivery_disaster_recovery_for_webcenter
This method for keeping DR system in sync with Delivery using dual-publishing, requires that initially both DR system and Delivery are synchronized. Once they are initially synchronized, dual publishing keeps them in sync.
Also note, these procedures only synchronize content that is published to Delivery from Editorial. If your site visitors directly update some data on the live Delivery site, that data will not be copied to DR system. For example, if your website utilizes Community Server, and has user comments, ratings, reviews, polls etc. that are directly entered on the Delivery Server, those will not be synchronized using this procedure. If your website has “Forms”, and you capture the data submitted by the site visitors and store in the database, that data will also not be synchronized. For these you will need to backup the associated database tables and files.
Initial Setup
There are two methods for synchronizing content between DR and Delivery initially:
* Do a full publish to the DR system. This will ensure that all assets that are published to Delivery are also published to DR. It is a simpler of the two methods but may take longer depending on the number of assets to be published
* Take a backup of Delivery system and restore it in DR. The procedure for taking backup & restoring is given here: https://docs.oracle.com/cd/E29495_01/doc.1111/webcenter_sites_11gr1_backup_recovery.pdf
Disaster Recovery for Editorial
If you want to set up a DR for Editorial system also, you cannot rely on dual publishing. Content is created on Editorial. Many assets in Editorial are work-in-progress. The content editors frequently modify and save assets, and publish only after all the changes have been made and approved. To synchronize Editorial system and DR_Editorial, one should follow the back-up and restore procedures. While backing up and restoring the following must be kept in mind:
* WebCenter sites stores information both in database and shared disk. Both of the database and shared disk must be backed up at the same time. This will make sure that both database and shared disk are in sync when they are backed-up.
* Any changes done after the last back-up may get lost when you restore the back-up to DR Editorial. Suppose every night you back-up Editorial and restore to DR_Editorial. Now, if your Editorial goes down, and you switch over to DR_Editorial, the changes done in Editorial after the nightly back-up will not be present in DR_Editorial.
The procedure for taking backup & restoring is given in the WebCenter Sites Documentation here: https://docs.oracle.com/cd/E29495_01/doc.1111/webcenter_sites_11gr1_backup_recovery.pdf
In this blog, I have only talked about how to keep the live system and DR system in sync. For a full DR system, you will need additional procedures that recognize a failure of the live system, and then switch over to the DR system.
All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission