Practical Guide: Using IBM Tivoli Storage Manager for Enterprise Resource Planning to achieve dierent backup retention

times
By Thomas Prause IBM Deutschland Research & Development GmbH, Boeblingen Version 1.1 April 15,2011

Copyright Notices c Copyright International Business Machines Corporation 2006, 2011. All rights reserved. May only be used pursuant to a Tivoli Systems Software License Agreement, an IBM Software License Agreement, or Addendum for Tivoli Products to IBM Customer or License Agreement. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, magnetic, optical, chemical, manual, or otherwise, without prior written permission of IBM Corporation. IBM Corporation grants you limited permission to make hardcopy or other reproductions of any machinereadable documentation for your own use, provided that each such reproduction shall carry the IBM Corporation copyright notice. No other rights under copyright are granted without prior written permission of IBM Corporation. No part of this document may be reproduced or transmitted in any form without written permission from IBM Corporation. Product data is subject to change without notice. This information could include technical inaccuracies or typographical errors. IBM may make improvements and/or changes in the product(s) and/or program(s) at any time without notice. Any statements regarding IBMs future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. References in this document to IBM products, programs, or services do not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Any reference to an IBM Program Product in this document is not intended to state or imply that only that program product may be used. Any functionally equivalent program, that does not infringe IBMs intellectually property rights, may be used instead. It is the users responsibility to evaluate and verify the operation of any non-IBM product, program or service. Trademarks IBM, the IBM logo, Tivoli, the Tivoli logo, AIX, Tivoli Certied and Tivoli Enterprise are trademarks or registered trademarks of International Business Machines Corporation or Tivoli Systems Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. Other company, product, and service names may be trademarks or service marks of others. Notices References in this publication to Tivoli Systems or IBM products, programs, or services do not imply that they will be available in all countries in which Tivoli Systems or IBM operates. Any reference to these products, programs, or services is not intended to imply that only Tivoli Systems or IBM products, programs, or services can be used. Subject to valid intellectual property or

c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times

Version 1.1 2

other legally protectable right of Tivoli Systems or IBM, any functionally equivalent product, program, or service can be used instead of the referenced product, program, or service. The evaluation and verication of operation in conjunction with other products, except those expressly designated by Tivoli Systems or IBM, are the responsibility of the user. Tivoli Systems or 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, New York 10504 -1785, U.S.A.

c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times

Version 1.1 3

Contents
Overview Challenges Possible solutions Picture the solution Preparing the TSM server Conguring the database server Usage scenario for DB2 Usage scenario for Oracle Specics when using Oracle RMAN . . . . . . . . . . . . . . . Oine backups Conclusion and Limits 5 5 5 6 7 7 8 9 10 10 10

c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times

Version 1.1 4

Overview
This document outlines how IBM Tivoli Storage Manager for Enterprise Resource Planning (ERP) can be used to automate the process of keeping dierent numbers of versions of dierent backup types. There are often requirements to keep more than a specic number of backups on media. For instance in addition to the daily on-line backups a specic number of the weekly oine backups and quarterly backups should be retained as well. The intend of this document is to describe how these requirements can be fullled.

Challenges
What is so special about having dierent retention times for dierent kinds of backups? If unwanted backups are deleted manually by the user he just needs to choose the right one for deletion and keep the others untouched. Thats all. But in somewhat more complex environments it might be desirable to automate such tasks. Tivoli Data Protection for SAP has a feature which automatically keeps the specied number of full backups and corresponding redo logs. Older backup versions are deleted automatically. This is done by setting the parameter MAX VERSIONS in the prole to the desired number of versions to keep. But how should it know that some of the older backups are considered dierent and therefore must not be deleted?

Possible solutions
To get this problem solved there are two possibilities: 1. Deactivate versioning for the quarterly and monthly backups. This can be achieved by setting the parameter MAX VERSIONS to 0 (zero) or by removing it from the prole, since the default for this parameter is zero. All backups which are performed with this setting are not deleted when the automatic deletion of old backup versions is activated again (by setting the parameter MAX VERSIONS to a value higher than 0 again). So this would keep all the quarterly and monthly backups. But if only for instance 4 weekly backups should be kept the older backups need to be deleted manually. 2. Another way is to use dierent proles for the quarterly and monthly backups. This way it is possible to specify dierent values for the parameter MAX VERSIONS and fully utilize the automation features for the monthly and quarterly backups as well.
c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times Version 1.1 5

Picture the solution

To make the process of creating and maintaining dierent backup types as painless as possible, we will pick the second approach by using multiple proles. To ensure the daily backups do not get deleted when obsolete weekly backups get deleted, it is required that the backups of one conguration (e.g. weekly) must not be visible when performing the backups for another conguration (e.g. daily) and vice versa. Otherwise a weekly backup with a very low number may be get deleted when performing a daily backup. Figure 1 illustrates how the version numbers are assigned to the dierent backup types. If the number of daily backups to keep is set to 5 and you perform the daily backup number 8 all backups which have a version number lower than 3 get deleted. In this sample this would also aect the weekly backup number 2. Thats why the weekly and quarterly backups must not be visible to the conguration of the daily backup. Figure 1: numbering of the dierent backup types

This results in the requirement to use a separate cong le and a separate TSM node for each set of backups. Because these parameters are specied in the prole we would have to use dierent proles. But this is something we want do anyway to be able to specify the dierent numbers of backups to keep. Furthermore we can use these dierent proles to assign the dierent types of backups to dierent TSM management classes. So the policies for the data can be completely dierent. If you want to use dierent retention times you may also want to use dierent types of storage. This all can be achieved by using separate proles for each set of backups. For the following sample we assume the SID of your system is T01 and you want to keep a dierent number of weekly and quarterly backups in addition to the daily backups. This can be easily adapted to your specic needs.

c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times

Version 1.1 6

Preparing the TSM server

The rst step is to create the separate nodes and management classes on the TSM server. The management classes dene which storage pool will be used for the data. You are expected to be familiar with the administration of the TSM server and the necessary commands will not be outlined in detail here. Be sure to dene an archive copy group for each management class, because Tivoli Storage Manager for ERP does archive the data on the TSM server. Regardless if you perform a backup of the database or a archive of the redo logs. See Table 1 for a summary of the conguration. Table 1: TSM server related conguration purpose TSM node name associated management classes daily backup T01 DAILY DB DAILY LOG1 DAILY LOG2 DAILY weekly backup T01 WEEKLY DB WEEKLY quarterly backup T01 QUARTERLY DB QUARTERLY During the creation of the TSM nodes they will be not really linked to the management classes. They are more logically belonging together. But this table will serve as a reference for the next chapter. Due to the increased number of TSM nodes it is highly recommended to utilize the passwordaccess generate feature of TSM. This eliminates the need to update the numerous passwords manually.

Conguring the database server

On the database server a separate Tivoli Storage Manager for ERP prole (.utl le) is necessary for each of the dierent backup types. In this prole the TSM node name and the management classes to be used are specied. Since Version 6 Tivoli Storage Manager for ERP does no longer use the cong le (here initT01.bki) to store information about the backup versions. If the passwordaccess generate feature is used there is no need to use dierent cong les for the dierent backup types. Otherwise the proles need to be adjusted to reference dierent cong les. See Table 2 for the names which will be used in this example.

c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times

Version 1.1 7

Table 2: related conguration le names purpose prole cong le (optional) daily backup initT01.utl initT01.bki weekly backup initT01 weekly.utl initT01 weekly.bki quarterly backup initT01 quarterly.utl initT01 quarterly.bki All proles have essentially the same content, but for the server section and optionally the cong le. The following is an extract of the relevant part of the prole for the weekly backups initT01 weekly.utl.
CONFIG_FILE /oracle/T01/102_64/dbs/initT01_weekly.bki

SERVER SERVER_A SESSIONS PASSWORDREQUIRED BRBACKUPMGTCLASS BRARCHIVEMGTCLASS

1 YES DB_WEEKLY :SKIP:

# # # #

Max sessions Use a password Mgmt-Classes Mgmt-Classes

The usage of the argument :SKIP: for the brarchive management class indicates that we do not want to perform archives of redo logs on this server at all. The advantage of the dierent proles is, that you can change other settings, not related to the management classes, as well. May be the weekly backups are run during a downtime of the SAP system. So speed is not that important. You could lower the number of sessions to save on tape drives by lengthen the backup time. But keep in mind that it is recommended to use the same number of sessions for the restore. An increased number of sessions can not be utilized when the data is spread over less tapes than sessions. Now it comes to the point where we want to make use of the new conguration. Since the invocation of a backup is dierent for DB2 and Oracle we will take a look at both.

Usage scenario for DB2

For DB2 the prole to use for the backup is specied in the vendor environment le (default name vendor.env) by the parameter XINT PROFILE. The other parameters can remain unchanged. The path and name of the vendor environment le are set in the database conguration by the keyword VENDOROPT. The current value can be obtained with the following command: db2 get db cfg for db2t01
c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times Version 1.1 8

Table 3: Parameter XINT_PROFILE=<file> TDP_DIR=<directory> BACKOM_LOCATION=<file> PROLE_PORT=<port>

vendor environment le Remarks mandatory defaults to /tmp full qualied path to the backom executable (only necessary for redirected restores) optional

This should reect the settings for the daily backup. It is not recommended to change the DB conguration just for the monthly and quarterly backups. Fortunately the value for this keyword can be overridden by passing the full qualied name of the vendor environment le to the DB2 backup command using the options parameter. For example: db2 backup db db2t01 \ load /usr/tivoli/tsm/tdp_r3/db2/lib.so \ options /db2/T01/config/vendor.env So there are 3 dierent vendor.env les necessary with basically the same content, but a dierent XINT PROFILE. For instance vendor weekly.env for the prole initT01 weekly.utl and similar a le vendor quarterly.env using initT01 quarterly.utl as prole name.

Usage scenario for Oracle

The backup of an Oracle database is typically driven by the SAP BR*TOOLS. When brbackup is started without further arguments it takes the prole from the util par file parameter of the le initT01.sap. A default entry for this parameter is: util_par_file = ?/dbs/init@.utl In this case the le initT01.utl from the directory dbs inside of the $ORACLE HOME directory will be used. This is OK as long as we want to perform the daily backup and archive operations. For the monthly and quarterly backups we must instruct brbackup to use the appropriate proles. This is achieved by passing the name of the prole using the option -r or -parfile to brbackup. For example: brbackup -parfile initT01_weekly.utl If the les initT01 weekly.utl and initT01 quarterly.utl are located in the dbs directory it is not necessary to specify the full qualied path.

c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times

Version 1.1 9

Specics when using Oracle RMAN

If the backup is performed using Oracle RMAN the prole to use is specied in the BR*Tools prole initT01.sap with the parameter rman parms.
rman_parms="ENV=(XINT_PROFILE=/oracle/T01/102_64/dbs/initT01.utl, PROLE_PORT=57323, &BR_INFO)"

The usage of the brbackup option -r or -parfile is not sucient in this case. So to use dierent proles for TSM for ERP dierent BR*Tools proles are required. These proles can be specied when invoking brbackup using option -p or -profile:
brbackup -profile initT01_weekly.sap -parfile initT01_weekly.utl

Calling brbackup with the prole initT01 weekly.sap does instruct the Oracle RMAN adapter of the TSM for ERP to use the prole initT01 weekly.utl. Similar the initT01 quarterly.sap would reference the initT01 quarterly.utl. The option -r or -parfile is still necessary to ensure the backup of the logs and proles (which is not performed by Oracle RMAN) is performed using the desired conguration.

Oine backups
It should be noted that the additional backups - weekly and quarterly in this case - need to be oine backups. If these would be online backups the corresponding redo logs would be needed to recover the database after the restore. But they would not be available using the special conguration, since the redo logs get archived using the conguration for the daily backups. The special conguration for the weekly and quarterly backups must not be used to archive redo logs. Otherwise these redo logs would be missing when restoring a daily backup.

Conclusion and Limits

To make the weekly and quarterly backups more convenient it might be useful to create scripts which contain the appropriate calls outlined above. These scripts can then be used easily to perform the monthly and quarterly operations. Even if it is possible to keep backups over a long time they are not a replacement for an archiving solution. A backup can only be restored into exactly the same environment that was used for the backup. If there is a need to keep the data over a long period of time which might include major changes to the database or operating system software the outlined approach would

c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times

Version 1.1 10

not be suitable. It would require to rebuild the original environment for the restore.

c Copyright IBM Corporation, 2011 Using IBM Tivoli Storage Manager for ERP for dierent backup retention times

Version 1.1 11