WebSphere Process Server Disaster Recovery: UUIDs are unique to an install
If you are looking at WebSphere Process Server Disaster Recovery, you should know that the UUID’s that uniquely identify a server in both the Messaging Engine Database and the transaction log are unique for that particular installation. Running the equivalent installation commands on the restored system will not generate a server with the same id. This implies that you need to ensure your server installation (and profile) itself is backed up should restoration be needed in the future.
Also, as far as I know, there is no way to manually edit the UUID of a server. If you don’t keep a backup of the install, disaster recovery will be more difficult than expected and you may end up losing transactions.
Related Posts
- WebSphere Process Server Failed Event Manager: “The Recovery Sub-system is disabled.”
- Asynchronous replication of WebSphere Process Server and WebSphere Enterprise Service Bus for disaster recovery environments
- Uninstalling or updating the WebSphere V6.1 test environment using Installation Manager
- IBM Installation Manager Tip: Don’t “Save Files For Rollback”
- Migration to WebSphere Process Server and WebSphere Enterprise Bus 6.2 – Mandatory reading
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
September 23rd, 2009 at 7:15 pm
So the only way to setup the WebSphere Process Server on Disaster Recovery site is restoring the WPS profile from the Production. That means DM & managed nodes on DR sites need to take over the all IP address from Production system when the Production Sites goes down completely. What about transaction log replication between two sites? Can we just use SAN replication for transaction log replication between Prod and DR?
Cheers,
Ray
July 15th, 2010 at 7:23 am
The link below describes an overall solution for disaster recovery.
http://www.ibm.com/developerworks/websphere/library/techarticles/0809_redlin/0809_redlin.html