IBM BS029ML Self Help Guide - Page 223
Our approach to backup, Synchronize the nodes through the Deployment Manager Administrative Console.
![]() |
View all IBM BS029ML manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 223 highlights
Important: XMLAccess does not play a part in our backup approach. XMLAccess is not a tool that is designed for full backup purposes. XMLAccess is a tool designed for deploying Portal artifacts from one Portal environment to another Portal environment. For example, you can use XMLAccess to move Portal artifacts from your staging environment into your production environment once the Portal configuration has been thoroughly tested in the staging environment. While XMLAccess does have features that can play a role in some backup situations, you should not rely on an XMLAccess export in a disaster recovery scenario. Thus, we have left XMLAccess out of the discussion for WebSphere Portal disaster recovery to avoid giving a false impression of the tool's capabilities. Our approach to backup We recommend the following approach to backup: 1. Determine the time of day when the maintenance window takes place, preferably when the load on the cluster is the lowest. 2. Based on your environment, determine the fewest number of Portal nodes that are required to handle the load during this maintenance window. 3. Based on the length of your maintenance window and the minimum number of Portal nodes required to handle the load, determine the architecture of your backup procedure. For example, if you have a maintenance window of two hours for a 10 node cluster, you will need a minimum of three Portal nodes up to meet the average load requirements for this time period. If you assume that you can back up the file systems in 30 minutes, you can then break the backup into two sections. Bring down five Portal nodes, make backups, and then bring them back online. Then, take down the other five nodes and make backups. This is the quickest approach in a 24x7 environment, because you have divided your backup process into two sections. However, if you have a nine node cluster and the load requires six nodes to be up, then you will have to divide it into three sections. Depending on the speed of your backup process, you might need to extend the maintenance window in this situation. For this example, we divide the backups into two sections of five nodes each. 4. Stop the individual Portal application servers on nodes 1 through 5 using the Deployment Manager Administrative Console. Note: Ensure that you take steps to stop all Web traffic to the nodes that will be undergoing maintenance before you stop the portal application servers. 5. Stop the node agents for nodes 1 through 5 using the Deployment Manager Administrative Console. 6. Make sure no servers are running on nodes 1 through 5 by using the serverStatus.sh/bat command or by checking for running Java processes. 7. Make file system backups on each node, 1 through 5, of the WebSphere Application Server and WebSphere Portal root directories. 8. Start node agents through the command line on nodes 1 through 5 after file system backups are complete. 9. Synchronize the nodes through the Deployment Manager Administrative Console. Appendix B. Maintenance: Fix strategy, backup strategy, and migration strategy 209
![](/manual_guide/products/ibm-bs029ml-self-help-guide-6d3dd71/223.png)