Our Approach To Backup - IBM BS029ML - WebSphere Portal Server Self Help Manual

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