SG 245431

Backup Solutions for SAP R/3 4.
5B on Netfinity Servers running Windows NT

Steve Russell, Thomas Knppel
International Technical Support Organization www.redbooks.ibm.com
SG24-5431-00
International Technical Support Organization Backup Solutions for SAP R/3 4.5B on Netfinity Servers running Windows NT
SG24-5431-00
March 2000
Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix A, Special notices on page 167.
First Edition (March 2000) This edition applies to SAP R/3 version 4.5B and Tivoli Storage Manager version 3.7.1 for use with the Windows NT Server 4.0 operating system. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. HZ8 Building 678 P.O. Box 12195 Research Triangle Park, NC 27709-2195 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 2000. 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
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii The team that wrote this redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Comments welcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Part 1. Concepts and technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Chapter 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 1.1 SAP R/3 architecture . . . . . . . . . . . . . . . . . . . . . . 1.2 SAP R/3 system landscape . . . . . . . . . . . . . . . . . . 1.3 Backup requirements in an SAP R/3 environment . 1.4 Scope of this book . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2. Backup and recovery concepts 2.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Types of backup . . . . . . . . . . . . . . . 2.1.2 Open files . . . . . . . . . . . . . . . . . . . . 2.1.3 Backing up databases . . . . . . . . . . . 2.1.4 Backup strategies . . . . . . . . . . . . . . 2.2 Windows NT . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Our recommendations . . . . . . . . . . . 2.3 Microsoft Cluster Server . . . . . . . . . . . . . 2.3.1 Complete backup of a cluster . . . . . 2.3.2 Backing up clustered disks . . . . . . . 2.3.3 MSCS unique files. . . . . . . . . . . . . . 2.3.4 MSCS configuration for SAP R/3 . . . 2.4 SAP R/3 . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 SAP R/3 directory structure . . . . . . . 2.4.2 SAP kernel . . . . . . . . . . . . . . . . . . . 2.5 Databases . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Oracle . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 DB2 Universal Database . . . . . . . . . 2.5.3 Microsoft SQL Server . . . . . . . . . . . 2.6 SAP R/3 backup and recovery concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 .3 .4 .5 .5
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
.. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
. .7 . .7 . .7 . .8 . .8 . .9 .10 .10 .11 .12 .14 .15 .16 .17 .17 .19 .19 .19 .23 .27 .29 .33 .33 .35 .37 .41 .41 .42 .48 .53 .53 .54 .54 .55 .56 .56 .58 iii
Chapter 3. Netfinity backup technologies . . . . . . . . 3.1 Tape options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Sizing IBM Netfinity backup solutions for SAP R/3 3.2.1 Sizing example . . . . . . . . . . . . . . . . . . . . . . .
Chapter 4. Tivoli Storage Manager product set . . . . . . . . . . . . . . 4.1 Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Tivoli Storage Manager architecture . . . . . . . . . . . . . . . . . 4.1.2 Base concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Tivoli Storage Manager complementary products . . . . . . . . . . . 4.2.1 Tivoli Space Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Tivoli Disaster Recovery Manager . . . . . . . . . . . . . . . . . . . 4.2.3 Tivoli Decision Support for Storage Management Analysis 4.3 Tivoli Data Protection for applications . . . . . . . . . . . . . . . . . . . . 4.4 Tivoli Data Protection for Workgroups . . . . . . . . . . . . . . . . . . . . 4.5 Tivoli Data Protection for SAP R/3 . . . . . . . . . . . . . . . . . . . . . . 4.6 Tivoli Storage Manager and DB2 with SAP R/3 . . . . . . . . . . . . .
Copyright IBM Corp. 2000
4.7 Tivoli Data Protection for Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . 59 Part 2. Implementation with Tivoli Storage Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Chapter 5. Tivoli Storage Manager setup and configuration . . . 5.1 TSM server setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 General prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 A practical implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 TSM policy and storage configuration for Oracle . . . . . . . . 5.2.2 TSM policy and storage configuration for DB2 . . . . . . . . . . 5.2.3 TSM policy and storage configuration for MS SQL Server . Chapter 6. Oracle-based systems. . . . . . . . . . . . . 6.1 Installation and configuration . . . . . . . . . . . . . . . 6.1.1 Software interdependencies. . . . . . . . . . . . 6.1.2 Additional TSM Server configuration . . . . . 6.1.3 The TSM Windows NT client . . . . . . . . . . . 6.1.4 The TSM scheduler service . . . . . . . . . . . . 6.1.5 Tivoli Data Protection for SAP R/3 . . . . . . . 6.2 Backup procedure . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Oracle database and redo log backups . . . 6.2.2 Automation using the TSM client scheduler 6.2.3 Check your backup . . . . . . . . . . . . . . . . . . 6.3 Recovery Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 63 63 64 64 68 72 77 77 80 81 82 83 84 89 89 92 94 94
Chapter 7. IBM DB2-based systems . . . . . . . . . . . . 7.1 Installation and configuration . . . . . . . . . . . . . . . . 7.1.1 Software interdependencies. . . . . . . . . . . . . 7.1.2 Additional TSM Server configuration . . . . . . 7.1.3 The TSM Windows NT client . . . . . . . . . . . . 7.1.4 The TSM scheduler service . . . . . . . . . . . . . 7.2 Backup procedure . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 DB2 database and log backups . . . . . . . . . . 7.2.2 Automation using the TSM client scheduler . 7.2.3 Check your backup . . . . . . . . . . . . . . . . . . . 7.3 Recovery procedure . . . . . . . . . . . . . . . . . . . . . .
. 99 . 99 102 103 104 105 107 107 112 113 114 119 119 122 123 123 124 125 126 127 129 130 132 137 137 140 142
Chapter 8. Microsoft SQL Server-based systems . . . . . . . . . 8.1 Installation and configuration . . . . . . . . . . . . . . . . . . . . . . . . 8.1.1 Software interdependencies. . . . . . . . . . . . . . . . . . . . . 8.1.2 Additional TSM Server configuration . . . . . . . . . . . . . . 8.1.3 The TSM Windows NT client . . . . . . . . . . . . . . . . . . . . 8.1.4 The TSM scheduler service . . . . . . . . . . . . . . . . . . . . . 8.1.5 Tivoli Data Protection for SQL Server . . . . . . . . . . . . . 8.2 Backup procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.1 MS SQL Server database and transaction log backups 8.2.2 Automation using the TSM client scheduler . . . . . . . . . 8.2.3 Check your backup . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3 Recovery procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 9. MSCS environments: an Oracle-based example 9.1 Installation and configuration . . . . . . . . . . . . . . . . . . . . . . . 9.1.1 Software interdependencies. . . . . . . . . . . . . . . . . . . . 9.1.2 Additional TSM Server configuration . . . . . . . . . . . . . iv
Backup Solutions for SAP R/3 4.5B on Netfinity Servers running Windows NT
. . . .
9.1.3 The TSM Windows NT client . . . . . . . . . . . . 9.1.4 The TSM scheduler service . . . . . . . . . . . . . 9.1.5 Tivoli Data Protection for SAP R/3. . . . . . . . 9.2 Backup procedure . . . . . . . . . . . . . . . . . . . . . . . . 9.2.1 Oracle database and redo log backups . . . . 9.2.2 Automation using the TSM client scheduler . 9.2.3 Check your backup . . . . . . . . . . . . . . . . . . . 9.3 Recovery procedure . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
.. .. .. .. .. .. .. ..
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.. .. .. .. .. .. .. ..
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.. .. .. .. .. .. .. ..
. . . . . . . .
. . . . . . . .
.143 .146 .153 .157 .158 .161 .163 .163
Appendix A. Special notices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Appendix B. Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.1 IBM Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.2 IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.3 Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.4 Useful Web sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B.5 Microsoft Knowledge Base articles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 169 169 169 170 170
How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171 IBM Redbooks fax order form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .173 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175 IBM Redbooks review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
vi
Preface
Most companies today are dependent to a greater or lesser extent on their computing infrastructure, but few computing environments can be as fundamental to the operation of a business as SAP R/3. This enterprise resource planning software product is at the heart of a growing number of businesses that range in size from relatively small companies with a few hundred employees to global enterprises with tens of thousands. Protecting against the loss of critical business data held within the SAP system can be a crucial factor in ensuring the survival of a company. Whether you want to provide archive storage or to protect against data loss through user error, system failure, malicious damage, or natural disaster, taking regular backups is a necessary process in the management of any important data processing system and SAP R/3 is no exception. This redbook is aimed at SAP R/3 installations implemented using a Windows NT Server platform running on IBMs Netfinity range of Intel-based servers. It will help you to implement efficient and reliable backup processes for your SAP R/3 installation. Focus is placed on backing up the core SAP system, that is, the database and application servers that constitute the heart of the product. Solutions have been provided for systems based on the Oracle, IBM DB2 and Microsoft SQL Server databases. In addition, we have provided one example of a backup solution for a clustered SAP system. We have assumed you are familiar with the SAP R/3 system in a Windows NT environment. Our backup methodology uses Tivoli Storage Manager, and an introduction to this and related Tivoli products is provided in the first part of the book.
The team that wrote this redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Raleigh Center. Steve Russell is a Senior IT Specialist at the International Technical Support Organization, Raleigh Center. Before joining the ITSO in January 1999, Steve had a Technical Marketing role, working in the UK as a member of IBMs Netfinity organization in EMEA. Prior to that, he spent nearly 15 years managing and developing PC-based hardware and software projects. He holds a BSc in Electrical and Electronic Engineering and is a member of the Institution of Electrical Engineers and a Chartered Engineer. Thomas Knppel is an IT specialist in Germany with four years of experience in systems management. He is a certified SAP Basis Consultant for Windows NT and Oracle, and team leader of the IBM EMEA SAP Technical Focus Group. Thomas holds a diploma in engineering, focused on technical aspects of computer science. His areas of expertise include backup and recovery, and high availability concepts on AIX and Windows NT. He has contributed to High Availability for Tivoli Servers, SG24-2032-00.
vii
The following people worked on an earlier SAP R/3 backup project, some material from which was used in this book: Bill Sadek Thomas Marien David Vincent IBM Global Services IBM EMEA SAP R/3 Techline IBM ERP IT Service
Chapter 4, Tivoli Storage Manager product set on page 41 is largely based on the work of Pat Randall, Roland Leins, Edmund Haefele, Alexandre Hogate, T S Ranganathan, and Thomas Ritter who produced the book SAP R/3 Data Management with Tivoli Storage Manager, SG24-5743 at IBMs ITSO Center in San Jose, California. The people listed below have made significant contributions to the book by sharing their knowledge and helping to resolve questions that arose during its development: Rainer Goetzmann Thomas Rech Hans Juergen Moldowan Bruno Friess Patrick Randall Roland Leins Roland Tretau Gerd Basel Jim Smith Avishai Hochberg Del Hoobler Chris Zaremba Elke Stuerzel Chris Watson Kelly Rodgers Ralf Schmidt-Dannert Harry Husfelt Lee Pisarek John Gates International SAP IBM Competence Center IBM EMEA SAP DB2 Presales Support IBM EMEA SAP DB2 Presales Support IBM Advanced Technical Support in EMEA IBM ITSO San Jose IBM ITSO San Jose IBM Germany IBM Backint support and development IBM Tivoli Storage Manager client development IBM Tivoli Storage Manager client development IBM Tivoli Data Protection for SQL Development IBM Tivoli Data Protection for SQL Development IBM DB2 for SAP R/3 development IBM DB2 for SAP R/3 development IBM DB2 UDB development ERP Advanced Technical Support SAP R/3 Tivoli Storage Solutions Development IBM Raleigh IBM Raleigh
Comments welcome
Your comments are important to us! We want our redbooks to be as helpful as possible. Please send us your comments about this or other redbooks in one of the following ways: Fax the evaluation form found in IBM Redbooks review on page 179 to the fax number shown on the form. Use the online evaluation form found at http://www.redbooks.ibm.com/ Send your comments in an Internet note to redbook@us.ibm.com
viii
Part 1. Concepts and technologies
Chapter 1. Introduction
Many companies are moving to implement enterprise resource planning (ERP) solutions to increase the efficiency with which they operate. ERP products offer an integrated, usually modular, set of components that map directly onto the functions found in most businesses. These functions include areas such as inventory control, production control, sales, financial planning, human resources, and so on. The high level of integration between these functions within the software improves data flow across the organization, streamlining processes in a way that cannot easily be achieved without an ERP solution. SAP R/3 is the market-leading ERP package today. It runs on a variety of hardware and software platforms including AS/400, UNIX and Windows NT. This book is focused on the Windows NT platform running on IBMs award-winning Netfinity range of Intel processor-based servers. In this brief opening chapter we give you an overview of the SAP R/3 architecture and the typical way in which an overall production system is organized into an SAP landscape. We also discuss the need to provide adequate protection for your data. Following the introductory material, the chapter closes by describing the scope of the remainder of the book.
1.1 SAP R/3 architecture

The SAP R/3 software operates using a conventional client/server architecture and can operate in either a two-tier or a three-tier configuration. An SAP R/3 system consists of one database server, several application servers, and many front-end or presentation servers. These latter servers are, in fact, the client workstations but are referred to as servers in SAP R/3 terminology. All the logic and data of an SAP R/3 system is stored within the database managed by the central database server. Application servers communicate with the database server and execute the SAP R/3 programs. The front-end servers (usually desktop client systems) are connected to the application servers and provide the interface for users of the system. Solutions using terminal servers for the front-end servers or connections over the Internet using a Web browser may also be implemented. In a two-tier system, the central server operates as both database and application server, whereas a three-tier system is configured with these functions executing on separate physical machines. These structures are illustrated in Figure 1:
Database Server (Database + SAP Central Instance)
Application Server(s) (SAP Dialog Instance)
Presentation Servers (Front End Users)
2-Tier Architecture (Central Instance)
2-Tier Architecture (Clustered Central Instance)
3-Tier Architecture (Distributed System)
3-Tier Architecture (Distributed System) (Clustered Central Instance)
Figure 1. Two-tier and three-tier configurations
1.2 SAP R/3 system landscape

In a typical SAP environment, several SAP R/3 systems are connected together in an overall configuration termed a landscape. These individual systems serve different functions that allow ongoing development while the business uses the production system. The individual systems might be considered as: A development and test system. This is used for creating new elements of the overall business system and for testing the correct operation of these new elements. A consolidation and integration system that allows newly developed elements to be incorporated into the existing configuration without risking the main production system. A production system that carries the live business data. New elements are introduced into this system only when testing and consolidation activities have guaranteed a low risk of problems. Each system has its own database and may need its own backup processes. A typical system landscape is shown in Figure 2:
DEV
Database
CON
Database
PRD
Database
Development system
Consolidation system
Production system
Figure 2. Standard SAP R/3 system landscape
Each system in an SAP R/3 landscape has a three-character system identifier (SID). Our example landscape has three systems, DEV, CON and PRD. New SAP R/3 applications are designed and developed on the development system, then validated in a non-production environment on the consolidation system before being transported into the regular production environment. More complex system landscapes are possible, and these may include legacy systems that were in use by the customer prior to the implementation of SAP R/3.
1.3 Backup requirements in an SAP R/3 environment

Many of todays businesses cannot tolerate any interruption in service from their critical information processing systems. They therefore choose to implement highly available solutions using, for example, clustering (see Netfinity and SAP R/3 on Windows NT MSCS Clustering, SG24-5170). Even when some downtime can be tolerated, a failure resulting in a significant loss of data can lead to the shutdown of a business. For this reason, businesses with critical systems will invariably require a backup solution to protect these systems from situations that could cause permanent loss of data. The backup solution must allow quick and efficient recovery of computer data. In a typical SAP landscape such as that shown in Figure 2 above, the production system will certainly require a backup solution. The development and integration systems may also contain critical information and will consequently also require a backup solution. This book will show you how to implement effective backup solutions based on the backup guidelines for SAP R/3 Ready-To-Run 4.5B.
1.4 Scope of this book

In this book we examine ways to implement backup and recovery of SAP R/3 4.5B with Oracle, IBM DB2, and Microsoft SQL Server databases. We cover in detail SAP R/3 systems in a Windows NT Server environment and focus on IBM Netfinity solutions. The SAP R/3 product documentation itself covers the use of either local backup drives or standby databases for disaster recovery and so we
Chapter 1. Introduction
do not repeat this information in this book. Several backup software solutions are available in the market. The backup software we use for our examples is Tivoli Storage Manager 3.7 in a network environment, running on a central backup server. In Part 1, Concepts and technologies on page 1, we examine the fundamental concepts that support backup in an SAP R/3 environment. Chapter 2, Backup and recovery concepts on page 7 looks at the basic principles behind backup, particularly for the Windows NT operating system in both basic and clustered configurations. The unique characteristics of backing up an SAP system and, specifically, databases are also covered. Backup hardware products and sizing guidelines can be found in Chapter 3, Netfinity backup technologies on page 33. The section closes with a discussion of Tivoli Storage Manager, which is the backup software we selected to use for the practical examples in this book. Part 2, Implementation with Tivoli Storage Manager on page 61 takes you through practical scenarios of SAP R/3 backup systems beginning with the details of setting up the Tivoli software. Each of the three databases we discuss in this book then has its own chapter that explains in detail how to implement a backup system for that particular database. To demonstrate how to implement backup systems for SAP R/3 servers that are clustered using Microsoft Cluster Server (MSCS), we have included a chapter illustrating the necessary principles, using Oracle as the database.
Chapter 2. Backup and recovery concepts

This chapter provides an overview of backup and recovery terminology and methods. We first describe basic backup operations in their most general form. Then, because backup for SAP R/3 is essentially protecting your database, we discuss the specific techniques used for backing up these essential data repositories. We also present an overview of those Windows NT 4.0, Oracle, DB2 and SQL Server concepts and structures that are important for backup and recovery.
2.1 Terminology
First let us define exactly what we mean by backup and recovery. We want to differentiate these complementary activities from the associated areas of archiving and retrieval. These two pairs of functions are related but have a different focus from the viewpoint of both user and administrator. In essence, backup and recovery processes are used for restoring single or multiple files, directories or perhaps a whole file system following accidental erasure or some more catastrophic problem such as a disk failure. Archiving and retrieval, in contrast, are generally used to provide long-term storage of dormant but important computer files. Both backed up and archived data is usually stored on an offline storage medium such as tape, which frees up more expensive and constrained disk space for use with currently active files. Although lost files can be recovered from archived copies if necessary, generally these will neither be as recent nor be available as rapidly as files from a well-implemented, scheduled backup process.
2.1.1 Types of backup

What do we mean when we say we are going to take a backup? There are several types of backup in common use and a well-implemented backup process will probably use several of them. For normal file and directory backup, as would be implemented for an important file and print server, there are several terms in common use. We begin by defining their meanings: Full backup Partial backup A full backup creates copies of all files on the system on the backup medium. If you are only concerned about protecting a subset of all the files in your system, you can choose a partial backup. This creates copies of a selected group of files from the system on the backup medium. For example, you may choose to back up only those files on the D: drive. Only files that are unique to your system, such as data and configuration information, need to be backed up. Operating system and application files are easily reinstalled. By not copying these you reduce the space used on your backup medium.
Incremental backup
An incremental backup copies to the backup medium only those files that have been changed since the last full or incremental backup. Just as for partial backups, you can select a subset of the whole system and only the files within that subset that have been changed will be backed up. To recover your most recent data you need the last full backup plus all the incremental backups you have made. If you need an earlier version of your data, you can stop the restoration process after restoring the backup that contains the copy you want. Incremental backups minimize the amount of backup media used.
Differential backup
A differential backup copies to the backup medium only those files that have been changed since the last full backup. Once again you can select a subset of the whole system and only the files within that subset that have been changed will be backed up. To recover your most recent data you need the last full backup and the most recent differential backup. To recover an earlier version of your data, you select the relevant differential backup. Although differential backups require more space than incremental ones, they have the advantage that they simplify recovery, since restoring a maximum of two backup sets are required to recover to any given point.
2.1.2 Open files

When a system is being backed up there is a potential problem with open files, that is, files that are in use by the operating system or applications. If you back up these files with normal methods you cannot guarantee that the versions stored on the backup medium are consistent either in themselves or with each other. In order to correctly back up such files, you need either to stop the applications that are holding them open or to use a backup program that cooperates with the software using the files. The latter approach allows the files to remain in use but ensures the backup is done in a controlled way and that data consistency is maintained. Examples of files that remain open for extended periods include database files and the Windows NT registry files.
2.1.3 Backing up databases

Because their files are often held open, when the process of backing up databases is being discussed, some additional terminology and procedures are commonly used: Offline backup When you do an offline backup of a database, the database application is stopped for the duration of the backup and restarted when the backup is complete. This procedure is usually controlled by your database software or third-party backup software.
Online backup
For an online backup of a database you dont stop the whole database. However, the database files are locked to prevent clients from accessing them during the backup process. Data that clients wish to deposit in the locked databases is instead recorded in logging files. For a consistent backup, you must also back up the log files that are managed by the system to ensure overall database consistency. Incremental backup for a database is similar to an incremental backup of a disk. The difference is that you are now only backing up the changes within a database table since the last full or incremental backup of the table. When you do a partial backup of a database you dont save the whole database, only some parts, in other words, a selected number of database tables. A standby database is a copy or shadow of the production database. Changes to the data in the production database are reflected in the standby database by applying the database logs to it some time later. As an example, the time interval for updates might be four hours. This provides a window during which any activity that corrupts the production database will not damage the standby copy, simplifying recovery in this situation.
Incremental backup
Partial full backup
Standby database
Split mirror
A split mirror backup is a method based on hardware synchronization of triple mirrored disks. This is controlled by software that interacts with the database. You can find more information for this solution in the SAP document Split Mirror Disk Backup by Georg Chlond and Carola Steinmaier, which can be found at the following URL: http://www.sap.com/products/techno/pdf/smdb.pdf
2.1.4 Backup strategies

This book deals primarily with the details of taking an accurate backup copy of your system. However, in addition to determining how best to take a single backup of the system, you should also consider your overall backup process. Several approaches to backup have been developed: Assuming your business works a regular five-day week, your backup regime might look something like this: 1. At the weekend, change to the set of backup media containing the oldest backup. 2. On Saturday, take a full backup of your data. 3. Each evening, Monday to Friday, take an incremental backup. One common practice is to maintain multiple backup sets, say three, or more if your data is critical, on a rotating basis at weekly intervals. In this way, you have access to a backup that is very recent, one that is a week older and one a week older than that.
Many other possible strategies can be implemented. Tape and tape drive vendors can usually offer advice on backup strategies. One that needs 10 tapes to provide backups going back three months can be found at: http://www.hp.com/tape/papers/strategy.html
2.2 Windows NT
There are many books and products providing support and guidance for backing up data under Windows NT. We found the following books to be useful sources of information: Windows NT Backup and Recovery with ADSM, SG24-2231 and Windows NT Backup & Recovery, by McMains and Chronister (ISBN 0-07-882363-3). For detailed coverage of this topic, we recommend that you refer to either of these books or one of the many others that are available. For the purposes of this book, in this section we give you a brief summary of basic backup strategy in a Windows NT environment. When implementing backup and recovery solutions for Windows NT, you should bear the following in mind: Windows NT can only boot from diskette, CD-ROM, or hard disk. Booting from backup media such as tape is not supported. The software you use needs to be able to back up the Windows registry. To do this correctly, the software has to use the appropriate Microsoft API because the registry files are open at all times. In order to access an NTFS partition, you have to boot a Windows NT system. Booting from a DOS diskette will not allow access to NTFS partitions. Standard backup and recovery tools and techniques for Windows NT include: Using ntbackup to back up disks, files and the registry to local tape drives. A Windows NT repair diskette. A second Windows NT partition for backup and recovery. A boot diskette with ntldr, ntdetect.com and boot.ini and, optionally, ntbootdd.sys.
In addition to these standard tools, there is a lot of commercial third-party backup/recovery software available that usually provides increased functionality in comparison with these basic tools. These may include more sophisticated features, such as: Support for tape libraries. Backup and recovery over a network. Support for database systems such as IBMs DB2, MS SQL Server, Oracle, Lotus Notes, and MS Exchange. Report recovery.
2.2.1 Our recommendations

To simply the process of recovering a Windows NT system, we recommend the following implementation. Install a second copy of Windows NT on a different local drive from the original. This second installation should include the network drivers and any drivers required to support the systems local drives. Finally, you should install your 10
third-party backup software such as the Tivoli Storage Manager (TSM) backup client. Minimize the risk of stability or other problems with this second installation by resisting any temptation to install unnecessary additional software.
Note for clusters
When your primary Windows NT installation is a part of an MSCS cluster, the second installation should not be configured for clustering. Make sure that the second copy Windows NT has the same level of Windows NT Service Pack installed as you have on the primary installation. Also, remember to clear the Automatically adjust clock for daylight saving changes check box in the Date/Time Properties dialog (accessed through the Control Panel) for the second copy of Windows NT. This will prevent the time correction being made a second time. Finally, to avoid problems due to the Windows NT system identifier (SID), do not configure the second installation as a member of the domain to which the primary installation belongs; make it a member of a workgroup instead. You should, however, set the same computer network name and TCP/IP settings. The second installation allows you to take a full backup of your primary NT installation by booting the secondary copy. We recommend you take such backups before and after any major change within your primary NT installation. This includes updates such as applying new Service Packs or installing updated drivers. By following this recommendation you will be able to recover your primary Windows NT installation rapidly if the changes cause it to become corrupted. For more detailed information, refer to Windows NT Backup and Recovery with ADSM, SG24-2231.
2.3 Microsoft Cluster Server

Clustering with Microsoft Cluster Server (MSCS) offers significant benefits in terms of availability of your server resources. Implementing a clustered configuration allows operations to continue even when many hardware failures occur. Integrity of your data, however, cannot be guaranteed by clustering alone. User error or multiple hardware failures, for example, can compromise your systems. So, even in a clustered environment, a good backup process remains an important part of your data protection strategy. Similar backup and recovery processes to those used for stand-alone systems may be used, but additional factors and constraints have to be considered due to the unique characteristics of MSCS clustered systems. Just as for a standard Windows NT system, you can use local tape drives or a central backup server as backup devices for your cluster. Tape drives, however, cannot be defined as MSCS cluster resources to allow coordinated access by both nodes of the cluster and a tape drive attached to one node cannot directly back up the local system disk of the other node. If you decide on local tape drives you should attach the same number and type to each server in the cluster.
11
Microsoft Cluster Server (MSCS), with its common disk subsystem, causes some difficulties for backup and recovery, which we will discuss in this section. Specific characteristics of MSCS that are relevant include: A backup program running on a single cluster node may not be able to access all disks in the common disk subsystem. Tape devices cannot be cluster resources. Drives in the common disk subsystem are accessible from both nodes, but only one node at any given time. Which node has access to a particular drive at a particular time is controlled without reference to backup software. Files on the common disk subsystem need to be identified in a unique fashion. Taking databases and applications offline requires special care. Files unique to MSCS may not be handled correctly by backup software.
2.3.1 Complete backup of a cluster

The complete backup of a cluster includes the operating system files and other local drives on each node as well as all shared disks. During normal operation of an MSCS cluster, only a subset of the total number of disks in the common disk subsystem may be accessible from an individual node. A backup taken from one node will not include data from those disks the node cannot access. To overcome this difficulty and ensure that all of your data is backed up, one of these three approaches is often used: Move all resources to one node before beginning the backup. Run backup jobs on both nodes. Run backup jobs on the physical nodes to protect the data on their local disks, but back up the data on the common disk subsystem by running jobs on the virtual servers that own the disks. 2.3.1.1 Moving resources to a single node Moving all resources automatically before and after each backup operation requires that the backup program can launch pre- and post-backup procedures containing cluster commands (alternatively, Netfinity Manager may be used to schedule cluster actions). This may be an option if the availability requirements are moderate and the resulting scheduled interruptions in service are acceptable. Keep in mind, however, that failing over SAP R/3 or DBMS resources from one node to the other in an MSCS cluster causes in-process transactions and batch jobs to be aborted. 2.3.1.2 Local tape drives Running backup jobs on both nodes avoids any interruptions in service and also allows the local disks on both cluster nodes to be backed up regularly. If each node has its own local tape drive, however, you will have to keep track of which set of backup tapes belong to each machine and ensure that sets from each node are kept in step so that a complete cluster recovery can be performed. Also, because you do not know, in general, which particular node owns a specific disk in the common subsystem, each node has to attempt to back up all disks. This will cause backup failure messages for those disks that cannot be accessed from a particular system.
12
2.3.1.3 Dedicated backup server Another approach is to implement a centralized network backup process using a dedicated backup server. This, however, creates a problem with unique file identification for data residing on the common disk subsystem. In this configuration, the network backup software, consisting of a backup client on each cluster node that communicates with a central backup server, catalogs each saved file using the relevant clients network name and the path in the clients disk and file system. In this manner, the backup process regards file H:\DIR_X\FILE_Y from node A as different from H:\DIR_X\FILE_Y from node B. This is the case even if H: is one of the clustered disks that could be assigned to either node A or node B. Because of this, a backup copy of H:\DIR_X\FILE_Y could be created from node A one day and from node B the next. These two copies of the same file would be cataloged as backups of different objects because of the different backup client names. This is inconvenient if you are looking for all copies of a specific file or for a complete backup listing of a specific day. More importantly, incremental backup schemes, such as the one used by Tivoli Storage Manager, break down. The two copies of H:\DIR_X\FILE_Y are not considered to be sequential generations of the same file and so the incremental backup process fails. This is illustrated in the following figure:
MSCS cluster
Node_A
Daily backups
H:\DIR_X\FILE_Y
Node_B
Common disks
Available backups of object 1 1999/08/12 Node_A H:\DIR_X\FILE_Y 1999/08/10 Node_A H:\DIR_X\FILE_Y
Available backups of object 2 1999/08/14 Node_B H:\DIR_X\FILE_Y 1999/08/13 Node_B H:\DIR_X\FILE_Y 1999/08/11 Node_B H:\DIR_X\FILE_Y
Figure 3. Incremental backup process failure in a clustered environment
13
There are two practical approaches that overcome this problem and guarantee consistency: Alias definitions at the backup server By defining that files from node As disk H: are to be considered as identical to files from node Bs disk H: (NODE_A\\H: is an alias for NODE_B\\H:), the backup software will track changes to files on this disk. Aliases have to be defined at the level of individual disks because a general alias valid for all disks (node A is an alias for node B) would also merge local disk backups. This function would typically be provided by the backup server software. Using virtual names for backup clients To use this method, each clustered disk has to belong to a resource group with at least one virtual network name. In an SAP R/3 system, clustered disks belong either to the database group (with a virtual database name) or to the R/3 group (with a virtual R/3 name). The quorum disk may belong to any group (the cluster group with the cluster virtual name is the default). Now we configure three backup clients on each cluster node: Client 1 using the physical node name to identify itself Client 2 using the virtual database name Client 3 using the virtual R/3 name The first of these clients backs up the local disks of the particular node on which it is installed. Each of the other clients performs a backup only for those disks that belong to the corresponding resource group. Now, because the backup client that saves the file H:\DIR_X\FILE_Y is known to the backup server by a virtual name, all backup copies of H:\DIR_X\FILE_Y are kept under this name. Thus all files on shared disks are cataloged on the backup server in a unique manner, independent of which cluster node owned the data when the backup was made.
TSM implementation
Tivoli Storage Manager uses a special option for the backup client to identify cluster disks and then implements this second approach using the cluster name in the backup file catalog. See Using Tivoli Storage Management in a Clustered NT Environment, SG24-5742 for more information on this topic. It is important that clients 2 and 3 back up both the files and the database using the name of their respective virtual servers, not the name of the physical node.
2.3.2 Backing up clustered disks

In some cases, a backup of data held on clustered disks may be made without active backup client software by simply defining file shares with virtual names. As explained in Microsoft Cluster Server Administrator's Guide, Microsoft document X0327902, hidden administrative shares are useful for this purpose. For example, you might use the New Resource wizard in the Windows NT Cluster Administrator to create a \\<virtual_name>\HBACKUP$ file share for the root directory of partition H:. This share does not appear in the Windows NT browse list (thanks to the trailing $ symbol in its name) and could be configured to allow access only to members of the Backup Operators group. Then the backup server connects to the
14
share and performs a network drive backup without regard to which node owns the share. In an SAP R/3 cluster you may use this technique to back up files of the SAP R/3 disk (directory \USR\SAP). But you cannot perform an online database backup in the same way because the database files are open and database operations would interfere with backup access, leading to inconsistent data in the backup files. 2.3.2.1 Offline backups In a clustered SAP R/3 environment, the database service is a monitored cluster resource. Stopping the database with the usual commands (using Oracle as an example, this would be the svrmgr30 command) to allow an offline backup procedure will not work in a cluster. This is because the cluster resource monitor detects loss of the database processes and restarts them immediately on either the same or the other cluster node and the offline backup consequently fails. To stop the database service the appropriate cluster command has to be issued rather than the normal database management utility. The cluster command should affect only the database service, not the entire database resource group; the disks must stay online so that the data to be backed up can be accessed.
2.3.3 MSCS unique files

In an MSCS cluster, the system maintains files that contain information about cluster configuration and resource status. These include: Several files in directory \MSCS on the quorum disk Two files CLUSDB and CLUSDB.LOG in the directory %WINDIR%\CLUSTER These files are permanently open and, at present, no standard procedures will allow you to back them up. To protect these files, a workaround is necessary. The cluster information on the quorum disk may be restored if the configuration information on the nodes itself (in the CLUSDB file) is correct. Procedures to recover from a failed quorum resource or corrupted quorum log are described in Microsoft Cluster Server Administrator's Guide, Microsoft document X0327902, and in Microsoft Knowledge Base, articles Q172951 and Q172944. Thus you should maintain backup copies of at least CLUSDB and CLUSDB.LOG. To make these copies, there are three workarounds: By booting the second copy of Windows NT (see 2.2, Windows NT on page 10), you can do a complete offline backup of the production installation of Windows NT, including the special files. Because the emergency system should not have an MSCS installation (to avoid any problems in the case of emergency restore), this requires you to separate the cluster node from the shared bus (or to shut down the other node). The two files contain the registry branch that sits below the key HKEY_LOCAL_MACHINE\Cluster. You can export this tree using one of the standard Windows NT registry utility programs and recover by importing it back into the registry. By using Tivoli Data Protection for Workgroups with its logical replication to duplicate the files for backup.
15
2.3.4 MSCS configuration for SAP R/3

When you want to install SAP R/3 on an MSCS cluster, we recommend the same procedure as for a normal Windows NT installation. This includes installing a second NT partition for each node in the cluster (see 2.2, Windows NT on page 10). A typical MSCS-based SAP R/3 system has the following structure:
Common disk subsystem SAP R/3 cluster group Database cluster group Cluster group containing the quorum disk Local disk
Windows NT Paging
MSCS Cluster
Local disk Cluster node A Cluster node B

Windows NT Paging
Cluster heartbeat
Client network
Figure 4. Physical view of a standard SAP MSCS cluster
Later in this book (see Part 2, Implementation with Tivoli Storage Manager on page 61) we look at some specific backup and recovery implementations using Tivoli Storage Manager. In these examples, we address the problems of backing up an SAP R/3 MSCS cluster using the following tools and techniques:
Table 1. MSCS: resolving backup and recovery related issues
MSCS backup and recovery issue A backup program running on a cluster node may not be able to access all shared disks.
Resolution A scheduler resource exists within each MSCS resource group (virtual server), which is invoked externally from a backup server. An external system is implemented as a backup server using a tape library. A scheduler resource exists within each MSCS resource group (virtual server). Scripts containing cluster.exe commands are used to control these elements. Tivoli Data Protection for Workgroups object replication mechanism is used to back up these files.
Tape devices cannot be shared cluster resources. Files on the shared disks need to be identified in a unique fashion. Bringing databases and applications offline requires special care. Additional MSCS files may not be handled correctly by the backup software.
16
Attention
Be careful when you boot your second, unclustered installation of Windows NT. To avoid problems, the node should not be connected to the shared drives or the other node should be powered off. If your system requires different device drivers for its local and common disks, you can boot the second copy to access only the local drives if you dont install the drivers for the common disks.
2.4 SAP R/3

The SAP R/3 software can be characterized as a set of executable program files, configuration files, and history log files. There are two types of SAP R/3 program: business-specific programs developed in ABAP/4, also referred to as modules, and the core executables that run the SAP R/3 instance. The term SAP R/3 kernel refers to the latter set of programs. ABAP/4 programs are part of the database and are consequently stored in its tablespaces. A full backup of the database contains all of the installations ABAP/4 programs.
Online Service System and SAPNet
Users of SAP R/3 are given 24-hour-per-day access to SAPs Online Service System (OSS) and SAPNet at no charge. They are a valuable source of information for SAP-related questions and offer technical notes, SAP Hot Packages and access to other service and support offerings. We assume SAP implementors are familiar with OSS and SAPNet and occasionally give pointers to information available through these resources.
2.4.1 SAP R/3 directory structure

When the SAP R/3 software is installed, a number of directories are created, into which are placed the files that constitute the system. The directory structure is illustrated in Figure 5:
17
SAP R/3 Directory Structure

usr sap trans SYS profile exe run dbg opt global <SID> <instance name> work data log tmp put
Figure 5. SAP R/3 directory structure
2.4.1.1 Configuration and log files Important configuration information about the SAP R/3 system is maintained in a number of files, which therefore need to be backed up. They are: System profiles Three types of profile are stored in the profile directory: The start profile contains necessary entries for the startup of an instance. The default profile contains the settings common to all SAP instances in a system. The instance profile contains the settings specific to an instance. These files are read during the startup phase of the SAP instance and must therefore be available at this time. It is also important to have backup copies of these files, particularly when settings are being modified. Normally you change these profiles using the SAP R/3 RZ10 transaction. Changes made this way result in the different versions being stored within the R/3 database. But you still need to be sure that you have a known good profile to start the SAP R/3 system. It is therefore important to make normal backup copies of the profiles outside the database. Transport directory The transport directory, trans, contains change request management data that enable the transfer of modifications between two SAP systems. These files are critical to the consistency of the R/3 system landscape, and even more critical during the development and testing phases of an implementation. Furthermore, a list of noncritical log files that contain useful information, such as a system history, may also be backed up. For example, the work directory contains the log of the SAP work processes and can be useful for problem analysis and determination in case of system failure.
18
2.4.2 SAP kernel

The executables that constitute the SAP R/3 processes and other instance and database tools are stored In the \usr\sap\<SID>\SYS\exe\run directory. SAP recommends that you use the latest level of kernel available for your R/3 release. It is wise, however, to create a backup copy of your kernel files before applying an updated version.
Applying the latest SAP kernel level
SAP periodically distributes the latest kernel available on a kernel patch CD-ROM. You can also download the current level of the kernel and the database tool from the SAP FTP server. For further details see OSS Notes 19466 Downloading a patch from SAPSERVx.
2.5 Databases
Customers that implement SAP systems can select one of a number of different databases. The three main database systems utilized by SAP R/3 are Oracle, IBM DB2, and Microsoft SQL Server. This section looks at the architecture of these three databases and provides an overview of the distribution of the SAP R/3 database files.
2.5.1 Oracle
So that you understand which files are important and thus require backing up in an Oracle-based system, we first examine the structure of Oracle's database management system (DBMS). 2.5.1.1 Oracle DBMS structure Figure 6 on page 20 illustrates the key components of an Oracle 7 or Oracle 8 database that you must consider for backup and recovery. They are: The system tablespace User tablespaces Online redo logs Archived redo logs Control files Initialization parameter files Configuration files
19
System tablespace Configuration files
Initialization parameter files User tablespaces
Control files
Online redo logs

Figure 6. Oracle DBMS structure
Archived redo logs
The system tablespace is automatically created when the database is set up. It contains the data dictionary tables for the entire database. The data dictionary contains important information about the database, including the names of database users, users' privileges, table names, space usage information, auditing information, and other general database information. The data dictionary is critical to the operation of the database because it records, verifies, and conducts ongoing work. This tablespace is always online and cannot be taken offline because the data dictionary must be available to Oracle at all times. We recommend that you reserve the system tablespace for use by Oracle alone; do not create any user tables in this tablespace. The user tablespaces contain all user data. This is where the bulk of the application data is held. Redo logs are a set of files that record all changes made to the database so that, in the event of a failure, database updates are not lost. The redo log is comprised of two parts: the online redo log and the archived redo log. The online redo log consists of the current log files that are being used to record database changes. Optionally, filled online redo logs can be archived before being reused. If you have archived redo logs, the database can be recovered from both instance and disk failures (instead of only instance failures) and the database can be backed up while it is open. To use archived redo logs, Oracle is run with the Archivelog mode set to on.
Note
SAP considers that a production system running on Oracle must run in Archivelog mode. NoArchivelog mode should only be used for test systems.
20
Control files, among other things, keep information about the physical structure of the database and log files. If you make a change to the database's physical structure by adding, deleting, or renaming data or log files, you should back up the control files. By default, three control files are maintained. As long as one is available, the system can be recovered. You should therefore make sure that the control files are distributed among multiple disks so that a disk failure will not render the database unusable. Initialization parameter files and configuration files are text files stored in the file system. The initialization parameter files contain instance configuration parameters, such as how much memory to use and what to do with filled online redo logs. The initialization filename is init<SID>.ora and is located in the /ORANT/Database directory. Configuration files contain options that are common to multiple initialization parameter files. For additional explanation of these various database structures, we recommend Oracle Architecture, by Steve Bobrowski (published by Osborne McGraw-Hill, ISBN 0078822742). According to the SAP R/3 installation manual for Oracle, the minimum disk layout for an Oracle database using RAID arrays is: One logical drive for online redo logs in a separate RAID-1 array One logical drive for offline redo logs in a separate RAID1 array One logical drive for data files in a separate RAID-5 array For performance reasons, it can be advantageous to place the online redo logs on more than one logical disk.
21
2.5.1.2 Oracle file list The following table identifies the location and function of the most important files used by the Oracle database:
Table 2. Oracle database-related files list
Directory name \ORANT
Subdirectory
Description Installation and upgrade directory for the database software (Oracle Home directory)
\BIN \Database \Network\Admin \ORACLE\<SID>\ \OriglogA \OriglogB \MirrlogA \MirrlogB \Saparch \Sapreorg \Saptrace \Sapbackup \Sapcheck \Sapdata1 \Sapdata2 \Sapdata3 \Sapdata4 \Sapdata5 \Sapdata6
Binaries / executables Configuration files Network configuration files Directory for Oracle Instance <SID> Original online redo logs, set A Original online redo logs, set B Mirrored online redo logs, set A Mirrored online redo logs, set B Backup of online redo logs (archives) Working directory for database administration Oracle alert and trace files Backup logs Logs of Sapdba -check, -next, -analyse SAP Data SAP Data SAP Data SAP Data SAP Data SAP Data
2.5.1.3 SAP tools for the Oracle database SAP provide some tools for maintaining an Oracle database. These tools can be used to perform various management functions with the database, including database backup, archiving of log files, restoration of log files and other tasks. The tools are: brbackup: Used for backing up the database
brarchive: Used for archiving offline redo logs brrestore: Used for recovering the database from database backups and the offline redo logs sapdba: This is an interactive and powerful ASCII-based application for database maintenance, backup and recovery
22
These tools are well-integrated into the SAP R/3 transaction DB13, which is used for database administration and scheduling of database activities such as backups and checking. They are usually stored in the same directory as the SAP R/3 kernel. If you are running a clustered system, however, they are stored locally under %WINDIR%\sapcluster. There is a configuration file for the sapdba utility which, by default, is called init<DBSID>.dba, located in the \orant\database directory. The configuration file for the other database tools is init<DBSID>.sap, also in the \orant\database directory. Further information about these tools can be found on the SAP Documentation CD, shipped with the product. In addition to the previously discussed tools, SAP has defined an interface for third-party backup software, called Backint. Figure 7 illustrates how third-party software is integrated using the Backint interface:
Oracle Database:
DB Agent: Orders: Interface:
Backup backup Backint
Archive backup Backint
Restore restore Backint
SAPDBA inquire Backint
File Backup/Restore:
ext. Backup Server
Oracle Filesystem
Media:
Media
Figure 7. SAP Backint interface
2.5.2 DB2 Universal Database

The DB2 Universal Database is IBMs scalable relational database product. DB2 UDB Version 5 enables the database manager to exploit the multiprocessor capability available in many modern Intel-based servers, such as IBMs own Netfinity systems. This expands the workload that may be processed and improves performance. SAP R/3 Release 4.x currently supports only the Enterprise Edition of DB2 on Intel processor-based servers running Windows NT. The DB2 Client Application Enabler (DB2 CAE) is also supported under SAP R/3. The Client Application
23
Enabler is needed on any administrator workstation to enable access to those DB2 functions necessary to perform administrative tasks. The DB2 Universal Database Control Center provides a graphical user interface and the necessary tools required to administer DB2 UDB databases. The Control Center provides a visual system overview so that, from a single control center, you may administer multiple DB2 servers, both local and remote.
SAP R/3 Release 4
SAP AG delivers the DB2 UDB database manager with the R/3 code. You must only use the version of DB2 delivered by SAP. You must obtain database updates from SAP, not IBM. These database updates are referred to as a service pack by SAP. Periodically, SAP will distribute CD-ROMs with a collection of R/3 related fixes; this collection of fixes is known as a Hot Package. These are all generally available via OSS and SAPnet. 2.5.2.1 Architecture Figure 8 shows the general architecture of a DB2 database.
DB2 database instance
R/3 Database
Non-R/3 database
Tablespaces
Tablespaces Online logs Offline logs
Containers
Files
Files
Files
Figure 8. DB2 General Architecture
DB2 logging with SAP R/3 The activation of the archive log retention mode allows you to perform a recovery of your data in case of a system failure. In Figure 9 on page 25, we show how DB2 logging works in an SAP environment. Every change to data is recorded in the online active logs (1 in Figure 9), in the log directory (Log_dir). The number of online retained logs is defined in the database configuration (30 being the default installation value). When the current active log becomes full, the next one is designated as active and starts to be filled up (2 in Figure 9). When the last retained log available is full, the user exit program (db2uext2) supplied by SAP archives (or copies) the online log into the archive directory (Log_archive) following a first in, first out process (3 in Figure 9). The offline retained logs can then be moved to media by the brarchive program, becoming archived retained logs (4 in Figure 9).
24
Log Buffer
DB2 Logger
Old New
Log_dir
Online Active
AAA BBB CCC
111 222 333 Online Retained Log File full
3
E er Us xi t
Last data page wrtitten to disk deleted or reused
Log_archive
4
Offline Retained
BRARCHIVE
Archived Retained
Figure 9. DB2 Logging Process on SAP R/3
DB2 can be configured to use one of two modes of logging: Circular logging Circular logging is the default for a new database. When this option is used, only full, offline backups can be taken. The logs are reused in a circular fashion. This option does not allow for roll-forward recovery after restoring a backup.
Archival logging Archival logging enables roll-forward recovery using both the active and archived logs to any time before a failure, or to the end of available logs. Active logs are kept and remain available to the DB2 system as online archived logs.To recover from a failure, you can restore the database from the last good backup and apply the desired logs, both active and archived.
Note
SAP consider that a production system running on DB2 UDB must run in log retention (archival logging) mode. Circular logging mode should only be used for test systems. According to the SAP R/3 installation manual for DB2, the minimum disk layout for a DB2 database using RAID arrays is: One logical drive for online logs in a separate RAID-1 array One logical drive for offline logs in a separate RAID1 array One logical drive for data files in a separate RAID-5 array
25
2.5.2.2 File list for DB2 The following table identifies the location and function of the most important files used by the DB2 database:
Table 3. DB2 database related files list
Directory Name \SQLLIB
Subdirectory
Description Installation and upgrade directory for the database software created during installation of DB2 common server software
\adsm \bin \cfg \db2\<SID> \sapdata1 \sapdata2 \sapdata3 \sapdata4 \sapdata5 \sapdata6 \sapreorg \log_dir \log_archive\<SID> \db2<SID>\ \NODE000n\SQLDBDIR \errors \db2UserExit \NODE000n\SQL0000n \NODE000n\SQL0000n+1
ADSTAR Distributed Storage Manager files DB2 executable files DB2 default system configuration files R/3 data R/3 data R/3 data R/3 data R/3 data R/3 data Used for DB2 import and export files Online log file Offline archived log files DB2 UDB root database file directory for the instance DB2 Local Database Directory files Error log of ADSM application DB2 User Exit programs DB2 UDB R/3 database files are found under this directory DB2 UDB R/3 Administration database files are found under this directory
2.5.2.3 SAP Tools for DB2 The SAP tools for DB2 are integrated with the Computing Center Management System (CCMS) of the R/3 system. They enable you to: Schedule and check backups Manage log files Reorganize tables Update table statistics Analyze database performance Monitor the space in your database
26
In addition, the DB2 Control Center (DB2CC) is extended and offers the following functions for the SAP R/3 system: Log file management Tape management Password management The admin database (or ADM<SID> database) contains data about the included functions for the SAP R/3 system. This database is mirrored to the R/3 database by a scheduled job, which allows it to be recovered from the R/3 database. Circular transaction logging is used for the admin database, that is, the LOGRETAIN and USEREXIT parameters are set to OFF.
2.5.3 Microsoft SQL Server

Microsoft SQL Server 7.0 is a member of Microsofts BackOffice suite. It is a scalable, powerful database for Windows NT Server 4.0. Two versions of Microsoft SQL Server 7.0 are available: the Standard version and the Enterprise version. The Enterprise version supports the 3 GB of application address space supported by Windows NT Server 4.0 Enterprise Edition and can operate in a clustered (MSCS) environment. SQL Server 7.0 is a dynamic database, that is it allocates and frees memory dynamically. It fully supports symmetric multiprocessing (SMP) systems with up to four processors and beyond. 2.5.3.1 SQL Server architecture MS SQL Server 7.0 introduced a new backup interface, called the Virtual Device Interface (VDI), which uses shared memory instead of the named pipes used in earlier versions of the product. One of the main advantages of the VDI backup interface is better performance in comparison to named pipes. SQL Server supports full and differential backup of the database and backup and truncation of transaction logs. It supports parallel backup to multiple local tape drives. Built directly into the SQL Server product code is support for replication of a database to another server. During a normal SQL Server 7.0 installation, the following databases are created by default: master The master database contains the system tables of all created databases and maintains information about the SQL Server installation. The model database is simply a template database and is used when you create a new database. The tempdb database is a temporary database that is recreated every time SQL Server is started. The msdb database is used by the SQL Server Agent service. This service performs scheduled activities such as backup and maintenance. It also maintains backup history information. A sample database. A sample database.
model tempdb msdb
pubs Northwind
27
Each database consists of the following files: Primary data file Every database has one primary data file that also keeps information about the other database files. By convention this file has the extension .mdf.
Secondary data file Secondary data files are optional. By convention these files have the extension .ndf. Log files Every database must have at least one log file. It contains information that is needed to recover transactions of the database. Several log files are seen as one contiguous log file. By convention these files have the extension .ldf.
The simplified architecture of an SAP R/3 database using SQL Server looks like this:
SQL Server 7.0
R/3 DB
primary log
master DB
primary log
model DB
primary log
msdb DB
primary log
tempdb DB
primary log
secondary
Figure 10. SAP R/3 SQL Server Architecture
Microsoft maintains a section of its Web site specifically for SQL Server. This can be found at: http://www.microsoft.com/sql
28
2.5.3.2 SQL Server file list The following table identifies the location and function of the most important files used by SQL Server:
Table 4. SQL Server database related files list
Directory Name \MSSQL7
Subdirectory \BINN \DEVTOOLS \BOOKS \HTML \Install \Upgrade
Description Client and server executables, online help files, dll files for extended stored procedure *.h and *.lib files for programming online book files MMC and SQL Server HTML files Scripts run during setup Files run during upgrades of SQL Server Default location for backup files System and sample database files Storage location for temporary job output files Error log files Working directory for replication tasks Files for tempdb database R/3 data files R/3 transaction log
\MSSQL7DB
\Backup \Data \jobs \log \Replicate
\TEMPDB \<SAPSID>DATA<1> \<SAPSID>LOG<1>
2.6 SAP R/3 backup and recovery concepts

There are many ways to implement backup and recovery processes. They all require answers to the following questions: Which part of the system do I need to back up? What type of backup is suitable? How frequently should I take backups? When should backups be performed? What media should I use for backup? How are backup devices managed? How do I monitor and check my backups? How long do I keep my backups?
The concepts and recommendations we use in the implementation part of this book are based on the SAP R/3 Ready-To-Run Guidelines, which suggest a 28-day backup cycle and assume a normal (five day) working week.
29
The details for the three databases we discuss in this book are summarized in the following tables. First for Oracle:
Table 5. Recommended backup schedule for Oracle
Type of backup Full online database backup Full offline database backup Backup of database logs
Time to start backup 22:00 22:00 On the hour
Backup frequency Every Monday through Thursday Every Friday Every hour except when you perform a database backup
Number of backup versions maintained 16 4 Make two copies of each log file on different media for security. Maintain entries for the entire backup cycle. 3 3
Incremental backup of OS files Incremental backup of SAP R/3 executables and configuration files Incremental backup of other database files including directory structure, configuration, files, executables, and so on
06:00 06:00
Every weekday Every weekday
06:00
Every weekday
30
Next we have the recommendations for IBM DB2:

Table 6. Recommended backup schedule for DB2
Type of backup Full offline database backup Backup of database logs
Time to start backup 22:00 On the hour
Backup frequency Every Weekday Every hour except when you perform a database backup
Number of backup versions maintained 20 Make two copies of each log file on different media for security. Maintain entries for the entire backup cycle. 3 3
06:00 06:00
06:00
Every weekday
And, finally, the schedule recommended for SQL Server:

Table 7. Recommended backup schedule for SQL Server
Type of backup Full online database backup Backup of database logs
Time to start backup 22:00 On the hour
Backup frequency Every weekday Every hour except when you perform a database backup
Number of backup versions maintained 20 Make two copies of each log file on different media for security. Maintain entries for the entire backup cycle. 3 3
06:00 06:00
06:00
Every weekday
31
The above schedules apply to routine, automatic backups. You would make additional backups before upgrading your SAP system, installing software (such as a new driver), or upgrading Windows NT with a Service Pack. If the relevant scheme above does not match your own work environment you will have to adjust backup frequency, timing and the number of back up versions you maintain. This would be necessary for businesses that operate seven days per week, for example.
32
Chapter 3. Netfinity backup technologies

This chapter provides an overview of the different IBM Netfinity tape solutions that we use in SAP environments. We focus only on digital linear tape (DLT) and Magstar technologies because they offer the speed and capacity that is needed for backing up large enterprise databases such as those used in SAP systems. For a detailed discussion of tape products and solutions for Netfinity servers, see Netfinity Tape Solutions, SG24-5218.
3.1 Tape options

IBM offers a number of different tape drives, starting with products with capacities as low as 4 GB. SAP R/3 systems can have large databases; 50 GB is not uncommon. Databases of this size will require a lot of manual intervention to swap tape cartridges as they are filled up during the backup process. Lower capacity tape drives also tend to have lower data transfer rates, which means significant lengths of time will be required to back up large databases. A tape cartridges capacity is usually expressed as two related figures. The first is its native capacity. This is the amount of data the cartridge can store assuming a direct copy from disk is performed. Data compression is almost always used with tape devices, however, as this increases the effective capacity of the media. The second figure given is the uncompressed size of the amount of compressed data that can be stored on the cartridge. For example, a DLT 20/40 tape drive uses cartridges that have a native, or uncompressed, capacity of 20 GB. With compression, however, the 20 GB of data physically stored on the tape will decompress to about 40 GB. It is important to understand that this second figure, for compressed data, is only an estimate as some data is more amenable to compression than other data. Most SAP systems, therefore, use the high-speed, high-capacity technology offered by tape drives such as DLT or IBMs Magstar units to minimize these problems. For the largest databases, tape libraries are often used. These usually have multiple tape drive units, thereby increasing the overall throughput to the backup media, and a robotic mechanism for exchanging cartridges as they become full.
33
In Table 8, we have listed the current DLT and Magstar tape drives supported by Netfinity servers along with their basic specifications and performance data:
Table 8. IBM Netfinity DLT and Magstar tape drives
Tape drive DLT20/40 DLT35/70
Native throughput 2 MBps or 7 GBph1 5 MBps or 18 GBph 6 MBps or 21.6 GBph 7 MBps or 25 GBph 9 MBps or 32.4 GBph 14 MBps or 50.4 GBph
Compression factor 2 2
Native capacity 20 GB 35 GB
Attachment Fast SCSI SE, 36 GBph Fast/Wide SCSI, 72 GBph Ultra2 SCSI LVDS, 144 GBph Fast/Wide SCSI DE, 72 GBph Fast/Wide SCSI DE, 72 GBph Ultra2 SCSI, 144 GBph
Standalone possible Yes Yes
DLT40/80
40 GB
Yes
Magstar 3570 XL Magstar 3590 Magstar 3590 E1X

1
7 GB
No, only within library No, only within library No, only within library
10 GB
20 GB
MBps is megabytes per second, GBph is gigabytes per hour
For applications where the capacity of a single tape is insufficient, or where minimal operator intervention is desired, IBM offers a number of tape library systems supported by Netfinity servers. These are listed in Table 9:
Table 9. IBM Netfinity tape libraries
Library IBM 3502 IBM 3503 Magstar MP 3575 L06 Magstar MP 3575 L12 Magstar MP 3575 L18 Magstar MP 3575 L24 Magstar MP 3575 L32 Magstar 3494
Tape drives DLT35/70 or DLT7000 DLT40/80 or DLT8000 Magstar 3570C-XL Magstar 3570C-XL Magstar 3570C-XL Magstar 3570C-XL Magstar 3570C-XL Magstar 3590 or 3590E1X
Number of tape drives 1-3 1-3 2 2-4 2-6 2-6 2-6 1-16
Available cartridge slots 14 14 60 120 180 240 324 160-6240
Native capacity 490 GB 560 GB 420 GB 840 GB 1200 GB 1600 GB 2200 GB 124800 GB
34
3.2 Sizing IBM Netfinity backup solutions for SAP R/3

In order to correctly size an SAP R/3 backup solution you need to know several items of information. The following questions are based on a centralized backup solution using a TCP/IP network. If you perform either a local or a SAN backup, you can neglect the network considerations. How long is your backup window? How big is the SAP R/3 database? How many versions do you want to store within your library? For the following sizing estimates, we made the following assumptions: During the backup the full network capacity is available The backup is not disturbed by any SAP R/3 processing To help us estimate the sizings, we need some additional information. First, let us review the maximum data throughput that can be achieved over current networks and relate them to typical figures that experience has taught us can be achieved:
Table 10. Network throughput data
Network type 10 Mbps Ethernet 100 Mbps Ethernet Gigabit Ethernet 16 Mbps token ring 100 Mbps FDDI 155 Mbps ATM SP switch
Media throughput 4.5 GBph 45 GBph 450 GBph 7.2 GBph 45 GBph 69.75 GBph 576 GBph
Backup throughput 1-3 GBph 18-29 GBph 150-250 GBph 3-5 GBph 20-29 GBph 30-35 GBph 172-345 GBph
Next to be considered is the rate at which data can be read from the disk drives commonly used in Netfinity servers. The data in Table 11 is typical for current server-class disk drives. Once again, experience shows that the practical throughput is somewhat less than the theoretical maximum.
Table 11. Hard disk drive throughput data
Hard disk rotational speed 7200 RPM 10000 RPM
Maximum throughput 11 - 22 MBps 41 - 80 GBph 24 -30 MBps 86 - 108 GBph
Backup throughput 5 - 11 MBps 18 - 40 GBph 12 - 15 MBps 43 - 54 GBph
Another area where throughput is important is the disk controller card and the bus or other connection medium by which the disks are attached to it. A Netfinity server being used to run an SAP R/3 system would almost certainly utilize a RAID disk subsystem with either SCSI or Fibre Channel technology. It is impossible to provide a single figure that characterizes the data transfer rate from the disk subsystem, because many factors can significantly affect the throughput. How many physical disks form the RAID array? How many SCSI
35
channels are being used by the array, and how is data distributed across it? The answers to these and other questions can profoundly influence the throughput achieved. While testing a variety of configurations, our performance laboratory has seen transfer rates vary as much as a factor of three or more. Table 12 provides figures near the centre of a typical spread of rates. Note that this data reflects the fact that data is being read from a RAID-5 array. Data throughput for writing data is considerably slower.
Table 12. Adapter throughput data
SCSI controller Netfinity ServeRAID3H
Maximum throughput 3 channels at 80 MBps each
Backup throughput 20 - 25 MBps 72 - 90 GBph
Finally, the subsystem technology imposes its own limits on the throughput. Table 13 lists the maximum data transfer rates for common disk subsystem interconnects:
Table 13. Bus throughput data
Protocol SCSI Fast SCSI Fast/Wide SCSI Ultra SCSI Wide Ultra SCSI Ultra2 SCSI Wide Ultra2 SCSI Fibre Channel AL SSA80 SSA160
Frequency in MHz 5 10 10 20 20 40 40 100 20 40
Max. Transfer Rate in MBps 5 10 20 20 40 40 80 100 80 160
For backup sizing we focus only on the database files, ignoring the database logs or other files. In typical situations the size of these files is relatively small so they can be neglected. Our recommended approach to sizing for backup is as follows: First, determine the requirements of the disk subsystem: 1. Calculate how many GBph you need to back up to complete the process in the available time: GBph = size of database / backup window in hours 2. Determine how many disk controllers you need: Number of adapters = GBph / backup throughput of one adapter 3. Determine how many disks you need for the database: Number of disks = GBph / backup throughput of disk
36
Then, determine the requirements of the tape subsystem: 1. Calculate the number of tape drives you need: Number of tapes = GBph / backup throughput of tape drive 2. Determine which tape library you want to use: How many tape cartridge slots will you need in your library?: Slots required = (Size of database * versions within the library)/Capacity of Media + 2 slots (or more) for logs + 2 slots for other files + 2 slots for backup server database + 1 slot (or more) for a cleaning cartridge Select a tape library that supports this number of slots and drives. 3. Determine the number of SCSI adapters you need for your tape library: Number of SCSI adapters = Number of tape drives * backup throughput of tape drive / backup throughput of SCSI adapter Determine the throughput requirements of the network between your SAP R/3 system and the backup server: 1. Determine the network type by comparing the required GBph for backup with the throughput of the various network types and choose the most appropriate. 2. How many network adapters do I need? Normally you would use only one adapter unless parallel backup sessions are supported such as between Backint and Oracle; this kind of setup is more complex, however. In this sizing methodology we have not considered what type of server you need in terms of memory, processors and so on. For a backup server, the network and tape subsystems are the primary bottlenecks to consider. We recommend, however, that your TSM server have at least 512 MB of memory and, while one processor is usually sufficient, you may need a second CPU for optimum performance.
3.2.1 Sizing example

To close this chapter, we give an example of a typical sizing exercise: Assuming the following: Size of the database to be backed up: Backup window: Versions we wish to keep within the library: Determine the requirement for the disk subsystem: 1. Calculate the GBph we need to back up: GBph = size of database / backup window in hours 50 GB/1.5h = 33.3 GBph 50 GB 1.5 hours 20
37
2. Determine how many disk controllers we need: Number of adapters = GBph / backup throughput of one adapter 33.3 GBph / 72 GBph = 0.45 So we need one ServeRAID3H Adapter 3. Determine how many disks we need for the database: Number of disks = GBph / backup throughput of disk 33.3 GBph / 43 GBph = 0.78 So a single 10,000 RPM disk is enough.
Important
Even though one disk is enough for backup and recovery, you probably will store your database on several disks to provide RAID protection and to increase the available number of input/output operations per second. Determine the requirements of the tape subsystem: 1. Calculate the number of tape drives you need: Number of tapes = GBph / backup throughput of tape drive DLT: 33.3 GBph / 21.6 GBph (DLT40/80) =1.5
So two DLT 40/80 tape drives will suffice. Alternatively: Magstar: 33.3 GBph / 25 GBph (Magstar 3570C) =1.3
We could also select two Magstar 3570C drives. 2. Determine which tape library you want to use: How many tape cartridge slots will you need in your library?: Slots required = (Size of database * versions within the library)/Capacity of Media + 2 slots (or more) for logs + 2 slots for other files + 2 slots for Backup Server database + 1 slot (or more) for a cleaning cartridge DLT: Magstar: (50 GB*20)/80GB + 2 +2 +2 +1 = 12.5 +7 = 19.5 20 slots are needed (50GB*20)/15GB + 2 +2 +2 +1 = 66.7 +7 = 73.7 74 slots are needed
Select a tape library that supports this number of slots and drives: DLT: Magstar: 3503: available slots 14, slots required 20, so this library will not fulfil our requirements. 3575-L12, -L18, -L24, -L32 all have more than 74 slots and support two or more drives. We can therefore select any of these Magstar libraries.
38
3. Determine the number of SCSI adapters you need for your tape library: Number of SCSI adapters = Number of tape drives * backup throughput of tape drive / backup throughput of SCSI adapter With a tape drive throughput of 25 GBph, two drives can manage 50 GBph so you need a SCSI adapter than can handle this amount of data. Otherwise, it may be worth using one adapter per tape drive. Determine the throughput requirements of the network between your SAP R/3 system and the backup server: 1. Determine the network type by comparing the required GBph for backup with the throughput of the various network types and choose the most appropriate. One ATM adapter or a single Gigabit Ethernet adapter would meet our needs, since both have a bandwidth bigger than 33.3 GBph. If we wanted to use 100 Mbps Ethernet, we would have to use two adapters to connect our SAP system to the backup server.
39
40
Chapter 4. Tivoli Storage Manager product set

Tivoli Storage Manager is the core product of the Tivoli Storage Management product set. It provides a solution for distributed data and storage management in an enterprise network environment. Tivoli Storage Manager supports a wide variety of platforms for mobile, small and large systems, and delivers many data management functions, such as data protection for file and application data, record retention, space management, and disaster recovery. This chapter gives a high-level technical introduction to Tivoli Storage Manager. It positions Tivoli Storage Manager within the overall Tivoli Storage Management solution, provides an overview of its architecture, base concepts, interfaces, and supported environments, and shows Tivoli Storage Managers interaction with other products of the Tivoli Storage Management product set. If you are not familiar with Tivoli products, several references can be found in Appendix B, Related publications on page 169.
4.1 Tivoli Storage Manager

Tivoli Storage Manager (TSM) is the next generation product based on ADSM (ADSTAR Distributed Storage Manager), which protects and manages data on over 30 operating platforms, covering mobile, desktop and server systems. It is integrated with hundreds of storage devices as well as LAN, WAN and emerging SAN infrastructure. The base function provided by Tivoli Storage Manager includes: Data protection: Operational backup and restore of data: The backup process creates a copy of the data to protect against the operational loss or destruction of file or application data. You have the ability to define how often to back up your data (frequency) and how many copies or versions of your data are to be maintained. The restore process places the backup copy of the data back into a customer-designated system or workstation. Disaster recovery: This encompasses all activities to organize, manage and automate the recovery process from a major loss of IT infrastructure and data across an enterprise. Disaster recovery includes processes to move data off site into a secure vault location, to rebuild IT infrastructure, and to reload data successfully and in an acceptable time frame. Storage resource management: Vital record retention archive and retrieval: The archive process creates a copy of a file or a set of files representing an end point of a process for long-term storage. Files can remain on the local storage media or can be deleted. The customer defines the retention period for data, which controls how long an archive copy is to be retained. The retrieval process locates data within the archival storage and places it back into a customer-designated system or workstation.
41
Hierarchical space management: This process provides automatic and transparent movement of operational data from the user system disk space to a central storage repository. If the user accesses this data, it is dynamically and transparently restored to the client storage. The solution is network based, which means that these functions are available to the whole network environment. All the functions can be automated to run 24 hours a day, seven days a week without user intervention. Administration costs are minimized by the centralization of all management of Tivoli Storage Manager components.
4.1.1 Tivoli Storage Manager architecture

Tivoli Storage Manager is implemented as a client-server software application, consisting of Tivoli Storage Manager server software, and Tivoli Storage Manager backup/archive client, and is able to operate in conjunction with complementary Tivoli and other vendor software products. Figure 11 below shows the main TSM components:
Administration Client
WEB
Local Area Network
Server Systems
Database Storage Repository
Client / Application Systems
Storage Area Network
Figure 11. Tivoli Storage Manager architecture
The Tivoli Storage Manager server software builds the data management backbone by managing the storage hardware and establishing a secure environment. It provides automation, reporting and monitoring functions, implements storage management policies and stores all object inventory information in the Tivoli Storage Manager database. The Tivoli Storage Manager client software implements data management functions such as data backup and recovery, archiving, hierarchical space management, and disaster recovery.
42
The client software runs on many different systems, including laptops, PCs, workstations, or server systems. Both client and server software may also be installed on the same system for a local backup solution, or to implement LAN-free backup solutions exploiting SAN infrastructure. It is also possible to define server hierarchies or multiple peer-to-peer servers in order to provide a multi-layer storage management solution or an electronic vaulting solution. 4.1.1.1 Tivoli Storage Manager server A main architectural component of the Tivoli Storage Manager server software is the relational semantic database. The storage manager database was especially designed for the task of managing data, and it implements zero-touch administration. All policy information, logging, authentication and security, media management and object inventory is managed through this database. Most of the fields are made available through the Tivoli Storage Manager high-level administration commands, SQL SELECT statements or, for reporting purposes, by using an ODBC driver. For storing the managed data the Tivoli Storage Manager server software uses a storage repository, built from any combination of disk, optical, tape or robotic storage devices. These are locally connected to the TSM server system or are accessible through a SAN. The server software provides built-in drivers for more than 300 different device types from every major manufacturer. Within the storage repository the devices can operate stand-alone or be linked together to form one or more storage hierarchies. The storage hierarchy is not limited in the number of levels and may also span multiple servers using so-called virtual volumes. More information on this topic can be found 4.1.2.2, Storage and device concepts on page 50. 4.1.1.2 Backup/archive client The Tivoli Storage Manager client, included with the server program, provides the operational backup and archival function. The software implements a patented progressive backup methodology and unique record retention methods as described in 4.1.2.1, Backup, and archival concepts on page 48. All Version 3.7 and later backup/archive clients are implemented as multi-session clients, which enables them to exploit the multi-threading capabilities of modern operating systems in order to execute parallel backup and archive operations and thus maximize the throughput to the server system. In a Windows NT environment, the backup/archive client provides graphical, command line and Web browser interfaces (see Figure 12 on page 44). Particularly useful in a help desk scenario, the Web client interface offers a convenient way to perform backup, archive or recovery operations for a client system from a remote location.
43
Figure 12. Backup/archive client user interfaces
44
4.1.1.3 Administration For the central administration of one or multiple Tivoli Storage Manager instances, and the whole data management environment, Tivoli Storage Manager provides an administration client that may be controlled through either a command line or a Java-based interfaces. These are illustrated in Figure 13:
Figure 13. Tivoli Storage Manager administration interfaces
Using the unique enterprise administration feature, it is possible to configure, monitor and manage all server and client instances from one administrative interface, known as the enterprise console. It includes: Enterprise configuration This allows server configurations to be defined centrally by an administrator and then propagated to other servers. This significantly simplifies the configuration and management of multiple Tivoli Storage Manager servers in an enterprise.
45
Administrative command routing This allows administrators to issue administrative commands from one server and route them to other target servers. The commands are executed on the target servers, and the command output is returned and formatted on the server from which the command was issued. Central event logging functions. In an enterprise environment with multiple Tivoli Storage Manager servers, client and server events can be logged to a central management server through server-to-server communications, thereby enabling centralized event management and automation. 4.1.1.4 External interfaces Tivoli Storage Manager provides a data management application programming interface (API), which can be used to implement so-called application clients to integrate business applications such as database or groupware applications into the Tivoli Storage Management solution or to implement specialized clients for unique data management needs or non-standard computing environments. In general we distinguish between Tivoli Data Protection for application software products and the API exploitation through vendor applications. Tivoli Data Protection for applications are separate program products delivered by Tivoli to connect business applications to the Tivoli Storage Manager data management API. Such applications, which include, for example, Oracle, Lotus Notes, Microsoft Exchange, and Microsoft SQL server, usually have their own storage management interfaces. For more information see 4.3, Tivoli Data Protection for applications on page 55. Alternatively, there is a great number of vendor applications that exploit the Tivoli Storage Manager data management APIs by direct integration into their software product to implement new data management functions, or to provide backup and archival functionality on additional system platforms. Some examples are IBMs CommonStore for SAP/R3 data archival and IBM DB2 Universal Database. In addition to the interfaces to the server database described in 4.1.1.1, Tivoli Storage Manager server on page 43, Tivoli Storage Manager offers multiple interfaces for event logging, reporting and monitoring of the data management environment. In general, activities of the TSM server and client are logged in the server database and can be sent for reporting and monitoring purposes to external event receivers using an event filter mechanism. Potential event receivers include the Tivoli Enterprise framework, SNMP-based systems management software packages, the Windows NT event log and user-written applications. To integrate Tivoli Storage Manager storage management with external library management applications, Tivoli Storage Manager offers an external library manager interface. Using this interface it is possible to integrate the Tivoli Storage Manager server into third-party storage management environments. 4.1.1.5 Supported environment Tivoli Storage Manager server and client software is available on many different operating system platforms and can exploit several different communication protocols. Figure 14 gives a pictorial overview of the supported environment:
46
IBM*
DATA GENERAL DG/UX
DIGITAL OpenVMS (SSSI)*** UNIX
FUJITSU***
CRAY*** UNICOS
HEWLETTPACKARD HP-UX
AIX AS/400 OS/2
OS/2 Lan Server OS/2 Warp OS/390 UNIX System Services
AUSPEX**
APPLE Macintosh
MICROSOFT Windows 95 Windows 98 Windows NT Windows NT DEC Alpha
Linux DB2
INFORMIX
NCR UNIX SVR4
Tivoli Storage Manager client platforms

NEC EWS-UX/V
LOTUS NOTES
MICROSOFT Exchange Server SQL Server ORACLE Oracle7 EBU Oracle8 RMAN SAP R/3 SYBASE TANDEM GUARDIAN (ETI)*** SCO PYRAMID Unix 386 NILE Open Desktop Open Server
NOVELL NETWARE
VM OS/2 OS/400 MVS AIX
SEQUENT PTX SILICON SUN MICROSYSTEMS GRAPHICS IRIX Solaris

SIEMENS NIXDORF SINIX SINIX Reliant UNIX SINIX 386/486
Tivoli Data Protection for application Family:

Lotus Domino Lotus Notes Oracle Microsoft SQL Server Microsoft Exchange Informix SAP R/3
Solaris HP-UX
Tivoli Storage Manager also supports:

IBM DB2 Sybase
Tivoli Storage Manager server platforms
Windows NT
Disk
Optical
Tape
Storage Hierarchy
Figure 14. Tivoli Storage Manager supported environment
Information about supported environments can be found at the Tivoli Storage Manager home page at: http://www.tivoli.com/products/index/storage_mgr/ Table 14 below lists the three different Intel-based system TSM clients that are available:
Table 14. Version 3.7 PC clients
TSM PC Client Platforms Novell NetWare Microsoft Windows (Intel) Microsoft Windows (Alpha)
Operating Systems 3.12, 3.20, 4.11, 4.20, 5.0 Windows NT 4.0, Windows 95, Windows 98, Windows 20001 Windows NT 4.0
47
4.1.2 Base concepts

Tivoli Storage Manager implements data and storage management functions using its client and server software as discussed in the preceding sections. Nevertheless, the paradigms for providing these base functions are slightly different from those of other backup/archive applications. This section gives a high-level introduction to the base data and storage management mechanisms used by Tivoli Storage Manager. We will cover data backup, record retention, storage management, policies, and security. 4.1.2.1 Backup, and archival concepts Backup means creating an additional copy of a data object to be used for recovery if the working copy is lost. A data object can be a file, a raw logical volume, or a user-defined data object such as a database table. The backup version of this data object is stored separately, in the Tivoli Storage Manager server storage repository. Potentially, you can make several backup versions of the data, each version being a copy at a different point-in-time. These versions are closely tied together and related to the original object as a group of backups. If the master data object is invalid or lost, restoration is the process of using a backup version of the data to recreate a new working copy. The most current version of the data would normally be used, but you can restore from any of the existing backup versions. TSM allows you to control the number of backup versions maintained by the system. Old backup versions may be automatically deleted as new versions are created. You may also stipulate that they be deleted after a certain period of time has elapsed. For file level based backup, the main difference from many other backup applications is that Tivoli Storage Manager uses a progressive backup methodology. As indicated in Figure 15 on page 49, Tivoli Storage Manager operates with incremental backups after it has created a copy of all files. As a consequence, only those files that have been changed since the last backup will be backed up.
48
Full+Incremental Backup
Backup cycle
Full Backup Incremental Incremental Incremental
Full+Differential Backup
Progressive Backup Methodology
#1 #2 #3 #4
Full Backup Differential Differential Differential
#1 #2 #3 #4
Base Backup Incremental Incremental Incremental
#1 #1 #1 #1 #2 #2 #2
Data and tape consolidation

New full backup
#7*
New full backup
#7*
server internal tape reorganisation
#1
#2
Point-in-time** restoration of all data

Full backup & 3 incrementals
#1... #4
Full backup & 1 Differential
#1 #4
Point-in-time data only
#1
#2
* assuming 5 incrementals between full backups, ** after the 3rd incremental
Figure 15. Progressive backup methodology compared with other backup schemes
The reorganization of the physical storage media to store each clients data physically together on a small number of media, in order to provide faster access in the case of a complete system recovery, is done transparently to the client. This process is completely automated on the server using data meta-information stored in the TSM server database. If we compare this file level backup methodology with others such as the Full+Incremental or Full+Differential schemes shown in Figure 15, the advantage of Tivoli Storage Managers method is to prevent backups of unchanged data (unnecessary backups) when we wish to reduce and consolidate the recovery tape set. This also includes a more efficient use of storage resources by not storing redundant data, as for differential backups, and a faster recovery by not restoring multiple versions of the same file, as occurs when incremental backups are restored. Tivoli Storage Manager allows the creation of a complete set of client files (a backup set) on the server system using the most recent backup versions stored in the server storage repository. These backup sets can be used to retain a snapshot of all client files for a longer period of time for archival purposes, or for LAN-free recovery of a client system by copying this backup set to portable media and restoring them locally. Archiving a file with Tivoli Storage Manager means creating a copy of the file as a separate entity in the storage repository, to be retained for a specific period of time. Typically you would use this function to create an additional copy of data to be preserved for posterity. Vital records (data that must be kept for legal or other business reasons) are likely candidates for the archive process. When the archive copy of data has been created on the server, you can delete the original copy. Thus you can use archive to free up disk space on the Tivoli Storage Manager
49
client. However, archive should not be thought of as a complete space management function, because automatic recall is not available. Archived data is accessed by using the retrieve function to return it to the Tivoli Storage Manager client. To locate the archived data within the storage repository, Tivoli Storage Manager allows you to add a description to the data and to compose what is termed an archive package. Using a search engine and the server database, the description can be used as a target for a search to determine which data to retrieve. In summary, the difference between backing up and archiving is that backing up creates and controls multiple backup versions that are directly attached to the original file, whereas archiving creates an additional file that is normally kept for a specific period of time, as in the case of vital records. 4.1.2.2 Storage and device concepts All the Tivoli Storage Manager client data is stored in the TSM storage repository, which can consist of different storage devices, such as disk, tape, or optical devices, and controlled by the Tivoli Storage Manager server program. To do so, Tivoli Storage Manager uses its own model of storage (see Figure 16 below) to view, classify, and control these storage devices, and to implement its storage management functionality. The main difference between the storage management approach of Tivoli Storage Manager and other commonly used systems is that TSM storage management concentrates on managing data objects instead of managing and controlling backup tapes. Data objects can be files, directories or raw logical volumes that are backed up from the client systems. They can be objects such as tables or records from database applications, or simply a block of data that a client system wants to store on the server.
Client System
Storage Repository Storage Pool Volume

WAN, LAN, SAN
Device Class Storage Pool Storage Pool

Migrate & colocate
Server System
Copy
Data Object
Relocate
Storage Pool Device Class Storage Hicharchy
Figure 16. Tivoli Storage Manager storage management concept
50
To store these data objects on storage devices and to implement storage management functions, Tivoli Storage Manager defines logical entities to classify the available storage resources. Most important is the logical entity called a storage pool. A storage pool describes a storage resource for one single type of media, for example, a disk partition or a set of tape cartridges. Storage pools are places where data objects are stored. A storage pool is built up from one or more storage pool volumes. For example, in the case of a tape storage pool, this would be a single physical tape cartridge. To describe the methods by which Tivoli Storage Manager can access those physical volumes to place the data objects on them, Tivoli Storage Manager has another logical entity called a device class. A device class is connected to a storage pool and describes how volumes of this storage pool can be accessed. Tivoli Storage Manager organizes storage pools in one or more hierarchical structures. A storage hierarchy can span over multiple server instances and is used to implement management functions to migrate data objects automatically, that is, without client intervention, from one storage hierarchy level to another; or in other words, from one storage device to another. This function may be used, for example, to cache backup data (for performance reasons) onto a Tivoli Storage Manager servers disk space before moving the data to tape cartridges. The actual location of a data object is tracked within the server database. Also, Tivoli Storage Manager has implemented storage management functions for moving data objects from one storage volume to another. As discussed in the previous section, Tivoli Storage Manager uses the progressive backup methodology to back up file level data to the Tivoli Storage Manager storage repository. The reorganization of the data and storage media for fast recovery happens completely within the server. For this purpose, Tivoli Storage Manager implements functions to relocate data objects from one volume to another and to co-locate data objects that belong together, either at the client system level or at the data group level. Another important storage management function implemented within the Tivoli Storage Manager server is the ability to copy data objects asynchronously and to store them in different storage pools or on different storage devices, local at the server system or on another server system. It is especially important for disaster recovery solutions to have a second copy of data available somewhere in a secure place. This function is fully transparent to the client, and can be performed automatically within the Tivoli Storage Manager server. 4.1.2.3 Policy concepts Basically, a data storage management environment consists of three types of resources: client systems, rules, and data. The client systems contain the data to be managed, and the rules specify how the management must occur. In the case of backup, for example, rules determine how many versions should be kept, where they should be stored, and so on. Tivoli Storage Manager policies define the relationships between these three resources. Figure 17 illustrates these policy-based relationships. Depending on your specific needs for managing your enterprise data, these policies can be very simple or very complex.
51
Policy set Copy group Rules Nodes Machines Policy domain Copy group Rules Management class Data Management class Data Management class Data
Copy group Rules
Figure 17. Policy relationships and resources
Tivoli Storage Manager has logical entities that group and organize the storage resources and define relationships between them. Client systems, or nodes in Tivoli Storage Manager terminology, are grouped together with other nodes needed by the same storage management into a policy domain. The policy domain links the nodes to a policy set, a collection of storage management rules for different storage management activities. A policy set consists of one or more management classes. A management class contains the rule descriptions called copy groups, and links these to the data objects to be managed. A copy group is the place where all the storage management parameters, such as the number of stored copies, the data retention period, the storage media, and so on, are defined. When data is linked to particular rules, it is said to be bound to the management class that contains those rules. Another way to look at the components that make up a policy is to consider them in the hierarchical fashion in which they are defined. That is, think of the policy domain as containing the policy set, the policy set as containing the management classes, and the management classes as containing the copy groups and the storage management parameters. 4.1.2.4 Security concepts Because the storage repository of Tivoli Storage Manager is the place where the important data of an enterprise is stored and managed, security is of vital concern for Tivoli Storage Manager. To ensure that data can only be accessed from the owning client or an authorized party, Tivoli Storage Manager implements a mutual suspicion algorithm for authentication purposes, which is similar to the methods used by Kerberos authentication. Whenever a client (backup/archive as well as administrative) wants to communicate with the server, an authentication has to take place. This authentication contains both-sides verification, which means the client has to
52
authenticate itself to the server, and the server has to authenticate itself to the client. To do this, all clients have a password, which is stored at the server side as well as at the client side. In the authentication dialog, these passwords are used to encrypt the communication. The passwords will not be sent over the network, to prevent hackers from intercepting them. Only if both sides are able to decrypt the dialog will a communication session be established. If the communication has ended, or if a timeout period without activity is passed, the session will be automatically terminated and a new authentication will be necessary.
4.2 Tivoli Storage Manager complementary products

Tivoli Storage Manager complementary products using the Tivoli Storage Manager server software package as a backbone product to implement additional data and storage management functions. The following section introduces Tivoli Space Manager for hierarchical space management, Tivoli Disaster Recovery Manager as an enterprise-wide solution for disaster recovery and Tivoli Decision Support for Storage Management Analyses to provide a comprehensive reporting and monitoring solution to plan the growth and collect vital management information for an efficient enterprise data management deployment.
4.2.1 Tivoli Space Manager

Tivoli Space Manager uses the framework services of Tivoli Storage Manager in combination with the industry-standard Data Management Application Programming Interface (DMAPI) to deliver a fully integrated solution for open systems hierarchical storage management (HSM).Tivoli Space Manager provides an HSM client, which interfaces with DMAPI and implements the functionality outlined in Figure 18:
E RAT MIG
SERVER
LL CA RE
DB
AGENT
Migrates Inactive Data Transparent Recall Policy Managed Integrated with Backup
Cost/Disk Full Reduction
Figure 18. Hierarchical space management
53
Tivoli Space Manager maximizes usage of existing storage resources by transparently migrating data off workstation and file server hard drives based on size and age criteria to the Tivoli Storage Manager repository. When migrated data is accessed, Tivoli Space Manager transparently recalls the data back onto the local disk. The migration of files and the management of migrated files is controlled by policies. Users may also initiate migration and recall. Tivoli Space Managers HSM function is fully integrated with Tivoli Storage Manager operational backup. It is possible to specify that a file should not be migrated until there is a backup copy in the server storage repository. If a file is migrated and then a backup is done the next day, Tivoli Storage Manager copies the file in the storage repository and does not require a recall to the client system to back it up again, avoiding multiple transfers of the same file across the network.
4.2.2 Tivoli Disaster Recovery Manager

Tivoli Disaster Recovery Manager coordinates and automates the process of recovering from a disaster. It integrates with Tivoli Storage Manager and the rest of the Tivoli data management portfolio to provide for off-site media management, automated restore and managed recovery. It complements the already robust protection features of Tivoli Storage Manager and automates many protection functions. Tivoli Disaster Recovery Manager automatically captures information required to recover the Tivoli Storage Manager server after a disaster. It assists in preparing a plan that allows recovery in the most expedient manner. This disaster recovery plan contains information, scripts, and procedures needed to automate server restoration, and helps ensure quick recovery of your data after a disaster. Also Tivoli Disaster Recovery Manager manages and tracks the movement of off-site media to reduce the time required to recover in the event of a disaster. It is able to track media that are stored on-site, in-transit, or off-site in a vault, no matter whether it is an manual or electronic vault, so your data can be easily located if disaster strikes. Client recovery information can be captured by Tivoli Disaster Recovery Manager to assist with identifying which clients need to be recovered, in what order, and exactly what is required to recover them.
4.2.3 Tivoli Decision Support for Storage Management Analysis

Tivoli Decision Support for Storage Management Analysis uses the framework services of Tivoli Decision Support to deliver important information to enable you to make considered decisions about your enterprise data management deployment. Tivoli Decision Support is a stand-alone product that provides a ready-to-use view into the data gathered by Tivoli enterprise products. The product consolidates this data and transforms it into accessible business-relevant information. This information, presented in a variety of graphical formats, can be viewed interactively (slice, dice, drill down, drill through), posted on a URL. Tivoli
54
Decision Support provides insight and the ability to better answer business-relevant information technology questions. The Tivoli Decision Support Discovery Guides are a set of best practices guides provided to assist in the use of the tool. To use these guides Tivoli Decision Support has to be installed and available. The Tivoli Decision Support for Storage Management Analysis is the guide used to produce the following analysis: Storage Event Analysis Storage Performance Analysis Capacity Analysis The information used by the guide is obtained directly from the Tivoli Storage Manager server through the ODBC interface. The information is then transferred to a relational database, which may be IBM DB2, Microsoft SQL, Oracle, or Sybase. The database can reside on the same system as Tivoli Storage Manager or Tivoli Decision Support or on a separate system. Queries to the database generate the Tivoli Decision Support reports.
4.3 Tivoli Data Protection for applications

Tivoli Data Protection for applications is a group of solutions to protect data used by business applications. They are interface programs that sit between a storage management API provided by the vendor application and the Tivoli Storage Manager data management API. Typical applications providing such interfaces are databases and groupware applications, such as Lotus Notes or Microsoft Exchange. Figure 19 shows Tivoli Data Protection for Lotus Domino as a typical example of the architecture and the data flow of a Tivoli Data Protection for application solution:
Domino R5 server
Transaction log
Tivoli Storage Manager server
Domino API
Domino R5 databases
TDP for Lotus Domino
TSM API
Figure 19. Tivoli Data Protection for Lotus Domino
The purpose of Tivoli Data Protection for applications solutions is to receive application backup-and-restore requests and to translate them into Tivoli Storage Manager backup-and-restore operations. The activity is always initiated from the
55
application. This means that backups and restores can also be performed while the application is online. It also means that only the level of data protection implemented in the applications storage management API can be guaranteed. For the latest information on Tivoli Data Protection solutions, check the following Tivoli Storage Management Web page: http://www.tivoli.com/products/solutions/storage/
4.4 Tivoli Data Protection for Workgroups

Tivoli Data Protection for Workgroups (TDPfW) provides complete disaster recovery for Windows NT 4.0. Using unique object replication technology from STAC, it backs up disk partitions to locally attached tape media. All disk contents with the exception of hidden system partitions, including partition information and boot records, are backed up while allowing full access to the disk. The backup can be controlled and scheduled with the Tivoli Data Protection (TDP) Administrative Tool. You can mount backup partitions as additional Windows NT partitions. TDPfW can be integrated with Tivoli Storage Manager using the TSM scheduler service and TSM event logging. To recover a Windows NT system, you use the three Windows NT boot diskettes, which are modified by TDPfW, an additional recovery disk and the backup tape. Full recovery can be achieved without the need for a Windows NT CD-ROM. TDPfW uses a label to identify tapes. If the backup data requires more than a single tape, multiple tapes can be used. You can stipulate that a backup job writes to a tape with a specific label to ensure that the correct media is used. Backed up data can overwrite or be appended to existing data on the tape. TDPfW is suitable for fast recovery of a Windows NT server.
4.5 Tivoli Data Protection for SAP R/3

Tivoli Data Protection for SAP R/3 was formally known as Backint for ADSM. Tivoli Data Protection is a certified backup solution for SAP R/3 with Oracle Database using the Backint interface of SAP. It integrates SAP R/3 backups into Tivoli Storage Manager. It supports several platforms including AIX 4.x, Solaris 2.5.1 and 2.6, and HP-UX 11.xx as well as Windows NT. Tivoli Data Protection for SAP R/3 architecture looks like this:
56
List of DB objects
BRBACKUP
Configuration File
SAP DBA
BRARCHIVE BRRESTORE
Profile
Database Utilities
Tivoli Data Protection for SAP R/3 PRO

Interface program
Tivoli Agent #2 Data Protection API
Backup/ Restore Server
Storage Media
ORACLE DB
Tivoli Agent #1 Data ProtectionClient API API API for SAP R/3 for SAP R/3 Tivoli for SAP R/3 TivoliData Protection TivoliDataProtection Data Protection API Client Client API Client for SAP R/3 API for SAP R/3 for SAP R/3 Tivoli Data Protection API Client Client API Client API Client for SAP R/3 Client Client
Tivoli for SAP R/3 TivoliData Protection Data Protection
Backup/ Restore Client
Communication Interface
SAP R/3 Database Server
Tivoli Storage Manager
Figure 20. Architecture of Tivoli Data Protection for SAP R/3
Tivoli Data Protection for SAP R/3 consists of two programs: Backint/ADSM PRO deals with the SAP backint interface and Backint/ADSM Agent deals with the TSM API client. In addition to these programs there are the following files: init<DBSID>.utl This is the configuration file for Tivoli Data Protection for SAP R/3 which is normally stored in the \orant\database\ directory. This file stores an encrypted password if you use manual password authentication with TSM server. It is also used to track the number of backup versions maintained.
init<DBSID>.bki
57
File
INIT<DBSID>.SAP
Parameter util_par_file
File
INIT<DBSID>.UTL
Parameter CONFIG_FILE Parameter SERVER
Same directory File

INIT<DBSID>.BKI
File
TSMSRV.OPT
Environment variable
DSMI_CONFIG
File
DSM.OPT
Contents ignored
Figure 21. Reference structure for Tivoli Data Protection for SAP R/3 and SAPDBA files
Tivoli Data Protection for SAP R/3 offers the following useful features: Fast null block compression Individual tablespace locking Multiple redo log copies Alternate backup paths Alternate backup servers Reporting for statistical purposes Tracing Multiplexing Detailed information about Tivoli Data Protection for SAP can be found in Program Description and Operations, SC33-6379. This book can be downloaded from: http://www.de.ibm.com/ide/dlindex.html
4.6 Tivoli Storage Manager and DB2 with SAP R/3

DB2 UDB has built-in functionality to back up to local attached tape drives. In order for other backup programs to support DB2, a plug-in is required. DB2 itself provides such a plug-in for Tivoli Storage Manager, which supports database backups using the TSM API client. At present, DB2 does not support parallel TSM sessions on Windows NT. There are plans to introduce this feature with a future release of the DB2 database product.
58
Archiving of offline logs is not integrated with the DB2 UDB tools. Each backup database or log has a unique filename for TSM, because a unique timestamp is added to the filename. SAP R/3 itself provides tools to support archiving of offline logs to local attached tape drives or to TSM. The tools for archiving DB2 logs are: brarchive brrestore db2adutl This utility backs up the offline redo logs. This utility restores the offline redo logs. This utility can query and delete database backups. It also can download them or copy them to hard disk. This is a standard DB2 utility located in \sqllib\misc. This utility can query log files in TSM. This utility can delete log files in TSM.
brdb6qry <SID> brdb6dsd
To recover the administration database from the R/3 database, you can use the sdd6mir command.
4.7 Tivoli Data Protection for Microsoft SQL Server

Tivoli Data Protection for Microsoft SQL Server (TDPSQL) enables the integration of Microsoft SQL Server with Tivoli Storage Manager for backup and recovery of SQL Server databases and transaction logs. TDPSQL runs on Windows NT 4.0 and Windows 2000 and currently supports SQL Server 6.5 and SQL Server 7.0. For SQL Server 7.0, SP1 must be applied. TDPSQL has the following features and restrictions: Performs full database backups Performs incremental transaction log backups Does not yet support differential database backups Deletes a SQL database backup from TSM storage Back up to different TSM servers using a simple drag-and-drop interface Performance optimization Automated scheduled backups Automated deletion of old backups Supports SQL databases in a Microsoft Cluster Server environment
SQL Server
SQL DB-LIB
SQL Application Client
TSM API
TSM Server
Figure 22. Overview of SQL Application Client Operating environment
An SQL Server 7.0 full database backup records all database and transaction log data up to the time when the operation completes. In contrast, an SQL Server 6.5 full database backup only records database and transaction log data that existed at the time the backup began. Data that is modified during the backup is not backed up.
59
TDPSQL can use the Virtual Device Interface (VDI), which is a high-performance alternative to the named pipe interfaces used with earlier versions. The VDI is automatically used if TDPSQL detects that SQL Server 7.0 is installed. Some additional things to consider when using TDPSQL are: When you run TDPSQL in an MSCS environment you have to install TDPSQL on both nodes. TDPSQL uses a TSM backup copy group for storing SQL Server data. You can have only one backup-and-restore session per database. Support for parallel backup sessions is anticipated in a future release of the software. We recommend that you use collocation for sequential media pools
60
Part 2. Implementation with Tivoli Storage Manager
61
62
Chapter 5. Tivoli Storage Manager setup and configuration

In Part 1 of this book we looked at some of the concepts behind backup and restore, with particular emphasis on the issues arising in an SAP R/3 environment. Now we move on to examine implementation details for practical SAP R/3 installations, using Tivoli Storage Manager (TSM) as the backup software. Many of the techniques discussed, however, can be utilized if you have selected other backup products. This chapter focuses on the setup of Tivoli Storage Manager itself. The following chapters scrutinize the implementation of backup systems for SAP R/3 with each of the major databases. Depending on which database your installation uses, please refer to one of the following: Chapter 6, Oracle-based systems on page 77 Chapter 7, IBM DB2-based systems on page 99 Chapter 8, Microsoft SQL Server-based systems on page 119 For those of you that have implemented a clustered SAP R/3 installation, we have included a chapter to illustrate our recommended way of backing up such systems. Our example uses the Oracle database, but the principles can be applied generally (see Chapter 9, MSCS environments: an Oracle-based example on page 137).
5.1 TSM server setup

In this section we examine the necessary steps required to configure Tivoli Storage Manager to back up SAP R/3 running on Windows NT. We do not describe the installation of the TSM product, since this is outside the scope of this book. For more information on using TSM, we recommend Windows NT Backup and Recovery with ADSM, SG24-2231 (ADSTAR Distributed Storage Manager, or ADSM, is the name by which TSM was previously known). The configurations we use in this chapter use policies suitable for SAP R/3 installations. Different policies may be applicable for other environments.
5.1.1 General prerequisites

We assume that you have already installed the Tivoli Storage Manager (TSM) server software. The installation process is straightforward, using the familiar installation wizard technology found in many Windows NT applications. Our starting point for the discussion that follows therefore assumes that the steps below have been completed: Installation of the Tivoli Storage Manager server software and the latest product program temporary fixes (PTFs). Configuration of the TSM server option file. Initial space for the TSM database and recovery log volume has been created. The TSM server license has been registered. The tape library, drives and device class have been configured. The default storage pool has been configured. The default policy has been configured. 63
Backup and recovery procedures for the TSM database have been established.
Note
You will find the latest code fixes (PTFs) for TSM on this FTP server: ftp://index.storsys.ibm.com
Following a brief introductory discussion, the remainder of this chapter describes setting up Tivoli Storage Manager for each of the three databases covered in this book: 5.2.1, TSM policy and storage configuration for Oracle on page 64. 5.2.2, TSM policy and storage configuration for DB2 on page 68. 5.2.3, TSM policy and storage configuration for MS SQL Server on page 72.
5.2 A practical implementation

For the purpose of writing this book, we set up a number of different SAP R/3 environments which are described in the following sections and chapters. For each of these systems we used the same backup storage device: an IBM 3447 DLT tape library with two DLT 7000 tape drives. This tape library was connected to a Tivoli Storage Manager server, based on an IBM Netfinity 5000 with four internal 9 GB disk drives. Tivoli Storage Manager offers a number of different ways to configure your backup storage devices. These include a graphical user interface wizard, a command line interface and access through a Web browser. For our examples, we chose to use the command line interface.
Information about screen captures in this chapter
In the screen shots used in this chapter, many commands are preceded by the Tivoli Storage Manager command prompt. TSMSRV was the name of our TSM server, so our TSM prompt was: tsm: TSMSRV> The other commands are invoked from the Windows NT command line and follow the normal Windows NT command prompt, shown as D:\> (for example) for clarity, but in practice this would reflect the path for the utilities of the TSM server, which in our case was D:\program files\tivoli\tsm\utils. Commands that are too long for a single line are continued on the following line or lines. This is indicated by the continuation character: \
5.2.1 TSM policy and storage configuration for Oracle

Figure 23 illustrates the way we chose to set up the policy domain, policy set, management classes, and device classes within the TSM server for an SAP R/3 system using the Oracle database. These definitions provide a path to the backup devices available to the backup server for the various data elements within the SAP system. For example, the DATA management class is defined to copy 64
backup data to disk devices, migrating the backed up data to tape when directed to do so by a command. In contrast, the DB management class directs backup data directly to tape. Each file is associated with a management class. The copy groups that belong to a management class define how many versions of a file are maintained in the case of a backup copy group, or for how long archive copies are kept in the case of an archive copy group. Backup scheduling defines which data is backed up and at what time. This is controlled by the TSM central scheduler. The following sections describe the process of defining these backup resources.
Policy domain R3 Policy set R3 Management class DATA Backup copy group
verdeleted=3 verexists=3 retextra=360 retonly=360 destination=R3_DISK
Device class DISK

Storage pool R3_DISK
Volume
Volume
Migrate storage pool command
Device class 3447

Storage pool R3_TAPE
Archive copy group

destination=R3_DISK
IBM 3447 DLT Library

Volume Volume Library 3447
Management class DB Archive copy group

retver=NOLimit destination=R3_DB Storage pool R3_DB Drive1 Volume Volume Drive2
Management class LOG1 Archive copy group retver=NOLimit

destination=LOG1 Volume Volume Storage pool R3_LOG1
Management class LOG2 Archive copy group

retver=NOLimit destination=LOG2 Storage pool R3_LOG2
Volume
Volume
Figure 23. TSM policy configuration for SAP R/3 with Oracle
5.2.1.1 Storage devices and device class definition We first define a device class through which TSM can communicate with the backup hardware. To define a device class in TSM, follow these steps:
65
1. First we define the library, which may contain one or more drives:
tsm: TSMSRV> define library 3447 libtype=3447 device=lb6.0.0.1
Note
You can find device names (such as lb6.0.0.1 in the above command) by looking at the list of available devices using the TSM server utilities. 2. Now we assign the drives to the library:
tsm: TSMSRV> define drive 3447 drive_a device=mt3.0.0.1 element=116 tsm: TSMSRV> define drive 3447 drive_b device=mt4.0.0.1 element=117
Note
Device names for the tape drives can also be found by using the TSM server utilities. Element numbers are found in Properties for the relevant library. 3. Then we define a device class for the library:
tsm: TSMSRV> define devclass 3447dev devtype=dlt format=dlt35c mountlimit=2 4. Finally, we label the DLT tape cartridges we will use with the IBM 3447 library:
D:\> dsmlabel -drive=mt3.0.0.1,116 -drive=mt4.0.0.1,117 -library=lb6.0.0.1 \ -search=yes -keep
5.2.1.2 Storage pool and volume definition Now that our devices are defined, we define the storage pools and volumes used to hold our invaluable backup data: 1. To begin, we define the storage pools:
tsm: tsm: tsm: tsm: tsm:
TSMSRV> TSMSRV> TSMSRV> TSMSRV> TSMSRV>
define define define define define
stgpool stgpool stgpool stgpool stgpool
r3_log1 3447dev maxscratch=2 r3_log2 3447dev maxscratch=2 r3_db 3447dev maxscratch=5 r3_data 3447dev maxscratch=2 r3_disk disk nextpool=r3_data
2. Before we can define the storage pool volumes for the r3_disk pool, we have to format the data files. We chose to use drives E: and H: for r3_disk.
D:\> dsmfmt -data e:\data1 2000 D:\> dsmfmt -data h:\data1 2000
66
3. Now we can define the volumes for the r3_disk pool:
tsm: TSMSRV> define volume r3_disk e:\data1 tsm: TSMSRV> define volume r3_disk h:\data1 4. Each tape cartridge in the library has to be made available to Tivoli Storage Manager using the checkin command. The library can differentiate between tapes by scanning the barcode label found on each cartridge.
tsm: TSMSRV> checkin libvol 3447 ... status=scratch In the above command, the ellipsis (...) is replaced by the name of the specific cartridge being checked into the library. 5.2.1.3 Policy definition Our last step to complete the setup of Tivoli Storage Manager for our SAP R/3 with Oracle environment is to define the policy. Here is how we did it: 1. First we define the policy domain:
tsm: TSMSRV> define domain r3 2. And the policy set:
tsm: TSMSRV> define policyset r3 r3 3. Next we define the management classes for our data files:
tsm: TSMSRV> define mgmtclass r3 r3 data 4. Our database files:
tsm: TSMSRV>define mgmtclass r3 r3 db 5. Our database log files:
tsm: TSMSRV> define mgmtclass r3 r3 log1 6. And for our database mirrored log files:
tsm: TSMSRV> define mgmtclass r3 r3 log2 7. Then we define the copy groups. First for the logs:
tsm: TSMSRV> define copygroup r3 r3 log1 type=archive dest=r3_log1 retver=NOLimit
67
8. Then for mirrored logs:
tsm: TSMSRV> define copygroup r3 r3 log2 type=archive dest=r3_log2 retver=NOLimit 9. For the database:
tsm: TSMSRV> define copygroup r3 r3 db type=archive dest=r3_db retver=NOLimit 10.And the last two copy groups, which are for data:
tsm: TSMSRV>define copygroup r3 r3 data type=archive dest=r3_disk tsm: TSMSRV> define copygroup r3 r3 data type=backup dest=r3_disk \ verdeleted=3 verexists=3 retextra=360 retonly=360 11.We complete the definitions by assigning a default management class:
tsm: TSMSRV> assign defmgmtclass r3 r3 data 12.Finally we validate and then activate the SAP R/3 policy set:
tsm: TSMSRV> validate policyset r3 r3 tsm: TSMSRV> activate policyset r3 r3
5.2.2 TSM policy and storage configuration for DB2

The diagram in Figure 24 below illustrates the way we chose to set up the policy domain, policy set, management classes, and device classes within the TSM server for an SAP R/3 system using the IBM DB2 database. These definitions provide a path to the backup devices available to the backup server for the various data elements within the SAP system. Each file is associated with a management class. The copy groups which belong to a management class define how many versions of a file are maintained in the case of a backup copy group, or for how long archive copies are kept in the case of an archive copy group. Backup scheduling is controlled by the TSM central scheduler. The following sections describe the process of defining these backup resources.
68
Policy domain R3DB2 Policy set R3DB2 Management class DATA Backup copy group
verdeleted=3 verexists=3 retextra=360 retonly=360 destination=R3_DISK
Device class DISK

Volume
Volume
Device class 3447

Archive copy group

destination=R3_DISK

Management class DB2_DB Backup copy group

verdeleted=0 destination=R3_DB Storage pool R3_DB Drive1 Volume Volume
Backup storage pool command
Drive2
Management class DB2_LOG Archive copy group

retver=28 destination=R3_LOG Storage pool R3_LOG Storage pool R3_LOGC
Volume
Volume
Volume
Volume
Figure 24. TSM policy configuration for SAP R/3 with DB2
5.2.2.1 Storage devices and device class definition We first define a device class through which TSM can communicate with the backup hardware. To define a device class in TSM follow these steps: 1. First we define the library that may contain one or more drives:
Note
69
Note
D:\> dsmlabel -drive=mt3.0.0.1,116 -drive=mt4.0.0.1,117 -library=lb6.0.0.1 \ -search=yes -keep 5.2.2.2 Storage pool and volume definition Now that our devices are defined, we define the storage pools and volumes used to hold our invaluable backup data: 1. To begin, we define the storage pools:
r3_log 3447dev maxscratch=2 r3_logc 3447dev pooltype=copy maxscratch=2 r3_db 3447dev maxscratch=5 r3_data 3447dev maxscratch=2 r3_disk disk nextpool=r3_data
2. Before we can define the storage pool volumes for the r3_disk pool, we have to format the data files. We choose to use drives e: and h: for r3_disk.
D:\> dsmfmt -data e:\data1 2000 D:\> dsmfmt -data h:\data1 2000 3. Now we can define the volumes for the r3_disk pool:
tsm: TSMSRV> checkin libvol 3447 ... status=scratch In the above command, the ellipsis (...) is replaced by the name of the specific cartridge being checked in to the library.
70
5.2.2.3 Policy definition Our last step to complete the setup of Tivoli Storage Manager for our SAP R/3 with IBM DB2 environment is to define the policy. Here is how we did it: 1. First we define the policy domain:
tsm: TSMSRV> define domain r3db2 2. And the policy set:
tsm: TSMSRV> define policyset r3db2 r3db2 3. Next we define the management classes for our data files:
tsm: TSMSRV> define mgmtclass r3db2 r3db2 data 4. Our database files:
tsm: TSMSRV> define mgmtclass r3db2 r3db2 db2_db 5. And for our database log files:
tsm: TSMSRV> define mgmtclass r3db2 r3db2 db2_log 6. Then we define the copy groups. First for the archive copy group for logs:
tsm: TSMSRV> define copygroup r3db2 r3db2 log type=archive dest=r3_log retver=28 7. Then the backup copy group for the database:
tsm: TSMSRV> define copygroup r3db2 r3db2 db type=backup dest=r3_db verdeleted=0 8. And the last two copy groups are a backup copy group for normal files:
tsm: TSMSRV> define copygroup r3db2 r3db2 data type=backup dest=r3_disk \ verexists=3 verdeleted=3 retextra=360 retonly=360 9. And an archive copy group for normal files:
tsm: TSMSRV> define copygroup r3db2 r3db2 data type=archive dest=r3_disk 10.We complete the definitions by assigning a default management class:
tsm: TSMSRV> assign defmgmtclass r3db2 r3db2 data
71
11.To finish, we validate and then activate the SAP R/3 policy set:
tsm: TSMSRV> validate policyset rdb23 r3db2 tsm: TSMSRV> activate policyset r3db2 r3db2 12.And define an administrative schedule which copies the primary storage pool log to the copy storage pool logc:
tsm: TSMSRV> define schedule copy_db2_log \ cmd=backup stgpool r3_log r3log1 \ active=yes \ starttime=01:00:00 \ duration=5 \ durunits=minutes \ period=1 \ perunits=hours \ dayofweek=weekday
5.2.3 TSM policy and storage configuration for MS SQL Server

The diagram in Figure 25 illustrates the way we chose to set up the policy domain, policy set, management classes, and device classes within the TSM server for an SAP R/3 system using the SQL Server database. These definitions provide a path to the backup devices available to the backup server for the various data elements within the SAP system. Each file is associated with a management class. The copy groups that belong to a management class define how many versions of a file are maintained in the case of a backup copy group, or for how long archive copies are kept in the case of an archive copy group. Backup scheduling is controlled by the TSM central scheduler. The following sections describe the process of defining these backup resources.
72
Policy domain R3SQL Policy set R3SQL Management class DATA Backup copy group
verdeleted=3 verexists=3 retextra=360 retonly=360 desination=R3_DISK
Device class DISK

Volume
Volume
Device class 3447

Archive copy group

desination=R3_DISK

Management class SQL_DB Backup copy group

verdeleted=0 desination=R3_DB Storage pool R3_DB Drive1 Volume Volume
Backup storage pool command
Drive2
Management class SQL_LOG Backup copy group

verdeleted=0 desination=R3_LOG Storage pool R3_LOG Storage pool R3_LOGC
Volume
Volume
Volume
Volume
Figure 25. TSM policy configuration for SAP R/3 with SQL Server
5.2.3.1 Storage devices and device class definition We first define a device class through which TSM can communicate with the backup hardware. To define a device class in TSM follow these steps: 1. First we define the library, which may contain one or more drives:
Note
73
Note
D:\> dsmlabel -drive=mt3.0.0.1,116 -drive=mt4.0.0.1,117 -library=lb6.0.0.1 \ -search=yes -keep
5.2.3.2 Storage pool and volume definition Now that our devices are defined, we define the storage pools and volumes used to hold our invaluable backup data: 1. To begin, we define the storage pools:
r3_log 3447dev maxscratch=2 r3_logc 3447dev pooltype=copy maxscratch=2 r3_db 3447dev maxscratch=5 r3_data 3447dev maxscratch=2 r3_disk disk nextpool=r3_data
2. Before we can define the storage pool volumes for the r3_disk pool, we have to format the data files. We choose to use drives e: and h: for r3_disk.
D:\> dsmfmt -data e:\data1 2000 D:\> dsmfmt -data h:\data1 2000 3. Now we can define the volumes for the r3_disk pool:
tsm: TSMSRV> checkin libvol 3447 ... status=scratch In the above command, the ellipsis (...) is replaced by the name of the specific cartridge being checked in to the library.
74
5.2.3.3 Policy definition Our last step to complete the setup of Tivoli Storage Manager for our SAP R/3 with SQL Server environment is to define the policy. Here is how we did it: 1. First we define the policy domain:
tsm: TSMSRV> define domain r3sql 2. And the policy set:
tsm: TSMSRV> define policyset r3sql r3sql 3. Next we define the management classes for our data files:
tsm: TSMSRV> define mgmtclass r3sql r3sql data 4. Our database files:
tsm: TSMSRV> define mgmtclass r3sql r3sql sql_db 5. And for our database log files:
tsm: TSMSRV> define mgmtclass r3sql r3sql sql_log 6. Then we define the copy groups. First for the logs:
tsm: TSMSRV> define copygroup r3sql r3sql log type=backup dest=r3_log verdeleted=0 7. Then for the database:
tsm: TSMSRV> define copygroup r3sql r3sql db type=backup dest=r3_db verdeleted=0 8. And the last two copy groups that are for normal files:
tsm: TSMSRV> define copygroup r3sql r3sql data type=archive dest=r3_disk tsm: TSMSRV> define copygroup r3sql r3sql data type=backup dest=r3_disk \ verexists=3 verdeleted=3 retextra=360 retonly=360 9. We complete the definitions by assigning a default management class:
tsm: TSMSRV> assign defmgmtclass r3sql r3sql data
75
10.To finish, we validate and then activate the SAP R/3 policy set:
tsm: TSMSRV> validate policyset r3sql r3sql tsm: TSMSRV> activate policyset r3sql r3sql 11.And define an administrative schedule that copies the primary storage pool log to the copy storage pool logc:
tsm: TSMSRV> define schedule copy_sql_log \ cmd="backup stgpool r3_log r3logc" \ active=yes \ starttime=01:00:00 \ duration=5 \ durunits=minutes \ period=1 \ perunits=hours \ dayofweek=weekday
76
Chapter 6. Oracle-based systems

This chapter takes you through the steps we recommend to implement backup-and-recovery processes for SAP R/3 4.5B using the Oracle database. The information you will find here is based on an actual SAP R/3 backup system. We installed several complete SAP R/3 systems in our laboratory during the writing of this book. This allowed us to test and validate what we wanted to say so that we could be sure the information is accurate and up-to-date. We give specific details of the hardware and software configurations we used, which should help you to implement your own solutions simply and quickly. We begin by examining the hardware configuration and then move on to look at the way in which the various software components are related to each other. Each component is installed and configured to complete the backup solution. The chapter closes by illustrating possible backup and recovery processes with sample batch command files.
In the screen captures used in this chapter, many commands are preceded by the Tivoli Storage Manager command prompt. TSMSRV was the name of our TSM server, so our TSM prompt was: tsm: TSMSRV> The other commands are invoked from the Windows NT command line and follow the normal Windows NT command prompt, shown as D:\> (for example) for clarity, but in practice this would depend on the prompt setting for the system. Commands that are too long for a single line are continued on the following line or lines. This is indicated by the continuation character: \.
6.1 Installation and configuration

In our laboratory, we installed a number of SAP R/3 systems. For this particular example, we used a Netfinity 7000 M10 to run both the Oracle database and SAP application servers in a two-tier configuration. Most SAP installations are two-tier so this represents the majority of real-life situations. Backing up the database is the most complex part of the backup solution, so extending our example to a three-tier installation is straightforward. The SAP server was configured with both internal SCSI disks and an external Fibre Channel array of disks. For the Tivoli Storage Manager server, we used a Netfinity 5000 server connected to a 3447 DLT tape library with two physical tape drives. The servers were connected together using a 100 Mbps Ethernet network, which was also the network used for client access to the servers. Figure 26 below illustrates our configuration and provides information about the various adapters we used and where they were installed in each server:
77
SAP R/3 system Netfinity 7000 M10 2 x 9 GB disks 1
TSM server and domain controller Netfinity 5000 2 x 9 GB disks 5
100 Mbps Ethernet
3447 2 x DLT tape drives Fibre Channel hubs
Fibre Channel RAID control unit with redundant controller
EXP15 disk enclosure 10 x 9 GB disks
Tape library KEY 1 ServeRAID-3L (slot 2 driving internal disks) 2 Fibre Channel adapter (slot 1) 3 Fibre Channel adapter (slot 6) 4 Etherjet adapter (slot 12) 5 ServeRAID-3H (slot 1 driving internal disks) 6 Onboard Ethernet adapter 7 Onboard SCSI-2 F/W adapter driving tape
Figure 26. Backup solution hardware for SAP R/3 using Oracle
Further hardware details that are relevant are: The BIOS of the Netfinity 7000 M10 we used was at Release 5. The ServeRAID-3L adapter we used to drive the local disks in the SAP server was at BIOS and firmware level 3.50C. RAID adapter parameters were set to their default values. The ServeRAID-3L was configured with a single RAID-1 array (A), comprising two 9 GB disks, and providing a total capacity of 9 GB. The array was set up as three RAID logical drives as shown in Table 15:
Table 15. ServeRAID configuration for SAP R/3 using Oracle
Logical drive 0 1 2
Write policy Write through Write through Write through
Capacity 2 GB 2 GB 4.7 GB
Disk label c_sosnt d_nt e_page
Drive letter C: D: E:
78
Note
IBMs ServeRAID adapters provide the ability to back up your RAID configuration data to diskette. We strongly recommend that you take advantage of this feature. You can use this to recover your ServeRAID configuration in case of hardware failure. If your ServeRAID adapter has battery-backed up cache, you can set the adapters write policy to write-back, which will boost disk subsystem performance. Our Fibre Channel disk subsystem used the following software levels: Netfinity Fibre Channel PCI Adapter BIOS version: Netfinity Fibre Channel RAID support firmware: 1.35 3.01.01.00
Netfinity Fibre Channel PCI Adapter Windows NT 4.0 driver:6.16 SYMplicity Storage Manager release: 06.22.25.15
Using the SYMplicity software, we configured our Fibre Channel RAID disk subsystem as follows:
Table 16. Fibre Channel configuration for SAP R/3 using Oracle
Drive group 1
LUN 0 4
RAID level 1 1 5 1 1
Capacity 1GB 2GB 26GB 2GB 9GB
Disk label q s_sap h_sapdata j_onlinelog i_offlinelog
Drive letter Q: S: H: J: I:
2 3 4
1 3 2
Note
For security, you should save your Fibre Channel configuration files to disk. The following table shows how we chose to distribute the SAP files within the system:
Table 17. File distribution for SAP R/3 using Oracle
Directory name \orant \oracle\PRD\sapdata1 \oracle\PRD\sapdata2 \oracle\PRD\sapdata3 \oracle\PRD\sapdata4 \oracle\PRD\sapdata5 \oracle\PRD\sapdata6
Drive letter D: H: H: H: H: H: H:
79
Directory name \oracle\PRD\saparch \oracle\PRD\sapbackup \oracle\PRD\sapcheck \oracle\PRD\sapreorg \oracle\PRD\saptrace \oracle\PRD\origloga \oracle\PRD\origlogb \usr\sap \usr\sap\trans
Drive letter I: I: I: I: I: J: J: S: S:
6.1.1 Software interdependencies

Figure 27 on page 81 shows the interdependencies between Oracle and Tivoli Storage Manager for SAP R/3. The diagram highlights the important files and environment variables that control the operation of the backup system, and illustrates the relationships among them. The TSM Scheduler Service is a Windows NT service that executes commands that are received from the TSM Server. In our environment, we created three batch files to run backup commands. These are: full_online_backup.cmd, full_offline_backup.cmd, and archive.cmd. The dsm.opt file to the left in Figure 27 is used by the TSM client for backup of normal files in the system. Backups of Oracle databases are controlled by Tivoli Data Protection for SAP R/3 through the TSM API client. Several configuration files are used by Tivoli Data Protection for SAP R/3 for database back up. These are located using the DSMI_CONFIG environment variable, and include init<SID>.sap, init<SID>.utl, init<SID>.bki, <server>.opt and the empty version of dsm.opt. The TSM Server section of the diagram shows important information about the configuration, such as the Policy Domain, Policy Set, and Management Classes with defined copy groups. The client points to elements on the TSM server and these links control the backup process. Activity and event logs are maintained by the TSM server.
80
SAP R/3 Oracle
DB12 DB13
init<SID>.SAP
util_par_file backup_dev_type
init<SID>.utl
CONFIG_FILE SERVER BRBACKUPMGTCLASS BRARCHIVEMGTCLASS
init<SID>.bki
Policy Domain Policy Set

MGMT-Class Copy Group
dsm.opt
TCPSERVERADDRESS NODE INCLUDE EXCLUDE
<server>.opt
NODE SERVERADDRESS
MGMT-Class Copy Group
text
dsm.opt
[empty file]
Node
DSMI_CONFIG
Schedules
Event log
Activity log
TSM API Client
TSM Client
full_online_backup.cmd full_offline_backup.cmd archive.cmd
TSM Server
TSM Scheduler Service
SAP R/3 Server

Figure 27. Software interdependencies within the TSM client
6.1.2 Additional TSM Server configuration

We assume you have completed the Tivoli Server Management installation and configuration as described in Chapter 5, Tivoli Storage Manager setup and configuration on page 63. The only additional configuration required is to register your node using the following command:
tsm: TSMSRV> register node sapr3 sap domain=r3 backdelete=yes maxnummp=2
81
Note
In TSM Server 3.7, multiple client sessions for file backup are introduced. To activate this new feature, which increases performance by allowing concurrent backup to multiple tape drives, a new node parameter maxnummp is introduced. This parameter limits the number of sessions a client may use to access sequential storage media and defaults to the value 1. To allow our installation to back up both the database and log files simultaneously, we set the value of maxnummp to 2.
6.1.3 The TSM Windows NT client

Now you need to install the TSM client software. Remember that the TSM client runs on the SAP server and requests service from the TSM backup server. We used the following steps to install the client: 1. Use the setup command to start the installation and click Next to start the installation. 2. Enter the destination folder for installation. We kept the default folder: D:\Program Files\Tivoli\TSM. 3. Select the type of installation you require: Compact, Custom or Typical. We chose Custom. 4. To install only the client, clear all checkboxes except for the one to select Client files. Make sure Client files is selected and click the Change button. Within this subsection we chose only the Backup-Archive Client Files. This selection includes the API Client Runtime Files, which are needed for Tivoli Data Protection for SAP R/3. 5. Click Next and select the Start menu folder for the TSM programs. We kept the default, which is Tivoli Storage Manager. Then click Next again. 6. We deselected View README file and Start Tivoli Storage Manager. 7. Reboot the server. After the installation, we configured the TSM option file (DSM.OPT) in d:\program files\tivoli\tsm\baclient for normal incremental file backup. We excluded the following system files: All All All All page files files in the recycler user profiles on D: registry hives on D:
We also excluded all Oracle database and archive files. To make sure that all Oracle control files are backed up, some of which are located in sapdata directories, we included them explicitly. The following screen shows our DSM.OPT file:
82
NODENAME sapr3 TCPSERVERADDRESS TSMSRV PASSWORDACCESS GENERATE Exclude.dir d:\WINNT\system32\config Exclude d:\WINNT\Profiles\*\NTUSER.DAT Exclude d:\WINNT\Profiles\*\ntuser.dat.LOG Exclude ?:\oracle\???\sapdata*\...\*.* Include ?:\...\cntrl???.dbf Exclude ?:\...\saparch\???ARCH*.* Exclude ?:\pagefile.sys Exclude ?:\recycler\...\* Exclude ?:\recycler\...\*.*
6.1.4 The TSM scheduler service

Tivoli Storage Manager allows us to set up a central scheduling configuration where the TSM server initiates the backup process. To allow the client to respond to a backup request, we have to define a TSM scheduler service on the SAPR3 node. The following screen shows the dsmcutil command that sets up the scheduler service: . C:\> d: D:\> cd \program files\tivoli\tsm\baclient D:\> dsmcutil inst /name:TSM scheduler service /NODE:SAPR3 /password:sap /autostart:yes To allow the scheduler to execute the necessary backup commands, which are received from the TSM server, it has to have the necessary rights so that Windows NT will allow access to the database. A simple way to give the scheduler service the right to connect to the database is to run the service using the SAPservice<SID> account instead of the default system account. To do this you have to change the Log On As parameter to the <SID>adm account by opening the Services icon in the Control Panel and clicking Startup... for the TSM scheduler service.
83
Figure 28. TSM scheduler service modification for Oracle
6.1.5 Tivoli Data Protection for SAP R/3

Tivoli Data Protection for SAP R/3 is the new name for a well-established product called Backint/ADSM. The name change took place not long before we wrote this book so you will see in our description of the installation that some names have not yet been changed to reflect the new product title. Depending on when you obtain the software, you too may find these older names being used. Installation is GUI-based and is started by executing the program backint_24X3_nt_service.exe. The numeric part of the filename indicates the version you are installing, so you can see that we installed Version 2.4X3. Test and product versions of the code and documentation can be downloaded from: http://www.de.ibm.com/ide/backint_adsm.html Software obtained in this way is scrambled and you will have to purchase a key to decrypt the program code. In addition to these files you need a password for starting the installation if you install the service version. If you are installing the program version you dont need a password.
Attention
Be aware that the user variables are set to reflect the user who is logged on. So before you start the installation please log on as <SID>ADM. After configuring IBM Backint/ADSM, this will allow you to use the SAP tools as you know them whenever you are logged on as <SID>ADM. If you wish other users to be able to execute backup and recovery commands using Backint, you will need to set up a similar environment for each user.
84
Here then are the steps we used to install Tivoli Data Protection for SAP R/3: 1. Start the installation by running the backint executable. 2. If you have a service version of TDP for SAP you have to enter the password now. If the password is correct, the Continue button is no longer greyed out. The product version of TDP does not require a password. 3. You are now asked if additional help is needed during installation. We chose not to see the help by clicking the No button. 4. The Welcome dialog reminds you to exit any running Windows programs. Click Next to continue. 5. The Select Components dialog is displayed next and offers three options for installation: Standard (all files - 1200 KB) Minimum (only executables, profile, configfile - 1160 KB) Custom (the files you select) We chose the standard installation. Click the Next button. 6. The Initial Target Directory dialog offers C:\win32app\ibm\backint_ADSM as the default Destination Folder. We clicked the Browse button to change this to D:\program files\tivoli\tsm\backint. We think it is more convenient to have all TSM-related software under a common directory, which, in our installation, we made d:\program files\tivoli\tsm. If the directory you select does not exist, you are asked if it should be created. After changing the directory, just click the Next button to continue. 7. The Executables Target Directory dialog defaults the destination folder to C:\oracle\C21\samnt\C21\sys\exe\run. We changed the destination target to the location of our SAP R/3 executables, which was S:\usr\sap\prd\sys\exe\run. Click Next to continue. 8. The Profile and Configfile dialog suggested D:\orant\database as the destination folder. We didnt alter this as it fit our environment. Click Next to continue. 9. The ADSM Client Option File dialog sets the location for the client option files. Sample option files are copied here during the installation. We changed the path from C:\...\sapmnt\C21\sys\exe\run\dsm_opt to D:\program files\tivoli\tsm\backint\dsm_opt. Click Next to continue. 10.The Start Copying Files dialog show a summary of the current settings. Click Next to start the installation. 11.The installation program asks if you want to have a log file written in D:\program files\tivoli\tsm\backint\documentation. We chose Yes. 12.The next window asks you if you wish to set the user-environment variables. We selected No, because we chose to set these variables manually in the user environment of the <SID>adm user. 13.At the end of the installation procedure, the Setup Complete dialog is displayed. We didnt want either to read the readme.txt file or reboot the system so we cleared the check boxes before clicking the Finish button. 14.An information box gives the message Setup Successfully Completed.
85
After the installation, we defined the TSM API client environment variables for the <SID>adm user. We set the following variables: DSMI_CONFIG = D:\program files\tivoli\backint\dsm_opt\dsm.opt DSMI_LOG = D:\program files\tivoli\tsm\api DSMI_DIR = D:\program files\tivoli\tsm\api The DMSI_DIR variable must contain the path where the DSCAMENG.TXT file resides. Finally, we rebooted the server. 6.1.5.1 Configuration of Tivoli Data Protection for SAP R/3 The next step is to configure Tivoli Data Protection for SAP R/3 to use the Tivoli Storage Manager server for backup and recovery. Here is how we did it: 1. Check the Oracle parameter file D:\orant\database\initPRD.ora. See OSS note 0124361, Oracle database parameter setting for R/3 4.x.
Note
We had to enter the following parameter which is needed for SAP R/3 4.5 backups: control_file_record_keep_time = 30 2. Next there are some settings required in the SAPDBA profile (initPRD.sap), located in D:\orant\database. First we define that we will use the Backint interface: backup_dev_type = util_file Next we set the parameter that declares that we are running online backups by default: backup_type = online Then we define where the configuration file for the Backint program is located: util_par_file = D:\orant\database\initPRD.utl 3. We also have to set up the initPRD.utl and initPRD.bki files, located in D:\orant\database\. First we copied the provided sample files from the Backint installation directory: copy ...\initC21.bki to ...\initPRD.bki copy ...\initC21.utl to ...\initPRD.utl After copying the sample *.utl file we modified the new copy in the d:\orant\database directory as follows:
86
BACKUPIDPREFIX PRD___ default SAP___ # MAX_SESSIONS 2 default 1 # MAX_BACK_SESSIONS2 default 1 # MAX_ARCH_SESSIONS2 default 1 # MAX_RESTORE_SESSIONS2 default 1 # BACKAGENT S:\usr\sap\PRD\sys\exe\run\backagent.exe REDOLOG_COPIES 2 # default 1 RL_COMPRESSION # default NO YES #MULTIPLEXING# default 1 1 #DISKBUFFSIZE 32768 # default 32768 #ADSMBUFFSIZE 131072 default 131072 # #FRONTEND pgmname parameterlist# default none #BACKEND pgmname parameterlist# default none MAX_VERSIONS 10 default 0 # #BATCH YES # unattended automated operation #BATCH NO # manual operation #EXITONERROR # default no NO #REPORT NO # default no, yes = all, 2 = all + summary #TRACE YES default no # #TRACEFILE filename# default stdout #TRACEMAX 100 default 100 # CONFIG_FILE D:\orant\database\initPRD.bki #RETRY 5 default 3 # #TCPWAIT 1 default 1 # #FILE_RETRIES 3 default 3 # #SNMPTRAP xxx.xxx.xxx.xxx public DETAIL# default none #LOG_SERVER server_a WARNING# default none SERVER TSMSRV # Servername SESSIONS 2 PASSWORDREQUIRED NO #ADSMNODE SAPR3 BRBACKUPMGTCLASS DB BRARCHIVEMGTCLASS LOG1 LOG2 # USE_AT 0123456 #SERVER server_b 2. Server if available # # SESSIONS 1 # PASSWORDREQUIRED YES # ADSMNODE C21 # BRBACKUPMGTCLASS mdb # BRARCHIVEMGTCLASS mlog1 mlog2 # USE_AT 0123456 END 4. Next, we created the <server>.opt file for a Backint with TSM environment and an empty DSM.OPT file, placing both of them in the directory pointed to by DSMI_CONFIG. copy server_a.opt to TSMSRV.opt and made the following modifications: # Max sessions # Use a password # ADSM Nodename # Mngm-Classes # Mngm-Classes # Days for backup
87
COMMmethod TCPIP COMPression OFF NODEname SAPR3 TCPPort 1500 TCPServeraddress TSMSRV PASSWORDACCESS GENERATE 5. We chose to implement automatic password control. By setting the following parameters: PASSWORDACCESS GENERATE in the server.opt file and PASSWORDREQUIRED NO in the SERVER stanza of the init<SID>.utl file. Also, you are not allowed to define the ADSMNODE parameter in the init<SID>.utl file. In addition to this, you have to switch authentication on for your TSM server:
tsm: TSMSRV> set AUTHENTICATION ON We chose to have a password expiration period of 30 days for our system. You can set the password expiration period for your TSM server with the following command:
tsm: TSMSRV> set PASSEXP 30
Attention
Before you connect to the TSM server with Backint, you should first connect with the TSM client. For example, you could issue the command: dsmc q mgm This is a once-only action, required to initialize the PASSWORDACCESS GENERATE function. 6. Now you should perform a manual check of the installation: a. Start sapdba from a command prompt. b. Select h for backup. c. In the Backup menu, check to make sure the following entries are correct: b- Enter parameter file: init<SID>.utl c- Enter backup device type: external backup tool (Backint) e- Enter backup type: online d. Select a small tablespace for testing d- Enter tablespace(s): PSAPUSER1D e. Start the backup procedure with option s. f. On completion, a message will inform you of success or failure.
88
6.2 Backup procedure

There are several ways in which you could implement a backup procedure in the environment under consideration. First, you could use the scheduling mechanism built into SAP itself. This is the recommended strategy if you are not using third-party backup software. Database administration and backup planning is implemented in SAP transaction DB13. Figure 29 shows you the types of backup you can select using this method:
Figure 29. DB13 for Oracle
Another possibility is to write scripts to control backup processes and then use the Windows NT scheduler to execute the commands as required. The Windows NT at command allows you control the timing and frequency of backups. A third possibility is to use the scheduling mechanism of Tivoli Storage Manager. We chose to implement a combination of SAP scheduling with DB13 and scheduling with TSM. In our scenario, scheduling for the backup of database files and archiving redo logs is done by TSM, so that all backups (database, logs, files) are maintained by TSM. All other scheduling for the Oracle database is done using SAP R/3s scheduler. In this book, we do not explain how to set schedules within transaction DB13 that are not related to backup.
6.2.1 Oracle database and redo log backups

We developed several scripts to control the different types of backup needed to implement our backup strategy. Because these scripts are started by the TSM scheduler service, you have to set all environment variables within them. We created the scripts in the Backint command files directory, which is located in d:\program files\tivoli\tsm\backint\.
89
6.2.1.1 Full online database backup Here is our script to perform a full online database backup:
@echo off rem Full Online Backup batch file: rem --------------------------------------------------------------------------rem file name: full_online_backup.cmd rem --------------------------------------------------------------------------rem Set Path environment variable set PATH=%PATH%;s:\usr\sap\PRD\sys\exe\run; rem set set set Set TSM environment variables DSMI_CONFIG=d:\program files\tivoli\backint\dsm_opt\tsmsrv.opt DSMI_DIR=d:\program files\Tivoli\TSM\api DSMI_LOG=d:\program files\tivoli\tsm\api
rem Set Oracle environment variables set ORACLE_HOME=D:\orant set ORACLE_SID=PRD rem set set set set set set set set set set set set Set SAP environment variables SAPDATA_HOME=H:\oracle\PRD SAPREORG=i:\oracle\PRD\sapreorg SAPTRACE=i:\oracle\PRD\saptrace SAPARCH=i:\oracle\PRD\saparch SAPBACKUP=i:\oracle\PRD\sapbackup SAPCHECK=i:\oracle\PRD\sapcheck SAPDATA1=H:\oracle\PRD\sapdata1 SAPDATA2=H:\oracle\PRD\sapdata2 SAPDATA3=H:\oracle\PRD\sapdata3 SAPDATA4=H:\oracle\PRD\sapdata4 SAPDATA5=H:\oracle\PRD\sapdata5 SAPDATA6=H:\oracle\PRD\sapdata6
rem execute brbackup command brbackup -c -m all -t online
90
6.2.1.2 Full offline database backup The script for a full offline database backup is very similar:
@echo off rem Full Offline Backup batch file: rem --------------------------------------------------------------------------rem file name: full_offline_backup.cmd rem --------------------------------------------------------------------------rem Set Path environment variable set PATH=%PATH%;s:\usr\sap\PRD\sys\exe\run rem set set set Set TSM environment variables DSMI_CONFIG=d:\program files\tivoli\backint\dsm_opt\tsmsrv.opt DSMI_DIR=d:\program files\Tivoli\TSM\api DSMI_LOG=d:\program files\tivoli\tsm\api
brbackup -c -m all -t offline_force
91
6.2.1.3 Archive redo log backups Our archive redo log script is also very similar:
@echo off rem Save and Delete Redo Logs Batch File: rem --------------------------------------------------------------------------rem file name: archive.cmd rem --------------------------------------------------------------------------rem Set Path environment variable set PATH=%PATH%;s:\usr\sap\PRD\sys\exe\run rem set set set Set TSM environment variables DSMI_CONFIG=d:\program files\tivoli\backint\dsm_opt\tsmsrv.opt DSMI_DIR=d:\program files\Tivoli\TSM\api DSMI_LOG=d:\program files\tivoli\tsm\api
brarchive -c -sd
6.2.2 Automation using the TSM client scheduler

Tivoli Storage Manager allows you to establish schedules for your backups to suit your needs. The schedule and backup strategy you decide upon will have to take into account several factors including: How frequently do you wish to take backups? How long do you have to take backups that require the system to be offline? How long do you think you can afford to take to restore your data? There will be a minimum time based on how much data you have to restore.
92
The following table shows the backup schedule we planned for our lab systems:
Table 18. Backup schedule for SAP R/3 and Oracle
Task Database online backup Database offline backup using force option Archiving database logs to tape Incremental backup of other files
Time Every Monday, Tuesday, Wednesday, Thursday at 22:00 Every Friday at 22:00 Every weekday at 23:00 Every weekday at 06:00
To define a client schedule for a TSM node, you have to do two things. First you have to set the schedule timings and then you have to associate nodes to the schedule. Tivoli Storage Manager does not allow a schedule to be defined for just Monday, Tuesday, Wednesday and Thursday, so you have to define four individual schedules. In total, therefore, we have to define seven distinct schedules. That is, four for online backup, one for offline backup, one for archive files and a final one for incremental file backup. Here is a sample TSM macro to define the Monday online backup schedule, including the association of node SAPR3 with this schedule.
DEFINE SCHEDULE R3 full_online_backup_monday \ DESCRIPTION="Full online Database backup on Monday" \ ACTION=COMMAND \ OBJECTS="D:\Progra~1\Tivoli\tsm\backint\commandfiles\full_online_backup.cmd" \ Priority=2 \ STARTTIME=22:00:00 \ DURUNITS=HOURS \ PERUNIT=WEEK \ DAYOFWEEK=MONDAY DEFINE ASSOCIATION R3 full_online_backup_monday SAPR3
The macros for the other database backups are similar. To define the daily (Monday to Friday) incremental schedule, for example, we used this TSM macro:
DEFINE SCHEDULE R3 daily_incr \ DESCRIPTION="Daily incremental backup" \ ACTION=INCR \ Priority=2 \ STARTTIME=06:00:00 \ DURUNITS=HOURS \ PERUNIT=DAY \ DAYOFWEEK=WEEKDAY DEFINE ASSOCIATION R3 daily_incr SAPR3
93
6.2.3 Check your backup

After defining the required schedules and writing the necessary scripts, your system backup should work automatically. The reason for taking backups is to protect yourself against loss of data and it is important to check that your backup process is working correctly. So what you have to do every day as an SAP backup administrator is to check that your backups were completed successfully. Checking the backup includes the following tasks: 1. Examine your backups using SAP R/3 transaction DB12. This transaction looks at the log files of brbackup and brarchive that are created in \oracle\<SID>\brarchive and \oracle\<SID>\brbackup directories. Because Tivoli Data Protection for SAP R/3 does not change the basic operation of these commands, you can use the standard methods for checking these logs as referred to in the SAP R/3 Oracle documentation. 2. Check the events for your schedules on a daily basis. Here is an example of a TSM command to examine all events that have occurred and will occur in the TSM domain named R3 for the period from yesterday until tomorrow. This will show you which schedules have been executed, their results and also future events scheduled for today and tomorrow.
tsm: TSMSRV> QUERY EVENT R3 * BEGINDATE=TODAY-1 ENDDATE=TODAY+1 3. Check the TSM logs on the SAP system. These are: dsmsched.log Here you find the results of actions executed by the local TSM Scheduler service. Because all of our backups are executed by this service, everything relevant to our backups is located here. You should monitor the size of this log file because it is growing constantly. When necessary, take steps to reduce its size by deleting older data. This file is the error log for manual file backup-and-restore commands. It should be monitored for errors. This file is the error log for the TSM API client, used by Backint. It should be monitored for errors.
dsmerror.log dsmierror.log
4. Check the activity log of the TSM server:
tsm: TSMSRV> query actlog For more information about the query actlog command see the TSM Reference Guide shipped with the TSM product.
6.3 Recovery Procedure

The recovery procedure for the SAP R/3 system with Tivoli Data Protection for SAP R/3 is similar to a normal recovery of an SAP R/3 system. Of course you have to make sure you have a connection to your TSM server and have installed the TSM client for file recovery and Tivoli Data Protection for SAP R/3 to be able to restore your database and logs. You have to check that the correct tapes are
94
available within your tape library, but if they are not, TSM will tell you exactly which tapes contain the data you need for recovery. To successfully recover, you must make sure your system is fully functional. That is, any hardware or software failures must have been corrected. The following flowchart shows one possible recovery strategy:
Hardware error (no crash)
Repair Hardware
OK
Check SAP
OK
System OK
Fail
Hardware error (crash)
Repair Hardware
OK
Check Win NT
Fail
Recover Win NT
Check Files
OK
Fail Restore files
OK
User error
Repair SAP
Fail
Check Database
Fail
Recover database
Check SAP
OK
System OK
Figure 30. Recovery procedure for SAP R/3 and Oracle database
Note that the flowchart in Figure 30 refers to recovery from hardware errors and user errors. We assume that, prior to the failure that necessitates recovery, your SAP R/3 system was working well and running without any errors. That is, there are no faulty device drivers or other software that could cause problems. We can divide hardware problems into two classes: those that crash the system and those that do not because the system was protected by redundant components such as a RAID disk array or a redundant power supply. In the latter situation, after you have repaired your hardware successfully, you should always check your system by checking the SAP R/3 system log to determine whether any jobs have failed or there are any other signs of problems. If there are no errors, your system is up and running correctly again. However, if the hardware error has crashed your system or SAP has problems (and this can include a blue screen trap, corrupted operating system or database
OK
Fail Call Help
OK
95
and so on), you should start a bottom-up process to check and repair your whole system. This means we check Windows NT first. You should check that you can start both Windows NT partitions (the production and backup Windows NT installation). Check that all services are online, and see if there any messages in the Windows NT event log. This will help to make sure that your network and other essential subsystems are working properly. If there is a problem, you should try to recover the production Windows NT partition first. If you cannot repair the first partition, then attempt to recover using the second Windows NT installation. So, here is our suggested sequence of preferred methods to recover Windows NT: Use a Windows NT repair disk Use a Windows NT boot diskette Use the second Windows NT partition with the TSM client If both Windows NT installations cannot be recovered, you will have to install a new second copy of Windows NT and the TSM client software, making sure to configure them to be able to access the network and the TSM server, and then restore your production system. Having achieved a functional Windows NT installation, the next step will be to check all Windows NT partitions, in particular, the partitions containing the Oracle database and the SAP R/3 software. The checks should also include any database files that are needed for startup and recovery. For example, you need the files in the sapbackup and saparchive directories. You also need the control files to start a database restore. If any files are missing you can restore them now using the TSM client. After all the files on your system are in place, you can check the database itself. If there are any errors when you open the database, you will have to recover the database to its most recent backed-up state. The easiest way of doing this is using sapdba. You can use Oracle tools such as svrmgr30 as well. Once you have successfully recovered your database, you need to check your SAP system again. This time, everything should now be operating correctly. You should be aware that you might have to repeat lost transactions. Looking again at the flowchart in Figure 30 on page 95, if a user error has caused the problem, the recovery procedure starts at a later point, since you do not have to repair hardware or recover Windows NT. If you can recover the user failure within your SAP system then you don't need to perform a database restore, which can save a lot of time. Should you need to restore your database, make sure everything is working as expected prior to the restore. To recover your database, the best tool is once again sapdba. After successfully restoring the Oracle database, you need to check your SAP system again. Of course, you have to reapply any changes made to your database since the backup that has been restored. This procedure should give you a general overview of backing up and recovering your SAP system. We can't show an example here because there is no typical restore scenario. You always have to analyze your system in order to know what actions you have to take. We recommend that you make yourself familiar with the
96
recovery procedure before you go into production. Do a complete recovery of the whole system, to make sure you know what you have to do and to have the confidence that you can recover if you ever have to do so in a real situation.
97
98
Chapter 7. IBM DB2-based systems

This chapter takes you through the steps we recommend to implement backup-and-recovery processes for SAP R/3 4.5B using the DB2 database. The information you will find here is based on an actual SAP R/3 backup system. We installed several complete SAP R/3 systems in our laboratory during the writing of this book. This allowed us to test and validate what we wanted to say so that we could be sure the information is accurate and up-to-date. We give specific details of the hardware and software configurations we used, which should help you to implement your own solutions simply and quickly. We begin by examining the hardware configuration and then move on to look at the way in which the various software components are related to each other. Each component is installed and configured to complete the backup solution. The chapter closes by illustrating possible backup and recovery processes with sample batch command files.

In our laboratory, we installed a number of SAP R/3 systems. For this particular example, we used a Netfinity 7000 M10 to run both the DB2 database and SAP application servers in a two-tier configuration. Most SAP installations are two-tier so this represents the majority of real-life situations. Backing up the database is the most complex part of the backup solution, so extending our example to a three-tier installation is straightforward. The SAP server was configured with both internal SCSI disks and an external Fibre Channel array of disks. For the Tivoli Storage Manager server, we used a Netfinity 5000 server connected to a 3447 DLT tape library with two physical tape drives. The servers were connected together using a 100 Mbps Ethernet network, which was also the network used for client access to the servers. Figure 31 illustrates our configuration and provides information about the various adapters we used and where they were installed in each server:
99
SAP R/3 system Netfinity 7000 M10 2 x 9 GB disks

1
100 Mbps Ethernet
Figure 31. Backup solution hardware for SAP R/3 using DB2
Table 19. ServeRAID configuration for SAP R/3 using DB2
Logical drive 0 1 2
100
Note
IBMs ServeRAID adapters provide the ability to back up your RAID configuration data to diskette. We strongly recommend that you take advantage of this feature. You can use this to recover your ServeRAID configuration in case of hardware failure. If your ServeRAID adapter has battery-backed up cache, you can set the adapters write policy to write-back which will boost disk subsystem performance. For our Fibre Channel Installation we used following levels of Software: Netfinity Fibre Channel PCI Adapter BIOS Version: Netfinity Fibre Channel RAID support Firmware: 1.35 3.01.01.00
Netfinity Fibre Channel PCI Adapter Windows NT 4.0 Driver:6.16 Symplicity Storage Manager Release: Our general Fibre Channel configuration looks like this:
Table 20. Fibre Channel configuration for SAP R/3 4.5B using DB2
06.22.25.15
Drive group 1 2 3 4
LUN 1 2 3 4
RAID 5 1 1 1
Capacity 26GB 9GB 9GB 2GB
Disk label h_sapdata i_log j_archive s_sap
Drive letter H: I: J: S:
Note
For security, you should save your Fibre Channel configuration files to disk. The following table shows how we chose to distribute the SAP files within the system:
Table 21. File distribution for SAP R/3 4.5B using DB2
Directory name \SQLLIB \db2<SAPSID> \db2\<SAPSID>\log_dir \db2\<SAPSID>\log_archive log_retrieve \db2\<SAPSID>\sapreorg \db2\<SAPSID>sapdata1 \db2\<SAPSID>sapdata2 \db2\<SAPSID>sapdata3
Drive letter D: D: I: J: H: J: H: H: H:
101
Directory name \db2\<SAPSID>sapdata4 \db2\<SAPSID>sapdata5 \db2\<SAPSID>sapdata6 \usr\sap \usr\sap\trans
Drive letter H: H: H: S: S:

Figure 32 on page 103 shows the interdependencies between DB2 UDB and Tivoli Storage Manager for SAP R/3. The diagram highlights the important files and environment variables that control the operation of the backup system, and illustrates the relationships among them. Looking closer at the elements that form the backup system, DB2 configuration consists of two parts. The first, called SAP DB2 admin tools in the diagram, contains the information controlling log backups and defines the name of the TSM management class for log files. The second, DB2 utilities, contains the information controlling database backups and the name of the TSM management class for database files. Other parameters are left empty. The TSM Scheduler Service is a Windows NT service that executes commands that are received from the TSM Server. In our environment we created four batch files to run backup commands. These are: full_online_backup.cmd, full_offline_backup.cmd, archive.cmd, and delete__db_backups.cmd. Backups of DB2 UDB databases are controlled through the TSM API client, whereas normal file backups are controlled through the TSM client. The DSMI_CONFIG environment variable points to the default option file for the TSM Client, which is called dsm.opt. This same configuration file is used by the TSM API Client and contains information about the TSM server and backup options. Other environment variables, DSMI_DIR and DSMI_LOG, point to directories used during the backup process. The TSM Server section of the diagram shows important information about the configuration, such as the Policy Domain, Policy Set, and Management Classes. The client points to elements on the TSM server and these links control the backup process. Activity and event logs are maintained by the TSM server.
102
SAP R/3 DB2 UDB

ADM<SAPSID> database SAP DB2 admin tools
backup_dev_type=adsm adsm_mc=DB2_LOG
DB12 DB13
Policy Domain SAPDB2 Policy Set SAPDB2

MGMT-Class DB2_DB Backup Copy Group
ADM<SAPSID> database DB2 utilities
<SAPSID> database
ADSM Password = ADSM Nodename= ADSM Owner Name= ADSM Management Class=DB2_DB
MGMT-Class DB2_LOG dsm.opt

DSMI_CONFIG= d:\Program Files\tivoli\tsm\baclient\dsm.opt DSMI_DIR=d:\Program Files\tivoli\tsm\api DSMI_LOG=d:\Program Files\tivoli\tsm\api
Archive Copy Group
Node
Schedules
TSM API Client

full_online_backup.cmd full_offline_backup.cmd
TSM Client
archive.cmd delete_db_backups.cmd Event log Activity log
TSM Server
SAP R/3 Server


tsm: TSMSRV> register node sapdb2 sap domain=r3db2 At the time we wrote this book, DB2 did not support the use of multiple backup sessions so we left the parameter maxnummp at its default value of 1 (see 6.1.2, Additional TSM Server configuration on page 81 for an example of how this parameter can be used when multiple sessions are supported). This feature is anticipated in a future release of DB2.
103

Now you need to install the TSM client software. Remember that the TSM client runs on the SAP server and requests service from the TSM backup server. We used the following steps to install the client: 1. Use the setup command to start the installation and click Next to start the installation. 2. Enter the destination folder for installation. We kept the default folder: D:\Program Files\Tivoli\TSM. 3. Select the type of installation you require: Compact, Custom or Typical. We chose Custom. 4. To install only the client clear all check boxes except for the one to select Client files. Make sure Client files is selected and click the Change button. Within the subsection we chose only the Backup-Archive Client Files. This selection includes the API Client Runtime Files, which are needed for DB2 database and log backup to TSM server. 5. Click Next and select the Start menu folder for the TSM programs. We kept the default, which is Tivoli Storage Manager. Then click Next again. 6. We deselected View README file and Start Tivoli Storage Manager. 7. Reboot the server. After the installation, we configured the TSM option file (DSM.OPT) in d:\program files\tivoli\tsm\baclient for normal incremental file backup. We excluded the following system files: All All All All page files files in the recycler user profiles on D: registry hives on D:
We also excluded all DB2 database and logfile files. The following screen shows our DSM.OPT file:
NODENAME SAPDB2 TCPSERVERADDRESS TSMSRV PASSWORDACCESS GENERATE SUBDIR YES DIRMC DATA Exclude.dir d:\WINNT\system32\config Exclude d:\WINNT\Profiles\...\NTUSER.DAT Exclude d:\WINNT\Profiles\...\ntuser.dat.log Exclude ?:\pagefile.sys Exclude ?:\...\dsm*.log Exclude ?:\RECYCLER\...\* Exclude ?:\RECYCLER\...\*.* Exclude ?:\db2\???\sapdata*\*.container* Exclude ?:\db2\???\log_dir\*.log Exclude ?:\db2\???\log_archive\...\*.LOG.*
104

Tivoli Storage Manager allows us to set up a central scheduling configuration where the TSM server initiates the backup process. To allow the client to respond to a backup request, we have to define a TSM scheduler service on the SAPDB2 node. The following screen shows the dsmcutil command that sets up the scheduler service: . C:\> d: D:\> cd \program files\tivoli\tsm\baclient D:\> dsmcutil inst /name:TSM scheduler service /NODE:SAPDB2 /password:sap /autostart:yes To allow the scheduler to execute the necessary backup commands, which are received from the TSM server, it has to have the necessary rights so that Windows NT will allow access to the database. A simple way to give the scheduler service the right to connect to the database is to run the service using the <SID>adm account instead of the default system account. To do this you have to change the Log On As parameter to the <SID>adm account by opening the Services icon in the Control Panel and clicking on Startup... for the TSM scheduler service.
Figure 33. TSM scheduler service for DB2
7.1.4.1 Configuration of DB2 to use TSM for backup To configure DB2 for backup recovery with Tivoli Storage Manager, you have to change the built-in database backup configuration and the SAP administration utilities for log file management. Three environment variables also have to be set for the TSM API environment. These provide information to the system about where to find components important to the operation of TSM: DSMI_CONFIG=d:\program files\tivoli\tsm\baclient\dsm.opt DSMI_DIR=d:\program files\tivoli\tsm\api DSMI_LOG=d:\program files\tivoli\tsm\api
105
To change the configuration for database backup to use TSM, first start the DB2 Control Center. Right-click the SAP system database and select Configure... A Configure Database dialog opens in which you should select the Recovery tab and change the ADSM (TSM) Management Class to DB2_DB, which is our management class for DB2 database backups. This is shown in Figure 34 on page 106:
Figure 34. TSM database settings for DB2
For the DB2 database there are three ADSM parameters of interest to us. These are: ADSM Password, ADSM Node name, and ADSM Management Class. In our environment we only have to configure the parameter ADSM Management Class; we used DB2_DB which is linked to the DB2 database storage pool. ADSM Node name is already specified in the DSM.OPT configuration file. Finally, because we automatically generate the password, we do not set a fixed password with the ADSM Password parameter. These parameters apply to the SAP administration database, as well, so we are also able to back up the administration database with TSM. To configure the SAP DB2 log file management to use TSM, you have to change two parameters in the SAP-DB2 administration options: backup_dev_type = adsm adsm_mc = DB2_LOG These are accessed by right-clicking in the DB2CC while pointing at the SAP system database.
106

Figure 35. DB13 for DB2
DB2 does not support offline backup of the database in an SAP R/3 environment. To perform an offline backup of your database you have to stop R/3. This ensures that there will not be any problems with database corruption. Another possibility is to write scripts to control backup processes and then use the Windows NT scheduler to execute the commands as required. The Windows NT at command allows you control the timing and frequency of backups. A third possibility is to use the scheduling mechanism of Tivoli Storage Manager. We chose to implement a combination of SAP scheduling with DB13 and scheduling with TSM. In our scenario, scheduling for the backup of database files and archiving redo logs is done by TSM, so that all backups (database, logs, files) are maintained by TSM. All other scheduling for the DB2 Database is done using SAP R/3s scheduler. In this book, we do not explain how to set schedules within transaction DB13 that are not related to backup.
7.2.1 DB2 database and log backups

We developed several scripts to control the different types of backup needed to implement our backup strategy. Because these scripts are started by the TSM scheduler service, you have to set all environment variables within them. We
107
created the scripts in the Backint command files directory, which is located in d:\program files\tivoli\tsm\backint\. The script is executed by the <SID>adm user. 7.2.1.1 Full online database backup Here is our script to perform a full online database backup:
echo on rem -------------------------------------------------------------------rem file name: full_online_backup.cmd rem -------------------------------------------------------------------rem set PATH environment variable set PATH=%PATH%;s:\usr\sap\DB2\sys\exe\run rem set set set set set set set set set set set DB2 Server environment variables DB2INSTANCE=db2db2 DB2CODEPAGE=819 DB2DB6EKEY=sap DB2DB6_R3DBPATH=d:\sqllib\bin DB2DBDFT=DB2 DB2DSCDB6HOME=SAPDB2 DB6EKEY=sap DBMS_TYPE=DB6 DIR_LIBRARY=S:\usr\sap\DB2\sys\exe\run DSCDB6HOME=SAPDB2
rem set SAP environment variables set SID=DB2 rem -------------------------------------------------------------------rem execute full online database backup rem -------------------------------------------------------------------rem full online backup of SAP database db2db6 backup database %SID% online use adsm rem full offline backup of admin database db2db6 backup database adm%SID% use adsm
108
7.2.1.2 Full offline database backup The script for a full offline database backup is a little more complicated. Note that the script is too long to fit on a single page and is continued on the next:
echo on rem -------------------------------------------------------------------rem file name: full_offline_backup.cmd rem rem this scripts works only with a central system rem you have to include start and stop for application rem servers for any none central systems rem -------------------------------------------------------------------rem Set PATH environment variable set PATH=%PATH%;s:\usr\sap\DB2\sys\exe\run rem set set set set set set set set set set rem set set set Set DB2 Server environment variables DB2INSTANCE=db2db2 DB2CODEPAGE=819 DB2DB6EKEY=sap DB2DB6_R3DBPATH=d:\sqllib\bin DB2DBDFT=DB2 DB2DSCDB6HOME=SAPDB2 DB6EKEY=sap DBMS_TYPE=DB6 DIR_LIBRARY=S:\usr\sap\DB2\sys\exe\run DSCDB6HOME=SAPDB2 Set SAP Server environment variables SID=DB2 CIHOST=SAPDB2 SYSNR=00
rem -------------------------------------------------------------------rem execute full offline Datebase backup rem -------------------------------------------------------------------:STOPR3 rem stop SAP R/3 on Central Instance sapsrvkill %CIHOST%_%SID%_%SYSNR% sapntwaitforhalt \ pf=\\%CIHOST%\sapmnt\%SID%\sys\profile\START_DVEBMGS%SYSNR%_%CIHOST%SAPDIAHOST \ =%HOST% 120 db2stop force rem stop and start of db2%SID% net stop db2%SID% net start db2%SID% if errorlevel == 1 goto DB2ERROR1
109
This is the second part of our full offline database backup script, continued from the previous page:
:DB2ERROR1 sleep 30 net stop db2%SID% net start db2%SID% if errorlevel == 1 goto ENDERROR goto DB2STOPPED :DB2STOPPED rem backup SAP database use adsm db2db6 backup database %SID% use adsm rem backup SAP admin database use adsm db2db6 backup database adm%SID% use adsm :STARTR3 rem start SAP R/3 on CI startsap R3 %SID% %CIHOST% start_dvebmgs%SYSNR%_%CIHOST% goto END :ENDERROR Echo Script aborted because the service DB2%SID% could not be stopped ! :END Echo Script finished
110
7.2.1.3 Backup of offline logs For DB2, we also need a script to handle the backup of offline logs. Our example is shown below:
echo on rem -------------------------------------------------------------------rem file name: archive.cmd rem -------------------------------------------------------------------rem Set PATH environment variable set PATH=%PATH%;S:\usr\sap\DB2\sys\exe\run rem set set set set set set set set set set Set DB2 environment variables DB2INSTANCE=db2db2 DB2CODEPAGE=819 DB2DB6EKEY=sap DB2DB6_R3DBPATH=d:\sqllib\bin DB2DBDFT=DB2 DB2DSCDB6HOME=SAPDB2 DB6EKEY=sap DBMS_TYPE=DB6 DIR_LIBRARY=S:\usr\sap\DB2\sys\exe\run DSCDB6HOME=SAPDB2
rem Set SAP environment variables set SID=DB2 rem -------------------------------------------------------------------rem execute log backup with delete of log files rem -------------------------------------------------------------------brarchive -sd -d adsm -node NODE0000 -out 7.2.1.4 Delete old database backups Finally, we need a script to delete old backups:
echo on rem -------------------------------------------------------------------rem file name: delete_db_backups.cmd rem -------------------------------------------------------------------rem Set PATH environment variable set PATH=%PATH%;d:\sqllib\misc rem set script environemnt set SID=DB2 set days=28 rem delete SAP system database backup in TSM (mark inactive) db2adutl delete older than %days% days db %SID% without prompting rem delete SAP admin database backup in TSM (mark inactive) db2adutl delete older than %days% days db adm%SID% without prompting
111

Tivoli Storage Manager allows you to establish schedules for your backups to suit your needs. The schedule and backup strategy you decide upon will have to take into account several factors including: How frequently do you wish to take backups? How long do you have to take backups that require the system to be offline? How long do you think you can afford to take to restore your data? There will be a minimum time based on how much data you have to restore. The following table shows the backup schedule we planned for our lab systems:
Table 22. Backup schedule strategy for SAP R/3 and DB2
Task Database offline backup Delete old database backup Archiving database logs to tape Incremental backup of other files
Time Every Monday through Friday at 22:00 Every Monday through Friday at 21:00 Every weekday at every hour except during the database backup Every weekday at 06:00
To define a client schedule for a TSM node, you have to do two things. First you have to set the schedule timings and then you have to associate nodes to the schedule. Here is a sample TSM macro to define a weekday offline database backup schedule including the association of node R3DB2 to this schedule:
DEFINE SCHEDULE R3DB2 full_offline_backup \ DESCRIPTION="Full offline Database backup" \ ACTION=COMMAND \ OBJECTS="D:\backup\full_offline_backup.cmd" \ Priority=2 \ STARTTIME=22:00:00 \ DURUNITS=HOURS \ PERUNIT=DAY \ DAYOFWEEK=WEEKDAY DEFINE ASSOCIATION R3DB2 full_online_backup SAPDB2 The macros for the other database backups are similar. To define the daily incremental schedule (Monday - Friday) we used this TSM macro:
DEFINE SCHEDULE R3DB2 daily_incr \ DESCRIPTION="Daily incremental backup" \ ACTION=INCR \ Priority=2 \ STARTTIME=06:00:00 \ DURUNITS=HOURS \ PERUNIT=DAY \ DAYOFWEEK=WEEKDAY DEFINE ASSOCIATION R3DB2 daily_incr SAPDB2
112

After writing all of the necessary scripts and defining the necessary schedules, your system backup should work automatically. The reason for taking backups is to protect yourself against loss of data and it is important to check that your backup process is working correctly. So what you have to do every day as an SAP backup administrator is to check that your backups were completed successfully. Checking the backup includes the following tasks: 1. Examine your backups using SAP R/3 transaction DB12.
Figure 36. DB12 transaction for DB2 Server
2. Check the events for your schedules on a daily basis. Here is an example of a TSM command to examine all events that have occurred and will occur in the TSM domain named R3DB2 for the period from yesterday until tomorrow. This will show you which schedules have been executed, their results and also future events scheduled for today and tomorrow.
tsm: TSMSRV> QUERY EVENT R3DB2 * BEGINDATE=TODAY-1 ENDDATE=TODAY+1
113
3. Check the TSM logs on the SAP system. These are: dsmsched.log Here you find the results of actions executed by the local TSM Scheduler service. Because all of our backups are executed by this service, everything relevant to our backups is located here. You should monitor the size of this log file because it is growing constantly. When necessary, take steps to reduce its size by deleting older data. This file is the error log for manual file backup-and-restore commands. It should be monitored for errors. This file is the error log for the TSM API client, used by Backint. It should be monitored for errors.
7.3 Recovery procedure

To recover, you must make sure your system is fully functional. That is, any hardware or software failures must have been corrected. The following flowchart shows one possible recovery strategy:
114
Repair Hardware
OK
Check SAP
OK
System OK
Fail
Repair Hardware
OK
Check Win NT
Fail
Recover Win NT
Check Files
OK
Fail Restore files
OK
User error
Repair SAP
Fail
Check Database
Fail
Recover database
Check SAP
OK
System OK
Figure 37. Recovery procedure for SAP R/3 and DB2 database
Note that the flowchart in Figure 37 refers to recovery from hardware errors and user errors. We assume that, prior to the failure that necessitates recovery, your SAP R/3 system was working well and running without any errors. That is, there are no faulty device drivers or other software that could cause problems. We can divide hardware problems into two classes: those that crash the system and those that do not because the system was protected by redundant components such as a RAID disk array or a redundant power supply. In the latter situation, after you have repaired your hardware successfully, you should always check your system by checking the SAP R/3 system log to determine whether any jobs have failed or there are any other signs of problems. If there are no errors, your system is up and running correctly again. However, if the hardware error has crashed your system or SAP has problems (and this can include a blue screen trap, corrupted operating system or database and so on), you should start a bottom-up process to check and repair your whole system. This means we check Windows NT first. You should check that you can start both Windows NT partitions (the production and backup Windows NT installation). Check that all services are online, and see if there any messages in the Windows NT event log. This will help to make sure that your network and other essential subsystems are working properly. If there is a problem, you should
OK
Fail Call Help
OK
115
try to recover the production Windows NT partition first. If you cannot repair the first partition, then attempt to recover using the second Windows NT installation. So, here is our suggested sequence of preferred methods to recover Windows NT: Use a Windows NT repair disk Use a Windows NT boot diskette Use the second Windows NT partition with the TSM client If both Windows NT installations cannot be recovered, you will have to install a new second copy of Windows NT and the TSM client software, making sure to configure them to be able to access the network and the TSM server and then restore your production system. Having achieved a functional Windows NT installation, the next step will be to check all Windows NT partitions, in particular, the partitions containing the DB2 database and the SAP R/3 software. The checks should also include any database files that are needed for startup and recovery. After all the files on your system are in place, you can check the database itself. If there are any errors when you open the database, you will have to recover the database to its most recent backed-up state. Once you have successfully recovered your database, you need to check your SAP system again. This time, everything should now be operating correctly. You should be aware that you might have to repeat lost transactions. Looking again at the flowchart in Figure 37 on page 115, if a user error has caused the problem, the recovery procedure starts at a later point, since you do not have to repair hardware or recover Windows NT. If you can recover the user failure within your SAP system then you don't need to perform a database restore which can save a lot of time. Should you need to restore your database, make sure everything is working as expected prior to the restore. After successfully restoring the DB2 database, you need to check your SAP system again. Of course, you have to reapply any changes made to your database since the backup that has been restored. This procedure should give you a general overview of backing up and recovering your SAP system. We can't show an example here because there is no typical restore scenario. You always have to analyze your system in order to know what actions you have to take. We recommend that you make yourself familiar with the recovery procedure before you go into production. Do a complete recovery of the whole system, to make sure you know what you have to do and to have the confidence that you can recover if you ever have to do so in a real situation. Here are some useful hints and tips: To recover the offline redo logs from TSM you can use the brrestore command. For example, if you wish to recover log file 50, you would use following command: brrestore -a 50 -d adsm -out
116
And to recover multiple log files, for example files 50 to 100, you would use this command: brrestore -a 50-100 -d adsm -out
Note
If you have to restore an archive log twice you must delete the logfile entry in the SAP admin database with brrestore -dr -n 50 -d adsm -out The command brrestore -ex does not work with Windows NT, as stated in SAP online documentation. The recovery procedure for the SAP R/3 system running with DB2 is straightforward. Of course you have to make sure you have a connection to your TSM server and have installed the TSM client for file recovery to be able to restore your database and logs. You have to check that the correct tapes are available within your tape library, but if they are not, TSM will tell you exactly which tapes contain the data you need for recovery. To recover the database you can use the restore command in DB2 command center: restore database <SID> use DB2. The database instance must be started for this command to execute successfully.
117
118
Chapter 8. Microsoft SQL Server-based systems

This chapter takes you through the steps we recommend to implement backup-and-recovery processes for SAP R/3 4.5B using the Microsoft SQL Server database. The information you will find here is based on an actual SAP R/3 backup system. We installed several complete SAP R/3 systems in our laboratory during the writing of this book. This allowed us to test and validate what we wanted to say so that we could be sure the information is accurate and up-to-date. We give specific details of the hardware and software configurations we used, which should help you to implement your own solutions simply and quickly. We begin by examining the hardware configuration and then move on to look at the way in which the various software components are related to each other. Each component is installed and configured to complete the backup solution. The chapter closes by illustrating possible backup and recovery processes with example batch command files.

In our laboratory, we installed a number of SAP R/3 systems. For this particular example, we used a Netfinity 7000 M10 to run both the SQL Server database and SAP application servers in a two-tier configuration. Most SAP installations are two-tier so this represents the majority of real-life situations. Backing up the database is the most complex part of the backup solution, so extending our example to a three-tier installation is straightforward. The SAP server was configured with both internal SCSI disks and an external Fibre Channel array of disks. For the Tivoli Storage Manager server, we used a Netfinity 5000 server connected to a 3447 DLT tape library with two physical tape drives. The servers were connected together using a 100 Mbps Ethernet network, which was also the network used for client access to the servers. Figure 38 below illustrates our configuration and provides information about the various adapters we used and where they were installed in each server:
119
SAP R/3 system Netfinity 7000 M10 2 x 9 GB disks

1
100 Mbps Ethernet
Figure 38. Backup solution hardware for SAP R/3 using SQL Server
Table 23. ServeRAID configuration for SAP R/3 using SQL Server
Logical drive 0 1 2
120
Note
IBMs ServeRAID adapters provide the ability to back up your RAID configuration data to diskette. We strongly recommend that you take advantage of this feature. You can use this to recover your ServeRAID configuration in the case of hardware failure. If your ServeRAID adapter has battery-backed up cache, you can set the adapters write policy to write-back which will boost disk subsystem performance. For our Fibre Channel Installation we used following levels of Software: Netfinity Fibre Channel PCI Adapter BIOS Version: Netfinity Fibre Channel RAID support Firmware: 1.35 3.01.01.00
Netfinity Fibre Channel PCI Adapter Windows NT 4.0 Driver:6.16 SYMplicity Storage Manager Release: Our general Fibre Channel configuration looks like this:
Table 24. Fibre Channel configuration for SAP R/3 4.5B using SQL Server
06.22.25.15
Drive group 1 2 3 4
LUN 1 2 3 4
RAID 5 1 1 1
Capacity 26GB 9GB 9GB 2GB
Disk label h_sapdata i_log j_mssql s_sap
Drive letter H: I: J: S:
Note
For security, you should save your Fibre Channel configuration files to disk.
The following table shows how we chose to distribute the SAP files within the system:
Table 25. File distribution for SAP R/3 4.5B using SQL Server
Directory name \MSSQL7 \MSSQL7DB \TEMPDB \<SID>sapdata1 \<SID>sapdata2 \<SID>sapdata3 \<SID>saplog \usr\sap \usr\sap\trans
Drive letter J: J: J: H: H: H: I: S: S:
121

Figure 39 on page 123 shows the interdependencies between Tivoli Data Protection for SQL Server and Tivoli Storage Manager in an SAP R/3 environment. The diagram highlights the important files and environment variables that control the operation of the backup system, and illustrates the relationships among them. Looking closer at the elements that form the backup system, the diagram consists of two major parts, the SAP R/3 server and the Tivoli Storage Manager server. Within the TSM server, we show the important elements necessary for an SAP R/3 system configuration. These are primarily the TSM Management Classes with which the files to be backed up are associated. On the SAP R/3 system, the TSM Scheduler Service executes the command files for backup when requested to do so by the TSM server. In our example, these command files are called log_backup.cmd, full_db_backup.cmd, and auto_delete_backup.cmd. SQL Server consists itself of several databases, such as MSDB and the master database. We must also, of course, back up the SAP R/3 database <SAPSID>. The Tivoli Data Protection for SQL Server agent uses the TSM API Client to back up these databases. Two different option files are created for database backups. dsmdb.opt is used for database backup, using the SQL_DB Management Class. Database logs are backed up using the settings in dsmlog.opt, which uses the SQL_LOG Management Class. The dsm.opt file is used for backing up normal files such as those belonging to the operating system files or the SAP R/3 executables.
122
SAP R/3 SQL Server 7.0

MSDB database Master database
DB12 DB13
Policy Domain SAPSQL Policy Set SAPSQL

MGMT-Class SQL_DB Backup Copy Group
<SAPSID> database
TDP SQL Agent
MGMT-Class SQL_LOG dsmdb.opt

TCPSERVERADDRESS NODE INCLUDE * SQL_DB
dsmlog.opt
TCPSERVERADDRESS NODE INCLUDE * SQL_LOG
dsm.opt
Backup Copy Group
Node
Schedules
TSM API Client

log_backup.cmd full_db_backup.cmd
TSM Client
auto_delete_backup.cmd
Event log
Activity log
TSM Server
SAP R/3 Server


tsm: TSMSRV> register node sapsql sap domain=r3sql
At the time we wrote this book, SQL Server did not support the use of multiple backup sessions so we left the parameter maxnummp at its default value of 1 (see 6.1.2, Additional TSM Server configuration on page 81 for an example of how this parameter can be used when multiple sessions are supported).

Now you need to install the TSM client software. Remember that the TSM client runs on the SAP server and requests service from the TSM backup server. We used the following steps to install the client:
123
1. Use the setup command to start the installation and click Next to start the installation. 2. Enter the destination folder for installation. We kept the default folder: D:\Program Files\Tivoli\TSM. 3. Select the type of installation you require: Compact, Custom or Typical. We chose Custom. 4. To install only the client clear all check boxes except for the one to select Client files. Make sure Client files is selected and click the Change button. Within the subsection we chose only the Backup-Archive Client Files. This selection includes the API Client Runtime Files, which are needed for Tivoli Data Protection for MS SQL Server. 5. Click Next and select the Start menu folder for the TSM programs. We kept the default, which is Tivoli Storage Manager. Then click Next again. 6. We deselected View README file and Start Tivoli Storage Manager. 7. Reboot the server. After the installation, we configured the TSM option file (DSM.OPT) in d:\program files\tivoli\tsm\baclient for normal incremental file backup. We excluded the following system files: All All All All page files files in the recycler user profiles on D: registry hives on D:
We also excluded all SAP R/3 data and log files and SQL Server data and log files for other databases such master, model, and tempdb. The following screen shows our DSM.OPT file:
NODENAME sapsql TCPSERVERADDRESS sapitsodc PASSWORDACCESS GENERATE Exclude.dir d:\WINNT\system32\config Exclude d:\WINNT\Profiles\...\NTUSER.DAT Exclude d:\WINNT\Profiles\...\ntuser.dat.LOG Exclude ?:\...\dsm*.log Exclude ?:\???data?\*.* Exclude ?:\???log?\*.* Exclude ?:\MSSQL7DB\data\*.mdf Exclude ?:\MSSQL7DB\data\*.ldf Exclude.dir ?:\tempdb Exclude ?:\pagefile.sys Exclude ?:\recycler\...\* Exclude ?:\recycler\...\*.*

Tivoli Storage Manager allows us to set up a central scheduling configuration where the TSM server initiates the backup process. To allow the client to respond to a backup request, we have to define a TSM scheduler service on the SAPSQL
124
node. The following screen shows the dsmcutil command that sets up the scheduler service: . > d: > cd \program files\tivoli\tsm\baclient > dsmcutil inst /name:TSM scheduler service /NODE:SAPSQL /password:sap /autostart:yes Unlike implementations using Oracle or DB2, there is no need to provide additional rights to the TSM scheduler, since access is controlled by the user ID and password within the backup scripts.
8.1.5 Tivoli Data Protection for SQL Server

We chose the following options for the installation of the TDPSQL: 1. Use the setup command to start the installation and click Next to start the installation. 2. Choose the destination folder. We kept the default folder: D:\Program Files\Tivoli\TSM. 3. Select the type of installation you require: Compact, Custom or Typical. We selected Custom. 4. We selected everything (TDP for MS SQL Server Program Files, TDP for MS SQL Server Licenses, TDP for MS SQL Server Users Guide). After selection click Next. 5. Select the Start menu folder for the TSM programs. We kept the default, which is Tivoli Storage Manager. After selection, click Next. 6. After this you have to fill out the Registration sheet to finish the installation. You can do this also later. 7. We rebooted the server. We created two option files for Tivoli Data Protection for SQL Server: one for the database file and one for the logs. Tivoli Data Protection for SQL Server has no built-in parameter to associate a backup to a particular TSM management class. This means that every backup uses the same management class by default, and hence the same storage pool and tapes. In order to separate the database files from the log files, we had to create two different TSM client option files, using the include parameter to associate the files to a management class. The SQL Server backup utility allows you to define a separate TSM option file, and so we are now able to use different management classes for the database and the log files. We put the option file in the default directory of the TDP SQL Agent, which is in our case D:\program files\tivoli\tsm\mssql.
125
Here is the option file, which we called dsmdb.opt, that we created to control the backup of the database files:
COMMMethod TCPPort TCPServeraddress NODename CLUSTERnode COMPRESSIon PASSWORDAccess TAPEPrompt *SQL_MOUNTWait include * SQL_DB
TCPip 1500 TSMSRV SAPSQL No On Generate Yes Yes
Figure 40. TDP for SQL dsmdb.opt option file for database files
And here is the similar file, which we called dsmlog.opt, that we created to control the backup of the log files:
COMMMethod TCPPort TCPServeraddress NODename CLUSTERnode COMPRESSIon PASSWORDAccess TAPEPrompt *SQL_MOUNTWait include * SQL_LOG
TCPip 1500 TSMSRV SAPSQL No On Generate Yes Yes
Figure 41. TDP for SQL dsmlog.opt option file for log files
The manual recommends that you use the Verdelete parameter for backupcopygroup = 0, because each backup file has its own individual name within TSM. If not TSM will never delete files on backup tapes because they never expire. Backup files in TSM may be deleted using the delete function of TSPSQL. The performance of TDP for SQL can be tuned using the following parameters in the TSM option files: Compression ON or OFF. /BUFFERS:n - the default for n is 3 and n may range from 2 to 8.

126
Figure 42. DB13 for SQL Server
Another possibility is to write scripts to control backup processes and then use the Windows NT scheduler to execute the commands as required. The Windows NT at command allows you control the timing and frequency of backups. A third possibility is to use the scheduling mechanism of Tivoli Storage Manager. We chose to implement a combination of SAP scheduling with DB13 and scheduling with TSM. In our scenario, scheduling for the backup of database files and archiving redo logs is done by TSM, so that all backups (database, logs, files) are maintained by TSM. All other scheduling for the SQL database is done using SAP R/3s scheduler. In this book, we do not explain how to set schedules within transaction DB13 that are not related to backup.
8.2.1 MS SQL Server database and transaction log backups

We developed several scripts to control the different types of backup needed to implement our backup strategy. Because these scripts are started by the TSM scheduler service, you have to set all environment variables within them. We created the scripts in the Backint command files directory, which is located in D:\program files\tivoli\tsm\backint\.
127
8.2.1.1 Full online database backup Here is our script to perform a full online database backup for MS SQL Server:
echo on rem -------------------------------------------------------------------rem file name: full_db_backup.cmd rem -------------------------------------------------------------------rem -------------------------------------------------------------------rem execute full online backup without truncating the log rem -------------------------------------------------------------------d: cd \progra~1\tivoli\tsm\mssql rem full backup of master database d:\progra~1\tivoli\tsm\mssql\sqldsmc /sqlserver:sapsql /sqluser:sa /sqlpwd: /adsmoptfile:d:\progra~1\tivoli\tsm\mssql\dsmdb.opt /backupfull:master rem full backup of msdb database d:\progra~1\tivoli\tsm\mssql\sqldsmc /sqlserver:sapsql /sqluser:sa /sqlpwd: /adsmoptfile:d:\progra~1\tivoli\tsm\mssql\dsmdb.opt /backupfull:msdb rem full backup of PR1 database d:\progra~1\tivoli\tsm\mssql\sqldsmc /sqlserver:sapsql /sqluser:sa /sqlpwd: /adsmoptfile:d:\progra~1\tivoli\tsm\mssql\dsmdb.opt /backupfull:PR1 8.2.1.2 Log file backup We also need a script to back up the log files. Here is our example:
echo on rem -------------------------------------------------------------------rem file name: log_backup.cmd rem -------------------------------------------------------------------rem -------------------------------------------------------------------rem execute log backup with truncate rem -------------------------------------------------------------------d: cd \progra~1\tivoli\tsm\mssql rem log backup with truncate d:\progra~1\tivoli\tsm\mssql\sqldsmc /sqlserver:sapsql /sqluser:sa /sqlpwd: /adsmoptfile:d:\progra~1\tivoli\tsm\mssql\dsmlog.opt /backupincr:PR1
128
8.2.1.3 Automatic deletion of backups To finish, we need a script to automatically delete old backup files:
echo on rem -------------------------------------------------------------------rem file name: auto_delete_backup.cmd rem -------------------------------------------------------------------rem -------------------------------------------------------------------rem execute log backup with truncate rem -------------------------------------------------------------------d: cd \progra~1\tivoli\tsm\mssql rem auto delete backup older than 28 days d:\progra~1\tivoli\tsm\mssql\sqldsmc /adsmautodelete:PR1 /ifolder:28 /sqlserver:sapsql /sqluser:sa /sqlpwd: /adsmoptfile:d:\progra~1\tivoli\tsm\mssql\dsmdb.opt

Tivoli Storage Manager allows you to establish schedules for your backups to suit your needs. The schedule and backup strategy you decide upon will have to take into account several factors including: How frequently do you wish to take backups? How long do you have to take backups that require the system to be offline? How long do you think you can afford to take to restore your data? There will be a minimum time based on how much data you have to restore. The following table shows the backup schedule we planned for our lab systems:
Table 26. Backup schedule strategy for SAP R/3 and SQL Server
Task Database online backup Archiving database logs to tape Incremental backup of other files Delete old backups
Time Every weekday at 20:00 Every weekday at every hour except during the database online backup Every weekday at 06:00 Every weekday at 24:00
To define a client schedule for a TSM node, you have to do two things. First you have to set the schedule timings and then you have to associate nodes to the schedule.
129
Here is a sample TSM macro to define a weekday schedule for database online backups, including the association of node SAPSQL to this schedule:
DEFINE SCHEDULE R3SQL full_online_backup \ DESCRIPTION="Full online Database backup" \ ACTION=COMMAND \ OBJECTS="D:\backup\full_db_backup.cmd" \ Priority=2 \ STARTTIME=22:00:00 \ DURUNITS=HOURS \ PERUNIT=DAY \ DAYOFWEEK=WEEKDAY DEFINE ASSOCIATION R3 full_online_backup SAPSQL The macros for the other database backups are similar. To define the daily incremental schedule (Monday - Friday) we used this TSM macro:
DEFINE SCHEDULE R3SQL daily_incr \ DESCRIPTION="Daily incremental backup" \ ACTION=INCR \ Priority=2 \ STARTTIME=06:00:00 \ DURUNITS=HOURS \ PERUNIT=DAY \ DAYOFWEEK=WEEKDAY DEFINE ASSOCIATION R3 daily_incr SAPSQL

After writing all of the necessary scripts and having defined the necessary schedules, your system backup should work automatically. The reason for taking backups is to protect yourself against loss of data and it is important to check that your backup process is working correctly. So what you have to do every day as an SAP backup administrator is to check that your backups were made successfully. Checking the backup includes the following tasks: 1. Check your backups using SAP R/3 transaction DB12. This transaction looks into the SQL Server backup history:
130
Figure 43. DB12 transaction for SQL Server
2. Check the events for your schedules on a daily basis. Here is an example of a TSM command to examine all events that have occurred and will occur in the TSM domain named R3SQL for the period from yesterday until tomorrow. This will show you which schedules have been executed, their results and also future events scheduled for today and tomorrow.
tsm: TSMSRV> QUERY EVENT R3SQL * BEGINDATE=TODAY-1 ENDDATE=TODAY+1 3. Check the TSM logs on the SAP system, which are: dsmsched.log Here you find the results of actions executed by the local TSM Scheduler service. Because all of our backups are executed by this service, everything relevant to our backups is located here. You should monitor the size of this log file because it is growing constantly. When necessary, take steps to reduce its size by deleting older data. This file is the error log for manual file backup-and-restore commands. It should be monitored for errors. This file is the error log for the TSM API client, used by Backint. It should be monitored for errors. Here you find the log of TDP for SQL. By default this file is located in the TDP for SQL installation directory.
dsmerror.log dsmierror.log sqldsm.log
tsm: TSMSRV> query actlog
131
For more information about the query actlog command see the TSM Reference Guide shipped with the TSM product.

When recovering an SAP system that uses SQL Server, the first thing to do is to restore the master database. This important database plays a central role in the system because it contains the system catalog that holds important information about your SQL Server configuration. Restoring the master database requires a careful series of steps to be executed. When you rebuild the master database, the msdb database is dropped and recreated again, which means that this second database must also be restored. Here are the steps: 1. Run the SQL Server setup program to rebuild the master database. You must rebuild using the same character set and sort order as the master database backup that will be restored. 2. Start the SQL Server in single-user mode. 3. Use TDPSQL to restore the master database. 4. Restart the SQL Server normally (in multi-user mode). 5. Manually reapply any changes that were made to the master database after the date of the database copy used for the restore operation. 6. Use the SQL application client to restore the msdb database. Now let us look at two scenarios that cover many situations where a recovery is necessary: 1. A disk crash means that some or all of your SAP R/3 data files are corrupted. These are the steps we recommend to recover from this situation: a. Delete all data and log files. b. Start the Tivoli Data Protection GUI to control the recovery c. On the Tivoli Storage Manager server, specify the following option: Set commtimeout to 3600 or more (the default is 60). In our environment it took SQL Server 5 minutes per gigabyte to create the data and log files. SQL Server does not communicate with the TSM server while these databases are being created and the session will be closed if commtimeout is exceeded. 2. If your system is functioning normally but you wish to recover to an earlier state, this is our recommended approach: a. b. c. d. e. Change the database operating mode to single user. Restart the database. Start the Tivoli Data Protection GUI to control the recovery. When the database has been recovered, change back to multi-user mode. Restart the database.
The recovery procedure for the SAP R/3 system with Tivoli Data Protection for SAP R/3 is similar to recovering an SAP R/3 system with normal recovery procedures. Of course, you have to make sure you have a connection to your TSM Server and that you have installed the TSM client for file recovery and Tivoli 132
Data Protection for SAP R/3 to restore your database and logs. In addition, you will need the appropriate tapes available to the tape library. If the tapes are not available, Tivoli Storage Manager will notify you and indicate which tapes are required. The process we describe assumes that you had a properly working system without any hardware or software errors prior to the incident that necessitated a recovery. To successfully recover, you must make sure your system is fully functional. That is, any hardware or software failures must have been corrected. The following flowchart shows one possible recovery strategy:
Repair Hardware
OK
Check SAP
OK
System OK
Fail
Repair Hardware
OK
Check Win NT
Fail
Recover Win NT
Check Files
OK
Fail Restore files
OK
User error
Repair SAP
Fail
Check Database
Fail
Recover database
Check SAP
OK
System OK
Figure 44. Recovery procedure for SAP R/3 and SQL Server database
Note that the flowchart in Figure 44 refers to recovery from hardware errors and user errors. We assume that, prior to the failure that necessitates recovery, your SAP R/3 system was working well and running without any errors. That is, there are no faulty device drivers or other software that could cause problems. We can divide hardware problems into two classes: those that crash the system and those that do not because the system was protected by redundant components such as a RAID disk array or a redundant power supply. In the latter situation, after you have repaired your hardware successfully, you should always check your system by checking the SAP R/3 system log to
OK
Fail Call Help
OK
133
determine whether any jobs have failed or there are any other signs of problems. If there are no errors, your system is up and running correctly again. However, if the hardware error has crashed your system or SAP has problems (and this can include a blue screen trap, corrupted operating system or database and so on), you should start a bottom-up process to check and repair your whole system. This means you should check Windows NT first. You should check that you can start both Windows NT partitions (the production and backup Windows NT installation). Check that all services are online, and see if there any messages in the Windows NT event log. This will help to make sure that your network and other essential subsystems are working properly. If there is a problem, you should try to recover the production Windows NT partition first. If you cannot repair the first partition, then attempt to recover using the second Windows NT installation. So, here is our suggested sequence of preferred methods to recover Windows NT: Use a Windows NT repair disk Use a Windows NT boot diskette Use the second Windows NT partition with the TSM client If both Windows NT installations cannot be recovered, you will have to install a new second copy of Windows NT and TSM client software, making sure to configure them to be able to access the network and the TSM server and then restore your production system. Having achieved a functional Windows NT installation, the next step will be to check all Windows NT partitions, in particular, the partitions containing the SQL Server database and the SAP R/3 software. The checks should also include any database files that are needed for startup and recovery. After all the files on your system are in place, you can check the database itself. If there are any errors when you open the database, you will have to recover the database to its most recent backed-up state. Once you have successfully recovered your database, you need to check your SAP system again. This time, everything should now be operating correctly. You should be aware that you might have to repeat lost transactions. Looking again at the flowchart in Figure 44 on page 133, if a user error has caused the problem, the recovery procedure starts at a later point, since you do not have to repair hardware or recover Windows NT. If you can recover the user failure within your SAP system then you don't need to perform a database restore, which can save a lot of time. Should you need to restore your database, make sure everything is working as expected prior to the restore. After successfully restoring the SQL Server database, you need to check your SAP system again. Of course, you have to reapply any changes made to your database since the backup that has been restored. This procedure should give you a general overview of backing up and recovering your SAP system. We can't show an example here because there is no typical restore scenario. You always have to analyze your system in order to know what actions you have to take. We recommend that you make yourself familiar with the
134
135
136
Chapter 9. MSCS environments: an Oracle-based example

If your company has made the decision to base its business operations on SAP R/3, you will quickly understand the mission-critical nature of the system. To avoid the cost of downtime, you may choose to implement a Microsoft Cluster Server-based system. Such systems impose their own requirements on backup-and-recovery processes. This chapter takes you through the steps we recommend to implement backup and recovery for clustered SAP R/3 4.5B systems that use the Oracle database. The general principles, however, are applicable no matter which database is used. The information you will find here is based on an actual SAP R/3 backup system. We installed several complete SAP R/3 systems in our laboratory during the writing of this book. This allowed us to test and validate what we wanted to say so that we could be sure the information is accurate and up-to-date. We give specific details of the hardware and software configurations we used, which should help you to implement your own solutions simply and quickly. We begin by examining the hardware configuration and then move on to look at the way in which the various software components are related to each other. Each component is installed and configured to complete the backup solution. The chapter closes by illustrating possible backup and recovery processes with example batch command files. A typical MSCS implementation of SAP R/3 is described in 2.3, Microsoft Cluster Server on page 11. If you are unfamiliar with the way in which Microsoft Cluster Server can help to increase the availability of an SAP R/3 installation, you may want to refer to the following redbooks: Implementing SAP R/3 4.5B using Microsoft Cluster Server on IBM Netfinity Servers, SG24-5170 Netfinity Clustering Planning Guide, SG24-5845
In the screen captures used in this chapter, many commands are preceded by the Tivoli Storage Manager command prompt. TSMSRV was the name of our TSM server, so our TSM prompt was: tsm: TSMSRV> The other commands are invoked from the Windows NT command line and follow the normal Windows NT command prompt, shown as D:\> (for example) for clarity, but in practice this depends on the prompt setting for the system. Commands that are too long for a single line are continued on the following line or lines. This is indicated by the continuation character: \.

In our laboratory, we installed a number of SAP R/3 systems. For this particular example, we used two Netfinity 7000 M10 systems running Microsoft Cluster Server to run the Oracle database and SAP application servers in a two-tier
137
configuration. Most SAP installations are two-tier so this represents the majority of real-life situations. Backing up the database is the most complex part of the backup solution, so extending our example to a three-tier installation is straightforward. The clustered SAP servers were configured with both internal SCSI disks and an external Fibre Channel array of disks which were used as cluster storage. A 100 Mbps Ethernet crossover cable connected the two servers to form the heartbeat link necessary for cluster operation. For the Tivoli Storage Manager server, we used a Netfinity 5000 server connected to a 3447 DLT tape library with two physical tape drives. The servers were connected together using a 100 Mbps Ethernet network which was also the network used for client access to the servers. Figure 45 below illustrates our configuration and provides information about the various adapters we used and where they were installed in each server:
MSCS clustered SAP R/3 system Netfinity 7000 M10 2 x 9 GB disks 1

8 2 3 4 2
Netfinity 7000 M10 2 x 9 GB disks 1

8 3 4
100 Mbps Ethernet
Tape library KEY 1 ServeRAID-3L (slot 2 driving internal disks) 2 Fibre Channel adapter (slot 1) 3 Fibre Channel adapter (slot 6) 4 Etherjet adapter (slot 12) 5 ServeRAID-3H (slot 1 driving internal disks) 6 Onboard Ethernet adapter 7 Onboard SCSI-2 F/W adapter driving tape 8 Etherjet adapter (slot 9)
Figure 45. Backup solution hardware for SAP R/3 using Oracle in an MSCS environment
Further hardware details that are relevant are: The BIOS of the Netfinity 7000 M10 systems we used was at Release 5. The ServeRAID-3L adapters we used to drive the local disks in the SAP servers were at BIOS and firmware level 3.50C. RAID adapter parameters were set to their default values.
138
The ServeRAID-3L adapters were each configured with a single RAID-1 array (A), comprising two 9 GB disks, and providing a total capacity of 9 GB. The arrays were each set up as three RAID logical drives as shown in Table 27:
Table 27. ServeRAID configuration for SAP R/3 using Oracle in an MSCS environment
Logical drive 0 1 2
Note
IBMs ServeRAID adapters provide the ability to back up their RAID configuration data to diskette. We strongly recommend that you take advantage of this feature. You can use this to recover your ServeRAID configuration in the case of hardware failure. When a SCSI-based cluster is configured, the ServeRAID write policy must be set to Write-through. Here, however, the ServeRAID adapter is driving only the local disks, so if your ServeRAID adapter has battery-backed up cache, you can set the adapters write policy to write-back, which will boost disk subsystem performance. For our Fibre Channel Installation we used following levels of Software: Netfinity Fibre Channel PCI Adapter BIOS Version: Netfinity Fibre Channel RAID support Firmware: 1.35 3.01.01.00
Netfinity Fibre Channel PCI Adapter Windows NT 4.0 Driver:6.16 Symplicity Storage Manager Release: Our general Fibre Channel configuration looks like this:
Table 28. Fibre Channel configuration for SAP R/3 4.5B on Oracle Installation
06.22.25.15
Drive group 1
LUN 0 4
RAID 1 1 5 1 1
Capacity 1GB 2GB 26GB 2GB 9GB
Disk label q s_sap h_sapdata j_onlinelog i_offlinelog
Drive letter Q: S: H: J: I:
2 3 4
1 3 2
Note
For security, you should save your Fibre Channel configuration files to disk.
The following table shows how we chose to distribute the SAP files within the system. Note that the third column in Table 29 indicates whether or not a
139
particular directory is located on both servers local disk or in the external shared disk enclosure:
Table 29. File distribution of SAP R/3 4.5B on Oracle
Directory name \winnt \orant \oracle\PRD\sapdata1 \oracle\PRD\sapdata2 \oracle\PRD\sapdata3 \oracle\PRD\sapdata4 \oracle\PRD\sapdata5 \oracle\PRD\sapdata6 \oracle\PRD\saparch \oracle\PRD\sapbackup \oracle\PRD\sapcheck \oracle\PRD\sapreorg \oracle\PRD\saptrace \oracle\PRD\origloga \oracle\PRD\origlogb \usr\sap \usr\sap\trans \mscs (MSCS quorum) \winnt\sapcluster Oracle fail safe agent:
Drive letter D: D: H: H: H: H: H: H: I: I: I: I: I: J: J: S: S: Q: D: J:
Local or shared Local Local Shared Shared Shared Shared Shared Shared Shared Shared Shared Shared Shared Shared Shared Shared Shared Shared Local Shared

The following additional software components were used in our implementation: Tivoli Tivoli Tivoli Tivoli Storage Manager Microsoft Client 3.7.1.0 Storage Manager Server for NT 3.7.1.0 Data Protection for SAP R/3 2.4x3 Data Protection for Workgroups 1.1.0.1
Figure 46 on page 142 shows the interdependencies between Tivoli Data Protection for SAP R/3 and Tivoli Storage Manager in a clustered Oracle-based SAP R/3 environment. The diagram highlights the important files and environment variables that control the operation of the backup system, and illustrates the relationships among them. Looking closer at the elements that form the backup system, the diagram consists of two major parts, the clustered SAP R/3 server (running on two physical nodes) and the Tivoli Storage Manager server. On the right of the diagram, within the
140
TSM server, we show the important elements necessary for an SAP R/3 system configuration. These are primarily the TSM Management Classes with which the files to be backed up are associated. To the left of the diagram is the SAP R/3 MSCS cluster, consisting of the two physical nodes (SAPNODEA and SAPNODEB). Three MSCS virtual servers have been defined. These are SAPCLUSTER, used by MSCS itself, and SAPDB and SAPR3. The latter two virtual servers are used to run the Oracle database and the SAP R/3 kernel, respectively. Within SAP R/3 Group, a TSM scheduler service has been created (as a generic service in MSCS). This scheduler service is configured using dsmr3.opt and executes the command files for backup when requested to do by the TSM server. Another TSM scheduler service has been created within the ORACLE_<SID> Group, which uses the dsmdb.opt configuration file. These files are duplicated on the local disks of both nodes since the virtual servers may run on either physical node. On the cluster common disk (H:) that belongs to the ORACLE_<SID> Group, we store the command files full_offline_backup.cmd, archive.cmd and full_online_backup.cmd. These files initiate the various backup processes when requested to do so by the TSM server. Other configuration files for Tivoli Data Protection for SAP R/3 are also located on a shared disk (H:). These include dsm.opt, init<SID>.bki, <server>.opt and init<SID>.utl.
141
Cluster Group
SAPCLUSTER
SAP-R/3 Group TSM Scheduler Service SAPR3 (generic service)
Policy Domain R3 Policy Set R3

MGMT-Class DB Archive Copy Group
SAPR3
ORACLE<SID> Group TSM Scheduler Service SAPDB (generic service) MGMT-Class LOG1 Archive Copy Group
full_offline_backup.cmd
dsm.opt [empty file] init<SID>.bki
archive.cmd
<server>.opt
full_online_backup.cmd
init<SID>.utl
CONFIG_FILE SERVER BRBACKUPMGTCLASS BRARCHIVEMGTCLASS
MGMT-Class LOG2 Archive Copy Group
NODE SERVERADDRESS
Disk H: (physical disk)
SAPDB
Nodes SAPNODEA SAPNODEB SAPCLUSTER SAPR3 SAPDB
Schedules
TSM Scheduler Service TSM Client + API Client Backint

dsm.opt NODE=SAPNODEA DOMAIN=C: D: E:
TSM Scheduler Service TSM Client + API Client Backint

dsm.opt NODE=SAPNODEB DOMAIN=C: D: E:
Event log
Activity log
TSM Server
dsmr3.opt NODE=SAPR3 CLUSTERNODE=YES DOMAIN=S:
dsmr3.opt NODE=SAPR3 CLUSTERNODE=YES DOMAIN=S:
dsmdb.opt NODE=SAPDB CLUSTERNODE=YES DOMAIN=H: I: J:
dsmdb.opt NODE=SAPDB CLUSTERNODE=YES DOMAIN=H: I: J:
init<SID>.sap util_par_file=H:\backup\init<SID>.utl backup_dev_type=util_file
init<SID>.sap util_par_file=H:\backup\init<SID>.utl backup_dev_type=util_file
SAPNODEA
SAPNODEB
Figure 46. Configuration of TSM server, TSM client and SAPs Backint interface

We assume you have completed the Tivoli Server Management installation and configuration as described in Chapter 5, Tivoli Storage Manager setup and configuration on page 63. The only additional configuration required is to register the cluster nodes using the following commands:
142
register register register register register
node node node node node
SAPNODEA sap domain=r3 backdelete=yes SAPNODEB sap domain=r3 backdelete=yes SAPCLUSTER sap domain=r3 backdelete=yes SAPR3 sap domain=r3 backdelete=yes SAPDB sap domain=r3 backdelete=yes maxnummp=2
Note
In TSM Server 3.7, multiple client sessions for file backup are introduced. To activate this new feature, which increases performance by allowing concurrent backup to multiple tape drives, a new node parameter maxnummp is introduced. This parameter limits the number of sessions a client may use to access sequential storage media and defaults to the value 1. To allow our installation to back up both the database and log files simultaneously, we set the value of maxnummp to 2.

Now you need to install the TSM client software. Remember that the TSM client runs on the SAP server and requests service from the TSM backup server. Because we want to back up the local drives on each node and have to remember that either node in the cluster may own the database when a backup is scheduled to occur, the software is installed locally on both cluster nodes. We used the following steps, repeated on both nodes, to install the client: 1. Use the setup command to start the installation and click Next to start the installation. 2. Enter the destination folder for installation. We kept the default folder: D:\Program Files\Tivoli\TSM. 3. Select the type of installation you require: Compact, Custom or Typical. We chose Custom. 4. To install only the client, clear all check boxes except for the one to select Client files. Make sure Client files is selected and click the Change button. Within this subsection we chose only the Backup-Archive Client Files. This selection includes the API Client Runtime Files, which are needed for Tivoli Data Protection for SAP R/3. 5. Click Next and select the Start menu folder for the TSM programs. We kept the default, which is Tivoli Storage Manager. Click Next again. 6. We deselected View README file and Start Tivoli Storage Manager. 7. Reboot the server. After the installation we configured the default option file (DSM.OPT) in d:\program files\tivoli\tsm\baclient for normal incremental file backup. We excluded following system files: All All All All page files files in the recycler user profiles on d: registry hives on d:
143
Local disks We need to ensure that the physical nodes in the MSCS cluster back up only data from their local drives and not the clustered SAP data held on the common disk subsystem. To achieve this, we included a DOMAIN statement specifying just the local drives in the DSM.OPT option files on both nodes. Here are the two DSM.OPT nodes, first for node A:
NODENAME SAPNODEA TCPSERVERADDRESS TSMSRV PASSWORDACCESS GENERATE DOMAIN C: D: E: Exclude.dir d:\WINNT\system32\config Exclude d:\WINNT\Profiles\...\NTUSER.DAT Exclude d:\WINNT\Profiles\...\ntuser.dat.LOG Exclude ?:\pagefile.sys Exclude ?:\recycler\...\* Exclude ?:\recycler\...\*.* Exclude d:\winnt\cluster\clusdb Exclude d:\winnt\cluster\clusdb.log Then for node B:
NODENAME SAPNODEB TCPSERVERADDRESS TSMSRV PASSWORDACCESS GENERATE DOMAIN C: D: E: Exclude.dir d:\WINNT\system32\config Exclude d:\WINNT\Profiles\...\NTUSER.DAT Exclude d:\WINNT\Profiles\...\ntuser.dat.LOG Exclude ?:\pagefile.sys Exclude ?:\recycler\...\* Exclude ?:\recycler\...\*.* Exclude d:\winnt\cluster\clusdb Exclude d:\winnt\cluster\clusdb.log
After you have configured the DSM.OPT file for local backup, you should connect once to the TSM server for each client server. This will store your password in the client machines registry and you will not have to enter the password again. Clustered Disks The external disk subsystem forms a set of resources available to Microsoft Cluster Server. These resources are allocated to resource groups that are made available on the client network, appearing to users as virtual servers. These virtual servers can exist on either one of the two physical servers, but only one at any given time. Users must connect to a virtual server to gain the advantages of failover. That is, if the physical server hosting a particular virtual server fails, the MSCS software transfers ownership of the virtual server and all of its resources to the surviving physical server. Connected users see only a brief interruption in service. Users connected to a physical server that fails will lose access to all resources that were on that server.
144
We defined two virtual servers (SAPR3 and SAPDB), which run the SAP R/3 executables and the Oracle database respectively. In normal operation, one of the physical servers will host SAPR3 while the other hosts SAPDB. If one of the physical servers fails, the survivor will then host both virtual servers. Bearing the above in mind, we could locate the TSM option file for data on the clustered disks either on those same disks or on the local disks of both machines (necessary because a virtual server can exist on either physical system). We chose to put the option file for the backup and recovery of clustered disk resources on the local disks of each physical system. The advantage of doing so is that the recovery of files stored on the clustered disks is simplified because you always use a local TSM client to recover shared disks. For example, if you have stored the TSM client configuration file for the virtual server on the shared disks, you have to create a new configuration file using TSM server information before you can recover the shared disks. Of course the disadvantage of this implementation is that you have to maintain two copies of the option file. We created a common backup directory on one disk for each cluster group. This has the advantage that we get central logging of the Cluster scheduler service and the error log file for backup of shared disks. We also used this directory to store the backup scripts for the Oracle Cluster group in one common place. The screen below shows the SAPR3.OPT option file for the SAPR3 virtual server. A copy of this file was stored on each physical server in the directory D:\program files\tivoli\tsm\baclient.
NODENAME SAPR3 CLUSTERNODE YES TCPSERVERADDRESS TSMSRV PASSWORDACCESS GENERATE DOMAIN S: BACKUPREGISTRY NO SUBDIR YES ERRORLOGNAME s:\backup\dsmerror.log SCHEDLOGNAME s:\backup\dsmsched.log
145
An option file for the SAPDB virtual server (SAPDB.OPT) is also needed and we stored this in the same directory as the previous file, again on both systems:
NODENAME SAPDB CLUSTERNODE YES TCPSERVERADDRESS TSMSRV PASSWORDACCESS GENERATE DOMAIN H: I: J: BACKUPREGISTRY NO SUBDIR YES Exclude ?:\oracle\???\sapdata*\...\*.* Include ?:\...\cntrl???.dbf Exclude ?:\...\saparch\???ARCH*.* ERRORLOGNAME h:\backup\dsmerror.log SCHEDLOGNAME h:\backup\dsmsched.log

Tivoli Storage Manager allows us to set up a central scheduling configuration where the TSM server initiates the backup process. To allow the client to respond to a backup request, we have to define a TSM scheduler service for each of the physical servers (SAPNODEA and SAPNODEB) on the SAPR3 node. The following screens show the dsmcutil commands that set up the scheduler service on each machine. Make sure each node has already been connected to the TSM server so your connection is known to be working and your password has been initialized within the registry. For this reason we call the TSM client for each option file and query the management class with which the client is associated. First for node A: . C:\> d: D:\> cd "\program files\tivoli\tsm\baclient" D:\> dsmc q mgm -optfile=dsm.opt D:\> dsmcutil inst \ /name:"TSM scheduler service SAPNODEA"\ /NODE:SAPNODEA \ /password:sap \ /autostart:yes Then for node B:
C:\> d: D:\> cd "\program files\tivoli\tsm\baclient" D:\> dsmc q mgm -optfile=dsm.opt D:\> dsmcutil inst /name:"TSM scheduler service SAPNODEB" \ /NODE:SAPNODEB \ /password:sap \ /autostart:yes
146
We also have to define TSM scheduler services for the SAP R/3 (SAPR3) and Oracle (SAPDB) resource groups. These services have to be defined on both physical nodes as either node could be hosting these virtual servers when a backup is initiated.
Note
When you issue the dsmcutil command to install the TSM scheduler service, make sure you have moved the relevant virtual server and its resources to the node where you are executing the dsmcutil command.
First for the SAPR3 virtual server:
C:\> d: D:\> cd "\program files\tivoli\tsm\baclient" D:\> dsmc q mgm -optfile=sapr3.opt D:\> dsmcutil inst \ /name:"TSM scheduler service SAPR3"\ /clientdir:"d:\program files\tivoli\tsm\baclient" \ /optfile:"d:program files\tivoli\tsm\baclient\sapr3.opt" /group:SAPCLUSTER /clusternode:yes /node:SAPR3 \ /password:sap \ /autostart:no
Then for the SAPDB virtual server:
C:\> d: D:\> cd "program files\tivoli\tsm\baclient" D:\> dsmc q mgm -optfile=sapdb.opt D:\> dsmcutil inst \ /name:"TSM scheduler service SAPDB" \ /clientdir:"d:\program files\tivoli\tsm\baclient" \ /optfile: "d:program files\tivoli\tsm\baclient\sapdb.opt" /group:SAPCLUSTER /clusternode:yes /node:SAPDB \ /password:sap \ /autostart:no To allow the scheduler for SAPDB to execute the necessary backup commands, which are received from the TSM server, it has to have the necessary rights so that Windows NT will allow access to the database. A simple way to give the scheduler service the right to connect to the database is to run the service using the SAPservice<SID> account instead of the default system account. To do this you have to change the Log On As parameter to the <SID>adm account by opening the Services icon in the Control Panel and clicking Startup... for the TSM scheduler service. This has to be repeated on both SAPNODEA and SAPNODEB.
147
Figure 47. TSM scheduler service modification for Oracle
In our environment we chose to store nothing but quorum information on the MSCS quorum disk, so we did not implement a TSM scheduler service to back up this disk. The quorum disk can be recreated with the -fixquorum option of the cluster service. See MS knowledge base article Q172944, How to Change Quorum Disk Designation. 9.1.4.1 Making the TSM scheduler services available to MSCS After installing the TSM scheduler service for SAP R/3 and Oracle, these services have to be made available to the MSCS resource groups as generic services. The following steps and accompanying figures show you how we did this for our lab systems. First we set up the SAPR3 scheduler service: 1. Using the MSCS Cluster Administrator, Select File->New->Resource (Figure 48).
Figure 48. Defining a new resource to MSCS
148
2. Give the new resource a name and a description if you wish, and select its type, which is Generic Service. We assigned this service to the SAP-R/3 PRD group (Figure 49). Click Next.
Figure 49. Assigning a name and resource type
3. Next you define which nodes in the cluster are allowed to own the resource. We want both physical servers to be able to do so and therefore select both as possible owners (Figure 50). Click Next.
Figure 50. Defining possible resource owners
149
4. MSCS then asks you to identify the other resources in the group upon which the new resource is dependent (Figure 51). For the scheduler service to be able to operate correctly, it needs the virtual server network name and the physical disk holding the data to be backed up to be available. Click Next.
Figure 51. Defining resource dependencies
5. You then provide a name for the service (Figure 52). We used the same name that we gave to the resource. No additional parameters are required. Click Next.
Figure 52. Naming the new service
150
6. The last step of the configuration process for the new service allows you to define registry keys that need to be monitored (Figure 53). For this service you need to set SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\SAPR3. Click OK to complete the definition of the new resource.
Figure 53. Setting the Registry key to be monitored
Setting up the TSM scheduler service for the SAPDB resource group is similar so we just show steps that are either particularly important or significantly different from before: Give the new resource a name and a description if you wish, and select its type, which is Generic Service as before. This time, however, we assigned the service to the ORACLEPRD group (Figure 54).
Figure 54. Assigning a name and resource type
151
When you define which nodes in the cluster are allowed to own the resource, it is important to remember that we want both physical servers to be able to do so and therefore select both as possible owners (Figure 55).
Figure 55. Defining possible resource owners
When MSCS asks you to identify the other resources in the group upon which the new resource is dependent (Figure 56), it needs the virtual server network name as before but this time you should specify all of the disks used by the database:
Figure 56. Defining resource dependencies
152
For the SAPDB scheduler service you need to set SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\SAPDB (Figure 57). Click OK to complete the definition of the new resource.
Figure 57. Setting the Registry key to be monitored
This completes the configuration of the TSM scheduler services.
9.1.5 Tivoli Data Protection for SAP R/3

Tivoli Data Protection for SAP R/3 is the new name for a well-established product called Backint/ADSM. The name change took place not long before we wrote this book so you will see in our description of the installation that some names have not yet been changed to reflect the new product title. Depending on when you obtain the software, you too may find these older names being used. Installation is GUI-based and is started by executing the program backint_24X3_nt_service.exe. The numeric part of the filename indicates the version you are installing, so you can see that we installed Version 2.4X3. Test and product versions of the code and documentation can be downloaded from: http://www.de.ibm.com/ide/backint_adsm.html In addition to these files you need a password for starting the installation if you install the service version. If you are installing the program version you dont need a password.
Note
There are two important items we want to make you aware of at this point: 1. Be aware that the user variables are set to reflect the user who is logged on. So before you start the installation, please log on as <SID>ADM. This will allow you to use the SAP tools as you know them, after configuring IBM Backint/ADSM, whenever you are logged on as <SID>ADM. 2. Make sure you move all the resource groups to the node on which you do the installation. 3. Steps 1 through 14 below have to be completed on both physical nodes in the cluster. Here then are the steps we used to install Tivoli Data Protection for SAP R/3: 1. Start the installation by running the backint executable. 2. If you have a service version of TDP for SAP you have to enter the password now. If the password is correct the Continue button is no longer greyed out. The product version of TDP does not require a password. 3. You are now asked if additional help is needed during installation. We chose not to see the help by clicking the No button.
153
4. The Welcome dialog reminds you to exit any running Windows programs. Click Next to continue. 5. The Select Components dialog is displayed next and offers three options for installation: Standard (all files - 1200 KB) Minimum (only executables, profile, configuration file - 1160 KB) Custom (the files you select) We chose the standard installation. Click the Next button. 6. The Initial Target Directory dialog offers C:\win32app\ibm\backint_ADSM as the default destination folder. We clicked the Browse button to change this to D:\program files\tivoli\tsm\backint. We think it is more convenient to have all TSM-related software under a common directory, which, in our installation, we made d:\program files\tivoli\tsm. If the directory you select does not exist, you are asked if it should be created. After changing the directory, just click the Next button to continue. 7. The Executables Target Directory dialog defaults the destination folder to C:\oracle\C21\samnt\C21\sys\exe\run. We changed the destination target to the location of our SAP R/3 executables, which was d:winnt\sapcluster. Click Next to continue. 8. The Profile and Configfile dialog suggested D:\orant\database as the destination folder. We didnt alter this as it fit our environment. Click Next to continue. 9. The ADSM Client Option File dialog sets the location for the client option files. Sample option files are copied here during the installation. We changed the path from C:\...\sapmnt\C21\sys\exe\run\dsm_opt to D:\program files\tivoli\tsm\backint\dsm_opt. Click Next to continue. 10.The Start Copying Files dialog shows a summary of the current settings. Click Next to start the installation. 11.The installation program asks if you want to have a log file written in D:\program files\tivoli\tsm\backint\documentation. We chose Yes. 12.The next window asks you if you wish to set the user-environment variables. We selected No, because we chose to set these variables manually in the user environment of the <SID>adm user. 13.At the end of the installation procedure, the Setup Complete dialog is displayed. We didnt want either to read the readme.txt file or reboot the system, so we cleared the check boxes before clicking the Finish button. 14.An information box gives the message Setup Successfully Completed. After the installation, we defined the TSM API client environment variables for the <SID>adm user. We set the following variables: DSMI_CONFIG = H:\backup\tsmsrv.opt DSMI_LOG = D:\program files\tivoli\tsm\api DSMI_DIR = D:\program files\tivoli\tsm\api
154
The DMSI_DIR variable must contain the path where the DSCAMENG.TXT file resides. Finally, we rebooted the server. 9.1.5.1 Configuration of Tivoli Data Protection for SAP R/3 The next step is to configure Tivoli Data Protection for SAP R/3 to use the Tivoli Storage Manager server for backup and recovery.
Note
In the procedure described below, steps 1 and 2 have to be completed on both physical nodes. The remaining steps are performed on only one node, since they affect data held on the common disk subsystem. Here is how we did it: 1. Check Oracle parameter file d:\orant\database\initPRD.ora. See OSS note 0124361, Oracle database parameter setting for R/3 4.x.
Oracle parameters
We had to enter the following parameter, which is needed for SAP R/3 4.5 backups: control_file_record_keep_time = 30 2. Next there are some settings required in the SAPDBA profile (initPRD.sap), located in D:\orant\database. First we define that we will use the Backint interface: backup_dev_type = util_file Next we set the parameter that declares that we are running online backups by default: backup_type = online Then we define where the configuration file for the Backint program is located: util_par_file = H:\backup\initPRD.utl 3. We also have to set up the initPRD.utl and initPRD.bki files, located in H:\backup\. First we copied the provided sample files from the Backint installation directory: copy ...\initC21.bki to ...\initPRD.bki copy ...\initC21.utl to ...\initPRD.utl After copying the sample *.utl file we modified the new copy in the H:\backup\ directory as follows:
155
BACKUPIDPREFIX PRD___ # default SAP___ MAX_SESSIONS 2 # default 1 MAX_BACK_SESSIONS 2 # default 1 MAX_ARCH_SESSIONS 2 # default 1 MAX_RESTORE_SESSIONS 2 # default 1 BACKAGENT d:\winnt\sapcluster\backagent.exe REDOLOG_COPIES 2 # default 1 RL_COMPRESSION YES # default NO #MULTIPLEXING 3 # default 1 #DISKBUFFSIZE 32768 # default 32768 #ADSMBUFFSIZE 131072 # default 131072 #FRONTEND pgmname parameterlist # default none #BACKEND pgmname parameterlist # default none MAX_VERSIONS 20 # default 0 #BATCH YES # unattended automated operation #BATCH NO # manual operation #EXITONERROR NO # default no #REPORT NO # default no, yes = all, 2 = all + summary #TRACE YES # default no #TRACEFILE filename # default stdout #TRACEMAX 100 # default 100 CONFIG_FILE H:\backup\initPRD.bki #RETRY 5 # default 3 #TCPWAIT 1 # default 1 #FILE_RETRIES 3 # default 3 #SNMPTRAP xxx.xxx.xxx.xxx public DETAIL # default none #LOG_SERVER server_a WARNING # default none SERVER TSMSRV SESSIONS 2 PASSWORDREQUIRED NO #ADSMNODE SAPR3 BRBACKUPMGTCLASS DB BRARCHIVEMGTCLASS LOG1 LOG2 # USE_AT 0123456 END 4. Next we created the <server>.opt file for a Backint with TSM environment in the directory pointed to by DSMI_CONFIG. This is in our case also h:\backup\tsmsrv.opt. We use the dsmdb.opt file for incremental backup of the shared disks. copy d:\program files\tivoli\tsm\baclient\dsmdb.opt to h:\backup\tsmsrv.opt 5. We chose to implement automatic password control by setting PASSWORDACCESS GENERATE in the server.opt file and PASSWORDREQUIRED NO in the SERVER stanza of the init<SID>.utl file. Also, you are not allowed to define the ADSMNODE parameter in the init<SID>.utl file. In addition to this you have to switch authentication on for your TSM server: # # # # # # # Servername Max sessions Use a password ADSM Nodename Mngm-Classes Mngm-Classes Days for backup
156
tsm> set AUTHENTICATION ON We chose to have a password expiration period of 30 days for our system. You can set the password expiration period for your TSM server with the following command:
tsm> set PASSEXP 30
Attention
Before you connect to the TSM server with Backint, you should first connect with the TSM client. For example, you could issue the command: dsmc q mgm This is a once-only action, required to initialize the PASSWORDACCESS GENERATE function. If you have followed our procedure, you have already done this before creating the cluster scheduler services. 6. Add the following user environment variables for the <SID>adm user: PATH=...;D:\winnt\sapcluster SAPEXE=D:\winnt\sapcluster SAPMNT=\\SAPR3\sapmnt 7. Now you should perform a manual check of the installation: a. Start sapdba from a command prompt. b. Select h for backup. c. In the Backup menu, check to make sure the following entries are correct: b- Enter parameter file: init<SID>.utl c- Enter backup device type: external backup tool (Backint) e- Enter backup type: online d. Select a small tablespace for testing: d- Enter tablespace(s): PSAPUSER1D e. Start the backup procedure with option s. f. On completion, a message will inform you of success or failure.

There are several ways in which you could implement a backup procedure in the environment under consideration. First, you could use the scheduling mechanism built into SAP itself. This is the recommended strategy if you are not using third-party backup software. Database administration and backup planning is implemented in SAP transaction DB13. Figure 58 on page 158 shows you the types of backup you can select using this method:
157
Note
Please refer to OSS note 114287 to set up sapdba in a Microsoft Cluster environment.
Figure 58. DB13 for Oracle
Another possibility is to write scripts to control backup processes and then use the Windows NT scheduler to execute the commands as required. The Windows NT at command allows you control the timing and frequency of backups. A third possibility is to use the scheduling mechanism of Tivoli Storage Manager. We chose to implement a combination of SAP scheduling with DB13 and scheduling with TSM. In our scenario, scheduling for the backup of database files and archiving redo logs is done by TSM, so that all backups (database, logs, files) are maintained by TSM. All other scheduling for the Oracle database is done using SAP R/3s scheduler. In this book, we do not explain how to set schedules within transaction DB13 that are not related to backup.
9.2.1 Oracle database and redo log backups

We developed several scripts to control the different types of backup needed to implement our backup strategy. Because these scripts are started by the TSM scheduler service, you have to set all environment variables within them. We stored the scripts on the clustered storage in the H:\backup\ directory to avoid having to maintain two copies of these files.
158
9.2.1.1 Full online database backup Here is our script to perform a full online database backup:
@echo off rem Full Online Backup batch file for MSCS environment rem See also OSS 0114287 rem-------------------------------------------------------------------rem file name: full_online_backup.cmd rem-------------------------------------------------------------------rem Set PATH environment variable set PATH=d:\orant\bin;d:\winnt\sapcluster;D:\winnt\sytem32 rem set set set set TSM environment DSMI_CONFIG=h:\backup\tsmsrv.opt DSMI_DIR=d:\program files\tivoli\tsm\api DSMI_LOG=d:\program files\tivoli\tsm\api
rem Set Oracle environment variables set ORACLE_HOME=d:\orant set ORACLE_SID=PRD rem set set set set set set set set set set set set set set set Set SAP environmet variables SAPDATA_HOME=H:\oracle\PRD SAPARCH=I:\oracle\PRD\saparch SAPBACKUP=I:\oracle\PRD\sapbackup SAPCHECK=I:\oracle\PRD\sapcheck SAPDATA1=H:\oracle\PRD\sapdata1 SAPDATA2=H:\oracle\PRD\sapdata2 SAPDATA3=H:\oracle\PRD\sapdata3 SAPDATA4=H:\oracle\PRD\sapdata4 SAPDATA5=H:\oracle\PRD\sapdata5 SAPDATA6=H:\oracle\PRD\sapdata6 SAPLOCALHOST=SAPR3 SAPREORG=I:\oracle\PRD\sapreorg SAPTRACE=I:\oracle\PRD\saptrace SAPEXE=d:\WINNT\sapcluster SAPMNT=\\SAPR3\sapmnt
brbackup.exe -c -m all -t online
159
9.2.1.2 Full offline database backup The script for a full offline database backup is slightly different:
@echo off rem Full Offline Backup batch file for MSCS environment rem See also OSS 0114287 rem-------------------------------------------------------------------rem file name: full_offline_backup.cmd rem-------------------------------------------------------------------rem Set PATH environment variable set PATH=d:\orant\bin;d:\winnt\sapcluster;D:\winnt\sytem32 rem set set set set TSM environment DSMI_CONFIG=h:\backup\tsmsrv.opt DSMI_DIR=d:\program files\tivoli\tsm\api DSMI_LOG=d:\program files\tivoli\tsm\api
rem stop Oracle DB cluster resource d:\winnt\system32\cluster.exe RES PRD.world /OFF /WAIT:600 if not errorlevel 0 goto errorend d:\winnt\system32\net start OracleServicePRD brbackup.exe -c -m all -t offline_force d:\winnt\system32\cluster.exe RES PRD.world /ON /WAIT:600 :errorend
160
9.2.1.3 Archive redo log backups Our archive redo log backup script is very similar to the full online backup script:
@echo off rem archive batch file for MSCS environment rem See also OSS 0114287 rem-------------------------------------------------------------------rem file name: archive.cmd rem-------------------------------------------------------------------rem Set PATH environment variable set PATH=d:\orant\bin;d:\winnt\sapcluster;d:\winnt\sytem32 rem set set set set TSM environment DSMI_CONFIG=h:\backup\tsmsrv.opt DSMI_DIR=d:\program files\tivoli\tsm\api DSMI_LOG=d:\program files\tivoli\tsm\api
brarchive -sd -c

Tivoli Storage Manager allows you to establish schedules for your backups to suit your needs. The schedule and backup strategy you decide upon will have to take into account several factors including: How frequently do you wish to take backups? How long do you have to take backups that require the system to be offline? How long do you think you can afford to take to restore your data? There will be a minimum time based on how much data you have to restore.
161
The following table shows the backup schedule we planned for our lab systems:
Table 30. Backup schedule for SAP R/3 and Oracle using MSCS
Task Database online backup Database offline backup using force option Archiving database logs to tape Incremental backup of other files
Time Every Monday, Tuesday, Wednesday, Thursday on 22:00 Every Friday on 22:00 Every weekday at every hour Every weekday at 06:00
To define a client schedule for a TSM node, you have to do two things. First you have to set the schedule timings and then you have to associate nodes to the schedule. Tivoli Storage Manager does not allow a schedule to be defined for just Monday, Tuesday, Wednesday and Thursday, so you have to define four individual schedules. In total, therefore, we have to define seven distinct schedules. That is, four for online backup, one for offline backup, one for archive files and a final one for incremental file backup. Here is a sample TSM macro to define the Monday online backup schedule, including the association of node SAPR3 with this schedule.
DEFINE SCHEDULE R3 full_online_backup_monday \ DESCRIPTION="Full online Database backup on Monday" \ ACTION=COMMAND \ OBJECTS="h:\backup\full_online_backup.cmd" \ Priority=2 \ STARTTIME=22:00:00 \ DURUNITS=HOURS \ PERUNIT=WEEK \ DAYOFWEEK=MONDAY DEFINE ASSOCIATION R3 full_online_backup_monday SAPR3
The macros for the other database backups are similar. To define the daily (Monday to Friday) incremental schedule, for example, we used this TSM macro:
DEFINE SCHEDULE R3 daily_incr \ DESCRIPTION="Daily incremental backup" \ ACTION=INCR \ Priority=2 \ STARTTIME=06:00:00 \ DURUNITS=HOURS \ PERUNIT=DAY \ DAYOFWEEK=WEEKDAY DEFINE DEFINE DEFINE DEFINE ASSOCIATION ASSOCIATION ASSOCIATION ASSOCIATION R3 R3 R3 R3 daily_incr daily_incr daily_incr daily_incr SAPR3 SAPDB SAPNODEA SAPNODEB
162

After writing all of the necessary scripts and having defined the necessary schedules, your system backup should work automatically. The reason for taking backups is to protect yourself against loss of data and it is important to check that your backup process is working correctly. So what you have to do every day as an SAP backup administrator is to check that your backups were completed successfully. Checking the backup includes following tasks: 1. Examine your backups using SAP R/3 transaction DB12. This transaction looks at the log files of brbackup and brarchive that are created in \oracle\<SID>\brarchive and \oracle\<SID>\brbackup directories. Because Tivoli Data Protection for SAP R/3 does not change the basic operation of these commands, you can use the standard methods for checking these logs as referred to in the SAP R/3 Oracle documentation. 2. Check the events for your schedules on a daily basis. Here is an example of a TSM command to examine all events that have occurred and will occur in the TSM domain named R3 for the period from yesterday until tomorrow. This will show you which schedules have been executed, their results and also future events scheduled for today and tomorrow.
tsm: TSMSRV> QUERY EVENT R3 * BEGINDATE=TODAY-1 ENDDATE=TODAY+1 3. Check the TSM logs on the SAP system. These are: dsmsched.log Here you find the results of actions executed by the local TSM Scheduler service. Because all of our backups are executed by this service, everything relevant to our backups is located here. You should monitor the size of this log file because it is growing constantly. When necessary, take steps to reduce its size by deleting older data. This file is the error log for manual file backup-and-restore commands. It should be monitored for errors. This file is the error log for the TSM API client, used by Backint. It should be monitored for errors.

The recovery procedure for the SAP R/3 system with Tivoli Data Protection for SAP R/3 is similar to a normal recovery of an SAP R/3 system. Of course you have to make sure you have a connection to your TSM server and have installed the TSM client for file recovery and Tivoli Data Protection for SAP R/3 to be able to restore your database and logs. You have to check that the correct tapes are
163
available within your tape library, but if they are not, TSM will tell you exactly which tapes contain the data you need for recovery. To successfully recover, you must make sure your system is fully functional. That is, any hardware or software failures must have been corrected. The following flowchart shows one possible recovery strategy:
Repair Hardware
OK
Check SAP
OK
System OK
Fail
Repair Hardware
OK
Check Win NT
Fail
Recover Win NT
Check Files
OK
Fail Restore files
OK
User error
Repair SAP
Fail
Check Database
Fail
Recover database
Check SAP
OK
System OK
Figure 59. Recovery procedure for SAP R/3 and Oracle database
Note that the flowchart in Figure 59 refers to recovery from hardware errors and user errors. We assume that, prior to the failure that necessitates recovery, your SAP R/3 system was working well and running without any errors. That is, there are no faulty device drivers or other software that could cause problems. We can divide hardware problems into two classes: those that crash the system and those that do not because the system was protected by redundant components such as a RAID disk array or a redundant power supply. In the latter situation, after you have repaired your hardware successfully, you should always check your system by checking the SAP R/3 system log to determine whether any jobs have failed or there are any other signs of problems. If there are no errors, your system is up and running correctly again. However, if the hardware error has crashed your system or SAP has problems (and this can include a blue screen trap, corrupted operating system or database, 164
OK
Fail Call Help
OK
and so on), you should start a bottom-up process to check and repair your whole system. These means we check Windows NT first. You should check that you can start both Windows NT partitions (the production and backup Windows NT installation). Check that all services are online, and see if there any messages in the Windows NT event log. This will help to make sure that your network and other essential subsystems are working properly. If there is a problem, you should try to recover the production Windows NT partition first. If you cannot repair the first partition, then attempt to recover using the second Windows NT installation. So, here is our suggested sequence of preferred methods to recover Windows NT: Use a Windows NT repair disk Use a Windows NT boot diskette Use the second Windows NT partition with the TSM client If both Windows NT installations cannot be recovered, you will have to install a new second copy of Windows NT and the TSM client software, making sure to configure them to be able to access the network and the TSM server and then restore your production system. Having achieved a functional Windows NT installation, the next step will be to check all Windows NT partitions, in particular, the partitions containing the Oracle database and the SAP R/3 software. The checks should also include any database files that are needed for startup and recovery. For example, you need the files in the sapbackup and saparchive directories. You also need the control files to start a database restore. If any files are missing you can restore them now using the TSM client. After all the files on your system are in place, you can check the database itself. If there are any errors when you open the database, you will have to recover the database to its most recent backed-up state. The easiest way of doing this is using sapdba. You can use Oracle tools such as svrmgr30 as well. Once you have successfully recovered your database, you need to check your SAP system again. This time, everything should now be operating correctly. You should be aware that you might have to repeat lost transactions. Looking again at the flowchart in Figure 59 on page 164, if a user error has caused the problem, the recovery procedure starts at a later point, since you do not have to repair hardware or recover Windows NT. If you can recover the user failure within your SAP system then you don't need to perform a database restore, which can save a lot of time. Should you need to restore your database, make sure everything is working as expected prior to the restore. To recover your database, the best tool is once again sapdba. After successfully restoring the Oracle database, you need to check your SAP system again. Of course, you have to reapply any changes made to your database since the backup that has been restored. This procedure should give you a general overview of backing up and recovering your SAP system. We can't show an example here because there is no typical restore scenario. You always have to analyze your system in order to know what actions you have to take. We recommend that you make yourself familiar with the
165
166
Appendix A. Special notices

This publication is intended to help SAP system technical staff and administrators to implement a reliable backup-and-restore process to protect valuable business data. The information in this publication is not intended as the specification of any programming interfaces that are provided by products from IBM Corporation, Tivoli or SAP Gmbh. See the PUBLICATIONS section of the IBM Programming Announcement for referenced products from IBM for more information about what publications are considered to be product documentation. References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM's product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM's intellectual property rights may be used instead of the IBM product, program or service. Information in this book was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels. IBM may have patents or pending patent applications covering subject matter 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 the IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The information about non-IBM (vendor) products in this manual has been supplied by the vendor and IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. Any performance data contained in this document was determined in a controlled environment, and therefore, the results that may be obtained in other operating environments may vary significantly. Users of this document should verify the applicable data for their specific environment.
167
Reference to PTF numbers that have not been released through the normal distribution process does not imply general availability. The purpose of including these reference numbers is to alert IBM customers to specific information relative to the implementation of the PTF when it becomes available to each customer according to the normal IBM PTF distribution process. The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:
ADSTAR AIX AS/400 AT CT DB2 IBM Magstar Netfinity Netfinity Manager NetView RETAIN RS/6000 ServeRAID SP SP1 System/390 XT
The following terms are trademarks of other companies: Tivoli, Manage. Anything. Anywhere.,The Power To Manage., Anything. Anywhere.,TME, NetView, Cross-Site, Tivoli Ready, Tivoli Certified, Planet Tivoli, and Tivoli Enterprise are trademarks or registered trademarks of Tivoli Systems Inc., an IBM company, in the United States, other countries, or both. In Denmark, Tivoli is a trademark licensed from Kjbenhavns Sommer - Tivoli A/S. C-bus is a trademark of Corollary, Inc. in the United States and/or other countries. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and/or other countries. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States and/or other countries. PC Direct is a trademark of Ziff Communications Company in the United States and/or other countries and is used by IBM Corporation under license. ActionMedia, LANDesk, MMX, Pentium and ProShare are trademarks of Intel Corporation in the United States and/or other countries. UNIX is a registered trademark in the United States and/or other countries licensed exclusively through X/Open Company Limited. SET and the SET logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others.
168
Appendix B. Related publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
B.1 IBM Redbooks

For information on ordering these ITSO publications see How to get IBM Redbooks on page 171. Using Tivoli Storage Management in a Clustered NT Environment, SG24-5742 Using Tivoli Data Protection for Workgroups, SG24-5490 Windows NT Backup and Recovery with ADSM, SG24-2231 Implementing SAP R/3 4.5B using Microsoft Cluster Server on IBM Netfinity Servers, SG24-5170 Using ADSM to Back Up Databases, SG24-4335 Netfinity Tape Solutions, SG24-5218 SAP R/3 Data Management with Tivoli Storage Manager, SG24-5743
B.2 IBM Redbooks collections

Redbooks are also available on the following CD-ROMs. Click the CD-ROMs button at http://www.redbooks.ibm.com/ for information about all the CD-ROMs offered, updates and formats.
CD-ROM Title System/390 Redbooks Collection Networking and Systems Management Redbooks Collection Transaction Processing and Data Management Redbooks Collection Lotus Redbooks Collection Tivoli Redbooks Collection AS/400 Redbooks Collection Netfinity Hardware and Software Redbooks Collection RS/6000 Redbooks Collection (BkMgr Format) RS/6000 Redbooks Collection (PDF Format) Application Development Redbooks Collection IBM Enterprise Storage and Systems Management Solutions Collection Kit Number SK2T-2177 SK2T-6022 SK2T-8038 SK2T-8039 SK2T-8044 SK2T-2849 SK2T-8046 SK2T-8040 SK2T-8043 SK2T-8037 SK3T-3694
B.3 Other publications

These publications are also relevant as further information sources: Backint/ADSTAR Interface Description and Operations, SC33-6379 SAP Documentation CD Release 4.5B, 50 030 561 (shipped with the product) Microsoft Cluster Server Administrator's Guide, X0327902 (shipped with the product) Windows NT Backup & Recovery, by McMains and Chronister (ISBN 0-07-882363-3) Oracle8 Architecture, by Steve Bobrowski (ISBN 0-07-882274-2)
169
B.4 Useful Web sites

The following Web sites are referenced in this book as sources of additional information: http://www.sap.com/products/techno/pdf/smdb.pdf http://www.hp.com/tape/papers/strategy.html http://www.microsoft.com/sql http://www.storage.ibm.com/hardsoft/diskdrdl/prod/ultrastar.htm ftp://index.storsys.ibm.com http://www.tivoli.com/products/index/storage_mgr/ http://www.tivoli.com/products/solutions/storage/ http://www.de.ibm.com/ide/dlindex.html http://www.de.ibm.com/ide/backint_adsm.html
B.5 Microsoft Knowledge Base articles

The following articles are referenced in this book. They can be found by submitting their article numbers to the search engine at: http://support.microsoft.com/search Q172944, How to Change Quorum Disk Designation Q172951, How to Recover from a Corrupted Quorum Log
170
How to get IBM Redbooks

This section explains how both customers and IBM employees can find out about ITSO redbooks, redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided. Redbooks Web Site http://www.redbooks.ibm.com/ Search for, view, download, or order hardcopy/CD-ROM redbooks from the redbooks Web site. Also read redpieces and download additional materials (code samples or diskette/CD-ROM images) from this redbooks site. Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a few chapters will be published this way. The intent is to get the information out much quicker than the formal publishing process allows. E-mail Orders Send orders by e-mail including information from the redbooks fax order form to: In United States Outside North America Telephone Orders United States (toll free) Canada (toll free) Outside North America 1-800-879-2755 1-800-IBM-4YOU Country coordinator phone number is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl e-mail address usib6fpl@ibmmail.com Contact information is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl
Fax Orders United States (toll free) Canada Outside North America 1-800-445-9269 1-403-267-4455 Fax phone number is in the How to Order section at this site: http://www.elink.ibmlink.ibm.com/pbl/pbl
This information was current at the time of publication, but is continually subject to change. The latest information may be found at the redbooks Web site. IBM Intranet for Employees IBM employees may register for information on workshops, residencies, and redbooks by accessing the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical professionals; click the Additional Materials button. Employees may access MyNews at http://w3.ibm.com/ for redbook, residency, and workshop announcements.
171
IBM Redbooks fax order form

Please send me the following:
Title Order Number Quantity
First name
Last name
Company
Address
City
Postal code Telefax number
Country VAT number
Telephone number Invoice to customer number
Credit card number
Credit card expiration date
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not available in all countries. Signature mandatory for credit card payment.
172
Abbreviations and acronyms

ADSM API ATM BIOS CAE CCMS CPU DBMS DLT DMAPI ERP FTP GB GUI HSM HTML IBM ISBN ITSO LAN LVDS MB MMC MSCS NTFS ODBC OSS PCI RPM SAN SAP ADSTAR Distributed Storage Manager application programming interface asynchronous transfer mode basic input/output system Client Application Enabler Computing Center Management System central processing unit database management system digital linear tape Data Management Application Programming Interface enterprise resource planning file transfer protocol gigabytes graphical user interface hierarchical storage manager hypertext markup language International Business Machines Corporation International Standard Book Number International Technical Support Organization local area network low-voltage differential SCSI megabytes Microsoft Management Console Microsoft Cluster Server NT file system open database connectivity Online Service System peripheral component interconnect revolutions per minute storage area network Systeme, Anwendungen und Programme in der Datenverarbeitung (Systems, Products, and Programs in Data Processing) small computer system interface system identifier symmetrical multiprocessing TDP TSM UDB URL VDI WAN SQL TCP/IP structured query language Transmission Control Protocol/Internet Protocol Tivoli Data Protection Tivoli Storage Manager Universal Database Uniform Resource Locator Virtual Device Interface wide area network
SCSI SID SMP
173
174
Index A
administration 45 ADSM ADSTAR Distributed Storage Manager See Tivoli Storage Manager ADSTAR Distributed Storage Manager See Tivoli Storage Manager application servers 3 archival logging 25 archive and retrieval 41 archived redo log 20 compressed data capacity 33 concepts, backup and recovery control files 21 copy groups 52 7
D
data protection 41 database backup 8 database server 3 database service, in MSCS 15 databases, default for MS SQL Server 28 DB2 architecture 24 archival logging 25 backup automation 112 backup procedure 107 backup scripts 107 batch files 102 checking your backup 113 circular logging 25 Client Application Enabler 23 configuration to use TSM 105 database and log backups 107 file distribution 101 file list 26 hardware configuration 99 logging with SAP R/3 24 minimum disk layout 25 recommended backup schedule 31 recovery hints and tips 116 recovery procedure 114 SAP R/3 systems based on 99 SAP tools 26 scheduler service 105 software interdependencies 102 Tivoli Storage Manager 58, 102 Tivoli Storage Manager configuration 68 TSM Server configuration 103 Universal Database Control Center 24 DB2 Universal Database 23 default management class 68, 71, 75 default profile 18 device class 51 differential backup 8 disaster recovery 41 disk controller throughput data (RAID-5) 36 disk layout, minimum 21, 25 disks in an MSCS cluster 144 DLT 20/40 tape drive 33
B
Backint interface 23 backup and recovery, concepts 7, 29 archiving, compared to 7 automation 92, 112, 129, 161 books, recommended 10 cycle 29 databases 8 differential, defined 8 full, defined 7 incremental, defined 8 large databases 33 methodology comparison 49 MSCS characteristics 12 Netfinity technologies 33 offline, defined 8 online, defined 9 open files 8 Oracle 19 partial, defined 7 requirements 5 schedule for DB2 31 schedule for MS SQL Server 31 schedule for Oracle 30 sizing Netfinity solutions 35 strategies 9 tape hardware used in examples 64 terminology 7 Tivoli Storage Manager 41 tools 10 types, defined 7 use of second copy of Windows NT 11 virtual names 14 Windows NT 10 backup commands 80, 102, 122, 141 backup procedure 89, 107, 126, 157 books, recommended 10
E
enterprise console 45 ERP enterprise resource planning SAP R/3 3 example sizing calculation 37
C
circular logging 25 clients 3 clustered disks 144 clustered disks, backing up 14
175
Fibre Channel 77, 99, 119, 138 file distribution 79, 101, 121, 140 flowchart DB2 recovery 115 MS SQL Server recovery 133 MSCS recovery 164 Oracle recovery 95 full backup 7
H
hard disk throughput data 35 hardware configuration 77, 99, 119, 137 hierarchical space management 42 Hot Package 17, 24
I
IBM DB2 23 incremental backup 8, 9 instance profile 18
K
kernel 19
L
landscape, SAP R/3 system 4 library, tape 33, 77, 99, 119, 138 logging 25 logical replication 15
M
Magstar tape drive 33 management class 52 Microsoft Cluster Server See MSCS mirror, split 9 MS SQL Server architecture 27 backup automation 129 backup procedure 126 backup scripts 127 batch files 122 checking your backup 130 database and transaction log backups file distribution 121 file list 29 hardware configuration 119 master database 27 model database 27 msdb database 27 primary data file 28 recommended backup schedule 31 recovery procedure 132 SAP R/3 systems based on 119 scheduler service 124 secondary data file 28 software interdependencies 122
tempdb database 27 Tivoli Data Protection for SQL Server 125 Tivoli Storage Manager 122 Tivoli Storage Manager configuration 72 TSM Server configuration 123 Virtual Device Interface 27 MSCS Microsoft Cluster Server approaches to backup 12 backing up clustered disks 14 backup automation 161 backup procedure 157 backup process, need for 11 backup scripts 158 batch files 141 characteristics relevant to backup 12 checking your backup 163 clustered disks 144 complete backup of a cluster 12 configuration for SAP R/3 16 database and redo log backups 158 database service 15 dedicated backup server 13 file distribution 140 hardware configuration 137 issues and resolutions 16 local tape drives 12 local versus networked tape devices 11 quorum disk 14, 148 recovery procedure 163 registry 15 SAP R/3 systems based on 137 scheduler services 148 software interdependencies 140 Tivoli Data Protection for SAP R/3 140, 153 Tivoli Storage Manager 140 Tivoli Storage Manager client 143 Tivoli Storage Manager, using 14 TSM Server configuration 142 unique files 15 virtual names for backup clients 14 virtual servers 145 multiple backup sets 9 multi-session 43 multi-threading 43 127
N
native capacity 33 Netfinity backup technologies 33 sizing backup solutions 35 supported DLT and Magstar tape drives 34 supported DLT and Magstar tape libraries 34 Tivoli Storage Manager server 64 network throughput data 35
O
offline backup online backup 8 9
176
online redo log 20 Online Service System 17 open files, backing up 8 Oracle backup automation 92 backup procedure 89 backup scripts 89 batch files 80 checking your backup 94 control files 21 database and redo log backups 89 DBMS structure 19 file distribution 79 file list 22 hardware configuration 77 minimum disk layout 21 parameter files 21 recommended backup schedule 30 recovery procedure 94 redo logs 20 SAP R/3 systems based on 77 SAP tools 22 sapdba utility 23 scheduler service 83 software interdependencies 80 tablespace 20 Tivoli Data Protection for SAP R/3 84 Tivoli Storage Manager 80 Tivoli Storage Manager configuration 64 TSM Server configuration 81 OSS See Online Service System
P
parallel backup and archive operations parameter files 21 partial backup 7 partial full backup 9 physical storage media 49 policy set 52 presentation servers 3 progressive backup methodology 48 43
recovery procedure 94, 114, 132, 163 recovery, backup and See backup redo log 20 replication 15 restoring cluster information 15 retrieval, backup and See backup rotating backup sets 9
S
SAP R/3 ABAP/4 17 architecture 3
backup and recovery concepts 29 backup requirements 5 clients 3 databases 19 DB13 transaction 23, 89, 107, 127, 158 directory structure 17 high availability 5 Hot Package 17, 24 kernel 17, 19 MSCS configuration 16 OSS 17 platforms 3 profiles 18 programs 17 RZ10 transaction 18 SAPNet 17 SID 5 system identifier 5 system landscape 4 tape backup devices 33 two-tier versus three-tier system 3 user interface 3 SAPNet 17 scheduler service 83, 105, 124, 148 scripts DB2 backup of offline logs 111 delete old database backups 111 full offline database backup 109 full online database backup 108 MS SQL Server automatic deletion of backups 129 full online database backup 128 log file backup 128 MSCS archive redo log backups 161 full offline database backup 160 full online database backup 159 Oracle archive redo log backups 92 full offline database backup 91 full online database backup 90 second copy of Windows NT, use of 11 security 52 ServeRAID 78, 100, 120, 139 setup and configuration of Tivoli Storage Manager shadow copy 9 sizing backup solutions 35 calculation 36 disk controller throughput data 36 example calculation 37 hard disk throughput data 35 network throughput data 35 SNMP-based systems 46 software interdependencies 80, 102 , 122, 140 split mirror 9 standby database 9 start profile 18 storage pool 51
63
177
storage repository 43 storage resource management strategies, backup 9 system identifier 5 system profiles 18
41
T
tablespace 20 tape capacity 33 cartridge 33 cartridge labels 66, 70, 74 data compression 33 DLT 20/40 drive 33 library 33, 77, 99, 119, 138 options for Netfinity servers 33 tape devices, in MSCS 12 terminal server implementations 3 three-tier system 3 Tivoli Data Protection for applications 46, 55 Tivoli Data Protection for Microsoft SQL Server 59 Tivoli Data Protection for SAP R/3 56, 84, 153 Tivoli Data Protection for SQL Server 125 Tivoli Data Protection for Workgroups 15, 56 Tivoli Decision Support for Storage Management Analysis 54 Tivoli Disaster Recovery Manager 54 Tivoli Enterprise framework 46 Tivoli Space Manager 53 Tivoli Storage Manager administration 45 architecture 42 archived data 50 archiving 49 backup/archive client 42, 43 base concepts 48 complementary products 53 configuration assumptions 63 configuration for DB2 68 configuration for MS SQL Server 72 configuration for Oracle 64 copy groups 52, 67, 68, 71, 72, 75 data objects 50 DB2 58, 102 device class 51, 65, 69, 70, 73, 74 DLT tape cartridges 66, 70, 74 enterprise console 45 external interfaces 46 features 41 hardware 77, 99, 119, 138 Intel-based clients 47 introduction 41 library definition 66, 69, 73 management class 52, 67, 68, 71, 72, 75 MS SQL Server 122 MSCS 140 Oracle 80 physical storage media 49 policy concepts 51 policy definition 67, 71, 75
policy domain 67, 71, 75 policy set 52, 67, 71, 75 product set 41 progressive backup methodology 48 remote operation 43 scheduler service 83, 105, 124, 146, 148 security concepts 52 server 43 setup and configuration 63 storage devices 50 storage pool 51, 66, 70, 74 supported environment 46 validation 68, 72, 76 volumes 51, 66, 70, 74 Web client interface 43 Web site 47 Windows NT client 43, 82, 104, 123, 143 transport directory 18 TSM See Tivoli Storage Manager two-tier system 3 types of backup 7
U
user interface 3
V
Virtual Device Interface 27 virtual names for backup clients virtual servers 145 vital record retention 41 14
W
Web client 43 Web site backup strategy 10 Microsoft Knowledge Base 170 MS SQL Server 28 SAP split mirror backup 9 Tivoli Data Protection for SAP R/3 Tivoli Storage Manager 47 Windows NT backup 10 backup and recovery tools 10 books, recommended 10 recommendations 10 registry 15 second copy 10, 15
84, 153
178
IBM Redbooks review

Your feedback is valued by the Redbook authors. In particular we are interested in situations where a Redbook "made the difference" in a task or problem you encountered. Using one of the following methods, please review the Redbook, addressing value, subject matter, structure, depth and quality as appropriate. Use the online Contact us review redbook form found at http://www.redbooks.ibm.com/ Fax this form to: USA International Access Code + 1 914 432 8264 Send your comments in an Internet note to redbook@us.ibm.com
Document Number Redbook Title Review
SG24-5431-00 Backup Solutions for SAP R/3 4.5B on Netfinity Servers running Windows NT
What other subjects would you like to see IBM Redbooks address?
Please rate your overall satisfaction: Please identify yourself as belonging to one of the following groups:
O Very Good
O Good
O Average
O Poor
O Customer O Business Partner O Solution Developer O IBM, Lotus or Tivoli Employee O None of the above
Your email address: The data you provide here may be used to provide you with information from IBM or our business partners about our products, services or activities. Questions about IBMs privacy policy?
O Please do not use the information collected here for future marketing or promotional contacts or other communications beyond the scope of this transaction.
The following link explains how we protect your personal information. http://www.ibm.com/privacy/yourprivacy/
179
SG24-5431-00
Printed in the U.S.A.
SG24-5431-00

SG 245431

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SG 245431

Hochgeladen von

Copyright:

Verfügbare Formate

Backup Solutions for SAP R/3 4.

5B on Netfinity Servers running Windows NT

International Technical Support Organization www.redbooks.ibm.com

Copyright IBM Corp. 2000

.143 .146 .153 .157 .158 .161 .163 .163

The team that wrote this redbook

Copyright IBM Corp. 2000

Part 1. Concepts and technologies

Copyright IBM Corp. 2000

1.1 SAP R/3 architecture

Copyright IBM Corp. 2000

Database Server (Database + SAP Central Instance)

Application Server(s) (SAP Dialog Instance)

Presentation Servers (Front End Users)

2-Tier Architecture (Central Instance)

2-Tier Architecture (Clustered Central Instance)

3-Tier Architecture (Distributed System)

3-Tier Architecture (Distributed System) (Clustered Central Instance)

Figure 1. Two-tier and three-tier configurations

1.2 SAP R/3 system landscape

Figure 2. Standard SAP R/3 system landscape

1.3 Backup requirements in an SAP R/3 environment

1.4 Scope of this book

Chapter 2. Backup and recovery concepts

2.1.1 Types of backup

Copyright IBM Corp. 2000

2.1.2 Open files

2.1.3 Backing up databases

Partial full backup

2.1.4 Backup strategies

Chapter 2. Backup and recovery concepts

2.2.1 Our recommendations

2.3 Microsoft Cluster Server

Chapter 2. Backup and recovery concepts

2.3.1 Complete backup of a cluster

Available backups of object 1 1999/08/12 Node_A H:\DIR_X\FILE_Y 1999/08/10 Node_A H:\DIR_X\FILE_Y

Figure 3. Incremental backup process failure in a clustered environment

Chapter 2. Backup and recovery concepts

2.3.2 Backing up clustered disks

2.3.3 MSCS unique files

Chapter 2. Backup and recovery concepts

2.3.4 MSCS configuration for SAP R/3

Local disk Cluster node A Cluster node B

Figure 4. Physical view of a standard SAP MSCS cluster

2.4 SAP R/3

2.4.1 SAP R/3 directory structure

Chapter 2. Backup and recovery concepts

SAP R/3 Directory Structure

Figure 5. SAP R/3 directory structure

2.4.2 SAP kernel

Chapter 2. Backup and recovery concepts

System tablespace Configuration files

Initialization parameter files User tablespaces

Online redo logs

Archived redo logs

Chapter 2. Backup and recovery concepts

Directory name \ORANT

DB Agent: Orders: Interface:

Backup backup Backint

Archive backup Backint

Restore restore Backint

SAPDBA inquire Backint