Some IT environments are constantly updated and modified, and are also shared by several people or groups, such as development environments. With many people making changes from the admin console at the same time, graphics FTP clients that can move directories, change configuration files directly and more. These environments can easily become candidates to fail or become unstable because of their use.
As a WebSphere administrator, maybe you do not have the responsibility to backup the machine or maybe can save all the systems in your environments, but as good technicians you can protect your WebSphere environment fully.
How to recover our systems?
WebSphere has different features to recover the environment before it fails. Since version 5 provides backupConfig and restoreConfig utilities, in version 8 these utilities have improved and allow us to recover our system more easily.
Why Backup our profiles?
- With a backup of your environment you can recover totally from scratch.
- Sometimes you can’t schedule a backup of your machine, in this case take a backup of your profiles.
- If you are going to make some configuration change and after it’s done you haven’t gotten the desired results, you can restore the profile.
- With a backup of your repository (DMGR) you can recreate your entire cell.
What is a backup?
- A WebSphere backup is a ZIP archive containing the contents of the profiles configfolder, as seen below in Figure 1.
Figure 1
Depending on the backup file, the profile can contain more or less information.
NOTE: WebSphere configurations are XML files, so its size is small but the user applications can be very large. It should be noted that the size of backup files can be quite large, as seen below in Figure 2.
Figure 2
Suppose the next environment is the one you’d like to back up, in Figure 3.
Figure 3
In this environment, we have three profiles, one cell (Profile Dmgr01) and two managed nodes (GABI Profiles \ AppSrv01 and STEVE \ AppSrv01). In cell-type profiles we have all our environments in one location, as eeb in Figure 4.
Figure 4
How to do a backup
If you specify a path and file name in [backup_file] the file will be saved in that location. If not, saved in the same directory as the command backupConfig, with name WebSphereConfig_YYYY-MM-DD.zip, as seen in Figure 5.
Figure 5
If run from WAS_HOME \ bin you must specify the profile name [-profileName]. If not, specify the default profile to use if run from \ bin will create the backup of PROFILE_NAME profile.
By default, backupConfig stops the server, so it is important to get a consistent copy. You can use the [-nostop] to prevent it.
An example, in Figure 6:
Figure 6
How to restore our backup:
With [-profileName] indicates the profile to restore. If not specified restores the default profile, in Figure 7.
Figure 7
If the configuration directory already exists, it is renamed before the restoration occurs, in Figure 8.
Figure 8
You can specify a location using [-location] if not specified is restored in the configdirectory. See Figure 9 and 10.
Figure 9
Figure 10
What’s new in WebSphere v8:
In WebSphere v8 and later we have new features to help in node recovery. addNodecommand has new parameter –asExistingNode.
With this parameter the steps to recover a damaged node are reduced. We suppose that we haven’t any backup of the node. There are less steps for WebSphere v8 and later, as seen below.
|
Previous Versions
|
WebSphere v8 and later
|
|
Stop the deployment manager.
|
|
|
Make a backup of the deployment manager configuration.
|
|
|
Use removeNode on the deployment manager to remove the node to be recovered.
|
|
|
Reinstall WebSphere Application Server v8 in the same directory as previously used.
|
Reinstall WebSphere Application Server V8 in the same directory as previously used.
|
|
Create a profile for a stand-alone application server node.
|
Create a profile with the same node name and path.
|
|
Use addNode to add the application server node to the deployment manager.
|
Recover the damaged node usingaddNode -asExistingNode
|
|
Restore the backed up configuration to the deployment manager.
|
|
Run the syncNode command.
|
Synchronize the nodes in the cell.
|
How to recover a Node in the same (named) machine:
We will recover a node, not available, from which we haven’t a backup, but its configuration remains in the DMGR, see Figure 11.
Figure 11
Our node STEVENode01 in host STEVE is unavailable, as shown in Figure 12.
Figure 12
STEP 1: Crash Node
We need to ensure that we haven’t any process (Node Agents, Servers) in unavailable node (STEVE).
STEP 2: Recovery procedure
- We need to delete the damaged node or install WebSphere in a new machine named (STEVE) in the same location.
NOTE: If you delete a profile keep in mind that if you launch
manageprofiles.bat -delete –profileName PROFILE_NAME
Your profile will be deleted from deployment manager too. Is better to delete (or move) from system profile directory, as seen in Figure 13.
Figure 13
Move or delete AppSrv03 directory, as in Figure 14.
Figure 14
Then create the profile with the same profile path, profile Name and hostname, as damaged profile, in Figure 15.
Figure 15
Run addNode with –asExistingNode parameter, in Figure 16.
Figure 16
NOTE: we don’t need to redeploy our applications they will redeploy automatically.
Then Synchronize the cell.
Recover node in the other machine:
In this case we recover a node on a different machine but with the same node name, in Figure 17.
Figure 17
The steps are similar to the above process only vary some of them.
STEP1: Change Hostname of the node in DMGR
We need to change the hostname (STEVE) of the Node (STEVENode01) to new host name (RICHARD), in Figure 18.
Figure 18
We do in DMGR machine using wsadmin, in Figure 19 and 20.
Figure 19
Figure 20
STEP 2: Create profile with SAME Node name
In target machine (RICHARD) we need to create a profile in same path, with SAME NODE NAME, as in Figure 21.
Figure 21
STEP 3: addNode –asExistingNode
The last step is addNode with parameter –asExistingNode in target machine.
If the node uses a Secure Sockets Layer certificate, you should also change the default certificate that contains the host name of the new node.
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/rxml_atpersonalcert.html
More examples?
Yes, we can recreate an entry cell from a backupConfig of our Deployment manager. We have also ConfigArchive operations to export or import server configurations and entire cell configurations. We will see these examples in the next article.
Conclusions:
Always have a backup of your environment, it is always easier to recover a configuration of that whole machine. We can be excellent technicians and do our own backups (a copy of WebSphere directory is a backup), but it is recommended to follow the procedures and use the features of the product.