Backing up web sphere application server with tivoli storage management redp0149

Front cover

Backing up WebSphere
Application Server
with Tivoli Storage Management
WebSphere Application Server
V3.5: backup/restore using TDP

V4.0: backup/restore using TSM

Installation and configuration

Leos Stehlik
Charlotte Brooks

ibm.com/redbooks Redpaper

International Technical Support Organization

Backing up WebSphere Application Server with
Tivoli Storage Management

June 2002

Take Note! Before using this information and the product it supports, be sure to read the
general information in “Notices” on page vii.

First Edition (June 2002)

This edition applies to Version 1 of Tivoli Data Protection for WebSphere Application Server,
5698-DPW for use with the Microsoft Windows NT, Microsoft Windows 2000 and IBM AIX.

Comments may be addressed to:
IBM Corporation, International Technical Support Organization
Dept. QXXE Building 80-E2
650 Harry Road
San Jose, California 95120-6099

When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the
information in any way it believes appropriate without incurring any obligation to you.

© Copyright International Business Machines Corporation 2002. All rights reserved.
Note to U.S Government Users – Documentation related to restricted rights – Use, duplication or disclosure is subject to
restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
The team that wrote this Redpaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Chapter 1. Overview of WebSphere Application Server V3.5 and backup. 1
1.1 WebSphere Application Server overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 WebSphere Application Server architecture overview . . . . . . . . . . . . 2
1.1.2 Administrative server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 Administrative database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.5 Administrative console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.6 Standard Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.7 Advanced Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.8 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.9 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.10 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.11 Workload management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.12 Open standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Tivoli Storage Manager overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.1 TSM basic architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 WebSphere Application Server backup strategy . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Why it is important to back up WebSphere Application Server . . . . . 10
1.3.2 What else needs to be backed up? . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.3 Considering the right strategy for your environment . . . . . . . . . . . . . 12

Chapter 2. Overview of TDP for WebSphere Application Server . . . . . . . 13
2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.1 TDP for WAS features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2 Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3 How backup/restore really works . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Prerequisites and supported environments . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Known limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Introducing TDP for WAS to your infrastructure . . . . . . . . . . . . . . . . . . . . 19

Chapter 3. Installing TDP for WAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Deploying TDP for WAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

© Copyright IBM Corp. 2002 iii

3.1.1 WebSphere Application Server V3.5 setup . . . . . . . . . . . . . . . . . . . . 22
3.1.2 Preparing the TSM server for TDP for WAS . . . . . . . . . . . . . . . . . . . 22
3.1.3 Installing TSM client API on WAS nodes . . . . . . . . . . . . . . . . . . . . . 24
3.1.4 Preparing DB2 for using with TDP for WAS . . . . . . . . . . . . . . . . . . . 24
3.1.5 Installing TDP for WAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.6 Post-installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Backup/restore with TDP for WAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1 Our TDP for WebSphere lab scenario . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Backing up WebSphere using TDP for WAS . . . . . . . . . . . . . . . . . . 37
3.2.3 Querying the backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.4 Restoring WebSphere using TDP for WAS. . . . . . . . . . . . . . . . . . . . 40
3.2.5 Deleting unwanted backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.1 What to do when things go wrong . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2 Recovering from failed TDP for WAS backup . . . . . . . . . . . . . . . . . . 46

Chapter 4. Backing up WebSphere V4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1 WebSphere 4.0 considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.1 WebSphere Application Server 4.0 backup/restore strategy . . . . . . 50
4.2 Planning for backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.1 Introducing our testing environment . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.2 Defining which objects we need to back up . . . . . . . . . . . . . . . . . . . 54
4.2.3 Backup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.4 Restore procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.5 WebSphere Application Server V4.0 complete recovery . . . . . . . . . 62
4.2.6 Backing up and restoring a non-DB2 WAS environment . . . . . . . . . 63

Appendix A. TDP for WAS config files ....... ...... ....... ...... .. 65
InitWAS.utl . . . . . . . . . . . . . . . . . . . . . . . . ....... ...... ....... ...... .. 66
db2uext.utl . . . . . . . . . . . . . . . . . . . . . . . . ....... ...... ....... ...... .. 70
vendor.env . . . . . . . . . . . . . . . . . . . . . . . . ....... ...... ....... ...... .. 72

Appendix B. WebSphere Application Server V4.0 backup scripts . . . . . . 73
B.1 Windows environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.2 AIX environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Appendix C. Additional material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Locating the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Using the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
System requirements for downloading the Web material . . . . . . . . . . . . . . 78
How to use the Web material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

iv Backing up WebSphere Application Server with Tivoli Storage Management

Related publications . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... .. 81
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... .. 81
Other resources . . . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... .. 81
Referenced Web sites . . . . . . . . . . . . . . . . . . . . . . ...... ....... ...... .. 81
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . ...... ....... ...... .. 82
IBM Redbooks collections . . . . . . . . . . . . . . . . . ...... ....... ...... .. 82

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Contents v

vi Backing up WebSphere Application Server with Tivoli Storage Management

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.

COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM's application
programming interfaces.

© Copyright IBM Corp. 2002 vii

Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:

AIX® OS/390® S/390®
Database 2™ OS/400® SP™
DB2® Redbooks(logo)™ Tivoli®
IBM® Redbooks™ WebSphere®
Magstar® RISC System/6000® z/OS™
MQSeries® RS/6000®

The following terms are trademarks of other companies:

Microsoft, Windows, Windows NT, Windows 2000 and the Windows logo are trademarks of Microsoft
Corporation in the United States, other countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, and service names may be trademarks or service marks of others.

viii Backing up WebSphere Application Server with Tivoli Storage Management

Preface

This Redpaper describes how to back up and restore two different versions of
WebSphere Application Server using Tivoli Storage Management products.

WebSphere Application Server Version 3.5 and Version 4.0 are considered
separately. WebSphere Application Server V3.5 can be backed up using Tivoli
Data Protection for WebSphere Application Server. WebSphere Application
Server V4.0 can be backed up using the Tivoli Storage Manager backup/archive
client.

This Redpaper presents an overview of WebSphere Application Server V3.5 and
Tivoli Storage Management products, then shows you how to install, configure
and run Tivoli Data Protection for WebSphere Application Server. For
WebSphere Application Server V4.0, a script is created which will perform a
backup of the administrative database and data files using operating system
utilities and the Tivoli Storage Manager Backup/Archive client.

We assume a basic knowledge of WebSphere Application Server and Tivoli
Storage Management.

The team that wrote this Redpaper
This Redpaper was produced by a team of specialists from around the world
working at the International Technical Support Organization, San Jose Center.

Leos Stehlik is an IT Specialist for TSM and SAN solutions at the IBM Global
Services in the Czech Republic. He has 5 years of experience in fields of UNIX,
Windows NT/2000 and storage management. His previous publications include
the IBM Redbook, Using Tivoli Storage Manager in a SAN Environment,
SG24-6132 and he worked on the development of workshop material for Tivoli
Storage Network Manager.

Charlotte Brooks is a Project Leader for Open Tape and Storage Management
Solutions at the International Technical Support Organization, San Jose Center.
She has 11 years of experience with IBM in the fields of RISC System/6000 and
storage management. She has written eight redbooks, and has developed and
taught IBM classes worldwide on all areas of storage management. Before
joining the ITSO in 2000, she was the Technical Support Manager for Tivoli
Storage Management in the Asia Pacific region.

© Copyright IBM Corp. 2002 ix

Thanks to the following people for their contributions to this project:

Mark Endrei
International Technical Support Organization, Raleigh Center

Ed Barton, Avishai Hochberg
IBM Tivoli Storage Manager Development, San Jose

Chris Zaremba,
IBM Tivoli Storage Manager Development, Endicott

Matthias Kubik
IBM Tivoli Storage Manager Development, Boeblingen

Yvonne Lyon, technical editor
International Technical Support Organization, San Jose Center

Comments welcome
Your comments are important to us!

We want our papers to be as helpful as possible. Send us your comments about
this Redpaper or other Redbooks in one of the following ways:
Use the online Contact us review redbook form found at:
ibm.com/redbooks
Send your comments in an Internet note to:
redbook@us.ibm.com
Mail your comments to the address on page ii.

x Backing up WebSphere Application Server with Tivoli Storage Management

1

Chapter 1. Overview of WebSphere
Application Server V3.5
and backup
In this chapter we provide an overview of the structure of WebSphere Application
Server V3.5, plus the components needed to back it up using Tivoli Data
Protection for WebSphere. We also explain why it is important to back up the
WebSphere Application Server environment and introduce various backup
strategies.

© Copyright IBM Corp. 2002 1

1.1 WebSphere Application Server overview
WebSphere Application Server is a core part of of IBM’s WebSphere software —
a set of middleware products which enable the building, deployment and
integration of high-performance Web sites with advanced e-business features
using open standards. The general Web site for IBM WebSphere products is:
http://www.ibm.com/software/websphere

IBM WebSphere Application Server (WAS) provides a scalable, industrial
strength deployment platform for e-business applications.

The Standard Edition supports the standard Java APIs for developing dynamic
Web content: Servlets, JavaServer Pages (JSP) and eXtensible Markup
Language (XML).

The Advanced Edition adds support for presenting business logic as Enterprise
Java Beans (EJB) components. It also provides the capability to scale an
application by distributing it across multiple physical machines, and the
administrative tools needed to manage a distributed site.

WebSphere Application Server and its supported technologies provide the ability
to rapidly build sophisticated applications that are well structured and hence
maintainable and extensible at e-business space.

Note: Please note that for the purpose of this Redpaper we only discuss
WebSphere architecture in a high-level overview. For additional detailed
information on WebSphere Application Server, refer to these Redbooks:
WebSphere V3.5 Handbook, SG24-6161
IBM WebSphere V4.0 Advanced Edition Handbook, SG24-6161

1.1.1 WebSphere Application Server architecture overview
After installing and running either Standard or Advanced editions of WebSphere
Application Server on a single machine, certain key processes will be running.
This section gives a brief introduction to these processes and their purpose.

Figure 1-1 gives a high-level overview of the major components that comprise a
WebSphere Application Server instance.

2 Backing up WebSphere Application Server with Tivoli Storage Management

application
Application administrative
server(s)
Server(s) console

administration
server administrative
database

Figure 1-1 WebSphere Application Server components

The following sections describe the components shown in this figure.

1.1.2 Administrative server
The administrative server is the systems management runtime component of
WebSphere. The administrative server is responsible for runtime management,
security, transaction coordination, and workload management. In most cases
(exceptions will be outlined later), the administrative server runs on all nodes in a
WebSphere administrative domain and controls the interaction between each
node and application server process in the domain.

1.1.3 Application server
Application code, servlets, JSPs, EJBs and their supporting classes run in an
application server. Multiple application servers can be defined, each of which has
its own Java Virtual Machine (JVM). The distribution of servlets, JSPs and EJBs
among the application servers is user configurable.

Chapter 1. Overview of WebSphere Application Server V3.5 and backup 3

1.1.4 Administrative database
WebSphere stores all runtime configuration information for a domain in a single
persistent repository. In Standard Edition this repository can be stored in
InstantDB (which ships with the Standard Edition), DB2 or Oracle. Advanced
Edition supports DB2, Oracle and Sybase. Different database versions are
supported in different releases of WebSphere Application Server — consult the
release notes to ensure compatibility and support.

In our diagram we show a single node running all processes, and this is common
in small-scale development situations. It is entirely reasonable to configure the
database on a remote server, and in production environments this is typically the
case.

1.1.5 Administrative console
The administrative console is the graphical user interface used for administration
of a WebSphere administrative domain. The administrative console can run on
one of the nodes that the administrative server is running on, or it can be a
remote node that attaches to a running administrative server.

1.1.6 Standard Edition
WebSphere Application Server Standard Edition is a single system, extremely
easy-to-use, but complete solution for building an active Web site and basic Web
applications that integrate with databases.

Standard Edition can be used for applications producing both static and dynamic
Web pages containing:
Static HTML (HTML, .gif, .wav, etc.)
HTML with imbedded client-side scripts, for example JavaScript

Applications producing dynamic content with servlets and JSPs can also be
developed.

WebSphere Standard Edition does not provide the workload management
(WLM) functionality that is available in WebSphere Advanced Edition, but does
allow for multiple JVMs on a single physical server. WebSphere Standard Edition
is also limited to a single node/machine unlike WebSphere Advanced Edition.
These JVMs can be mapped to multiple virtual hosts on a single HTTP server to
provide support for hosting multiple Web sites on a single application server.


1.1.7 Advanced Edition
WebSphere Advanced Edition extends the WebSphere Standard Edition’s
functions across multiple machines to provide complete support for developing
new high-performance, scalable and available, transactional Web-driven
applications. WebSphere Advanced Edition focuses on new applications (JSPs
and EJBs) that access relational databases for persistent state data.

WebSphere Advanced Edition also supports distributed system management
across the nodes in a distributed WebSphere Advanced Edition systems. The set
of nodes that are administered collectively comprise a WebSphere administrative
domain. An entire WebSphere domain can be administered from a single
administrative console.

The distributed WebSphere Advanced Edition architecture also requires other
fundamental services. These are briefly outlined in the following sections.

1.1.8 Naming
In an object-oriented distributed computing environment, clients must have a
mechanism to locate and identify the objects as if the clients and objects were all
on the same machine. A naming service provides this mechanism. WebSphere
uses the Java Naming and Directory Interface (JNDI) and the Lightweight
Directory Access Protocol (LDAP) to provide a common front end to the naming
service.

1.1.9 Security
WebSphere Advanced Edition allows access control to Web resources such as
HTML pages and JSPs, and also to EJBs and the business methods they
provide. Authorization to access a resource is permission-based. Access
permissions can be granted to users or groups in order to control which users or
groups can access the resource.

1.1.10 Transactions
A transaction is a set of operations that transforms data from one consistent
state to another. Any realistic business application will have operations that
require several updates to be made to a database, and for which, either all these
operations should complete, or none should complete. For example, if a money
transfer will debit one bank account and credit another, it would be a serious
error if only one of the two updates were to occur.


Traditional implementations of such business process would require the
programmer to place BEGIN and COMMIT transaction statements in the
application code. One benefit of the EJB programming model is that transactional
requirements are specified when configuring the EJB, not in the code. This
makes the code much simpler to write.

WebSphere Advanced Edition, in supporting EJBs, provides full transactional
capabilities. These are implemented using the mechanism defined in the Java
Transaction API (JTA).

1.1.11 Workload management
The workload management (WLM) functionality in WebSphere Advanced Edition
introduces the notion of modelling of application server processes. Clones, which
are instances of a model, can be created either on a single machine or across
multiple machines in a cluster. In either case the WebSphere Advanced Edition
WLM provides workload distribution and failover.

1.1.12 Open standards
Both WebSphere Standard and Advanced are based on and support key
open-industry standards such as HyperText Transfer Protocol (HTTP), HyperText
Markup Language (HTML), eXtensible Markup Language (XML), Secure
Sockets Layer (SSL), Java, JavaBeans, Common Object Request Broker
Architecture (CORBA), Lightweight Directory Access Protocol (LDAP), and most
importantly the following Enterprise Java APIs:
Enterprise JavaBeans (EJBs) are a reusable Java component for connectivity
and transactions (EJB support is provided only in WebSphere Application
Server Advanced Edition).
JavaServer Pages (JSPs) represent inline Java code scripted within Web
pages.
Java Servlets are used in building and deploying server-side Java
applications.
Java Interface Definition Language (JIDL) supports objects whose interfaces
are defined in CORBA IDL.
JDBC is for connections to relational databases. WebSphere supports JDBC
within its connection manager and within EJBs, for distributed database
interactions and transactions.
Java Messaging Service (JMS) is to be supported via MQSeries for
asynchronous messaging and queuing and for providing an interface.
Java Transaction Service (JTS) and Java Transaction API (JTA) are low-level
APIs for interacting with transaction-capable resources such as relational
databases. WebSphere uses these within EJBs for supporting distributed
transactions.


Java Naming and Directory Interface (JNDI) is for communicating with
directories and naming systems and is used in WebSphere Application
Server to look up existing EJBs and interact with directories.
Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI/IIOP)
is for communicating with Java objects in remote application servers.

1.2 Tivoli Storage Manager overview
Tivoli Storage Manager is part of the Tivoli Storage Management product set —
an enterprise-wide solution integrating automated network backup, archive and
restore, storage management and disaster recovery. Tivoli Storage Manager is
ideal for heterogeneous, data-intensive environments; supporting over 35
platforms and over 250 storage devices across LANs, WANs and SANs plus
providing protection for leading database, collaborative and middleware
applications. See Figure 1-2.

DIGITAL IBM*
DATA OpenVMS
(SSSI)*** AIX OS/2 Lan Server
GENERAL
AUSPEX** UNIX HEWLETT- NUMA-Q OS/2 Warp
APPLE DG/UX
FUJITSU*** AS/400 OS/390 UNIX
Tru64 UNIX PACKARD
Macintosh OS/2 System Services
HP-UX MICROSOFT
-Windows XP
Windows 95
Windows 98
Windows NT
Windows NT DEC Alpha
DB2 UDB Windows 2000

Linux for
INFORMIX Intel

LOTUS
DOMINO
Tivoli Storage Manager client platforms
Linux
LOTUS zSeries
NOTES and
OS/390
NDMP
filer
(NetApps)
MICROSOFT
Exchange Server NOVELL
SQL Server ORACLE NETWARE
Oracle7 EBU SEQUENT PTX
SAP
Oracle8 RMAN
EMC Symmetrix
R/3
NUMA-Q NSM
TANDEM SILICON SIEMENS NIXDORF
SYBASE
GUARDIAN SUN GRAPHICS
IRIX
SINIX VM
(ETI)*** MICROSYSTEMS SINIX Reliant UNIX
Solaris SINIX 386/486
OS/400
Tivoli Data Protection for application
MVS
Family:
Lotus Domino and Notes AIX
Oracle Solaris
Microsoft SQL Server
HP-UX
Microsoft Exchange
Informix Tivoli Windows
R/3 Storage NT
NDMP Windows Disk
WebSphere Application Server Manager 2000
Optical
Tivoli Storage Manager also supports: server
IBM DB2 UDB
Sybase
platforms Storage
Tape

Hierarchy

Figure 1-2 Tivoli Storage Manager supported platforms


Tivoli Storage Manager (TSM) allows users to confidently protect and manage
information; it integrates unattended network backup and archive capabilities
with centralized storage management and powerful disaster recovery functions.
Tivoli Storage Manager is intended for companies with homogeneous or
heterogeneous platforms and complex environments that include both traditional
LANs as well as SANs. It is a best-of-breed, scalable storage management
solution that helps provide consistent and reliable protection and management of
mission-critical data that is spread across your company's enterprise. It protects
a broad range of data across the enterprise from the laptop to the data center.

Tivoli Storage Manager is an industrial-strength centralized storage management
product for your enterprise, and can protect the following backup-archive clients:
Windows 98/NT/2000, NetWare, Macintosh, as well as AIX, Sun Solaris, HP-UX,
Linux and other UNIX variants as reflected in Figure 1-2. A Tivoli Storage
Manager server is provided for OS/390, z/OS, Windows NT/2000, AIX, Solaris,
HP-UX, and OS/400.

This breadth of platform coverage affords you the choice in selecting the storage
management platform that suits your environment and leverages your hardware
and software investments. Tivoli Storage Manager can help control the cost of
distributed storage management by leveraging storage resources, helping to
reduce the cost of downtime and lost data, and helping to increase the
productivity of storage administrators and end users.

Tivoli Storage Manager exploits the numerous advantages of SANs with its
LAN-Free and Library Sharing functions. These help to remove traffic from the
LAN, allow for multiple Tivoli Storage Manger servers to share a library, and off
load backup processing from mission-critical servers. Tivoli Storage Manager
also supports server-free backup — a method for backing up and restoring large
volumes of data directly between client-owned disks and storage devices in a
way which reduces overhead on the server and client, and which minimizes data
transfer on the LAN.

For more information about Tivoli Storage Management, visit its homepage
http://www.tivoli.com/products/index/storage_mgr

1.2.1 TSM basic architecture
TSM uses a client-server architecture — where the server and client are defined
as follows.


Server: A server is a computer system that provides services to one or more
clients, or other devices over a network. A Tivoli Storage Manager server is the
repository and manager of all the backed up client data. Administrative policies
defined at the server control the types of backup performed and retention policies
for the data. The server also manages the physical media and devices where the
backed up data is stored. The TSM server consists of software installed on any of
the supported platforms, along with storage devices where the backed-up client
data will be located, and a catalog or database located on disk which tracks the
data and its retention policies.

Client: A client is a computer system that requests a service of another
computer system that is typically referred to as a server. Multiple clients may
share access to a common server. In Tivoli Storage Manager terms, a client is a
computer system which has data assets requiring protection by the TSM server.
The client decides what data will be backed up and is subject to the server’s
defined administrative policies for data retention. Typically, a client’s data is
backed up automatically by a server scheduled operation.

There are four basic types of client: Backup/Archive, HSM (Hierarchical Space
Management), API, and Tivoli Data Protection (TDP).
The Backup/Archive client provides basic backup (typically on a daily
incremental basis) and long-term vital record retention, or archive functions
for filesystem or operating system data. The backup/archive client can also
backup special parts of the Windows operating system, such as the registry.
The HSM client provides automatic and transparent movement of data from
the client disk to the TSM server. If the user needs to access migrated data, it
is dynamically and transparently restored to the client storage.
The API client is a general purpose client providing an interface for
applications to TSM storage management functions. The API includes
function calls that can be used in an application to perform the following
operations:
– Start or end a session
– Assign management classes to objects before they are stored on a server
– Back up or archive objects to a server
– Restore or retrieve objects from a server
– Query the server for information about stored objects
– Manage filespaces
TDP clients are written using the API and provide specialized backup and
restore services for selected database, collaborative and middleware
applications. Because the TDP clients are aware of the internal structures and
operations of their applications, they can provide on-line, and often
incremental backup operations. In this way, application environments can be
backed up consistently and coherently.


1.3 WebSphere Application Server backup strategy
In this section we discuss why it is important to back up WebSphere Application
Server data and mention some different possibilities for taking backups.

1.3.1 Why it is important to back up WebSphere Application Server
The demand for a backup policy will vary depending on the type of applications
which are maintained in the WebSphere environment. In most of today’s
WebSphere implementations, losing WebSphere data and configuration would
cause negative business impact.

A WebSphere Application Server environment consists of different kinds of data,
which of course, need to be treated in the appropriate way:
Central database (DB2, Oracle)
WebSphere file data — binaries, configuration files
Application data
HTTP server configuration (for example, the httpd.conf file)
Operating system specific data (for example, the system registry on the
Windows operating system)

One of the most critical configuration files is the admin.conf file, as it contains the
JAVA classpath. As developers deploy new applications, a very common and
convenient way to do this is to modify the JAVA classpath, appending the
currently needed path to the existing CLASSPATH. This results in a somewhat
lengthy and specific CLASSPATH — which is critical to being able to locate
applications.

Knowing what type of data needs to be backed up, we can define what backup
options are available:
Full offline file-based backup
Full offline database backup plus file data backup
Full online database backup plus file data backup
Full online objects based backup using Tivoli Data Protection for WebSphere
Application Server

Let us consider each of these options further.


Full offline file-based backup
For the purposes of this Redpaper, a full offline file-based backup means that the
WebSphere Application Server and its database will be stopped, all necessary
files will be backed up using Tivoli Storage Manager Backup/Archive client and
the applications re-started. WebSphere will not be available for users during this
kind of backup.

Full offline database backup with file data backup
This backup is similar to the full offline file-based backup — the only difference is
that native tools are used for database backup (the backup database command
when using DB2, RMAN when using Oracle.). The database backup utility will
utilize TSM API in order to be able to send backups to the Tivoli Storage
Manager server. After the database backup is done, TSM backup-archive client
file backup is run file backup to back-up WebSphere related files.

Full online database backup with file data backup
In this case, database backup is invoked by the DB backup utility (the backup
database command when using DB2, RMAN when using Oracle), which utilizes
TSM resources. The database is still up and running during the backup process.
Afterwards you can invoke file-based backup with the TSM Backup/Archive
client. You still need to stop WebSphere before this backup to ensure a
consistent backup data.

Full online backup with TDP for WebSphere Application Server
On the WebSphere Master Node, Tivoli Data Protection for WebSphere creates a
point-in-time snapshot of the WebSphere database and data files. Then a
database backup is automatically invoked through the database backup utility.
Once the backup is complete, TDP will start to send corresponding WebSphere
data objects to TSM. On all WebSphere Controlled Nodes a point-in-time
snapshot of appropriate WebSphere objects will be invoked and data will be sent
to TSM. This is the only backup method which can operate without taking either
the database or WebSphere Application Server offline.

Restriction: Tivoli Data Protection for WebSphere Application Server (TDP
for WAS) is available only for WebSphere Application Server Version 3.5.

We will discuss the TDP for WebSphere architecture in more detail in Chapter 2,
“Overview of TDP for WebSphere Application Server” on page 13.


1.3.2 What else needs to be backed up?
The TDP for WAS client presented in this Redpaper is designed to back up the
WebSphere Application Server configuration data and the environment.
Therefore TDP for WAS is a part of a total backup solution. It is important to be
using a regular file-based backup for all WebSphere Application Server servers
(for example, Tivoli Storage Manager Backup/Archive client) to ensure that all
files in the filesystem, plus registry are backed up regularly. Application
databases also require backup — you can use the appropriate database backup
tool for this. Typically the WebSphere Application Server environment does not
change very often — a PTF install, or deployment of a new application are
examples. Therefore, TDP for WAS need not be run every night. However, the
other system components should be backed up every night (using incremental
backup techniques to reduce the total amount of data sent).

1.3.3 Considering the right strategy for your environment
Any IT infrastructure creates its own unique environment. That’s why choosing
the right backup strategy will never be a straighforward process. When planning
for backup/restore procedures, there are many aspects which need to be
considered. Here are just a few examples:
Backup window
Bandwidth (network, storage, backup server)
Amount of data
Backup policy (number of versions, expiration period)
Users’ demands for data availability
Costs
Disaster recovery requirements
Security requirements

For smaller to mid-scale WebSphere Application Server environments, you might
consider taking online daily point-in-time full backups of WebSphere Application
Server, and depending on your requirements weekly or monthly full offline
backups (essentially archives from the TSM point of view).

If your WebSphere Application Server environment is secured by a firewall
(which is often true), you should be sure to enable the appropriate ports for
backup. These are 1500 and 1501 for communication with the TSM server (by
default — local installations may vary) and 57321 for TDP for WAS.

For large scale distributed WebSphere Application Server environments, detailed
analysis is required, in order to understand and integrate WebSphere Application
Server backup with other critical business systems and the overall business
strategy. This exercise is beyond the scope of this Redpaper.


2

Chapter 2. Overview of TDP for
WebSphere Application
Server
In this chapter we overview the architecture of Tivoli Data Protection for
WebSphere Application Server (TDP for WAS). We explain how it works, the
prerequisites, what versions and platforms are supported by current release, and
what steps you need to take in order to successfully deploy TDP for WebSphere.


2.1 Architecture
In this section we look in detail at how TDP for WAS works. We discuss its main
features, and also consider some features this product does not provide, and
why.

2.1.1 TDP for WAS features
TDP for WAS provides the ability to archive and retrieve the data stored in a
WebSphere administrative DB2 database (including servlets and Enterprise Java
Beans — as long as they are registered within the administrative database) and
maintain DB2 redo log files. Note that although WebSphere Application can use
a variety of products for its administrative database, TDP for WAS only works
with DB2.

TDP for WAS does not provide backup/restore operations for any application
databases (used for example, by Web applications or servlets) even when these
databases are registered in the WebSphere administrative database. You need
to back up this data separately using the appropriate database backup utilities.
Also, WebSphere binaries are not backed up with the TDP for WAS application.
You can backup these files with the regular Tivoli Storage Manager
Backup/Archive client.

2.1.2 Design overview
Let us now take a closer look at the TDP for WebSphere design and its
components.

TDP for WebSphere has the following components:
TDP for WAS Main Module (TDPWS)
Prole service
Datamover
DB2 User Exit
DB2 Shared Vendor Library
TDPPASSWD command line utility

Figure 2-1 shows the dependencies and process flow between these TDP
WebSphere components. The diagram shows two WebSphere Application
Server servers and a database server. The TDPWS user command line interface
communicates with the main Java application module. The main module sends
requests to the Prole daemon, which then dispatches those requests to the
Datamover for file-based objects and to the DB2 User Exit for the WebSphere
administrative database backup. The Datamover then communicates with TSM
through the Shared Vendor Library component using the TSM API.


TDP for WebSphere - design overview

Server A (Master Node)

Pro
Prole datamover
Datamover
DB Server
WAS Admin
WAS Admin
Server
Server Log File
Manager
Pro
Prole
File datamover
Datamover
TDP for WAS
TDP for WAS File
system TSM
TSM
system
Main Module
Main
Shared Vendor Server
Server
DB2 Library
datamover
Datamover
Server B (Controlled Node)
Pro
Prole datamover
Datamover

File
File
system All additional nodes are considered
system
to be controlled nodes

Figure 2-1 TDP for WebSphere architecture overview

TDPWS
This component is a script which communicates with the main Java application.
The TDPWS utility is responsible for the entire backup/restore process of all your
WebSphere nodes. Please note that TDPWS is available (installed) on the
master node only. There’s only one master node for the whole WebSphere
domain. Before running the TDPWS command, you need to set the WAS_HOME
environment variable. This process is described in “Setting up environment
variables” on page 31.

Prole daemon
The Prole daemon receives tasks from TDPWS and forwards them to the other
TDP WebSphere components, like Datamover and/or DB2 services (userexit,
shared vendor library). The Prole daemon is actually responsible for executing
backup and/or restore processes. Prole runs on all the WebSphere nodes where
TDP for WAS has been installed.

Chapter 2. Overview of TDP for WebSphere Application Server 15

Datamover
As implied by the name of this component, the Datamover is responsible for all
data transfers. It is directly controlled by the Prole daemon. The Prole daemon
tells the Datamover where to move the particular data; and Datamover performs
this operation, sending back a return code to the Prole daemon indicating if the
operation succeeded or not.

DB2 User Exit
The DB2 User Exit program is more properly a DB2 component rather than a
TDP for WAS component. However, the particular DB2UEXT binary shipped with
the TDP for WAS product can only be used in conjunction with the WebSphere
administrative database. Its primary responsibility is to read and transfer DB2
redo log files from the DB2 log path to the TSM client (using TSM API). The User
Exit interfaces with Datamover in order to transfer log files to and from the TSM
server.

DB2 Shared Vendor Library
The DB2 Shared Vendor Library implements the interface between the DB2 User
Exit and the Datamover.

TDPPASSWD command line utility
Although this command line utility doesn’t control any data transfer between TDP
for WAS, DB2 and the TSM server, it is important for generating a TSM password
file for the TSM API client. This is necessary because DB2 cannot use the
PASSWORDACCESS GENERATE option for automated password handling
when communicating with TSM server.

2.1.3 How backup/restore really works
In this section we explain how the TDP for WAS backup and restore process
works.

Backup
When a backup is started through the tdpws command, a request for a full DB2
backup of the WebSphere administrative database is sent (through the Prole
daemon) to the DB2 database. One of two possible DB2 backup methods may
be used:
Full database offline backup
Full database online backup


Full database offline backup is used anytime when the WebSphere Application
Server database has its BACKUP_PENDING flag set to on (for example, after a
partial or failed backup, an update configuration for the database, and so forth).
Otherwise a full online backup will be used. Note that the WebSphere Application
Server server needs to be running when initiating a TDP for WAS backup. If it is
not, only a full offline backup of the administrative database will be performed —
no application or configuration data will be backed up.

Once the DB2 backup is complete, TDPWS starts to examine the WebSphere
domain configuration, saving the configuration file in XML format.

Now the backup process reaches its second stage, by parsing a list of objects
intended for backup. Figure 2-2 shows the data flow among TDP WebSphere
components.

TDP WebSphere data flow diagram

WAS Admin DB
DB2 instance
DB2 Server Process
DB2 Vendor API

TDP for WAS Prole daemon

TSM API
Profile Config file

TSM Server

Storage Library

Figure 2-2 TDP WebSphere data flow diagram


Restore
When restore is started through the tdpws command, TDP WebSphere will query
TSM server for list of available backups through TSM API. Then it displays this
list; you need to choose the desired backup ID. Remember that backup ID names
are case sensitive.

TDPWS sends a request to the Prole daemon for a database restore in order to
fully restore and recover the administrative database. After that, TDP for WAS
will start to restore file data objects.

2.2 Prerequisites and supported environments
Here are the prerequisites and supported environments for TDP for WAS. Since
support requirements do change, check the Web site for the most up to date
information:
http://www.tivoli.com/support/storage_mgr/tdp_websphere.html

Supported operating systems:
AIX 4.3.2 or later with the latest maintenance level installed
Windows NT (service pack 5 or higher) or Windows 2000 with the latest
service pack

Prerequisite software:
WebSphere Application Server version 3.5 Standard or Advanced Edition with
latest fixpack
Tivoli Data Protection for WebSphere with latest available fixes (release
1.1.1.)
DB2 UDB 7.1 or later recommended with latest fixpack supported with
WebSphere Application Server v 3.5
TSM Server V4.1 or later on any supported platform
TSM client API V4.1 or later on each node where TDP WebSphere will be
installed

Restriction: Please note that WebSphere Application Server V4.0 is not
supported by the current version of TDP for WAS. For details on how to
manually back up a WebSphere V4.0 environment using Tivoli Storage
Management, please refer to Chapter 4, “Backing up WebSphere V4.0” on
page 49.


2.2.1 Known limitations
Here is a list of some known limitations in the current release of TDP for WAS.
Only one WebSphere administrative database is supported per DB2 instance.
TDP for WAS can not be activated for any other DB2 database within the
instance.
TDP for WAS can not be activated for any other DB2 database than the
WebSphere Application Server administrative database.
If using the original release version of TDP for WAS (V1.1) and a backup of
the administrative database fails, the instance must be restarted (refer to
3.3.2, “Recovering from failed TDP for WAS backup” on page 46). This is not
necessary for versions of TDP for WAS at 1.1.1 and above.
The delete function of TDP for WAS (see 3.2.5, “Deleting unwanted backups”
on page 41) does not actually physically delete backup versions of the
WebSphere backups in TSM. It will mark them as inactive — you need to use
the TSM management class parameters to set the retention period and
number of versions to keep for expired objects to ensure that old backups will
actually be deleted from the TSM database.
DB2 on AIX requires an existing instance for a database restore. You need to
create an empty database instance before starting a restore (create db
<dbname>).
DB2 on Windows cannot load the vendor library from a directory path with
embedded spaces (for example “D:Program Files). Do not use the default
installation directory, follow exactly the installation instructions we describe in
3.1.5, “Installing TDP for WAS” on page 25.

2.3 Introducing TDP for WAS to your infrastructure
For the purpose of this section, we assume that you already have your
WebSphere infrastructure installed and running and that a TSM server is also
available. We will focus only on things you need to consider before implementing
TDP for WAS into the WebSphere infrastructure.

The following components will be affected in some way during TDP for WAS
implementation:
DB2 database
Tivoli Storage Manager


If you plan to install TDP for WAS into a production environment, remember that
you need to schedule a shutdown for the WebSphere nodes and database
servers. That’s because some configuration changes are required in the DB2
database environment in order to use TDP for WAS properly. These changes
require DB2 to be offline, which will of course affect production WebSphere
systems.

For more detailed information on the changes necessary to set up the
environment for TDP for WAS installation, see 3.1, “Deploying TDP for WAS” on
page 22.

How long of an outage for will be required for TDP for WAS implementation? It
depends primarily on the scale of your environment (number of WebSphere
nodes, size of the WebSphere Application Server administrative databases),
throughput of your TSM backup system and so on. This is because the DB2
configuration change needed for TDP for WAS requires an immediate full offline
backup of that database — depending on the size of the database. If the
database is large this may take some time.

From the TSM perspective, few changes are necessary, and an outage may not
be required. You need to define a policy for your WebSphere backups, register
the client nodes, create storage pools, and define media into them. This can all
be done online. You may then need to consider changing the time-out
parameters for client sessions in the main TSM configuration file dsmserv.opt as
described in “Modify server options file” on page 23. This change does require
the TSM server to be restarted.


3

Chapter 3. Installing TDP for WAS
In this chapter we describe how to install Tivoli Data Protection for WebSphere
Application Server (TDP for WAS). These topics are covered:
Setup necessary on the Tivoli Storage Manager server side before you install
TDP for WAS
DB2 setup
Description of the configuration files, location, environment variables,
password handling, tdppasswd usage
Basic backup and restore operations
Troubleshooting section — error messages, tracing, advanced diagnostics


3.1 Deploying TDP for WAS
In this section we describe the installation process and all the necessary
pre-installation and post-installation steps.

3.1.1 WebSphere Application Server V3.5 setup
For the purpose of this Redpaper, we assume that WebSphere Application
Server V3.5 is installed in the default location, it uses a local DB2 database as its
database engine, and the IBM HTTP server is up and running.

WebSphere Application Server uses a database called WAS as the
administrative database.

If you need any further information on how to install WebSphere application
server, please refer to the product manuals or to the Redbook WebSphere V3.5
Handbook, SG24-6161.

3.1.2 Preparing the TSM server for TDP for WAS
In this section we provide a brief overview of how to configure the TSM server in
order to use it with TDP for WAS.

We assume that your TSM server is already installed with a storage device
configured.

Please note that we cover only those TSM topics, which are necessary for the
purpose of this Redpaper. If you need any further information on how to install
and configure a TSM server environment, please refer to the product manuals for
your TSM platform. These are available at:
http://www.tivoli.com/support/public/Prodman/public_manuals/td/TD_PROD_LIST.html

Creating storage pool and policy definitions
You need two storage pools — one for the WebSphere Application Server
administrative database backup, and one for data files from your WebSphere
Application Server nodes.

Create those storage pools as shown in Example 3-1. We use the storage pool
names was_db for the database backup and was_nodes for the data files.

Example 3-1 Create storage pools
define stgpool was_db 3570 maxscratch=5
define stgpool was_nodes 3570 maxscratch=5


Specify the correct device_class_name for your environment.

Now we need to create and activate a policy definition for our WebSphere data,
associating our storage pools with the management class. Our policy domain is
called dom_was, with a policy set dom_was and management classes mdata,
mdb and mlog. The DB2 database backups and redo logs will use the mdb and
mlog management classes respectively, and the WebSphere Application Server
data files will use the mdata management class. The class mdata is associated
with the storage pool was_nodes and the management classes mdb and mlog
use the storage pool was_db. See Example 3-2.

Example 3-2 Creating and activating backup policy
define domain dom_was
define policyset dom_was dom_was
define mgmtclass dom_was dom_was mdata
define mgmtclass dom_was dom_was mdb
define mgmtclass dom_was dom_was mlog
define copygroup dom_was dom_was mdata standard destination=was_nodes
define copygroup dom_was dom_was mdb standard destination=was_db
define copygroup dom_was dom_was mlog standard destination=was_db
define copygroup dom_was dom_was mdata standard destination=was_nodes t=a
define copygroup dom_was dom_was mdb standard destination=was_db t=a
define copygroup dom_was dom_was mlog standard destination=was_db t=a
assign defmgmgtclass dom_was dom_was mdb
activate policyset dom_was dom_was

It is not necessary to specify versioning information in the TSM backup copy
groups, because TDP for WAS uses the TSM archiving function for operation and
therefore all data is processed according to the archive copy group definition.

Finally, you need to register a client node in the TSM server for the WAS node —
defining it to the policy domain set up for WebSphere (dom_was). You will log in
under this account to the TSM server from TDP for WAS. See Example 3-3.

Example 3-3 Register node for backing up Webpshere in TSM server
register node was <password> domain=dom_was maxnummp=2

Set the MAXNUMMP value (how many mount points this TSM client node can
allocate) according to your environment.

Modify server options file
For most database related backups it is necessary to increase the default values
for COMMTIMEOUT and IDLETIMEOUT in the server options file dsmserv.opt.

Chapter 3. Installing TDP for WAS 23

If you forget to change these parameters, and you start a backup session (or any
other backup which uses TSM API as the communication interface), the TSM
server might cancel that session if one of the timeout values is exceeded. If that
happens, your backup will fail — since even if the client is able to restart its
backup session, it will be using a different session ID; however, the backup utility
is still expecting the original session ID.

We recommend that you set these values as shown in Example 3-4.

Example 3-4 Modify timeout options in DSMSERV.OPT configuration file
COMMTIMEOUT 600
IDLETIMEOUT 45

A TSM server restart is required to activate changes to the server options file.

3.1.3 Installing TSM client API on WAS nodes
In this step, install TSM Backup/Archive client and the client API on all your
WebSphere nodes which you plan to back up with TDP for WAS. There’s no
additional configuration necessary, you only need to install it.

3.1.4 Preparing DB2 for using with TDP for WAS
TDP for WAS is fully integrated with the native DB2 commands for database
backups. In order to take online DB2 backups, your WebSphere Application
Server administrative database must be set to logretain mode and must be
enabled to use the userexit program shipped with TDP for WAS.

Attention: After applying the changes described below, you won’t be able to
start the WebSphere server until you run a full offline DB2 backup of your
WebSphere administrative database. This is because setting the logretain and
userexit parameters switches the database to a Backup pending mode.
However, before running a DB2 full backup, you need to set additional TSM
environment variables. You can find information on how to prepare your
environment in “Setting up environment variables” on page 31.

Example 3-5 shows how to apply these changes from the DB2 Command Line
Processor.

Example 3-5 Update DB2 WebSphere administrative database settings
db2> update db cfg for was using logretain on
db2> update db cfg for was using userexit on


Now we need to disable database parallel recovery. Quit the DB2 Command Line
Processor and issue the command shown in Example 3-6 from the regular
operating system command line:

Example 3-6 Disabling database recovery parallelism
db2set DB2_USE_PARALLEL_RECOVERY=FALSE

More information on backing up DB2 using TSM (including full installation
details) is available in the Redbook Backing up DB2 Using Tivoli Storage
Manager, SG24-6247.

We are now ready to install TDP for WAS.

3.1.5 Installing TDP for WAS
In this section, we will show the installation process on Windows 2000 and AIX
platform.

Windows 2000 installation
In order to install TDP for WAS on a WebSphere node, run setup.exe from your
installation directory. An Installation Wizard will start (Figure 3-1) to guide you
through the installation.

Figure 3-1 Install Wizard startup


Click the Next button to continue with the installation. You will select the
installation type as shown in Figure 3-2.

Figure 3-2 Select type of installation

Choose Master Node installation if you’re installing TDP for WAS on the master
WebSphere node in your domain. This type of installation will install all the files
necessary to perform backup/restores of your complete distributed WebSphere
environment.

If you choose Controlled Node installation, setup will install only those files
which are necessary to back up/restore a local WebSphere node.
Backup/restore operations are controlled (invoked) by the master node.

Custom installation gives full control over what packages will be installed and is
not recommended.

Select the destination directory where the TDP for WAS binaries and
configuration files will be installed as shown in Figure 3-3. Do not use the default
Program Files folder. Many applications do not correctly handle folder names
containing spaces, and we observed DB2 backup errors when using the default
installation path.


Figure 3-3 Choose installation folder

Attention: Do not use the default “?:Program Filestdpws” directory. Choose
an alternative folder without spaces (we used C:TDPWS).


Figure 3-4 shows the next screen with a valid installation directory specified.
Click Next to continue.

Figure 3-4 Choose install destination other than Program files folder

You will be asked to confirm the installation options before the install process
starts to copy the files. Once installation program finishes copying files, a new
service is added to the system’s registry as shown in Figure 3-5. This gives you
the ability to control the Prole service.

Figure 3-5 Creates entries for system services

Tip: If you need to understand the role of the Prole service or other
components of the TDP for WAS, please read 2.1, “Architecture” on page 14.


Figure 3-6 shows the Windows Services panel with the Prole service installed
and running after TDP for WAS installation.

Figure 3-6 Prole installed as a Windows system service

As shown in Figure 3-7, the installation process now asks you if you wish to set
your environment variables. Do not do this now. Setup will set the
DSMI_CONFIG variable as a Windows User Variable, which will not work with
the DB2 database. DB2 requires to have the DSMI_CONFIG variable set as
System variable, therefore click No here.

Figure 3-7 Setting environment variables

The installation is now complete.


AIX installation
To install TDP for WAS on your AIX machine, perform the following:
1. Mount the TDP for WAS installation CD, for example:
mount /cdrom
2. Switch to the installation directory /cdrom/usr/sys/inst.images/ :
cd /cdrom/usr/sys/inst.images
3. Start SMIT based installation:
smitty install_latest
4. Specify the installation directory as a installation directory.
5. Choose “all_latest”under “Software to install”. Your SMIT screen should look
like Example 3-7.
6. Press Enter to start the installation.

Example 3-7 SMIT screen for installing TDP for WAS
Install and Update from LATEST Available Software

Type or select values in entry fields.
Press Enter AFTER making all desired changes.

[Entry Fields]
* INPUT device / directory for software /cdrom/usr/sys/inst.im>
* SOFTWARE to install [_all_latest]
PREVIEW only? (install operation will NOT occur) no
COMMIT software updates? yes
SAVE replaced files? no
AUTOMATICALLY install requisite software? yes
EXTEND file systems if space needed? yes
OVERWRITE same or newer versions? no
VERIFY install and check file sizes? no
Include corresponding LANGUAGE filesets? yes
DETAILED output? no
Process multiple volumes? yes

TDP for WAS will be installed in the directory /usr/tivoli/tsm/tdpws.

Now follow the steps described in 3.1.6, “Post-installation steps” on page 31.
Please note that you need to adapt the procedure (setting environment variables
and so on) according to the specifics of your operating system environment.


3.1.6 Post-installation steps
In this section we cover the necessary post-installation steps in order to get TDP
for WAS working properly.

Setting up environment variables
After installation, we need to set up the environment variables properly, otherwise
TDP for WAS will not work.

To avoid possible problems, we recommend that you set up all variables as
System variables. For example, DB2 requires to have the DSMI_CONFIG
variable set as a System variable — because, if this is set as a User variable,
DB2 won’t be able to perform backup/restore operations.

In Table 3-1, we show the list of variables which you need to set up. We assume
that TDP for WAS has been installed in the directory c:tdpws, and that the TSM
Backup/Archive and API clients are installed in the default directories of
c:Program FilesTivolitsmbaclient and c:Program FilesTivolitsmAPI.

Table 3-1 Setting up environment variables
Variable Name Value (example)

DB2_DIAG_PATH c:db2db2dump

DB2_UEXT_PROFILE c:db2sqllibdb2uext2.utl

DB2_VENDOR_INI c:db2sqllibvendor.env

XINT_PROFILE c:db2sqllibinitwas.utl

DSM_CONFIG c:tdpwsdsm.opt

DSMI_CONFIG c:tdpwsdsm.opt

DSM_DIR c:progra~1tivolitsmbaclient

DSMI_DIR c:progra~1tivolitsmapi

DSM_LOG c:tdpws

DSMI_LOG c:tdpws

WAS_HOME c:websphereappserver

In order to set system variables, right-click the MyComputer icon on your
desktop, choose Properties -> Advanced and then click Environment
Variables as shown in Figure 3-8. Add the new variables in the System variables
heading.


Figure 3-8 Managing environment variables

Re-start DB2
After setting up the environment variables, you need to restart the DB2 database.
This is the only way for the DB2 database to re-read the changed environment
on the Windows platform.

Add DB2 configuration data
Now you need to create a folder to store all the configuration data necessary for
TDP for WAS to operate with the DB2 database. We chose the name
C:DB2SQLLIB — you should not include spaces in the folder name.

Now copy the following files from the TDP for WAS install directory into this new
folder:
agent.lic
initWAS.utl
db2uext2.utl
db2uext2.exe
db2tadsm.dll

Now we need to edit the profile files.


Editing db2uext2.utl file
In this file, you need to change the following values according to your
environment:
LOG_DB_NAME — This contains the name of the WebSphere Application
Server Administrative database (WAS by default).
LOG_USEREXIT_LOGPATH — This contains the path for the Log File
Manager's logs and control files. This is a subdirectory of the DB2
configuration data folder created in “Add DB2 configuration data” on page 32.
LOG_DB_NODE — This contains the WebSphere DB node name.

Example 3-8 shows how we set those values in our environment.

Example 3-8 Modify db2uext2.utl file
LOG_DB_NAME WAS
LOG_USEREXIT_LOGPATH"c:db2sqllibdb2dump
LOG_DB_NODE NODE0000

Please note that the LOG_USEREXIT_LOGPATH uses the directory we created
in “Setting up environment variables” on page 31.

The full db2uext2.utl file listing is shown in Appendix A, “TDP for WAS config
files” on page 65.

Editing initWAS.utl file
You need to set the following values in your initWAS.utl file:
CONFIG_FILE — This points to the TDP for WAS configuration file
(initWAS.bki in the TDP for WAS installation directory).
SERVER — This points to the same SERVERNAME set in the dsm.opt file
(see “Create dsm.opt file” on page 35).
SESSIONS — This specifies how many sessions will be opened to TSM
server. This is limited by the value specified by MAXNUMMP in the node’s
TSM definition (using TSM command REGISTER NODE or UPDATE NODE) if the
backups are to be sent straight to a tape storage pool.
PASSWORDREQUIRED — This is a password handling option; if set to YES,
then the PASSWORD option must be defined in dsm.opt file.
ADSMNODE — This is the TSM client node name which TDP for WAS will
use for backup/restore operations — we defined this as was in Example 3-3
on page 23.


BACKUPMGTCLASS — This specifies the TSM management class for
storing all data, as specified in “Creating storage pool and policy definitions”
on page 22.
ARCHIVEMGTCLASS — This specifies the TSM management class for
storing the DB2 offline log files, as specified in “Creating storage pool and
policy definitions” on page 22.
MAXSESSIONS — This specifies the number of total parallel sessions which
will be established by Tivoli Data Protection for WebSphere Application
Server. This number should correspond to the number of simultaneously
available tape drives specified for the Tivoli Storage Manager server.

Note: Please be aware that here we only mention those parameters you need
to change in order to set up TDP for WebSphere correctly. There are many
other parameters you can set up if required for your environment or diagnostic
purposes. Refer to the product documentation or the sample configuration file
provided for a detailed description of all parameters.

Example 3-9 shows how we have modified our initWAS.utl file for our lab
environment. The full initWAS.utl file listing is shown in Appendix A, “TDP for
WAS config files” on page 65.

Example 3-9 Modify initWAS.utl file
CONFIG_FILE “c:tdpwsinitWAS.bki"
LOG_SERVER server_a DETAIL
SERVER server_a
SESSIONS 2
PASSWORDREQUIRED YES
ADSMNODE was
BACKUPMGTCLASS MDB
ARCHIVEMGTCLASS MLOG
MAXSESSIONS 2

Editing vendor.env file
Now we will modify values in the vendor.env file, which supplies additional
environment variables for DB2. Your vendor.env file is located according to the
environment variable DB2_VENDOR_INI (see “Setting up environment variables”
on page 31), which in our case points to c:db2sqllibvendor.env.

Example 3-10 shows the vendor.env file modified for our environment.


Example 3-10 Example of vendor.env file
XINT_PROFILE=c:db2sqllibinitWAS.utl
DB2_DIAGPATH=c:db2sqllibdb2dump
DB2_UEXT2_PROFILE=c:db2sqllibdb2uext2.utl
DSMI_DIR=c:progra~1tivolitsmapi
DSMI_CONFIG=c:tdpwsdsm.opt

XINT_PROFILE — This points to the TDP for WAS profile we’ve copied to the
c:db2sqllib directory in “Add DB2 configuration data” on page 32.
DB2_DIAGPATH — This points to the standard DB2 location for storing log
files and traces.
DB2_UEXT2_PROFILE — This points to the DB2 userexit profile file we’ve
copied to the c:db2sqllib directory in “Add DB2 configuration data” on
page 32.
DSMI_DIR — This points to the TSM API directory. Its value must correspond
with the value of the DSMI_DIR variable defined in “Setting up environment
variables” on page 31.
DSMI_CONFIG — This points to the DSM.OPT configuration file for TSM API
and must correspond with the value of the DSMI_CONFIG variable defined in
“Setting up environment variables” on page 31.

The full vendor.env file listing is shown in Appendix A, “TDP for WAS config files”
on page 65.

The next step is to create dsm.opt file.

Create dsm.opt file
Create a file, dsm.opt, in the TDP for WAS installation directory. This file contains
the TSM client node configuration definitions. See Example 3-11.

Example 3-11 Create dsm.opt file
servername server_a
commm tcpip
tcps brazil
tcpp 1500
nodename was
passwordaccess prompt

SERVERNAME — This must match the SERVER definition in the initWAS.utl
file (see “Editing initWAS.utl file” on page 33).
TCPS — This is the hostname or TCP/IP address of the TSM server.


NODENAME — This is the TSM nodename, and must match the value
specified in ADSMNODE in the initWAS.utl file.

Now copy the dsm.opt file in the TDP for WAS directory into a new file called
<SERVERNAME>.opt, where <SERVERNAME> is the value of the
SERVERNAME parameter in your dsm.opt file. Our file is copied to server_a.opt.

Run tdppasswd command utility
Now in the last step, you need to run the tdppasswd command line utility in order
to generate an encrypted TDP password file. This command also serves as a
check to see if your TDP for WAS configuration is correctly set up. See
Example 3-12.

Example 3-12 Output of the tdppasswd utility
C:tdpws>tdppasswd -p "c:tdpwsinitwas.utl"

Tivoli Data Protection for WebSphere Application Server

- Version 1, Release 1, Level 0 -
(c) Copyright IBM Corporation, 2002, All Rights Reserved.

BKI2000I: Successfully connected to ProLE on port 57321.
BKI0049I: Please enter password for node WAS on server SERVER_A: ***
BKI0051I: Password successfully verified for node WAS on server SERVER_A.

You should be able to connect to the TSM server — there will be an entry in the
TSM activity log to show that the session for your WebSphere node started
successfully as shown in Example 3-13. Note that the session shows up as type
TDP R3.

Example 3-13 Output of the TSM activity log console
ANR0406I Session 11670 started for node WAS (TDP R3 WINNT) (Tcp/Ip
9.1.38.187(3041)).
ANR0403I Session 11670 ended for node WAS (TDP R3 WINNT).

At this point we recommend that you reboot the machine.

3.2 Backup/restore with TDP for WAS
In this section we show how to test the basic TDP for WAS backup/restore
commands.


Backing up web sphere application server with tivoli storage management redp0149

Backing up web sphere application server with tivoli storage management redp0149

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (14)

Ähnlich wie Backing up web sphere application server with tivoli storage management redp0149

Ähnlich wie Backing up web sphere application server with tivoli storage management redp0149 (20)

Mehr von Banking at Ho Chi Minh city

Mehr von Banking at Ho Chi Minh city (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Backing up web sphere application server with tivoli storage management redp0149