IBM E16RMLL-I, Tivoli Storage Manager Implementation Manual

Download

ibm.com/redbooks

IBM Tivoli Storage Manager Implementation Guide

Charlotte Brooks

Peter McFarlane

Norbert Pott

Eduardo Tomaz

Martin Trcka

Use the included worksheets, scripts, and macros to make your job easier

See features for new and advanced users

Use this hands-on guide for planning and setup

Front cover

IBM Tivoli Storage Manager Implementation Guide

June 2006

International Technical Support Organization

SG24-5416-03

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP

Fourth Edition (June 2006)

This edition applies to IBM Tivoli Storage Manager Version 5.3.2.

Note: Before using this information and the product it supports, read the information in “Notices” on page xxiii.

Contents

Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

The team that wrote this redbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxv

Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii

Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxviii

Part 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter 1. Implementation checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1 The big picture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Our support material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Planning checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.1 Server implementation checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.2 Client implementation checklist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2.3 Operations checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2. Implementation planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Client environment data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Client name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.2 Contact information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.3 Operating system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.4 Total storage available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.5 Total storage used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.6 GB changed per backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.7 Number of files backed up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.8 Number of backup versions to be kept . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.9 Data compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.10 Backup window times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.11 Backup number of hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.12 Required recovery time frame. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.13 Tivoli Storage Manager restore time frame . . . . . . . . . . . . . . . . . . . 23

2.2.14 GB copied per archive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.15 Number of files archived . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

iv IBM Tivoli Storage Manager Implementation Guide

2.2.16 Number of archives kept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.17 Archive frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.18 Archive window times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.19 Archive number of hours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.20 Number of image backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.21 Image backup frequency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.22 Number of backup sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.23 Backup set frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.24 Policy domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.25 Client option set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3 Data retention requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.1 Group name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.3.2 Number of backup versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.3 Backup file retention period. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.4 Number of deleted versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.3.5 Last deleted file version retention period . . . . . . . . . . . . . . . . . . . . . 27

2.3.6 Archive retention period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.7 Off-site copies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.8 Onsite collocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3.9 Off-site collocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3.10 Image backup retention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3.11 Backup set retention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4 Server architecture considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.1 Server platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.4.2 Installed user base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.3 Cost. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.4 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.5 Platform installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.6 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.7 Supported devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5 System size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.6 Multiple Tivoli Storage Manager servers . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.6.1 Reasons to consider multiple servers . . . . . . . . . . . . . . . . . . . . . . . . 34

2.6.2 Disadvantages of multiple servers . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.7 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.7.1 Network considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.7.2 Communication protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.7.3 Network name resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.8 Disk considerations and sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.8.1 The disk subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.8.2 Tivoli Storage Manager database . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.8.3 Database performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.8.4 Database size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Contents v

2.8.5 Archive sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.8.6 Database volume identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.8.7 Tivoli Storage Manager recovery log . . . . . . . . . . . . . . . . . . . . . . . . 43

2.8.8 Primary disk storage pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.8.9 Disk storage pool size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.8.10 Archive disk sizing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.8.11 Image disk sizing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.8.12 Device configuration table and volume history file . . . . . . . . . . . . . 48

2.8.13 Total disk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2.9 Tape drives and sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.9.1 Tape devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.9.2 Tape libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.9.3 Number of tape drives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.10 Tape volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.10.1 On-site volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.10.2 Off-site volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.10.3 Database tape volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.10.4 z/OS tape management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.11 Administrator IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.11.1 License considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.11.2 Licensed features registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

2.12 Other considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

2.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Part 2. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Chapter 3. Server installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.1 Software installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.2 Latest software updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.3 AIX server installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.4 Linux server installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.4.1 Installation packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.4.2 Installation commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.4.3 Post-installation steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

3.4.4 Uninstallation of the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.5 Windows 2000/2003 server installation. . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.5.1 Tivoli Storage Manager server package installation . . . . . . . . . . . . . 78

3.5.2 Tivoli Storage Manager License package installation . . . . . . . . . . . . 80

3.5.3 Tivoli Storage Manager Device Driver package installation . . . . . . . 81

3.5.4 Windows 2000/2003 configuration wizards. . . . . . . . . . . . . . . . . . . . 82

3.6 Integrated Solution Console and Administration Center . . . . . . . . . . . . . . 83

3.6.1 ISC and Administration Center installation . . . . . . . . . . . . . . . . . . . . 85

3.7 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

vi IBM Tivoli Storage Manager Implementation Guide

3.7.1 Server options file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.7.2 Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

3.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Chapter 4. Backup-archive client installation. . . . . . . . . . . . . . . . . . . . . . . 97

4.1 Backup-archive client code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.1.1 Backup-archive client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.1.2 Web client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.1.3 API client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.2 Code installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.2.1 Backup-archive client code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.2.2 AIX backup-archive client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4.2.3 Linux backup-archive client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.2.4 Windows backup-archive client. . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.3 Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.3.1 Backup-archive client customization . . . . . . . . . . . . . . . . . . . . . . . . 113

4.3.2 Web backup-archive client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

4.3.3 Using the client configuration wizard. . . . . . . . . . . . . . . . . . . . . . . . 120

4.4 UNIX/Linux configuration wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

4.5 Use of Windows configuration wizards . . . . . . . . . . . . . . . . . . . . . . . . . . 129

4.5.1 Backup-archive client configuration . . . . . . . . . . . . . . . . . . . . . . . . 129

4.5.2 Web client configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

4.5.3 Client scheduler configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

4.5.4 Journal engine configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

4.5.5 Online image support configuration . . . . . . . . . . . . . . . . . . . . . . . . 165

4.5.6 Open File Support configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

4.6 Client interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

4.6.1 Command line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

4.6.2 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

4.7 Client scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

4.7.1 Starting the client scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

4.7.2 Stopping the scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

4.8 Web client usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

4.8.1 Remote client GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

4.8.2 Client functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

4.8.3 Access authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

4.8.4 Starting the Web client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

4.8.5 Stopping the remote agent services . . . . . . . . . . . . . . . . . . . . . . . . 184

4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Chapter 5. Database and recovery log . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

5.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

5.1.1 Database design considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Contents vii

5.1.2 Defining database volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

5.2 Recovery log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

5.2.1 Recovery log design considerations . . . . . . . . . . . . . . . . . . . . . . . . 193

5.2.2 Defining recovery log volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

5.3 Setting the log mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

5.4 Defining the database backup trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

5.5 Setting the expansion trigger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

5.5.1 Database space trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

5.5.2 Recovery log space trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

5.6 Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

5.6.1 Database mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

5.6.2 Recovery log mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

5.7 Removing default volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

5.7.1 Removing the default database volume . . . . . . . . . . . . . . . . . . . . . 207

5.7.2 Removing the default recovery log volume . . . . . . . . . . . . . . . . . . . 209

5.8 Database backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

5.9 Additional commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

5.9.1 DELETE VOLHIST TYPE=DBBACKUP . . . . . . . . . . . . . . . . . . . . . 212

5.9.2 ESTIMATE DBREORGSTATS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

5.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Chapter 6. Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

6.1 Example environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

6.1.1 Primary storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

6.1.2 Copy storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

6.2 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

6.2.1 Defining a library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

6.2.2 Defining a path to a library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

6.2.3 Defining a drive in a library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

6.2.4 Defining a path to a drive in a library. . . . . . . . . . . . . . . . . . . . . . . . 226

6.2.5 Defining a device class for a library . . . . . . . . . . . . . . . . . . . . . . . . 228

6.2.6 Defining a sequential file device class . . . . . . . . . . . . . . . . . . . . . . 230

6.3 Storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

6.3.1 Defining a sequential access tape storage pool . . . . . . . . . . . . . . . 232

6.3.2 Defining a random access disk storage pool . . . . . . . . . . . . . . . . . 233

6.3.3 Defining a sequential access file storage pool . . . . . . . . . . . . . . . . 234

6.3.4 Defining a copy storage pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

6.3.5 Deleting the default storage pools. . . . . . . . . . . . . . . . . . . . . . . . . . 238

6.4 Storage pool volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

6.4.1 Defining random access disk volumes . . . . . . . . . . . . . . . . . . . . . . 239

6.4.2 Tape volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

6.5 Additional commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

6.5.1 Auditing library contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

viii IBM Tivoli Storage Manager Implementation Guide

6.5.2 Auditing volume contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

6.5.3 Back up a storage pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

6.5.4 Check a tape in to a library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250

6.5.5 Check out library volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

6.5.6 Deleting storage-related objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

6.5.7 Mounted volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

6.5.8 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

6.5.9 Moving data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

6.5.10 Querying volume contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

6.5.11 Querying occupancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

6.5.12 Rename a storage pool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

6.5.13 Reclamation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

6.5.14 SQL commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

6.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

Chapter 7. Data storage policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269

7.1 Recommended setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

7.1.1 Defining policy domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

7.1.2 Defining policy sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

7.1.3 Defining management classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

7.1.4 Defining backup copy groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

7.1.5 Defining the archive copy group . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

7.2 Verifying policy definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

7.2.1 Backup copy groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

7.2.2 Archive copy groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

7.3 Validating and activating a policy set . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

7.3.1 Validating the recommended policy sets. . . . . . . . . . . . . . . . . . . . . 278

7.3.2 Activating the recommended policy sets. . . . . . . . . . . . . . . . . . . . . 279

7.3.3 Deleting the STANDARD policy domain . . . . . . . . . . . . . . . . . . . . . 279

7.4 Enforcing your policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

7.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282

Chapter 8. Managing Tivoli Storage Manager. . . . . . . . . . . . . . . . . . . . . . 283

8.1 Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

8.1.1 Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

8.1.2 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

8.1.3 Default environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285

8.1.4 Recommended administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286

8.1.5 Working with administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288

8.2 Client nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

8.2.1 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

8.2.2 Default environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

8.2.3 Working with client nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292

Contents ix

8.3 Client option sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

8.3.1 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298

8.3.2 Default environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299

8.3.3 Recommended client option sets . . . . . . . . . . . . . . . . . . . . . . . . . . 299

8.3.4 Working with client option sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

8.3.5 Associating a client node with a client option set . . . . . . . . . . . . . . 301

8.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Chapter 9. Licensing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

9.1 Licensed features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

9.2 Registering licensed features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

9.3 Saving your licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

9.4 License compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

9.5 Monitoring licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

9.5.1 Displaying license information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

9.5.2 Auditing licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308

9.5.3 Scheduling automatic license audits . . . . . . . . . . . . . . . . . . . . . . . . 308

9.6 Tivoli Storage Manager V5.2 license features. . . . . . . . . . . . . . . . . . . . . 309

Chapter 10. Administrative client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311

10.1 Administration Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

10.1.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

10.1.2 Administration Center interface. . . . . . . . . . . . . . . . . . . . . . . . . . . 313

10.2 Administrative client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

10.2.1 Code installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

10.2.2 Administrative command-line client customization . . . . . . . . . . . . 318

10.2.3 Command-line interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320

10.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

Part 3. Operational details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

Chapter 11. Client operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

11.1 Running backup operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

11.1.1 Exclude rules preventing some files from being backed up . . . . . 331

11.1.2 UNIX command-line examples and output . . . . . . . . . . . . . . . . . . 333

11.1.3 Windows GUI backup examples . . . . . . . . . . . . . . . . . . . . . . . . . . 342

11.1.4 Additional backup options for Windows . . . . . . . . . . . . . . . . . . . . 344

11.2 Running restore operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

11.2.1 UNIX command-line examples and output . . . . . . . . . . . . . . . . . . 348

11.2.2 Windows GUI restore examples . . . . . . . . . . . . . . . . . . . . . . . . . . 354

11.3 Running archive operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

11.3.1 UNIX command-line examples and output . . . . . . . . . . . . . . . . . . 361

11.3.2 Windows GUI archive examples . . . . . . . . . . . . . . . . . . . . . . . . . . 363

11.4 Running retrieve operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

x IBM Tivoli Storage Manager Implementation Guide

11.4.1 UNIX command-line examples and output . . . . . . . . . . . . . . . . . . 366

11.4.2 Windows GUI retrieve examples. . . . . . . . . . . . . . . . . . . . . . . . . . 367

11.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Chapter 12. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

12.1 The wheel of life . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

12.2 Administrative schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

12.2.1 Defining an off-site backup schedule . . . . . . . . . . . . . . . . . . . . . . 377

12.2.2 Defining the volume history schedules . . . . . . . . . . . . . . . . . . . . . 380

12.2.3 Defining a migration schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . 382

12.2.4 Defining an expiration schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 382

12.2.5 Defining a reclamation schedule . . . . . . . . . . . . . . . . . . . . . . . . . . 383

12.2.6 Defining a licensing audit schedule. . . . . . . . . . . . . . . . . . . . . . . . 385

12.2.7 Querying administrative events. . . . . . . . . . . . . . . . . . . . . . . . . . . 386

12.3 Client schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

12.3.1 Defining a client backup schedule. . . . . . . . . . . . . . . . . . . . . . . . . 387

12.3.2 Defining an enhanced client schedule . . . . . . . . . . . . . . . . . . . . . 388

12.3.3 Associating a client with a schedule . . . . . . . . . . . . . . . . . . . . . . . 391

12.3.4 Verifying the client schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Chapter 13. Routine tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395

13.1 Operations staff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396

13.2 Server procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

13.2.1 Starting the Tivoli Storage Manager server. . . . . . . . . . . . . . . . . . 397

13.2.2 Stopping the Tivoli Storage Manager server. . . . . . . . . . . . . . . . . 401

13.3 Event monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

13.3.1 Event receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405

13.4 Health monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

13.4.1 Enabling the ADMIN_CENTER account . . . . . . . . . . . . . . . . . . . . 408

13.4.2 Using Health Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409

13.5 Operational Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

13.5.1 Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

13.6 Daily sanity checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

13.6.1 Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417

13.6.2 Client-server activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

13.7 Storage media management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

13.7.1 Tape use overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

13.7.2 Label and check in tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

13.7.3 On-site and off-site tape management . . . . . . . . . . . . . . . . . . . . . 430

13.7.4 Moving data from on-site to off-site. . . . . . . . . . . . . . . . . . . . . . . . 433

13.7.5 Off-site tape management to on-site. . . . . . . . . . . . . . . . . . . . . . . 439

13.7.6 Checking volumes into a library . . . . . . . . . . . . . . . . . . . . . . . . . . 440

13.7.7 Reclaiming off-site tapes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

Contents xi

13.7.8 Database backup management . . . . . . . . . . . . . . . . . . . . . . . . . . 442

13.8 Error conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

13.8.1 Tivoli Storage Manager errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . 446

13.8.2 Machine errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

13.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

Chapter 14. Advanced operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

14.1 Exporting server to server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

14.2 Exporting data directly to another server. . . . . . . . . . . . . . . . . . . . . . . . 454

14.2.1 Preparing to export to another server for immediate import . . . . . 455

14.2.2 Exporting administrator information to another server . . . . . . . . . 455

14.2.3 Exporting client node information to another server . . . . . . . . . . . 457

14.2.4 Exporting policy information to another server . . . . . . . . . . . . . . . 458

14.3 Exporting and importing server to server . . . . . . . . . . . . . . . . . . . . . . . 460

14.3.1 Moving a complete node’s data and meta data . . . . . . . . . . . . . . 460

14.3.2 Moving a node’s metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

14.4 Moving a node back to an originating server. . . . . . . . . . . . . . . . . . . . . 466

14.4.1 Merging file spaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467

14.4.2 Suggestions for leveraging the export feature . . . . . . . . . . . . . . . 471

14.5 Server groups and remote command routing . . . . . . . . . . . . . . . . . . . . 471

14.6 Reorganizing the database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473

14.7 Tivoli Storage Manager and TEC integration . . . . . . . . . . . . . . . . . . . . 478

14.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479

Chapter 15. Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . 481

15.1 How to measure performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

15.1.1 Network benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

15.1.2 Tivoli Storage Manager client performance tracing. . . . . . . . . . . . 488

15.1.3 Tivoli Storage Manager server performance tracing . . . . . . . . . . . 492

15.2 Architecture-based performance tuning . . . . . . . . . . . . . . . . . . . . . . . . 495

15.2.1 Database and recovery log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

15.2.2 Storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496

15.2.3 Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497

15.2.4 Client configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

15.2.5 LAN-free backup/restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

15.3 Tivoli Storage Manager server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498

15.3.1 Server database and recovery log . . . . . . . . . . . . . . . . . . . . . . . . 498

15.3.2 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

15.3.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502

15.3.4 General parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

15.4 Client node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

15.4.1 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506

15.4.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

xii IBM Tivoli Storage Manager Implementation Guide

15.4.3 General parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

15.5 System design for performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

15.5.1 PCI busses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

15.5.2 Tape busses (SCSI, Fibre) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

15.5.3 Disk topology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

15.5.4 System memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

15.5.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

15.5.6 Tape devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

15.6 Special performance tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

15.6.1 LAN-free tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

15.6.2 LTO/DLT tape tuning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

15.6.3 File system volumes versus raw logical volumes . . . . . . . . . . . . . 514

15.6.4 AIX virtual memory system tuning. . . . . . . . . . . . . . . . . . . . . . . . . 514

15.6.5 Use NTFS partitions for the server . . . . . . . . . . . . . . . . . . . . . . . . 516

15.6.6 Journal-based incremental backup . . . . . . . . . . . . . . . . . . . . . . . . 517

15.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

Part 4. Advanced topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

Chapter 16. Leveraging SAN environments . . . . . . . . . . . . . . . . . . . . . . . 525

16.1 LAN-free prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526

16.2 Server setup for LAN-free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528

16.2.1 Defining library, drives, and associated paths on the server. . . . . 530

16.2.2 Defining the device class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

16.2.3 Creating primary sequential storage pool for LAN-free. . . . . . . . . 531

16.2.4 Defining policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532

16.2.5 LAN-free validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533

16.3 Storage Agent setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

16.3.1 Device drivers for shared devices . . . . . . . . . . . . . . . . . . . . . . . . . 534

16.3.2 Storage Agent software installation. . . . . . . . . . . . . . . . . . . . . . . . 537

16.3.3 Configuring the Storage Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 540

16.3.4 Device configuration on the Storage Agent. . . . . . . . . . . . . . . . . . 548

16.4 SAN device discovery support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552

16.4.1 Recovering from offline paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553

16.5 Client LAN-free customization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556

16.6 Performing LAN-free operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558

16.6.1 Determining whether the data movement is LAN-free . . . . . . . . . 560

16.6.2 LAN-free data transfer considerations . . . . . . . . . . . . . . . . . . . . . 562

16.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562

Chapter 17. Server-free data movement . . . . . . . . . . . . . . . . . . . . . . . . . . 565

17.1 Server-free: What it is and why to use it . . . . . . . . . . . . . . . . . . . . . . . . 566

17.2 Server-free setup requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568

17.3 Configuration steps: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570

Contents xiii

17.4 Setting up server-free data movement . . . . . . . . . . . . . . . . . . . . . . . . . 570

17.4.1 SAN configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570

17.4.2 SAN zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572

17.4.3 Setting up the SAN Data Gateway (datamover) . . . . . . . . . . . . . . 574

17.4.4 Configuring Tivoli Storage Manager server. . . . . . . . . . . . . . . . . . 575

17.4.5 Configuring the Tivoli Storage Manager Client . . . . . . . . . . . . . . . 579

17.5 Running server-free backup and restore. . . . . . . . . . . . . . . . . . . . . . . . 579

17.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581

Chapter 18. Network Data Management Protocol (NDMP) . . . . . . . . . . . 583

18.1 NDMP terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

18.1.1 Tivoli Storage Manager and NDMP . . . . . . . . . . . . . . . . . . . . . . . 584

18.1.2 NDMP backup for NAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584

18.1.3 NDMP support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585

18.1.4 Multiple NAS appliances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587

Chapter 19. Disaster Recovery Manager. . . . . . . . . . . . . . . . . . . . . . . . . . 589

19.1 Example of a DRM implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 590

19.2 DRM setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591

19.2.1 Register DRM license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591

19.2.2 Create a copy storage pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592

19.2.3 DRM settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594

19.2.4 Verifying the settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598

19.3 Daily operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598

19.3.1 Back up primary storage pools to copy storage pool . . . . . . . . . . 600

19.3.2 Backup of Tivoli Storage Manager database . . . . . . . . . . . . . . . . 603

19.3.3 Querying DR media. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604

19.3.4 Send disaster recovery media off-site. . . . . . . . . . . . . . . . . . . . . . 605

19.3.5 Generate the recovery plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609

19.3.6 Returning expired volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610

19.4 Server restore setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611

19.4.1 Obtain the latest DR plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

19.4.2 Find a replacement server and storage . . . . . . . . . . . . . . . . . . . . 613

19.4.3 Install the operating system and the server . . . . . . . . . . . . . . . . . 613

19.5 Break out the disaster recovery plan. . . . . . . . . . . . . . . . . . . . . . . . . . . 613

19.5.1 Obtain the recovery volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616

19.5.2 Review the Tivoli Storage Manager macros . . . . . . . . . . . . . . . . . 616

19.5.3 Review the device configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 618

19.5.4 Start the restore Tivoli Storage Manager server scripts . . . . . . . . 620

19.5.5 Restore primary storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

19.5.6 Summary of example disaster recovery plan . . . . . . . . . . . . . . . . 627

19.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627

Chapter 20. Bare Machine Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

xiv IBM Tivoli Storage Manager Implementation Guide

20.1 Windows Bare Machine Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630

20.1.1 Collect client machine information for disaster recovery . . . . . . . . 630

20.1.2 Collect partition and logical volume information with diskmap . . . 633

20.1.3 Store system information for DRM access . . . . . . . . . . . . . . . . . . 633

20.1.4 Insert client machine information into DRM . . . . . . . . . . . . . . . . . 634

20.1.5 Use machchar.vbs to insert machine reports into DRM . . . . . . . . 635

20.1.6 Windows systems additional information . . . . . . . . . . . . . . . . . . . 638

20.2 Using SysBack for Bare Machine Recovery . . . . . . . . . . . . . . . . . . . . . 639

20.2.1 An introduction to SysBack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

20.2.2 System installation options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647

20.2.3 Network boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648

20.2.4 Multivolume backup and tape device support . . . . . . . . . . . . . . . . 650

20.2.5 Partition backup, recovery, and cloning . . . . . . . . . . . . . . . . . . . . 651

20.2.6 Partition backup and reinstallation (system recovery). . . . . . . . . . 651

20.2.7 Cloning backup images between partitions. . . . . . . . . . . . . . . . . . 657

20.2.8 Cloning from a stand-alone system to a partition . . . . . . . . . . . . . 665

20.2.9 License information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666

20.2.10 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667

20.3 Integrating SysBack with Tivoli Storage Manager. . . . . . . . . . . . . . . . . 667

20.3.1 Prerequisites, limitations, and exclusions . . . . . . . . . . . . . . . . . . . 667

20.3.2 Basic setup and configuration tasks . . . . . . . . . . . . . . . . . . . . . . . 670

20.3.3 Creating a Tivoli Storage Manager virtual device . . . . . . . . . . . . . 672

20.3.4 Configuring network boot options for BMR . . . . . . . . . . . . . . . . . . 675

20.3.5 Recovery and system reinstallation from a server . . . . . . . . . . . . 677

Chapter 21. Data Protection configuration on the server . . . . . . . . . . . . 681

21.1 Basic assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682

21.2 Policy creation requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682

21.2.1 Defining a management class in an existing policy domain . . . . . 682

21.2.2 Defining a new policy domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

21.2.3 Backing up and archiving copygroup considerations . . . . . . . . . . 684

21.3 Register node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687

21.4 Server configuration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 688

Chapter 22. Tivoli Storage Manager upgrade considerations . . . . . . . . 691

22.1 General upgrade considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

22.1.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692

22.1.2 Clients and Data Protection modules . . . . . . . . . . . . . . . . . . . . . . 694

22.1.3 Storage Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

22.2 Server upgrade best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

22.2.1 Server quiesce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698

22.2.2 Backing up important components . . . . . . . . . . . . . . . . . . . . . . . . 698

22.2.3 Upgrading the server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

Contents xv

22.2.4 Testing new updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

22.2.5 Enabling production mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700

22.3 Performing server upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700

22.3.1 Migration on Windows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701

22.3.2 Migration on AIX 5L. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707

22.4 Performing client upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

22.4.1 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715

22.4.2 AIX 5L client upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716

22.5 Storage Agent upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718

22.5.1 AIX Storage Agent migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718

22.5.2 Windows 2003 Storage Agent migration. . . . . . . . . . . . . . . . . . . . 719

22.6 Library migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719

Part 5. Appendixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721

Appendix A. Planning and sizing worksheets . . . . . . . . . . . . . . . . . . . . . 723

Worksheets grouped in tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724

Appendix B. Book support material: macros and scripts. . . . . . . . . . . . 729

Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730

Define administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730

Define client option sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731

Define policy structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733

Define schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

Define server scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737

Create storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738

Delete default storage pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739

Server options files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

z/OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742

Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744

Client options files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746

AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746

NetWare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747

Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751

Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765

IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765

Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768

xvi IBM Tivoli Storage Manager Implementation Guide

How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770

IBM Redbooks collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773

Figures

1-1 Our IBM Tivoli Storage Manager environment. . . . . . . . . . . . . . . . . . . . . 5

2-1 Tivoli Storage Manager backup/restore scenarios. . . . . . . . . . . . . . . . . 17

2-2 LAN-free data movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3-1 Windows Tivoli Storage Manager server installation menu . . . . . . . . . . 79

3-2 Windows reboot system after installation. . . . . . . . . . . . . . . . . . . . . . . . 81

3-3 Server main configuration wizard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3-4 ISC and TSM Administration Center: sample figure . . . . . . . . . . . . . . . 85

3-5 InstallShield Wizard for IBM Integrated Solutions Console . . . . . . . . . . 86

3-6 ISC installation: Review and confirm settings . . . . . . . . . . . . . . . . . . . . 87

3-7 ISC installation progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3-8 InstallShield wizard for Administration Center . . . . . . . . . . . . . . . . . . . . 89

3-9 Administration Center installation: Confirm . . . . . . . . . . . . . . . . . . . . . . 90

3-10 TSM Administration Center installation: success. . . . . . . . . . . . . . . . . . 91

4-1 Difference between a local and Web-based restore . . . . . . . . . . . . . . . 99

4-2 Web backup-archive client main window . . . . . . . . . . . . . . . . . . . . . . . 100

4-3 Tivoli Storage Manager lab setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

4-4 Backup-archive client installation packages . . . . . . . . . . . . . . . . . . . . 109

4-5 Client code destination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4-6 Client setup type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

4-7 Completion of client installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

4-8 Java GUI client configuration wizard . . . . . . . . . . . . . . . . . . . . . . . . . . 122

4-9 Server name definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

4-10 Client/Server communication method screen . . . . . . . . . . . . . . . . . . . 124

4-11 Setting up communication parameters . . . . . . . . . . . . . . . . . . . . . . . . 125

4-12 Client node name configuration screen . . . . . . . . . . . . . . . . . . . . . . . . 126

4-13 Completing client configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

4-14 UNIX Tivoli Storage Manager client login . . . . . . . . . . . . . . . . . . . . . . 127

4-15 Client Configuration Wizard startup window . . . . . . . . . . . . . . . . . . . . 130

4-16 Windows create options file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4-17 Windows client nodename . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

4-18 Client-server communication method . . . . . . . . . . . . . . . . . . . . . . . . . 133

4-19 TCP/IP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

4-20 Recommended Include/Exclude List . . . . . . . . . . . . . . . . . . . . . . . . . . 135

4-21 Common File Exclusion Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

4-22 Specifying domains for incremental and image backups. . . . . . . . . . . 137

4-23 Completion of client configuration wizard . . . . . . . . . . . . . . . . . . . . . . 138

4-24 Windows Tivoli Storage Manager client login . . . . . . . . . . . . . . . . . . . 138

4-25 Configuring the Web client selection . . . . . . . . . . . . . . . . . . . . . . . . . . 139

xviii IBM Tivoli Storage Manager Implementation Guide

4-26 Installing a new Web client screen panel. . . . . . . . . . . . . . . . . . . . . . . 140

4-27 Selection of the Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

4-28 Choose the path and file name of the options file . . . . . . . . . . . . . . . . 142

4-29 Enter a Web Client Acceptor port number . . . . . . . . . . . . . . . . . . . . . . 143

4-30 Enter the client’s node name and password . . . . . . . . . . . . . . . . . . . . 144

4-31 Selection panel for the account and startup options . . . . . . . . . . . . . . 145

4-32 Select the name of the client agent . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

4-33 Choose whether to allow remote access to the Web client . . . . . . . . . 147

4-34 Choose whether to start the service after the wizard completes . . . . . 148

4-35 Completion panel for the Web client configuration . . . . . . . . . . . . . . . 149

4-36 That is all for this wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

4-37 Installing a new client TSM Scheduler Wizard selection . . . . . . . . . . . 150

4-38 Choosing the name and location of the client scheduler . . . . . . . . . . . 151

4-39 Select the option file to use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

4-40 Supply the client node name and password . . . . . . . . . . . . . . . . . . . . 153

4-41 Choose the Windows account and starting options for the client . . . . 154

4-42 Defining schedule and error log names . . . . . . . . . . . . . . . . . . . . . . . . 155

4-43 Startup choice once the wizard has completed . . . . . . . . . . . . . . . . . . 156

4-44 Configuration completion panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

4-45 Scheduler installed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

4-46 Installing a new journal engine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

4-47 Choose the file systems that are to be journaled. . . . . . . . . . . . . . . . . 159

4-48 Specify the location for the journal database . . . . . . . . . . . . . . . . . . . . 160

4-49 Journal engine notification filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

4-50 Journal database maximum size panel . . . . . . . . . . . . . . . . . . . . . . . . 162

4-51 Login properties for the journal service . . . . . . . . . . . . . . . . . . . . . . . . 163

4-52 Start up service after the wizard completes . . . . . . . . . . . . . . . . . . . . . 164

4-53 Journal service completion wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

4-54 Journal engine successfully installed panel . . . . . . . . . . . . . . . . . . . . . 165

4-55 Install panel for the online image support . . . . . . . . . . . . . . . . . . . . . . 166

4-56 Successful configuration of online image support . . . . . . . . . . . . . . . . 167

4-57 Installation of the Logical Volume Snapshot Agent panel . . . . . . . . . . 167

4-58 Successfully completed panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

4-59 Windows GUI client interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

4-60 Java-based backup-archive client GUI interface . . . . . . . . . . . . . . . . . 173

4-61 Client scheduler service is running on a machine . . . . . . . . . . . . . . . . 176

4-62 Changing startup behavior of the client scheduler service in Windows 180

4-63 Platform-independent Web client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

4-64 Web client login dialog box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

5-1 Tivoli Storage Manager database volumes . . . . . . . . . . . . . . . . . . . . . 190

5-2 Recovery log volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

5-3 Database and recovery log mirroring. . . . . . . . . . . . . . . . . . . . . . . . . . 203

6-1 Storage pool hierarchy for our recommended setup . . . . . . . . . . . . . . 216

Figures xix

7-1 Sample policy definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

10-1 ISC login screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

10-2 Administration Interface welcome window . . . . . . . . . . . . . . . . . . . . . . 314

10-3 Server environment overview and health status . . . . . . . . . . . . . . . . . 315

10-4 Java-based command line administrative interface . . . . . . . . . . . . . . . 316

10-5 Using InstallShield Wizard to install the administrative client interface 318

11-1 Windows backup GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

11-2 Estimate function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

11-3 Backup report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

11-4 Windows 2000 system object backup . . . . . . . . . . . . . . . . . . . . . . . . . 345

11-5 Windows restore GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

11-6 Point-in-time restore function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

11-7 Restore options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

11-8 Restore destination options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

11-9 Restore report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358

11-10 System object restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

11-11 Windows archive GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

11-12 Archive options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

11-13 Archive report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365

11-14 Windows retrieve GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

11-15 Retrieve options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

11-16 Retrieve destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

11-17 Retrieve report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

12-1 Scheduling of operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374

12-2 Enhanced schedule repetition, day of week, ISC panel. . . . . . . . . . . . 390

12-3 Enhanced schedule, week of month, ISC panel . . . . . . . . . . . . . . . . . 390

13-1 Tivoli Storage Manager management monitor option . . . . . . . . . . . . . 399

13-2 Server Properties view showing Administrators. . . . . . . . . . . . . . . . . . 408

13-3 ADMIN_CENTER account update pwd and Lock box unchecked . . . 409

13-4 Health monitor menu selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

13-5 Defining the Health Monitor password and refresh interval . . . . . . . . . 411

13-6 Health monitor details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

13-7 IBM Tivoli Operational Reporting result . . . . . . . . . . . . . . . . . . . . . . . . 413

13-8 How Tivoli Storage Manager tapes are processed . . . . . . . . . . . . . . . 428

13-9 On-site and off-site distinction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

13-10 IBM Tivoli Storage Manager and tape life cycle. . . . . . . . . . . . . . . . . . 432

13-11 Tivoli Storage Manager tape processing . . . . . . . . . . . . . . . . . . . . . . . 433

13-12 IBM Tivoli Storage Manager error entries in Windows Event Viewer. . 450 13-13 Detailed event information of an IBM Tivoli Storage Manager error . . 451

14-1 Server-to-server lab setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461

15-1 Tivoli Storage Manager volume definitions . . . . . . . . . . . . . . . . . . . . . 497

15-2 Tivoli Storage Manager tunables overview . . . . . . . . . . . . . . . . . . . . . 521

16-1 SAN lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527

xx IBM Tivoli Storage Manager Implementation Guide

16-2 Windows device manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

16-3 Correctly identified devices in Windows Device Manager . . . . . . . . . . 536

16-4 Registry settings for MaximumSGList in Windows 2000 . . . . . . . . . . . 537

16-5 Storage Agent and Device Driver installation screen. . . . . . . . . . . . . . 538

16-6 Windows Storage Agent customer information . . . . . . . . . . . . . . . . . . 538

16-7 Windows Storage Agent setup type . . . . . . . . . . . . . . . . . . . . . . . . . . . 539

16-8 Storage Agent initialization wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541

16-9 Storage Agent configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

16-10 Tivoli Storage Manager server details . . . . . . . . . . . . . . . . . . . . . . . . . 543

16-11 Storage Agent service configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 544

16-12 Running Storage Agent service in Windows Services . . . . . . . . . . . . . 545

16-13 Backup of c:\console directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558

16-14 Backup status window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

17-1 Server-free data movement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

17-2 SAN network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

17-3 Server-free SAN zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572

17-4 StorWatch SAN configuration overview . . . . . . . . . . . . . . . . . . . . . . . . 573

17-5 Server-free client backup in process . . . . . . . . . . . . . . . . . . . . . . . . . . 580

17-6 Server-free backup server status query. . . . . . . . . . . . . . . . . . . . . . . . 580

17-7 Tivoli Storage Manager server-free client restore in process . . . . . . . 581

18-1 NDMP operations and Tivoli Storage Manager interactions . . . . . . . . 585

19-1 DRM lab setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590

19-2 DRM media states and life cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599

19-3 Primary pool backup and server database backup . . . . . . . . . . . . . . . 608

19-4 Disaster recovery plan generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609

19-5 Server restoration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

20-1 Insert machine characteristics using Admin Center. . . . . . . . . . . . . . . 635

20-2 Two-way pull backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

20-3 Three-way pull backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644

20-4 MIrrors split by the Offline Mirror Backup feature . . . . . . . . . . . . . . . . 645

20-5 Stacked full system (installation image) backup tape layout . . . . . . . . 646

20-6 Classic network boot relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

20-7 NIM resource network boot relationships. . . . . . . . . . . . . . . . . . . . . . . 650

20-8 Local backup to tape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652

20-9 Remote backup to tape and network boot of partition . . . . . . . . . . . . . 654

20-10 Local backup to CD/DVD and using that image for a new partition . . . 659

20-11 Remote backup, remote install, and network boot. . . . . . . . . . . . . . . . 661

20-12 Stand-alone system interaction with a partition . . . . . . . . . . . . . . . . . . 666

22-1 Windows lab environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701

22-2 Migration failure due to running server process. . . . . . . . . . . . . . . . . . 703

22-3 Automatic server instance upgrade during migration. . . . . . . . . . . . . . 703

22-4 Device driver upgrade requires reboot of the machine . . . . . . . . . . . . 704

22-5 Updating the server instance: applying the patch level . . . . . . . . . . . . 706

Figures xxi

22-6 AIX lab environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

xxii IBM Tivoli Storage Manager Implementation Guide

Notices

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

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

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES

THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

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

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

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

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

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

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

xxiv IBM Tivoli Storage Manager Implementation Guide

Trademarks

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

Eserver

Redbooks™ (logo) eServer™ iSeries™ pSeries® xSeries® z/OS® z/VM® zSeries® Advanced Peer-to-Peer

Networking® AFS® AIX® 5L™ AIX Domino® DB2® Universal Database™

DB2 DFS™ DFSMShsm™ Enterprise Storage Server® ESCON® HACMP™ Informix® IBM Lotus® Notes® Lotus Micro Channel® MVS™ Notes OS/390® OS/400® Passport Advantage® PowerPC® Reference Platform®

PowerPC PA L™ Redbooks RACF® RS/6000® S/390® System Storage™ SysBack™ SANergy® Tivoli® Enterprise™ Tivoli Enterprise Console® Tivoli TotalStorage® Versatile Storage Server™ WebSphere®

The following terms are trademarks of other companies:

eXchange™, IPX™, Java™, Java Naming and Directory Interface™, JVM™, ONC™, RSM™, Solaris™, Sun™, VSM™, and all Java-based trademarks are trademarks of Sun Microsystems™, Inc. in the United States, other countries, or both.

Excel®, Microsoft®, MS-DOS®, Windows® server, Windows NT®, Windows, Win32®, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Itanium®, Intel® logo, Intel Inside® logo, and Intel Centrino logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States, other countries, or both.

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

Linux™ is a trademark of Linus Torvalds in the United States, other countries, or both.

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

Preface

This IBM® Redbook describes how to integrate, install, configure, and operate the very latest IBM Tivoli® Storage Manager in heterogeneous environments.

You will learn how to implement and operate IBM Tivoli Storage Manager. You should already have a conceptual understanding of IBM Tivoli Storage Manager. We show you how to set up and implement the software, covering basic and advanced topics for Windows-based, AIX®-based, and Linux-based operating system platforms.

We demonstrate how to handle all of the important tasks necessary to protect your business: planning, client and server installation, operations, performance considerations, SAN environments, NDMP, and much more.

This practical guide is intended for these audiences: system administrators, new to IBM Tivoli Storage Manager, who are asked to commence a basic IBM Tivoli Storage Manager implementation for the very first time; as well as administrators who want to learn more about the basic and advanced components and their implementation. This book is also a very valuable resource if you are planning to become a certified IBM Tivoli Storage Manager consultant.

A companion redbook, IBM Tivoli Storage Management Concepts, SG24-4877, is available. It covers concepts, architecture, and systems management features of IBM Tivoli Storage Manager and shows complementary products available. That book is a useful general introduction for people who have had no previous exposure to IBM Tivoli Storage Manager.

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, San Jose Center.

Charlotte Brooks is an IBM Certified IT Specialist and Project Leader for Storage Solutions at the International Technical Support Organization, San Jose Center. She has 15 years of experience with IBM in storage hardware and software support, deployment, and management. She has written many IBM Redbooks™, and has developed and taught IBM classes in all areas of storage and storage management. Before joining the ITSO in 2000, she was the Technical Support Manager for Tivoli Storage Manager in the Asia Pacific Region.

xxvi IBM Tivoli Storage Manager Implementation Guide

Peter McFarlane is an IT Infrastructure Consultant for andersenIT in Brisbane,

Australia. He is a certified Tivoli Storage Manager Consultant and AIX Technical Expert. He has 28 years of experience in IT, including 22 years on UNIX platforms and 10 years on AIX and Tivoli Storage Manager. His areas of expertise include high availability, disaster recovery, and storage management. He is a certified Tivoli Storage Manager instructor. He is an author of the IBM Redbook IBM Versatile Storage Server™, SG24-2221.

Norbert Pott is an IBM Tivoli Storage Manager Support Specialist in Germany. He works for the Tivoli Storage Manager back-end support team and provides support to customers worldwide. He has 24 years of experience with IBM, over 15 years of experience in IT, and more than 10 years of experience in the Tivoli Storage Manager product, starting with then ADSM Version 2.1.5. His areas of expertise include Tivoli Storage Manager client development skill and in-depth knowledge when it comes to problem determination. He is an author of the IBM Redbook IBM Tivoli Storage Manager Version 5.3 Technical Workshop Presentation Guide, SG24-6774.

Eduardo Tomaz is an IT Specialist for IBM Global Services in Brazil, supporting IBM international accounts. He has five years of experience with IBM and Tivoli Storage Manager. His areas of expertise include consulting, planning, and implementation of IBM Tivoli Storage Manager backup solutions, storage management, and IBM Tivoli Data Protections for ERP, Mail, Database and Storage Agent for UNIX and Windows. He is an IBM Certified Deployment Professional - Tivoli Storage Manager V5.2 and V5.3, and IBM Certified Storage Administrator - Tivoli Storage Manager V5.

Martin Trcka is an IT Consultant at GC System a.s., an IBM Business Partner in the Czech Republic. He has eight years of experience in the IT field. His areas of expertise include data protection, pSeries® and AIX, and highly available clusters. He holds several certifications, including IBM Certified Deployment Professional - Tivoli Storage Manager 5.2, IBM Certified Advanced Technical Expert for pSeries and AIX 5L™, and IBM eServer™ Certified Systems Expert pSeries HACMP™ for AIX 5L.

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

Jason Basler and Ashish Agarwal developed and provided Chapter 17, “Server-free data movement” on page 565.

Jennifer Davis developed and provided the sections 20.2, “Using SysBack for Bare Machine Recovery” on page 639, and “Integrating SysBack™ for System Backup and Recovery with Tivoli Storage Manager”.

The authors of the previous editions of this redbook are Aezil Andal, Arnold Balingit, Ross Battaglia, Charlotte Brooks, Dan Edwards, J.P. Houle, Mathis

Preface xxvii

Landzettel, Armando Lemos da Silva Filho, Rod MacLeod, Andy Pattinson, Patrick Randall, Holger Speh, Phil Thomas, and Roland Tretau.

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

Emma Jacobs, Deanna Polm, Sangam Racherla, Julie Czubik International Technical Support Organization

Betsy Colby, Mike Dile, Diana Duan, Rob Elder, Del Hoobler, Tricia Jiang, Holly King, Randy Larson, Len Ling, Zong Ling, Steven John Mann, Urs Moser, Charles Nichols, Kathy Pang, Brian Pendergrass, Rosa Plaza, Deanna Shaw, Jim Smith, John Viksne, Chris Zaremba IBM Tivoli Storage Manager Development and Marketing, IBM US

Monika Doshi, Nicholas Wilhelm-Olsen, Chris Lueth Network Appliance, Inc.

Figure 1 The team: Eduardo, Martin, Peter, Charlotte, and Norbert

xxviii IBM Tivoli Storage Manager Implementation Guide

Become a published author

Join us for a two- to six-week residency program! Help write an IBM Redbook dealing with specific products or solutions, while getting hands-on experience with leading-edge technologies. You'll team with IBM technical professionals, Business Partners, or customers.

Your efforts will help increase product acceptance and client satisfaction. As a bonus, you'll develop a network of contacts in IBM development labs, and increase your productivity and marketability.

Find out more about the residency program, browse the residency index, and apply online at:

ibm.com/redbooks/residencies.html

Comments welcome

Your comments are important to us!

We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways:

򐂰 Use the online Contact us review redbook form found at:

ibm.com/redbooks

򐂰 Send your comments in an email to:

redbook@us.ibm.com

򐂰 Mail your comments to:

IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400

Part 1 Introduction

The objective of this book is to provide material describing how to implement and operate IBM Tivoli Storage Manager. We assume a basic knowledge of IBM Tivoli Storage Manager, which you can gain by reading the companion IBM Redbook, IBM Tivoli Storage Management Concepts, SG24-4877.

A successful implementation of IBM Tivoli Storage Manager benefits enormously from planning prior to attempting to set up the environment. The planning for what equipment is needed (such as hardware platform, size of processor, network connectively, and tape library) should all have been done before trying to make IBM Tivoli Storage Manager work in an environment that may not be suitable.

Part 1

2 IBM Tivoli Storage Manager Implementation Guide

Chapter 1. Implementation checklists

In this chapter we offer an overview of the IBM Tivoli Storage Manager environment described in our book, as well as implementation checklists for planning, installing, and operating that environment.

Our environment provides an integrated solution that incorporates client and server options, basic performance recommendations, and operational processes. In our experience, this environment has been shown to satisfy the most common client requirements while also forming a sound basis for extension.

The checklists provide step-by-step processes to plan and implement an IBM Tivoli Storage Manager environment. Although geared towards our book environment, the checklists can be used for any implementation. There are separate checklists for planning the environment, server implementation, client implementation, and daily operations.

We have provided planning sheets, option files, and administrative macros to help plan and implement your IBM Tivoli Storage Manager environment. Appendix A, “Planning and sizing worksheets” on page 723, and Appendix B, “Book support material: macros and scripts” on page 729, provide copies of those materials.

4 IBM Tivoli Storage Manager Implementation Guide

1.1 The big picture

Any Tivoli Storage Manager solution consists of a number of pieces that are crafted to satisfy a particular set of requirements. These solution pieces include definitions for data storage management, policy management, user management, and operational management.

The difficulty is in determining how to craft each of these pieces to complete the solution jigsaw puzzle. This is complicated by the vast number of options and variations that are possible with Tivoli Storage Manager.

This book is not designed to be a follow-along implementation guide that will actually install, configure, and implement Tivoli Storage Manager in your environment. Rather, the book is designed to provide you with step-by-step instructions and examples that you can follow when you design and implement your solution in your specific environment with your business policies and needs.

We have developed a functional Tivoli Storage Manager environment that has been shown to satisfy a number of key client requirements. Those key requirements are:

򐂰 Multiple backup copies of files to be kept 򐂰 Second copy of backup data to be kept off-site 򐂰 Restore time to be minimized 򐂰 High level of automation

Our environment also incorporates basic performance tuning recommendations and operational procedures for onsite-offsite tape movement. It forms a sound platform for future development.

Figure 1-1 on page 5 shows the data storage management perspective of our Tivoli Storage Manager environment. The figure shows the flow of data to and from the onsite storage pools and off-site copy pools. Some key features of this environment are:

򐂰 Separate storage pools for client directory information and client data 򐂰 Client data written to a disk storage pool, then migrated to tape storage pool 򐂰 Duplicate copies of onsite data created for off-site storage 򐂰 Mirrored Tivoli Storage Manager database and recovery log

Chapter 1. Implementation checklists 5

Figure 1-1 Our IBM Tivoli Storage Manager environment

The two primary disk storage pools hold client directory information (DISKDIRS) and client data (DISKDATA). The remaining storage pool (TAPEDATA) is on tape and holds only client data. A copy of the client data is stored in one off-site storage pool (OFFDATA), and a copy of the client directory data is stored in another storage pool (OFFDIRS).

1.1.1 Our support material

We provide worksheets, option files, and administrative macros to help plan and implement your Tivoli Storage Manager environment.

The worksheets are used during the planning phase of a Tivoli Storage Manager implementation, which we use and discuss in Chapter 2, “Implementation planning” on page 15.

CLIENT_1

EMPTY

OFFDIRS

OFFDATA

Return Reusable Tap e s

OFF SITE

ON SITE

Copy Pools

IBM Tivoli Storage Manager Server

MIGRATION

Backup Storage Pools to Copy Pools

Send copy to vault

Storage Pools

EMPTY

PRIVATE

TAPEDATA (LIBRARY)

SCRATCH

(USED)

(FREE)

DISKDATADISKDIRS

CLIENT_2

Client Directories

Client Data

6 IBM Tivoli Storage Manager Implementation Guide

The option files provided are examples for customizing your Tivoli Storage Manager server and clients. If you want to use them in your implementation, you need to modify the example files to fit into your environment, and replace the existing options files with these.

The administrative macros are used to reduce some steps in your Tivoli Storage Manager implementation. Again, you need to modify some of the macros to meet specific requirements in your Tivoli Storage Manager environment.

The support material we use here is available in softcopy on the Internet from the Redbooks Web server. Point your Web browser to:

ftp://www.redbooks.ibm.com/redbooks/SG245416

Alternatively, you can get to the same Web page at:

http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg245416.html?Open

Select Additional Materials and click the suggested link.

We provide two files. Each file contains all the support material in compressed format. The UNIX platform file is named sg245416.tar, and the Windows platform file is named sg245416.zip.

Table 1-1 lists the contents of the support material from those files.

Table 1-1 Our support material

File name Contents

dsmopt.aix Client user options file for AIX

dsmopt.nw Client options file for NetWare

dsmopt.win Client options file for Windows

dsmserv.aix Server options file for AIX

dsmserv.mvs Server options file for MVS™

dsmserv.win Server options file for Windows NT/2000

dsmsys.aix Client system options file for AIX

mac.admins Administrative macro to define administrators

mac.optionsets Administrative macro to define client option sets

mac.schedules Administrative macro to define administrative and client

schedules

mac.scripts Administrative macro to define server scripts

Chapter 1. Implementation checklists 7

We recommend that you download the support material files into a separate directory on a system from which you can run an administrative command client. In our experience, the implementation works best when you choose a UNIX or Windows platform for that system.

1.2 Planning checklist

Proper planning for your Tivoli Storage Manager environment is critical to the success of the implementation. This cannot be stressed enough. Plan first, verify the plan, then execute the plan.

The tasks contained in the Tivoli Storage Manager planning checklist are shown in Table 1-2. You should complete all of these tasks before implementing the Tivoli Storage Manager environment.

Table 1-2 Planning checklist

mac.stgcreate Administrative macro to create storage pools

mac.stgdelete Administrative macro to delete default storage pools

mac.policy Administrative macro to define policy domains, policy sets,

management classes, and copy groups

planning.123 Planning spreadsheets (Lotus® 123 format)

plan_sampledata.123 Planning spreadsheets (Lotus 123 format) with some

sample data

planning.xls Planning spreadsheets (Microsoft Excel format)

plan_sampledata.xls Planning spreadsheets (Microsoft Excel format) with some

sample data

readme.1st Contents of support materials

File name Contents

Tasks Refer to

Download our support materials. Table 1-1 on page 6

Complete client requirements worksheet. 2.2, “Client environment data” on

page 16

Complete data retention worksheet. 2.3, “Data retention requirements” on

page 26

8 IBM Tivoli Storage Manager Implementation Guide

1.2.1 Server implementation checklist

The server checklist identifies those tasks you must complete to set up this Tivoli Storage Manager server environment. The tasks contained in the checklist are shown in Table 1-3. These tasks are performed by either the system administrator or the Tivoli Storage Manager administrator.

The checklist consists of a series of tasks that must be performed sequentially. Each task in the table has a reference to another section in this book. The referred section contains the specific details about how to complete that task. For some tasks, we additionally refer to the macro file we provide, as described in

1.1.1, “Our support material” on page 5.

Table 1-3 Server implementation checklist

Choose server platform. 2.4, “Server architecture considerations”

on page 30

Size Tivoli Storage Manager server. 2.5, “System size” on page 33

Determine network load. Table 2-8 on page 37

Complete Tivoli Storage Manager database worksheet.

Table 2-9 on page 43

Complete Tivoli Storage Manager recovery log worksheet.

Table 2-10 on page 44

Complete Tivoli Storage Manager storage pool worksheet.

Table 2-11 on page 48

Complete Tivoli Storage Manager disk worksheet.

Table 2-13 on page 49

Determine tape library. 2.9.2, “Tape libraries” on page 52

Determine number of tape drives. Table 2-15 on page 51

Determine number of tape volumes. 2.10.1, “On-site volumes” on page 53

and 2.10.2, “Off-site volumes” on page 56

Complete administrator worksheet. Table 2-16 on page 59

Tasks Refer to

Tasks Refer to: Macro

Download latest server code fixes. 3.2, “Latest software

updates” on page 68

Chapter 1. Implementation checklists 9

Install base server code and latest fixes. 3.3, “AIX server

installation” on page 70,

3.4, “Linux server installations” on page 72 or 3.5, “Windows 2000/2003 server installation” on page 78 for your specific platform

Update server options file. 3.7.1, “Server options file”

on page 91

Create database volumes. 5.1, “Database” on

page 188

Create recovery log volumes. 5.2, “Recovery log” on

page 192

Mirror database. 5.6.1, “Database

mirroring” on page 205

Mirror recovery log. 5.6.2, “Recovery log

mirroring” on page 206

Remove default database volumes. 5.7.1, “Removing the

default database volume” on page 207

Remove default recovery log volumes. 5.7.2, “Removing the

default recovery log volume” on page 209

Set up server licensing. 9.2, “Registering licensed

features” on page 305

Define tape libraries. 6.2.1, “Defining a library”

on page 222

Define a library path. 6.2.4, “Defining a path to a

drive in a library” on page 226

Define tape drives. 6.2.3, “Defining a drive in

a library” on page 225

Define a tape path. 6.2.4, “Defining a path to a

drive in a library” on page 226

Tasks Refer to: Macro

10 IBM Tivoli Storage Manager Implementation Guide

Define device classes. 6.2.5, “Defining a device

class for a library” on page 228

Change server run-time settings. 3.7, “Customization” on

page 91

Define storage pools. 6.3, “Storage pools” on

page 231

stgcreate

Define storage pool volumes. 6.4, “Storage pool

volumes” on page 239

Remove default storage pools. 6.3.5, “Deleting the

default storage pools” on page 238

stgdelete

Define policy domains. 7.1.1, “Defining policy

domains” on page 272

policy

Define policy sets. 7.1.2, “Defining policy

sets” on page 272

policy

Define management classes. 7.1.3, “Defining

management classes” on page 272

policy

Define backup copy groups. 7.1.4, “Defining backup

copy groups” on page 274

policy

Define archive copy groups. 7.1.5, “Defining the

archive copy group” on page 276

policy

Activate the new policy. 7.3.2, “Activating the

recommended policy sets” on page 279

Remove default policy management definitions.

7.3.3, “Deleting the STANDARD policy domain” on page 279

Define administrator IDs. 8.1, “Management” on

page 284

admins

Define administrative schedules. 12.2, “Administrative

schedules” on page 374

schedules

Define client schedules. 12.3, “Client schedules”

on page 386

schedules

Tasks Refer to: Macro

Chapter 1. Implementation checklists 11

1.2.2 Client implementation checklist

The client implementation checklist consists of two parts that identify those tasks you must complete to set up this Tivoli Storage Manager client environment. The tasks contained in the checklists are shown in Table 1-4 and Table 1-5.

Each checklist consists of a series of tasks that must be performed sequentially. Each task in the table has a reference to another section in this book. The section referred to contains the specific details on how to complete that task.

The first checklist consists of tasks performed at the Tivoli Storage Manager server. These tasks are performed by the Tivoli Storage Manager administrator.

Table 1-4 Client implementation checklist: server tasks

The second checklist consists of tasks performed at the Tivoli Storage Manager client. These tasks are performed by the administrator of that client system.

Table 1-5 Client implementation checklist: client tasks

Create client option sets. 8.3, “Client option sets” on

page 298

optionsets

Tasks Refer to: Macro

Tasks Refer to

on page 292

Associate client nodes with schedules. 12.3.3, “Associating a client

with a schedule” on page 391

Associate client nodes with client option set. 8.3.5, “Associating a client

node with a client option set” on page 301

Grant authority for Web client access. “Web client” on page 183

Define event logging. 13.3, “Event monitoring” on

page 404

Tasks Refer to

Download the latest client code. 4.1.1, “Backup-archive

client” on page 98

12 IBM Tivoli Storage Manager Implementation Guide

1.2.3 Operations checklist

The operations checklist consists of those tasks you should complete on a daily basis. The tasks contained in the checklist are shown in Table 1-6. Each task in the table has a reference to another section in this book. Each section referred to contains the specific details on how to complete that task. This checklist does not include the tasks we recommend scheduling on a daily basis. See Chapter 13, “Routine tasks” on page 395, for more information about scheduled operations.

Table 1-6 Daily operations checklist

Install the client code. 4.2, “Code installation” on

page 101

Update the environment. “Environment variables” on

page 113

Update client options files. “Options file” on page 114

Start backup-archive client. “Starting a session” on

page 172

Implement scheduler. 4.7, “Client scheduler” on

page 173

Implement Web client. “Web client” on page 183

Tasks Refer to

Check completion of client and administrative events. 13.6.2, “Client-server

activity” on page 421

Bring free off-site volumes back to onsite. 13.7.5, “Off-site tape

management to on-site” on page 439

Send copy tapes to off-site location. 13.7.3, “On-site and

off-site tape management” on page 430

Send Tivoli Storage Manager database copy to off-site. 13.7.8, “Database backup

management” on page 442

Check database and log utilization. 13.6, “Daily sanity checks”

on page 414

Chapter 1. Implementation checklists 13

1.3 Summary

In conclusion, we have discussed and given you access to many checklists, and now it is time to move into the actual planning details, architectural considerations, environments, and our recommendations.

Monitor number of scratch tapes available. “Number of scratch tapes”

on page 419

Check client restartable restores. “Query restartable restore

sessions” on page 424

Tasks Refer to

14 IBM Tivoli Storage Manager Implementation Guide

Chapter 2. Implementation planning

A successful implementation of IBM Tivoli Storage Manager benefits enormously from planning prior to attempting to set up the environment. We have just discussed the checklists you can use, and now we head into the planning stage.

16 IBM Tivoli Storage Manager Implementation Guide

2.1 Planning

Understanding your customers, your environment, your business, your needs, and your requirements are key to success, in storage management as well as business in general. Tivoli Storage Manager can help with your storage management needs and requirements. You will need three things to achieve success:

򐂰 Realistic goals and objectives 򐂰 Understanding 򐂰 Planning

In this chapter, as well as in the IBM Redbook IBM Tivoli Storage Management Concepts, SG24-4877, we present a number of planning worksheets that lead

you through gathering the client requirements and the data retention requirements in an orderly way. We assume that you are somewhat familiar with IBM Tivoli Storage Management concepts and terms.

We provide planning sheets, option files, server scripts, and administrative macros to help plan and implement your Tivoli Storage Manager environment. Blank worksheets are provided in Appendix A, “Planning and sizing worksheets” on page 723. Appendix B, “Book support material: macros and scripts” on page 729, contains information about how to download those support materials and what those materials provide.

2.2 Client environment data

Tivoli Storage Manager exists to provide services to clients, so it makes sense to begin by gathering data about the client environment. A Tivoli Storage Manager client is the machine from which Tivoli Storage Manager backs up or archives data. It could be various types of workstation, mobile computer, file server, database, or application server. Even though you may know the machine as a server, to Tivoli Storage Manager it is considered a

client. The Tivoli Storage

Manager server refers to the machine where the Tivoli Storage Manager server code runs. The Tivoli Storage Manager server stores and manages all the data backed up from clients.

Note: For UNIX and Windows clients, Tivoli Storage Manager offers an extra level of protection called Logical Volume Backup. We use the terms Image Backup and Logical Volume Backup interchangeably throughout the book to refer to this feature.

Chapter 2. Implementation planning 17

At this point, it is very important that you consider your backup and restore requirements so that you can match the Tivoli Storage Manager features to your needs. Since statistics show that the majority of user restore requests are for single files or other small amounts of data, the Tivoli Storage Manager file-level backup is the foundation of any recovery strategy. However, there are additional methods to cover your data restore requirements more completely.

Tivoli Storage Manager provides the following backup methods: 򐂰 File-level backup: Good for small and ad-hoc file or directory restores, but

may not be the optimal solution for large-volume restores.

򐂰 Logical volume backup: Good for large full restores, but only available on

UNIX and Windows, and not for single file restores.

򐂰 Backup sets: Good for remote and portable restores.

Figure 2-1 shows some possible generic scenarios. Of course, you can combine those in different ways to fit your own requirements.

Figure 2-1 Tivoli Storage Manager backup/restore scenarios

Due to the nature and complexity of customer environments and requirements, our planning description will give the building blocks for your own environment definition. The tables and calculations take into account the backup, archive,

ServerClient

3. Progressive incremental + periodical image

backup

Fast restore in case of disaster recovery

scenario

Unique command to restore at the point in time

2. Logical volume backup (UNIX)

Restore of raw devices and full logical volumes

1. Progressive incremental backup and archive function

File-level granularity of restore

Integrated backup/restore scenarios

QIC-5010 Data CartridgeIBM

QIC-501 0 Dat a Ca rt ri dg e

IBM

QIC-5010 Data Cartridge

IBM

Backup sets

Portable, Lan-free restore

18 IBM Tivoli Storage Manager Implementation Guide

image, and backup set requirements that should be suitable for a real-life situation. In any case, you must evaluate whether all such requirements are really important in your case and decide whether to implement them.

Complete Table 2-1 using a column for data from each client being considered for this Tivoli Storage Manager implementation. Analyzing client data helps you make decisions about the Tivoli Storage Manager server environment. The information collected in the table is used for node definitions and for calculating database, recovery log, and storage pool sizes.

This table is presented in a portrait orientation in the book due to space considerations. If you have a large number of nodes or use a spreadsheet version, you may find the table more workable by transposing it to a landscape orientation.

Table 2-1 IBM Tivoli Storage Manager Client requirements worksheet

Client Type1 Workstation

Client Type 2 Database server

Number of similar clients 20 4

ClientName WORKSTN1..20 DBSERV1..4

Contact information John at x1645

Remote users

Nick at x3761 UNIX and AIX

Operating system Windows XP UNIX servers

Total storage available (GB) 80 150

Total storage used (GB) 60 100

Total data changed per backup (GB) 6 = 10% 100 = 100%

Number of files or total GB to be backed up 3,000 * 20 = 60,000 2,000 * 4 = 8,000

Number of backup versions to be kept 2 7

Data compression .5 .66

Backup window times 17:00–23:00 22:00–04:00

Number of hours to complete backups 14 6

Total recovery time frame per server 48 hours 8 hours

Tivoli Storage Manager restore time 24 hours 4 hours

Average GB copied per archive 10 * 20 = 200 4* 20 = 80

Number of files archived 4,000 * 20 = 80,000 3,000 * 4 = 12,000

Chapter 2. Implementation planning 19

2.2.1 Client name

Enter the name Tivoli Storage Manager will use for each client. Each name must be unique. We recommend using the host name for the Tivoli Storage Manager client name, so various groups such as Help Desk personnel or end users can easily correlate the client node to the Tivoli Storage Manager name without having to look in a translation table.

By allowing the Tivoli Storage Manager client name to default to the machine name on Windows clients, you can roll out a standard Tivoli Storage Manager options file to numerous clients automatically without having to modify the options file for each client.

2.2.2 Contact information

Enter information identifying the contact person or group responsible for this client. This should be the person who knows the data structure and applications that run on these servers.

2.2.3 Operating system

Identify the operating system and level the client is using. Any clients using operating systems not supported by Tivoli Storage Manager will have to be handled separately.

Number of archives kept 12 12

Archive frequency Monthly Monthly

Archive window times Monthly Month end

Archive number of hours 24 hours 24 hours

Number of image backups 1 12

Image backup frequency N/A Monthly

Number of backup sets 6 6

Backup set frequency Monthly Bi-monthly

Policy domain Workstation UNIX

Client option set Windows AIX

Client Type1 Workstation

Client Type 2 Database server

20 IBM Tivoli Storage Manager Implementation Guide

2.2.4 Total storage available

Calculate the total amount of usable disk storage in GB available on the client. This number is the amount of disk storage seen by the client file system and does not contain the actual amount installed and used by a RAID or mirroring implementation.

2.2.5 Total storage used

Calculate the total amount of disk storage in GB currently in use or expected to be used on the client. If this number is unknown, use the Total storage available from above.

2.2.6 GB changed per backup

Calculate the amount of storage, data, or files changed between backup cycles. This value indicates how long the client will be busy backing up, and how robust a network is required to complete all the backups each backup cycle. It is used to estimate disk and tape storage requirements on the Tivoli Storage Manager server. Table 2-2 presents typical percentages of data changed for various sizes and types of data.

Table 2-2 Rules of thumb for selecting percentage of data changed

If your data change percentage is known, then enter that number in the worksheet. Otherwise, use Table 2-2 to estimate a rate, keeping in mind that your numbers may vary. A high estimate is better than one that is too low.

Configuration Percentage of data

changed (%)

Large, busy file server 10

Smaller, less busy file server 5

Workstation 1

Database using utilities or Tivoli Storage Manager for Databases

10–20

Database not using utilities or Tivoli Storage Manager for Databases

100

Chapter 2. Implementation planning 21

2.2.7 Number of files backed up

Calculate the total number of files to be backed up for each client. This number is used to estimate disk and tape storage requirements on the Tivoli Storage Manager server.

If the number of files is unknown, two values are possible. Enter either an estimate of the number of files in this field, or enter 10% of the Total Storage Used field, in GB.

2.2.8 Number of backup versions to be kept

Determine the number of changed copies that you want to keep of a file that exists on the client when the backup task runs. How many different versions of that file do you want to be able to restore? For example, if backup runs every night and a file changes every day, and you want to be able to restore any version up to one week ago, then you would choose 7 as the number of backups to keep. Remember that the more versions you choose to keep, the more database and storage pool space you will need to configure.

2.2.9 Data compression

Estimate a data compression rate. To do that, you must first decide whether to use data compression on the client.

Tivoli Storage Manager allows a client to compress data before sending it to the Tivoli Storage Manager server. To decide whether to use Tivoli Storage Manager compression, take into account the speed of your network, the speed of the client CPU, and whether the Tivoli Storage Manager server storage devices are capable of compression. Table 2-3 provides some criteria for selecting data compression.

Table 2-3 Rules of thumb for selecting data compression

Configuration Compression

Dial-up connection Yes

Network is approaching capacity Yes

High-speed data network No

Slower CPUs in clients No

Faster CPUs in clients Yes

No hardware compression on tape devices Yes

22 IBM Tivoli Storage Manager Implementation Guide

Compression takes time, so you need to decide whether the compression is helping or hurting the total elapsed time of your operation. In general, very high speed networks do not benefit as much from compression because network bandwidth is usually not saturated. Conversely, older client CPU models may run slowly because the CPU cannot compress data fast enough to keep the network connection busy.

Many sites have various combinations of these configurations, such as slow networks, slow CPUs, and small/slow devices. In this case, make a judgement call about using Tivoli Storage Manager compression. Performing tests may show you the most efficient mode for your environment.

Data compresses to varying degrees depending on the content of the files. Data composed of text, or many repeated characters like blanks, compresses well. Data that is already compressed, and data consisting of random characters like executables, does not compress well, and may actually grow.

If you decide to use compression, enter your data reduction rate. Use Table 2-4 to estimate the data reduction if your actual ratio is unknown, but the best advice is to make some tests on your actual data.

If you decide not to use compression, or are unsure whether to use compression, enter one (no compression) in the Data Compression field.

If you do not use client compression and your tape device has a hardware compression capability, then the data will still end up compressed when it reaches a tape volume. If you do use client compression, then you should disable any hardware compression capability on your tape devices, since data in general cannot be

doubly compressed.

Table 2-4 Typical data compression ratios

Small capacity or slow response storage devices Yes

Compression ratio Data reduction

Database data 3:1–4:1 0.66–0.75

Print and file server data 2:1 0.5

Executables, compressed data, encrypted data

1:1 1

Configuration Compression

Chapter 2. Implementation planning 23

2.2.10 Backup window times

Enter the times of the day between which Tivoli Storage Manager must start and complete its backup cycle. This window depends on when end-user client usage drops off, by availability requirements and by network capacity usage time frames.

2.2.11 Backup number of hours

Calculate the number of hours in the backup window.

2.2.12 Required recovery time frame

Identify the time frame in hours, which you have agreed to with the client, to recover a client completely. This is the time from when the data is lost to the time the data is usable again. It includes the time to fix or replace the machine and the time to restore the data.

Recovery time frames are vitally important, as this is the whole reason you are backing up.

This field documents your service level agreement with the client.

2.2.13 Tivoli Storage Manager restore time frame

Calculate the time frame, in hours, allotted to Tivoli Storage Manager to restore (possibly all) the data to the client. This number is used to size factors affecting the restore process such as network throughput and the number of tape drives required.

To calculate the Tivoli Storage Manager Restore Time Frame, subtract from the

required restore time frame, the maximum time required to prepare the client

machine for a restore. In reality, this number will vary, depending upon the complexity of the restore. In the worst case (a disaster), the time to prepare the machine may include contacting support, fixing or replacing the machine, installing an operating system, installing the Tivoli Storage Manager client code, and connecting to the network. In the best case (to simply recover deleted data), the time to prepare the machine may be the same as the required restore time frame.

A full Tivoli Storage Manager restore typically takes significantly more time than a full Tivoli Storage Manager backup. This is because of extra processing overhead that is required when restoring. Bear this in mind when planning the restore window—testing typical restores is essential to getting accurate data on restore transfer rates in your particular environment.

24 IBM Tivoli Storage Manager Implementation Guide

2.2.14 GB copied per archive

Calculate or estimate the amount of data to be archived during each archive session. Archives target specific data files. Typically, you do not archive whole systems.

2.2.15 Number of files archived

Calculate or estimate the number of files archived in each archive session. You can calculate this number by using an operating system utility to verify the size of a directory tree or an entire file space.

2.2.16 Number of archives kept

Identify how many archives will be kept. For example, if an archive is performed monthly, you may want to keep 12 copies of that archive. Note that this number is basically influenced by the retention period for that archive, since archives, unlike backups, do not have versions that expire.

2.2.17 Archive frequency

Determine how often you want to perform an archive function. Archives are typically run less frequently than incremental backups. Time frames such as monthly or yearly are common.

2.2.18 Archive window times

Enter the times between which Tivoli Storage Manager must start and complete its archive cycle for this client. This window is influenced by when end-user client usage drops off, by availability requirements, by network capacity usage time frames, or by when the data becomes available for archive.

Archive time frames may be less time sensitive than incremental backups if they are going against copies of data or against data already processed. Often it is not possible to automatically schedule this archive function using Tivoli Storage Manager schedules, due to the dependency on other events external to Tivoli Storage Manager.

This number may be a specific time frame, such as between 23:00 and 04:00, or a more general time frame, such as after month-end processing finishes.

2.2.19 Archive number of hours

Identify the number of hours available to complete the archive function.

Chapter 2. Implementation planning 25

2.2.20 Number of image backups

Identify the number of eligible system images that you want to back up. For a workstation that does not change very frequently, a good number could be six to twelve per machine.

2.2.21 Image backup frequency

Identify how often you want to perform image backups. A good standard will be on a monthly basis for less critical and static machines, with more frequent backups for more critical and dynamic machines.

2.2.22 Number of backup sets

Determine the number of backup sets that you want to create. This number must be balanced against your full recovery time and the change rate for data. Consider a more frequent backup set for large file systems.

2.2.23 Backup set frequency

Determine how often you will need to generate a backup set. Although a backup set is made of client data, it is a server-initiated process that requires some scratch tapes in the automated library or some guidelines for the operations team to run.

2.2.24 Policy domain

Leave this field blank. During the planning phase, this is unknown. We used this field in 1.2.1, “Server implementation checklist” on page 8, to contain the policy domain chosen for this client. For example, if you are implementing our configuration, the policy domains would be SERVER or WORKSTN.

For more information about policy domains see Chapter 7, “Data storage policies” on page 269.

2.2.25 Client option set

Leave this field blank. During the planning phase, this is unknown. We used this field in 1.2.2, “Client implementation checklist” on page 11, to contain the client option set chosen for this client. For example, if you are implementing our configuration, the client options set names would be AIX, WINDOWS, or NETWARE.

26 IBM Tivoli Storage Manager Implementation Guide

For more information about client option sets see 8.3, “Client option sets” on page 298.

2.3 Data retention requirements

In this section we identify the requirements for managing the data received from the clients. Categorize your data into a small number of groups with similar requirements. This table provides information to create copy groups under Management Classes in Tivoli Storage Manager, calculate storage pool sizes, and calculate the number of tapes required to hold the data.

Complete a column in Table 2-5 for each different group. We show two example groups.

Table 2-5 Storage policy requirement worksheet

2.3.1 Group name

Choose a descriptive name for each categorized group of data. In our example, the Workstn group is used for files from a workstation, while the Server group is used for all data from a large file server.

Example 1 Example 2

Group name Workstn Server

Number of backup versions 27

Backup file retention period 90 days NOLIMIT

Number of deleted versions 1 2

Last deleted file version retention period 60 days 180 days

Archive retention period 180 days 360 days

Off-site copies Ye s Ye s

Onsite collocation No Yes

Off-site collocation No No

Image backup retention 30 days 30 days

Backup set retention 180 days 60 days

Chapter 2. Implementation planning 27

2.3.2 Number of backup versions

You will use the Number of Backup Versions field as a basis to group your data storage requirements into management classes.

2.3.3 Backup file retention period

Determine the number of days you want to keep a backup version of a file (other than the current version). There are two options: keep the backup version for a set number of days; or specify NOLIMIT, which implies that you want Tivoli Storage Manager to retain all backup versions, other than the most recent version, indefinitely (the most recent active version is already stored indefinitely by default).

2.3.4 Number of deleted versions

Determine how many versions of a file to keep after the file has been deleted from the original file system. This parameter comes into force during the first backup cycle after the file has been deleted. For example, assume you are keeping seven versions of a file as specified above, and you have set this parameter to one. When the next backup cycle runs after the file has been deleted off the client, Tivoli Storage Manager will flag the six oldest backup versions of the file for deletion and just keep the most current backup version.

2.3.5 Last deleted file version retention period

Determine the number of days you want to keep the last backup version of a file after it has been deleted from the client. There are two options: keep the last backup version for a set number of days; or NOLIMIT, which implies that you want to keep the backup version indefinitely.

For example, if you are keeping one version of a deleted file, and you set this parameter to 60, then 60 days after this file is noticed by Tivoli Storage Manager as being deleted from the client file system, the one remaining backup version will be deleted from Tivoli Storage Manager.

28 IBM Tivoli Storage Manager Implementation Guide

2.3.6 Archive retention period

Determine how long you want to keep a file that is archived. Many sites set up a limited number of data groups with standard archive retention periods, such as seven days, 31 days, 180 days, 365 days, or 7 years. Nonstandard requests for archive retention periods are slotted into the next larger retention period group. This reduces management complexity at the expense of keeping some data longer than actually required. If every nonstandard request is honored, the number of groups quickly becomes unmanageable. On the other hand, you can use the backup set feature to retain all nonstandard backup requirements, or even just use backup sets instead of archive.

2.3.7 Off-site copies

Determine whether you want to send a copy of the data off-site. Copying data to a removable device like tape allows the data to be taken off-site. An off-site copy along with other procedures provides recoverability in the event that the Tivoli Storage Manager server becomes unusable, or that data on the Tivoli Storage Manager server becomes corrupted.

Enter Yes to use off-site copies or No to not use off-site copies.

2.3.8 Onsite collocation

Determine whether you want to use onsite collocation.

Tivoli Storage Manager uses collocation to dedicate as few tapes as required to hold all of one client’s files. Collocation reduces elapsed time for multiple file restores and full client restores at the expense of using more tapes, potentially increasing backup times and increasing Tivoli Storage Manager management time for migration and for storage pool copies.

Collocating by client allows as many clients to be restored simultaneously as you have tape drives. If you have stringent restore requirements and sufficient tape drives, then collocation makes good sense.

Table 2-6 highlights some factors affecting whether to use collocation.

Table 2-6 Factors affecting collocation

Onsite collocation

Off-site collocation

Short restore window Yes Yes

Less than 10 Clients, each 10 GB storage No No

Chapter 2. Implementation planning 29

Tivoli Storage Manager implementations that are small (small number of clients managing a small amount of data) do not see much benefit from collocation, due to the small number of tapes required for any restore. Large Tivoli Storage Manager implementations often collocate both onsite and off-site files due to the amount of data required for the restore of a client.

Tape drive capacity is a consideration for collocation. To use the minimum number of tapes, each tape must be used to its maximum capacity. Smaller capacity tapes will tend to fill completely even with small clients. In this case, collocation may be useful. With large capacity tape devices and collocation, a small client may not be able to fill a tape. With a large number of clients, significant numbers of tape volumes may be required.

2.3.9 Off-site collocation

Determine whether you want to use off-site collocation. Off-site collocation is usually rarely used, as it greatly increases the number of tapes that need to be sent off-site.

2.3.10 Image backup retention

Determine how long you want to keep an image backup. Consider your restore time frame and balance the criticality of a full file space restore, compared with a single or a small number of files. Image backups can be very useful for quick restore of large file systems. However, this process will take longer, depending on how many changes there have been to the file system since the last image backup. A rule of thumb is to keep at least one weekly image for small servers and a monthly image for bigger servers (or more frequently if change rates in the file system are high).

More than 50 clients, each 10 GB storage No No

More than 50 clients, each 100 GB or more Yes Yes/No

Limited disk or tape resources No No

Workstations No No

Database, print, and file servers Yes Yes

Onsite collocation

Off-site collocation

30 IBM Tivoli Storage Manager Implementation Guide

2.3.11 Backup set retention

A backup set execution creates a copy of the client node's previously backed up active files and stores them on sequential media. This has an impact on the number of tapes that you may need, especially if you want to retain those backup sets for long periods of time or even if you want to have one copy onsite and one for off-site purposes.

Determine how long you want to keep the backup sets. Use a small retention if your data changes frequently and you do not need to keep it for long periods. You can use a longer retention for special cases or for legal requirements.

2.4 Server architecture considerations

Having gathered information about the total client environment, you can now make decisions about the architecture of the Tivoli Storage Manager server environment. This section deals with issues related to the Tivoli Storage Manager server.

2.4.1 Server platform

A Tivoli Storage Manager server runs on several platforms. How do you choose one platform over another? With only minor differences, a Tivoli Storage Manager server provides the same functionality on every platform. The major differences between Tivoli Storage Manager server platforms relate to capacity, cost, installation, operation, supported devices, and installed user base. Each of these factors is explained below. Table 2-7 summarizes these considerations in choosing a Tivoli Storage Manager server platform. Note these are indicative only and designed for comparative purposes.

In many cases, the choice of server platform will be dictated by enterprise policy or preference, and will be primarily related to the platforms already in use, and with skilled administrators available.

Table 2-7 Tivoli Storage Manager server platform considerations

Windows system

UNIX iSeries™ zSeries®

Installed user base +++ AIX +++

Linux- ++; HP-UX, Sun™ Solaris™ +

Chapter 2. Implementation planning 31

2.4.2 Installed user base

The number of Tivoli Storage Manager servers installed for a particular platform is a consideration. At the time of writing, there are more Tivoli Storage Manager servers installed in Windows and AIX platforms, compared with the other choices.

2.4.3 Cost

Cost is a very dynamic area to discuss in a static manual, so we only generalize here. Check for special promotions and other discounts before committing to acquiring a particular platform configuration.

Cost is further subdivided into platform costs and Tivoli Storage Manager software license costs. Platform costs include the cost to acquire all the hardware and software to run the platform exclusive of the Tivoli Storage Manager software license. It ranges from low for a Windows system to high for zSeries. The high cost of installing a new zSeries system usually precludes it from being selected to run a Tivoli Storage Manager server exclusively. However, if this platform is already in use, it can be an economical choice, particularly if there is considerable in-house expertise on this platform available.

Tivoli Storage Manager license costs vary somewhat, with Windows costs being the lowest, followed by Linux, AIX, HP-UX, Sun Solaris, and iSeries costs. All of these are one-time charges to purchase the product. zSeries licenses are available for a one-time charge or as a monthly license fee. You may want to calculate the break-even point.

Tivoli Storage Manager server costs include a license for only one client by default. To manage more clients, more client licenses must be purchased. The actual client code is free to download. Under the current pricing model, Tivoli Storage Manager is sold as a per-processor fee for either a server or client

Cost + UNIX

++/+++ Linux +

++/+++ +++

Capacity + ++/+++ ++/+++ +++

Platform installation Simple Simple Medium Complex

Operation Simple Medium Medium Complex

Supported devices Many Many Limited Limited

Windows system

UNIX iSeries™ zSeries®

32 IBM Tivoli Storage Manager Implementation Guide

license. Check with your sales representative for more information about pricing and license regulations.

2.4.4 Capacity

The Tivoli Storage Manager server can essentially manage a basically unlimited number of clients and an unlimited amount of data (within restrictions of the maximum Tivoli Storage Manager server database size). With that said, the Tivoli selected Storage Manager server platform does limit the maximum configuration size. Various hardware platforms have different capacities in regard to the CPU power they can deliver to Tivoli Storage Manager, the number of devices that can be attached, and the maximum throughput.

Choose your platform with growth in mind. Moving from a small platform to a larger platform of the same server type, such as from a small pSeries system to a larger pSeries system, is relatively simple. Starting at the top end of a server type and moving to another server type, such as from Windows to AIX, involves export and import operations. Although the procedure is straightforward, it can be time-consuming and labor-intensive.

2.4.5 Platform installation

Installation consists of the platform installation and the Tivoli Storage Manager server code installation. Platform installation consists of hardware installation and configuration, and of operating system installation and configuration. Installation of each platform requires specialized knowledge that is not covered here.

The Tivoli Storage Manager server code installation varies by platform in the specifics, but generally follows a similar procedure. Installation on Windows can be easier due to the Windows wizards that have been provided. Installation of the Tivoli Storage Manager server on other platforms is not difficult for an administrator familiar with the platform.

2.4.6 Operation

Operation of a platform varies from reasonably simple on Windows, to complex on zSeries, with the UNIX and iSeries platforms somewhere in the middle. The availability of tools to assist in managing the operation of the various platforms is nearly opposite, in that the zSeries environment has a rich, powerful assortment of tools, while Windows is lacking in this regard.

Operation of Tivoli Storage Manager itself varies only in the way some operating system-specific Tivoli Storage Manager commands are issued on each platform.

Chapter 2. Implementation planning 33

It is important to look at the skills available among your staff for a particular operating system platform. If there are more people familiar with a particular platform, then it will be easier to maintain Tivoli Storage Manager in this environment.

2.4.7 Supported devices

There are a wide variety of supported devices on the Windows and UNIX platforms, including disk drives, tape drives, optical drives, and automated tape libraries. zSeries and iSeries are more limited in their choice of devices, but these devices generally have tremendous capacity.

Be careful if choosing a “smaller” platform that you will have the ability to attach the required amount of devices as the environment grows. On larger platforms this concern is usually reduced.

2.5 System size

Choosing the correct platform CPU size and memory requirements is an inexact art. As you would expect, the risk of configuring insufficient resources increases with the size of the Tivoli Storage Manager implementation. Small Tivoli Storage Manager implementations are at less risk of choosing an incorrect platform size, and the incremental cost to scale up or down is small. Many sites start small and grow into larger systems. However, this is of little help if you are starting large.

The Tivoli Storage Manager server is CPU-intensive, I/O-intensive, and memory-intensive. CPU is a function of the number of files to manage and how your platform processes I/O. A large number of small files is more CPU-intensive than a small number of large files. As the number of files and the amount of data to be moved increases, each backup, migration, storage pool copy, and expiration process will use more CPU to maintain the database entries. Tivoli Storage Manager takes advantage of multiple processors.

In our experience, zSeries platforms seem to be more CPU-intensive than UNIX platforms. zSeries sites should be aware that Tivoli Storage Manager can use significant amounts of CPU. We have seen Tivoli Storage Manager among the top five users of CPU on such systems.

I/O is the major part of Tivoli Storage Manager processing. In fact, Tivoli Storage Manager does very little else. Backups and restores, database updates and retrievals, and storage pool management (reclamation, migration, copying) are all I/O intensive. The I/O subsystem needs to be robust enough to handle this load. As the number of files and the amount of data climb, the need for a larger,

34 IBM Tivoli Storage Manager Implementation Guide

faster I/O subsystem increases. Separate controllers or adapters for disk and tape devices become essential as the load increases.

Memory is used to cache database entries, among other things. As the number of files being managed increases (and thus the database size increases), the amount of memory that Tivoli Storage Manager requires increases. zSeries users note that Tivoli Storage Manager likes to keep a large part of its address space in real storage. Since memory is relatively cheap, and you will never regret having too much memory, we recommend starting with a minimum of 1 GB and increasing from there.

2.6 Multiple Tivoli Storage Manager servers

When first setting up a Tivoli Storage Manager environment, we recommend implementing a single server. Once experience has been gained, and the implementation has grown enough to be reaching the capacity of the current server model family, a second server may be considered. We recommend upgrading your current server hardware to its next larger model before considering a second server, because this will keep the management overhead smaller. Tivoli Storage Manager can handle very large amounts of data or clients in one implementation. Currently, we have seen implementations with Tivoli Storage Manager internal server databases of 80 GB and larger (admittedly on very powerful, large platforms).

2.6.1 Reasons to consider multiple servers

Multiple Tivoli Storage Manager servers can be configured to provide some redundancy and disaster recoverability in the event of a Tivoli Storage Manager server outage. For example, a company with two well-connected sites, A and B, may decide to install a Tivoli Storage Manager system at each site. The system at site A would back up the client data from site B and vice versa. The loss of site A would mean that the Tivoli Storage Manager system at site B (which holds the backup data for site A) could immediately start restoring the client systems onto replacement equipment. The server at site A (which was lost) could be recovered to the server at site B.

The virtual volumes and Enterprise Administration capabilities of Tivoli Storage Manager make managing multiple servers easier by centralizing some administration functions and allowing changes to be replicated on some or all systems.

For very large or critical clients such as a large, enterprise-wide business intelligence complex, a dedicated Tivoli Storage Manager server (either on the same system or a different one) might be the best solution.

Chapter 2. Implementation planning 35

In installations where network connectivity is slow or expensive, placing a Tivoli Storage Manager server close to the clients usually makes sense. For example, for a business that has multiple file servers in each of a number of cities interconnected by a slow network, it may be appropriate to install a Tivoli Storage Manager server in each city.

2.6.2 Disadvantages of multiple servers

Multiple servers increase costs. Two small server CPUs may be more expensive than one larger CPU of the same power. Where one automated tape library may be enough, multiple servers may require multiple automated libraries. Every Tivoli Storage Manager server requires a Tivoli Storage Manager server license.

Management of a multiple-server environment is more complex, costly, and time consuming than a single environment. Installation and maintenance procedures have to be repeated on each server. Confusion about where data is stored, in the event of a restore, may result. Some of these disadvantages can be reduced by using the Enterprise Administration feature.

2.7 Network

The network connection plays an integral part in providing service to the client. If the other components of the solution have been correctly sized, it will often turn out that the network is the performance bottleneck. The network typically consists of a combination of network interface cards, hubs, routers, gateways, wire, and software. Tivoli Storage Manager server software, Tivoli Storage Manager client software, the server platform, and the client platform all have at least minimal monitoring or management capabilities. Often small networks may have no more than this (that is, no additional network management hardware or software), with limited or no network administration expertise. This makes the network a weak link in the overall management of the implementation.

Network design, implementation, and operation are beyond the scope of this book. However, we cover some basic recommendations.

2.7.1 Network considerations

The network speed to back up clients should be enough to transport common data and backup data. Generally, the backup should be done during nonworking hours. We call this period the backup window. While it is possible to split client backups to minimize network bandwidth, it makes the backup administration more difficult.

36 IBM Tivoli Storage Manager Implementation Guide

Workload calculations

An important consideration for designing the overall Tivoli Storage Manager solution is the total amount of data that the Tivoli Storage Manager server will need to support for backup or restore over a particular time frame.

A normal approach to estimate the network bandwidth needed is to consider all client information backed up in the same backup window using the following procedure:

1. Calculate the amount of data a Tivoli Storage Manager server will have to accommodate during its nightly backup window and ensure that the hardware can reasonably accommodate the data.

2. Calculate the amount of data that will be restored from a disaster recovery Tivoli Storage Manager server and ensure that the hardware will meet DR recovery SLAs.

We can calculate the workload for a Tivoli Storage Manager server in a theoretical environment. As an example, the environment has the following systems that we must back up:

򐂰 Twenty workstations

Each workstation has 60 GB of file data.

– Incremental forever backup with a change of approximately 10% – Six-hour backup window

򐂰 Four database servers

Each server has 100 GB of database data.

– Full backups with a change of 100% – Six-hour backup window

So doing the calculation for backup workload, each night we will need to back up:

(60 × 20 × .10)+ (100 × 4 ×1) = 520 GB

And dividing that by the time allowed for the backup:

So the network interfaces, drives, Tivoli Storage Manager server, and all other infrastructures must handle this amount of data in order to meet SLAs for this environment. Note that this type of calculation does not only apply to backups—it can and should be done for disaster recovery restores and single system restores.

6.86

520

≈

Chapter 2. Implementation planning 37

LAN/WAN transports

The performance of your network backup solution will be no better than the performance of your network. You must consider expected and real performance of your network when you are designing a Tivoli Storage Manager solution.

As an example, calculate theoretical network throughput using Fast Ethernet and a 40% efficiency:

򐂰 Assume 40–80% of total theoretical throughput for a TCP/IP adapter or

protocol.

򐂰 Be careful of the CPU usage and real throughput of faster TCP/IP protocols

(such as would). They often do not perform even close to the 80% rule.

򐂰 Measure LAN throughput outside of Tivoli Storage Manager with simple

protocols such as FTP. This will provide a true picture of how a network is performing.

Using this type of calculation, you can calculate the anticipated throughput for any network transport. Table 2-8 shows the most common throughputs.

Table 2-8 Common throughputs

Using this table, your own calculations, and any real testing you may have done, you can validate the amount of data you need to move to back up and restore workload against your SLAs and your network transports. Obviously, if the network will not meet your SLAs, either the SLAs must be relaxed or the network must be improved.

LAN-free data movement (SAN backup and restore)

Tivoli Storage Manager for Storage Area Networks allows for Tivoli Storage Manager backups and restores to be sent over the SAN instead of the LAN, as shown in Figure 2-2 on page 38.

Technology MBps Assume speed

Fast Ethernet 100 MBps 18 GB/hr at 40% efficiency

Gigabit Ethernet 1000 MBps 180 GB/hr at 40% efficiency

T1 1.54 MBps 0.5 GB/hr at 80% efficiency

T3 45 MBps 16 GB/hr at 80% efficiency

184.

min60

min1

1024

1100

≈×××××

38 IBM Tivoli Storage Manager Implementation Guide

When planning for LAN-free data movement, remember that the file metadata must still be sent over the LAN. This metadata can add overhead to a LAN-free backup. Even though the data is streaming over the SAN to the tape or disk, the metadata still goes to the Tivoli Storage Manager server using whatever LAN protocol and speed are being used. As you might imagine, as the amount of metadata grows, the LAN-free backup speed will approach the speed of LAN-based backup.

Experience has shown that systems with large files (greater than 10 MB, on average) and large amounts of data (greater than 50 GB) are good candidates for LAN-free backup, while systems with numerous small files (average size in KB) often perform better using traditional LAN-based backups. Examples of the former include databases, mail systems, and ERP systems; examples of the latter are traditional file and print type servers.

Figure 2-2 LAN-free data movement

2.7.2 Communication protocol

Most network protocols such as TCP/IP and NETBIOS are supported by Tivoli Storage Manager. TCP/IP is the most common communication method and the easiest to set up. Certain functions, such as server prompted mode and the Web clients, require TCP/IP.

Client

Backup Server

Data

LAN/WAN (TCP/IP)

Tape

FC Device

SAN

Data Flow

Control Flow

Chapter 2. Implementation planning 39

2.7.3 Network name resolution

The Tivoli Storage Manager server machine requires a name that clients use to reference the Tivoli Storage Manager server. If TCP/IP is used, create a Domain Name Server (DNS) entry for Tivoli Storage Manager itself, as well as a DNS entry for the machine’s host names. For example, create DNS name TSMSRV1 and use it in the client option files. If Tivoli Storage Manager needs to be moved to another machine, only the DNS entry needs to be changed, instead of editing the Tivoli Storage Manager options file for each client. However, using DNS may impact backup availability if for some reason the DNS service is down (the DNS name will not get resolved unless availability has been built into the DNS setup).

2.8 Disk considerations and sizing

Tivoli Storage Manager requires disk to operate, to hold the database, logs, and usually the primary storage pools. In this section we talk about how to choose a disk subsystem, and how to size the required amount of disk storage capacity.

2.8.1 The disk subsystem

In general, choose the fastest disk subsystem that you can afford. Slow disks may not be a hindrance for a small implementation, but as the site grows, disk access becomes a large percentage of the overall elapsed time to complete a task. Choose a scalable disk subsystem because the vast majority of Tivoli Storage Manager implementations grow substantially. Multiple I/O paths and hot-swappable components should also be considered, both for performance and availability.

2.8.2 Tivoli Storage Manager database

The Tivoli Storage Manager database is critical to the operation of the entire Tivoli Storage Manager environment. Systems with poorly designed Tivoli Storage Manager databases tend to run very poorly and rarely meet expectations. When planning a Tivoli Storage Manager environment, you should plan enough instances of Tivoli Storage Manager to keep the size of each Tivoli Storage Manager database reasonable.

The database size depends on how many files are managed with Tivoli Storage Manager, and whether the files are in a primary storage pool or a copy storage pool.

40 IBM Tivoli Storage Manager Implementation Guide

The database holds two types of data: 򐂰 Entries for backups: This sizing calculates how much of the database holds

backup entries.

򐂰 Entries for archives: This sizing calculates how much of the database holds

archive entries.

The database also holds items such as entries for policy settings, client definitions, image backups, server scripts, and the volume history, but typically, these are insignificant in sizing the database.

Use backup or archive sizing, or both, depending on what functions your server will perform. If both backup and archive are used, then add the calculated database sizes together to arrive at the total database size.

If you are planning to use backup sets, remember that these are not tracked in the Tivoli Storage Manager database, so they do not impact our calculation. They do affect the tape library size if the media used is retained online. Image backups are entered in the database, although only one entry for each backup is required. The database space requirements for image backup entries will therefore be small compared to the backups and archives, and we will not include this in our calculation.

Our calculations assume that each backed up or archived file version uses 600 bytes of space in the server database. If off-site copies are used as well, this takes an extra 200 bytes of space. Where we did not know the number of files to be kept, but only the total storage, we estimated 5% of the total server storage requirement for onsite copies and 1% for off-site.

Do not let the Tivoli Storage Manager database get too large. A good general rule is 120 GB or so, but there is no “magic” number. When expiration, database restores, and other Tivoli Storage Manager admin processes take too long and client restores become too slow, it is too big.

We recommend using Tivoli Storage Manager internal software mirroring—it is the fastest and most reliable. Spread Tivoli Storage Manager volumes over as many physical disks as possible and use smaller database volume sizes (for example, 4–8 GB), as this will improve Tivoli Storage Manager and database performance.

2.8.3 Database performance

Database performance is a critical factor in design and operation of a Tivoli Storage Manager solution. In this area, there are certain typical performance recommendations for any database, and some that are peculiar to the Tivoli Storage Manager database.

Chapter 2. Implementation planning 41

As with any database, the faster the disk used for the database the better. Spreading the database over as many physical disks as possible allows for better performance because multiple disk heads can be seeking, reading, and writing simultaneously.

Counter to conventional thinking, however, several design ideas are peculiar to Tivoli Storage Manager. First, our lab measurements and client experiences have shown Tivoli Storage Manager internal software database mirroring to be a very efficient means of providing database redundancy—often more so than hardware redundancy.

And finally, due to locking and threading information in the Tivoli Storage Manager server code, smaller logical database volumes tend to perform better than the larger ones. This is primarily due to Tivoli Storage Manager server code locking and threading considerations.

2.8.4 Database size

To estimate the Tivoli Storage Manager database size for backup data, use the data collected in Table 2-1 on page 18 and Table 2-5 on page 26.

The calculation is based upon the actual number of file versions backed up. If this is not known, you can estimate 5% of the amount of data backed up for the primary storage pool and 1% for copy pools.

1. Sum the Number of Files Backed Up field for all clients.

2. Multiply this number by the number of versions kept, giving a total number of files backed up.

3. Multiply this number by 600 bytes, to give bytes used in the database for all known files backed up.

4. If copy storage pools are used (and we strongly recommend this), multiply the total number of files backed up and calculated in step 2 above by 200 bytes, giving the bytes for known copy storage pool files.

5. Add the bytes for known copy storage pool files to the estimated bytes for copy storage pool files to give the total bytes for copy storage pool files.

6. Add the total bytes for backed up files to the total bytes for copy storage pool files to give the total bytes calculated for the database.

7. Calculate 135% of the total bytes calculated for the database to give the database size. This is for overhead and for growth.

42 IBM Tivoli Storage Manager Implementation Guide

For example, using the sample data in Table 2-1 on page 18 and Table 2-5 on page 26, calculate the sample database size as follows:

1. 60,000 (3,000 files per workstation * 20 clients) + 8,000 (2,000 files per server) = 68,000

2. 60,000 * 2 + 8,000 * 7 = 176,000 files

3. 176,000 * 600 = 105.6 MB

4. 176,000 * 200 = 35.2 MB

5. 105.6 MB +35.2 MB = 140.8 MB

6. 140.8 MB * 1.35 = 190 MB database size for backup files

2.8.5 Archive sizing

To estimate the Tivoli Storage Manager database size for archive data, use the data collected in Table 2-1 on page 18 and Table 2-5 on page 26.

The calculation is based upon the number of files archived:

1. Sum the Number of Files Archived field for all clients.

2. Multiply the number of files archived by the number of archives kept times the yearly retention ratio (that is, desired monthly retention/12 months), giving a total number of files archived.

3. Multiply this number by 600 bytes to give total bytes for archived files.

4. If copy storage pools are used (and we strongly recommend this), then multiply the total number of files archived and calculated in step 2 above by 200 bytes, giving the total bytes for copy storage pool files.

5. Add the total bytes for archived files to the total bytes for copy storage pool files to give the total bytes calculated for the database.

6. Calculate 135% of the total bytes calculated for the database to give the database size for archives. This is for overhead and for growth.

For example, using the sample data in Table 2-1 on page 18 and Table 2-5 on page 26 calculate the sample database size for archive as follows:

1. 80,000 + 12,000 = 92,000 files

2. 92,000 * 12 * (12/12) = 1,104,000 files archived

3. 1,104,000 * 600 = 662.4 MB

4. 1,104,000 * 200 = 220.8 MB

5. 662.4 MB + 220.8 MB = 883.2 MB

6. 883.2 MB * 1.35 = 1192.32 MB database size for archive data

Chapter 2. Implementation planning 43

2.8.6 Database volume identification

The total required database size including both backup and archive requirements will be 190 + 1192.32 = 1382.4 MB.

We recommend using the Tivoli Storage Manager mirroring function for the database instead of a hardware or operating system mirroring, because Tivoli Storage Manager has additional functions to handle error conditions that may affect the mirrored copy.

If you are using Tivoli Storage Manager mirroring, you need to plan for the mirror copy by doubling the amount of disk for the database.

Various file systems have different maximum capacities, so the database may have to be split across numerous volumes to make up your database size. To ensure no single point of failure when mirroring the database, each volume in a mirrored set should be placed on a separate drive and even controller.

Complete Table 2-9 with the database file names and the volume names for your primary database and copy database. This table includes the space for the backup and archive requirements.

Table 2-9 Database worksheet - backup and archive requirements

2.8.7 Tivoli Storage Manager recovery log

The size of the recovery log depends on the amount of data changed between Tivoli Storage Manager database backups. The larger the amount of data, the larger the recovery log needs to be. Either a full or an incremental Tivoli Storage Manager database backup (in roll-forward mode) resets the recovery log back to empty. If the recovery log fills up completely, Tivoli Storage Manager stops and

Note: By summing up backup and archive database sizes, you will have a full, consolidated database for the calculated time frame. You can start with a smaller configuration initially but leave enough spare disk space for growth. You should round up database volume sizes to multiples of 4 MB plus 1 MB for overhead.

Database volume File name (primary) Size MBFile name (copy) Size

Vol1 /tsm/database/primary/file01 693 /tsm/database/copy/file01 693

Vol2 /tsm/database/primary/file02 693 /tsm/database/copy/file02 693

Total 1386 Total 1386

44 IBM Tivoli Storage Manager Implementation Guide

you have to manually increase the size of the recovery log. This may take some time but can usually be avoided with adequate precautions (for example, by monitoring and planning for growth).

To estimate the size of the recovery log, multiply the database size by the percentage of data that changes each backup cycle. Double this number to allow for two backup cycles to occur without a database backup. This gives a starting point for the recovery log.

For example, if the database size is 1386 MB, and 5% of the data changes every backup cycle, then the estimated size for the recovery log would be 1386 MB x

0.05 x 2 = 138.6 MB (141 MB for better allocation, if using a single volume).

As with the database, we recommend using the Tivoli Storage Manager mirroring function for the recovery log instead of hardware or operating system mirroring.

If you are using Tivoli Storage Manager mirroring, you need to plan for the mirror copy by doubling the amount of disk for the recovery log.

Various file systems have different maximum capacities, so the recovery log may have to be split across numerous volumes to make up your total recovery log size. To ensure no single point of failure when mirroring the recovery log, each volume in a mirrored set should be placed on a separate drive and even controller.

Complete Table 2-10 with the recovery log file names for your primary and copy recovery log.

Table 2-10 Recovery log worksheet

2.8.8 Primary disk storage pool

The traditional Tivoli Storage Manager design uses disks as a cache for nightly backups. Data is migrated daily from disk to a less expensive medium such as tape.

A best practice is to have enough disk storage pool space to store one night’s incremental file system backup, and send large file backups directly to tape (for example, database files) to optimize the overall I/O. Consider using the cache=yes parameter on disk storage pools—this means files remain on disk

Log volume File name (primary) Size

(MB)

File name (copy) Size

(MB)

Vol1 /tsm/log/primary/file01 141 /tsm/log/copy/file01 141

Total 141 Total 141

Chapter 2. Implementation planning 45

until space is needed for further backups. This can significantly improve restore performance for recently backed up files.

As the cost of per megabyte of disk decreases, more and more disk is being used in Tivoli Storage Manager designs. Some use no tape at all, so that all backed up data is saved to disk. In this case, the file-type device class should be used, not a disk-type (even if a disk-type is the initial destination). Disk-type pools become fragmented if data is retained for extended periods of time, unlike file-type classes, which can be defragmented.

Tivoli Storage Manager supports a

tapeless configuration through the use of disk

storage pools or a device class of type file. When deciding whether to use only disk for backup-archive storage, consider the following caveats:

򐂰 Do a realistic analysis of the total amount of storage needed considering your

data retention policies, total data, and growth expectations. Evaluate the cost of tape versus disk for storing all data.

򐂰 Invest in a disk technology that can permanently store the data. If the device

can fail (and all devices can, whether RAID, mirrored, or anything else), consider using a copy storage pool for data redundancy.

򐂰 Carefully consider the cost and technical feasibility of getting the data off-site

for disaster recovery purposes. Tape cartridges are portable. If using disk only, off-site copies have to be moved over a network transport.

In our scenario, when a client node backs up, archives, or migrates data via HSM, all data is stored in one primary storage pool. You could also use separate storage pools for a backup, archive, and HSM data for improved controls and manageability of production data.

To size the disk storage pool, calculate how much will be backed up during one cycle and add on a proportion of the amount of archive data transferred to the server. This amount (plus a contingency for growth) is the recommended size for the storage pool.

If you are also using Space Management (HSM) features, the rate of data migration to the server is hard to predict, so you need to get experience of your particular environment to make an accurate sizing.

Primary storage pools (usually disk devices) can be made larger or smaller than the recommended size, depending on the resources available. A larger pool size allows for more than one backup cycle of data to remain on disk, thus improving restore times. It also allows for spare capacity for an unexpectedly large amount of backup data to prevent server migration from running during backup. A smaller primary storage pool uses less disk, but runs the risk that the pool will fill up during back up. This is not functionally a problem, since the backup and

46 IBM Tivoli Storage Manager Implementation Guide

migration to the next storage pool can execute concurrently; however, performance will degrade.

We recommend using a primary disk storage pool of at least the recommended size to reduce interference from migration while backup is running.

2.8.9 Disk storage pool size

To estimate a primary storage pool size if running backup cycles only, do the following:

1. Using Table 2-1 on page 18, multiply the GB changed per backup by (1 - the Data compression rate) to give the total bytes transferred for each client.

2. Sum the total bytes transferred for all clients to give the total bytes transferred per backup cycle.

3. Add 15% to total bytes transferred per backup cycle to give the storage pool size. This allows for variability in the size and number of files per backup.

For example, using the sample figures in Table 2-1 on page 18, the GB changed per backup are 6 * 20 (120 GB) and 4 * x 100 (400 GB), while the data compression figures are 0.5 and 0.66, respectively.

1. Multiplying 120 by (1 - 0.5) gives 60, and multiplying 400 by (1 - 0.66) gives

136.

2. Summing 60 and 136 gives 196 GB.

3. Adding 15% gives a storage pool size of 225.4 GB. We will round to 226 GB.

2.8.10 Archive disk sizing

In most environments, archive disk sizing is less critical than for backup. This is because backup operations tend to run much more frequently (usually nightly) and to a stricter time frame. Archives may run less frequently, and on weekends when the overall workload is lighter. Since in these circumstances the impact of running concurrent archive and storage pool migration might not be so critical, it is not normally necessary to use the full archive size in calculating storage pool requirements. Another factor to be considered for sites that are doing frequent archiving of large amounts of data, where the storage pool and processing impact are great, is the possibility of substituting backup set operations for archive. The advantage of this is that generating a backup set requires the Tivoli Storage Manager server only—the client is not involved in any way since the backup set is created using data that has already been sent to the server in normal backup operations.

Chapter 2. Implementation planning 47

To additionally increase the storage pool to hold archive data as well, follow these steps:

1. Using Table 2-1 on page 18 and the GB copied per archive field, group all machines that require simultaneous archive operations during one common time frame (for example, every month). Select the biggest group, giving peak archive size.

2. Take 10% of the peak archive size, giving the archive storage size.

For example, using the sample figures in Table 2-1 on page 18:

1. Assuming a monthly/month-end time frame as our baseline, we have the workstations (200 GB) and database servers (80 GB), which equals 280 GB.

2. Taking 10% from all archive storage required during the time frame, 280 GB *

0.10 = 28 GB for archive disk storage.

2.8.11 Image disk sizing

If you are planning to use image backups, you should consider sizing the disk storage pool to hold the file spaces you want to back up. This is because image backups are single objects and therefore the server will require that size for storing data (or at least part of it, assuming compression is enabled).

For example, assuming that the client file spaces eligible for image backup are /oralog (200 MB), /finsys (1.5 GB), /oradata (1 GB), and /findata (1 GB), then the disk image requirements should be at least 3.7 GB to hold those file spaces in disk without having to use tape immediately. This is especially true if you are running parallel backup operations (that is, executing multiple concurrent backup image commands). Alternatively, since the disk storage requirements are so high for this operation, you could consider sending these backups straight to tape, provided that you have enough tape drives and the backup window is longe enough to coexist with normal backup and archive operations as well.

We recommend that the disk storage pools be allocated on fault-tolerant hardware devices such as RAID 5 devices. If you are using hardware or operating system mirroring, you need to plan for the mirror copy by doubling the amount of disk for the primary storage pool.

Various file systems have different maximum capacities, so the primary storage pool may have to be split across numerous volumes to make up your total primary storage pool size. We recommend that the disk storage pools be placed

Note: You must sum up all disk storage requirements (backup, archive, image) to have your final disk storage size. You can, of course, start with smaller numbers and evaluate future growth.

48 IBM Tivoli Storage Manager Implementation Guide

on their own disk devices and controller separate from the database and the recovery log, if possible.

Complete Table 2-11 with the primary storage pool file names and volume names for your primary storage pool. We are considering backup and archive requirements only, which was 226 + 28 GB = a total of 254 GB. If using 20 GB size for disk storage pool volumes, we would need at least 13 volumes.

Table 2-11 Primary storage pool worksheet

2.8.12 Device configuration table and volume history file

The device configuration table and the volume history table also require disk space, but they are typically very small. The device configuration table contains entries for defined device classes and definitions for drives and libraries. Every volume that is used by Tivoli Storage Manager is tracked in the volume history database, including the volume identifier for the database backups. The volume history information is periodically copied out to a volume history file that you can specify with the VOLUMEHISTORY option in the dsmserv.opt file.

We recommend defining at least two copies of both the device configuration table and the volume history file, in case one becomes unusable due to a hardware or software failure. We also highly recommend that you back up the device configuration file and the volume history file every time you back up your Tivoli Storage Manager database. These files will be invaluable in the event that you need to recover your Tivoli Storage Manager server.

File name Size (GB)

/tsm/stgpool/file01 20

/tsm/stgpool/file02 20

/tsm/stgpool/file03 20

/tsm/stgpool/file04 20

...

/tsm/stgpool/file13 20

Tot al 254

Chapter 2. Implementation planning 49

Complete Table 2-12 on page 49 with the device configuration and volume history file names and sizes.

Table 2-12 Device configuration and volume history worksheets

2.8.13 Total disk

Total disk refers only to the numbers discussed here. If you are using mirroring or some other version of RAID, you need to take that into consideration separately. The disk required to run the server platform operating system efficiently also has not been considered.

IBM Tivoli Storage Manager code requirements for disk vary depending on the server platform and release level. We use an estimate of 200 MB at the time of writing. Table 2-13 summarizes the disk requirements for the Tivoli Storage Manager server as we have planned it.

Table 2-13 Total IBM Tivoli Storage Manager disk required worksheet

Name Size (MB)

/tsm/files/primary/devconfg1.out 0.5

/tsm/files/copy/devconfg2.out 0.5

/tsm/files/primary/volhist1.out 0.5

/tsm/files/copy/volhist2.out 0.5

Total 2

Size (GB)

IBM Tivoli Storage Manager code (dependent on platform) .2

IBM Tivoli Storage Manager database 2.772

IBM Tivoli Storage Manager recovery log .282

Primary storage pools 254

Device configuration table and volume history table .002

Other (RAID, operating system) 0

Tot al 258

50 IBM Tivoli Storage Manager Implementation Guide

2.9 Tape drives and sizing

In this section we discuss the calculations for estimating the size of a tape library to support a Tivoli Storage Manager solution. Similar calculations can be used to determine the total disk storage needed to support an environment.

Most Tivoli Storage Manager designs incorporate tape and tape drives as the ultimate long-term storage locations for backups and archives. Therefore, it is important to understand the performance characteristics of tape drives and tapes when designing a Tivoli Storage Manager solution.

When using tape storage pools, a Tivoli Storage Manager server should have access to no less than two drives. For architecture calculation purposes, assume only 80% of maximum, uncompressed throughput for a tape drive. Be prepared to do restores while other administrative operations are happening on the system or when drives are broken.

Carefully consider card and bus throughput when attaching tape drives to systems. Most protocol/tape combinations can accommodate two or three tape drives per card. When using Fibre Channel/SAN attached tape drives and disks, do not mix disk and tape traffic on the same HBA.

When planning for tape drive throughput and tape capacity, it is best to be conservative. Although drives can perform close to and better than their compressed rating, typically their performance is far less than this in reality. We use 80% of native uncompressed throughput ratings and 150% of native capacity ratings for theoretical calculations of drive throughput and tape capacity.

Table 2-14 summarizes those calculations for some popular tape drives.

Table 2-14 Tape device comparisons

Tape drive Native speed

(MBps)

Native capacity (GB)

Assumed speed (GB/HR)

Assumed capacity (GB)

IBM LTO Gen 2 35 200 98 300

IBM LTO Gen 3 80 400 224 600

IBM 3590-E1A14403960

IBM 3590-H1A14603990

IBM 3592 40 300 112 450

STK T9840C 30 40 84 60

STK T9940C 30 200 84 300

Chapter 2. Implementation planning 51

Whether you use Table 2-14 or your own calculations, it is critical when designing a Tivoli Storage Manager solution to measure the backup and potential restore workload against the speed of your tape solution. In our earlier example, for instance, we calculated that we needed to move 86.6 GB/HR to meet SLAs. So based on the theoretical numbers above, a solution that is capable of that data movement would take three LTO Gen 1 tape drives.

In addition to calculating backup workload, an architect must also consider administrative processes and potential restores when deciding how many tape drives a system needs. Each day, off-site copies of tapes must be made and reclamation must occur. A potential restore of a large system could also require multiple drives to meet SLAs.

A detailed discussion of specific I/O protocol speeds is beyond the scope of this book. However, you should understand the speeds of the drive you choose and recommendations for system connectivity. As a general rule, most hardware vendors recommend no more than two to three tape drives per interface card and, if using Fibre Channel, that tape traffic be separated from disk traffic.

The information in Table 2-15 will be used when sizing tape libraries and then when defining them to Tivoli Storage Manager.

Table 2-15 Tape drive configuration worksheet

Sony AIT-3 12 100 33 150

Tape drive Native speed

(MBps)

Native capacity (GB)

Assumed speed (GB/HR)

Assumed capacity (GB)

Option

Library model IBM System

Storage™ TS3310 Tape Library

Number of drives 2

Drive model 3580

Number of on-site tape volumes 19

Number of off-site tape volumes 29

Number of database volumes 6

Number of scratch tapes 9

Number of backup set tape volumes 5

52 IBM Tivoli Storage Manager Implementation Guide

2.9.1 Tape devices

Tape drives come in all sizes, including, but not limited to, DLT, SDLT, LTO, 3590, and other device types. Each type of drive has a different data capacity, performance, cost, and reliability characteristics. Although data capacity and cost per megabyte stored are important, reliability is much more important. Having saved money buying tapes is small consolation when you are unable to restore your customer billing database due to a tape error.

In general, tape drives where the tape touches the read/write heads, such as 4 mm and 8 mm, tend to be less reliable (and slower) than tape drives where the tape does not touch the read/write heads, such as 3580 and 3590. If you do implement drives that touch the read/write heads, plan to replace the tapes at regular intervals.

2.9.2 Tape libraries

Tivoli Storage Manager was designed with automation in mind, specifically for automated tape libraries. The best and easiest way to run a Tivoli Storage Manager library is to keep all on-site data in the library so that tapes can be mounted automatically when needed for restores, backups, reclamation, and other Tivoli Storage Manager administration processes.

2.9.3 Number of tape drives

In attempting to reduce costs, some Tivoli Storage Manager customers might consider purchasing only one or at most two tape drives. Although the Tivoli Storage Manager could be configured with only one drive (or with a library containing one drive), we do not consider this to be a production-level solution and do not recommend it. A single drive solution cannot make additional data copies (for disaster recovery purposes) or perform space reclamation without considerable manual effort and additional disk resources. Any Tivoli Storage Manager server for production use should have a library with two or more tape drives. Here are some business reasons for selecting a multiple-drive solution:

򐂰 To avoid a single point of failure 򐂰 To avoid interruptions to automated backup processing (reclamation, backup

stgpool, migration contention)

Total tape volumes required 68

Assume 10% growth in first year 75

Option

Chapter 2. Implementation planning 53

򐂰 To avoid limiting your scalability (few environments are static or shrink with

regards to the amount of managed data)

򐂰 To avoid building additional complexity into the design and implementation,

which will drive the cost of implementation higher

򐂰 Because the price point for libraries and tape drives have fallen significantly in

the recent past

Two-drive systems allow for quicker reclamation and pool copies and reduced drive outages, but restores coming from tape may be delayed due to other competing tape activity. Systems with three or more tape drives can handle restores from tape occurring while tape reclamation or other tape processing is in progress.

As for the number of tape drives, a critical consideration is how quickly you need to restore one or more clients. More tape drives allow you to restore more clients in a given time. Collocation allows as many clients to be restored simultaneously as you have tape drives. If you have stringent restore requirements, collocation and multiple tape drives make sense. You could also consider features like backup sets and logical volume backups for highly time dependent servers to improve their restore window.

To calculate the rate of a restore operation, divide the amount of storage to be restored by the sustained data rate of the tape drive (not the instantaneous, or burst, rate) quoted by the manufacturer. If this number does not allow you to meet your service levels, collocation, more tape drives, faster tape drives, a new service level, or another backup strategy may be required.

We recommend a minimum of a library with a barcode reader and at least two tape drives for all production-level Tivoli Storage Manager solutions.

2.10 Tape volumes

Tape volumes are used to store on-site copies of data, off-site copies of data, and database backups. Additional tape volumes are required because all tape volumes are not filled to capacity. Some volumes are required to stock a scratch pool so that mounts for unused tape volumes can be satisfied. If you are considering backup sets and image backups, you may need to add more tapes to your scratch pool.

2.10.1 On-site volumes

You must consider how many tapes you will need to hold your backup, archive, and image data in a specified time frame. Each of those have different expiration

54 IBM Tivoli Storage Manager Implementation Guide

requirements, and therefore, the calculation may not be linear. In any case, keep in mind that it is best to assume a middle case/worst case scenario so that you do not run out of tapes.

Backup tapes

To calculate the number of on-site tape volumes required for backup operations, carry out the following calculations:

1. If this is a sequential storage pool (tape device), multiply the primary storage pool size by the number of backup versions from Table 2-5 on page 26 to give versions pool size.

2. Add the sum of all Total storage used fields for each client from Table 2-1 on page 18 to the versions pool size, giving tape pool size.

3. Divide the tape pool size by the device capacity to find the number of tape cartridges required.

4. Add 50% to cater to tapes that are in filling status to give the total cartridges required for on-site tapes.

5. If using collocation, normally there should be at least as many tape cartridges as there are clients. Consider tape native capacity as a rounding factor.

We do not use the compressed capacity of the tape here because we factored the client compression rate into the calculation of the storage pool size. If data is compressed at the client, it will not receive any benefit from hardware compression done by the tape drive.

Backup tape calculation

To calculate:

1. If the primary storage pool is 254 GB, and the number of versions kept is 7, then multiplying 1.04 * 7 gives a 1778 GB versions pool size.

2. If the all the clients are using 1200 and 400 GB, then 1200 + 400 + 1778 equals 3378 GB.

3. If the tape device has a capacity of 400 GB, then dividing 1938 by 400 gives 9 cartridges required to store all the data.

4. 5 * 1.5 gives 14 total cartridges required for on-site tapes.

5. If we use collocation for the database servers, since there 4 database servers and 20 file servers, we have enough tape volumes.

Chapter 2. Implementation planning 55

Archive tapes

For archive tapes:

1. Using Table 2-1 on page 18, multiply the GB copied per archive by (1 - the data compression rate), giving transferred archive data.

2. For each client, multiply the transferred archive data by the number of archives kept in a year times the yearly retention ratio (that is, desired monthly retention/12 months), and sum up, giving total archive data.

3. Divide the total archive data by the native tape capacity, giving the total number of tapes required.

Archive tape calculation

To calculate:

1. The clients in our table have 200 GB and 80 GB of archive data. The compression ratios are 0.5 and 0.66. This equals 200 *(0.5) and 80 * (0.34), which equals 100 and 27.2 GB.

2. The number of archives kept are 12 and 12. The yearly retention ratios are 12/12 and 12/12. This equals 100*12* 1 + 27.2*12*1 = 1526.4 GB.

3. If the tape device has a capacity of 400 GB, then dividing 1526.4 GB by 400 gives 4 cartridges required to store all archive data.

Image backup tapes

Image requirements are calculated on total allocated file system space. For the sake of simplicity, we are not considering any compression rating (you can use the compression ratio for the client on the sum of file systems), and therefore the number is already overestimated without any need for extra tapes:

1. Consider all client file spaces eligible for image backup. Sum them all, giving transferred image size per client.

2. Using Table 2-1 on page 18, multiply the number of image backups by transferred image size per client times yearly retention ratio (that is, desired monthly retention/12 months), and sum them all giving total image size.

3. Divide the total image size by the native tape capacity, giving the total number of tapes required.

Image backup tape calculation

To calculate:

1. In our example, we assume that the sum of all of client 3 eligible file spaces for logical volume backup would be 10 GB * 4 = 40 GB.

2. The retention ratio is 1/12. Assuming the previous calculation, this gives 12 * 40 * 0.16 = 76.8 GB.

56 IBM Tivoli Storage Manager Implementation Guide

3. If the tape device has a capacity of 400 GB, then the image backup data needs only one tape to store it all (assuming no compression).

Therefore, the total on-site tape requirements for this example would be 14+4+1 = 19 tapes.

2.10.2 Off-site volumes

You will probably have more tapes in your off-site pool than onsite, because of less frequent reclamation and partially filled tapes.

To estimate the number of tape cartridges required for off-site copies, use the number of onsite tape volumes calculated in the previous section. As a rough guide, add 50% to estimate the number of tapes required. In our example, this comes to 29 off-site tapes. Keep in mind that collocation may be set on for either, both, or none of the on-site and off-site tape pools, which will also affect tape volume requirements.

2.10.3 Database tape volumes

Each database backup requires at least one tape volume. We recommend backing up the database every day and keeping backups for at least five days.

To calculate the database tape volumes required:

1. Divide the database size calculated in, 2.8.4, “Database size” on page 41, by the tape device capacity and round up to the nearest whole number to give the number of tape volumes required for one database backup.

2. Multiply this number by six (five copies plus the copy just being made) to give the total number of tape volumes required for database backups.

For example, If the database size is 1386 MB, and the device capacity is 400 GB, each database backup will fit on one tape volume. Therefore, 1 tape * 6 versions = 6 tape volumes.

Scratch volumes

A scratch (or empty) volume is required every time Tivoli Storage Manager wants to write to an unused tape.

To estimate the number of scratch volumes required:

1. Total the number of tape volumes required for on-site tapes, off-site tapes, and database backup tapes.

2. Calculate 15% of this number to allocate for scratch tape volumes.

Chapter 2. Implementation planning 57

We have a total of 49 on-site, off-site, and scratch tapes. Fifteen percent of this is nine tapes.

Backup set volumes

It is worth calculating backup set tape space requirements separately from regular file-based processing due to the nature of backup sets. Note that although the backup set is a server-initiated procedure, our calculations are based on previous file-backup operations. Note that this step may not be necessary, since you may create backup sets onto disk and copy them onto media such as CD or use another tape format that is common to both the server and the client. For this calculation we are assuming the backup set consists of the entire client system’s file; however, you may only use a subset of its file spaces.

To estimate the number of backup set volumes required:

1. Using Table 2-1 on page 18, multiply the total storage used by (1 - the data compression rate) to give the total gigabytes for each client. Round up to the next multiple of the native tape capacity, since backup sets, like server database backups, cannot stack onto tapes.

2. Multiply the number of backup sets by the total gigabytes for that client to give the client backup set size.

3. Multiply the client backup set size by the yearly retention ratio (that is, desired monthly retention/12 months) for that client. Sum all client backup set sizes to give the total backup set requirement.

4. Divide the total backup set requirement by the device capacity to find the number of tape cartridges required.

Backup set calculation

To calculate:

1. Multiplying 1200 by (1 - 0.5) gives 600, and multiplying 400 by (1 - 0.66) gives

136. Assuming a native tape capacity of 400 GB, this rounds up to 800 and 400 GB, respectively.

2. From previous calculations, client backup set sizes are 6 * 800 (4800 GB) and 6 * 400 (2400 GB).

3. Assuming retention periods of 4/12 and 2/12, this gives 4800*0.33 + 2400*0.16 = 2000 GB as backup set space requirement.

4. If the tape device has a capacity of 400 GB, then dividing 2000 by 400 gives 5 cartridges required to store all backup set data during the specified time frame.

58 IBM Tivoli Storage Manager Implementation Guide

Adding up all these numbers as stored in Table 2-15 on page 51 gives a total of 68 tape volumes required, growing to 75 in the first year, assuming a 10% growth rate. You then need to consider this number against the library configurations available for your chosen technology. The IBM System Storage TS3310 with expansion unit has space for 128 cartridges, so this leaves some capacity for future growth. It should be noted that Tivoli Storage Manager setups rarely if ever shrink.

2.10.4 z/OS tape management

On all platforms except for iSeries and z/OS®, OS/390® (or MVS), Tivoli Storage Manager provides its own tape management functions. For z/OS, it uses the functions provided within the operating system or other tape library management systems.

Tivoli Storage Manager uses data set names to identify various types of Tivoli Storage Manager data sets. The data set name prefix is set by the device class parameter PREFIX. Each device class can have a different data set name prefix. The data set name suffix is fixed by Tivoli Storage Manager for various data types. The suffix .DBB indicates a database backup data set. The suffix .BFS indicates an on-site or off-site data copy.

Most tape library management systems on z/OS use the data set name to identify tapes to be taken off-site. Since Tivoli Storage Manager uses the data set name PREFIX.BFS for both on-site and off-site copies, the tape management system has no way to identify tapes that must be moved off-site.

To choose another data set name for off-site copies, create another device class for the off-site copies and choose a different prefix. Set the tape library management system to trigger on this different PREFIX.BFS data set name and off-site copies will be identified automatically.

Tivoli Storage Manager allows an external data manager (EDM) to control tapes. To inform the EDM when a tape goes into a scratch status, you can use the DFSMShsm™ ARCTVEXT parameter. Include the DELETIONEXIT ARCTVEXT parameter in the Tivoli Storage Manager server options file. For more information see IBM Tivoli Storage Manager for MVS and OS/390 Administrator's Guide, GC35-0377.

If your tape management system uses program names to identify External Data Managers, the Tivoli Storage Manager program name is ANRSERV.

Chapter 2. Implementation planning 59

2.11 Administrator IDs

Identify who will be the Tivoli Storage Manager administrators in your organization.

A Tivoli Storage Manager administrator controls Tivoli Storage Manager resources. There can be numerous administrators with varying levels of authority over the Tivoli Storage Manager server itself. Also, an administrator can use the Web backup-archive client to perform backup, restore, archive, and retrieve operations on the behalf of other users using a Web browser. Help desk personnel can use this to perform these client tasks for their end users without having to log on to the client machine.

If your Tivoli Storage Manager installation is large or widely dispersed, you should delegate some authority to administrators based on policy domains or storage pools. Therefore, a workstation administrator could look after setting data retention criteria for workstation data only (assuming the correct policy domains were set up). A UNIX administrator could be given Tivoli Storage Manager authority over UNIX data retention criteria only.

Since Tivoli Storage Manager logs all commands issued by administrators and it has no limit on the number of administrators, do not share administrator IDs. Sharing administrator IDs reduces the accountability of each ID, and therefore of all the people sharing the ID. Conversely, numerous administrator IDs may give too many people too much authority.

Table 2-16 suggests several administrator IDs you may want to implement.

Table 2-16 Administrator IDs worksheet

We recommend that, once you have created your required IDs, that you delete the default installed administrator, admin, to prevent the possibility of this ID being misused. Many sites leave this ID with its default password, creating a big security hole for any malicious person with basic Tivoli Storage Manager knowledge.

Functions Administrator ID Authority

Server console SERVER_CONSOLE System

System administrator sysadmin System

System support support System

System reporter reporter none

Client administrator helpdesk Node

60 IBM Tivoli Storage Manager Implementation Guide

2.11.1 License considerations

This section describes the tasks involved when licensing a Tivoli Storage Manager system, including registering, saving, and auditing.

The base IBM Tivoli Storage Manager feature includes the following support:

򐂰 An unlimited number of administrative clients 򐂰 Enterprise Administration, which includes command routing, enterprise

configuration, and enterprise logging (server-to-server)

򐂰 Server-to-server virtual volume capabilities (does not include database and

storage pool backup)

򐂰 Network Enabler (network connections for clients) 򐂰 AFS/DFS™ support (The S/390® platform includes the S/390 UNIX client as

part of Managed System for SAN.)

򐂰 Smaller tape libraries

Tivoli Storage Manager Extended Edition also includes the disaster recovery manager, Space Management, NDMP backup, server-free backup LAN-free backup, and use of any size tape library.

2.11.2 Licensed features registration

You must register a new license if you want to add support for any of the following features that are not already in your existing license agreement. Tivoli Storage Manager uses a license file and the REGISTER LICENSE command to complete this task. Licenses are stored in enrollment certificate files, which contain licensing information for the server product. When registered, the licenses are stored in a nodelock file within the current directory.

To register a license, use the REGISTER LICENSE command, as well as the license file associated with the license. See Table 9-1 on page 304 and Table 9-2 on page 309 for a list of valid license files for the different versions of Tivoli Storage Manager.

Saving your licenses

Save the CD-ROM or directory containing your enrollment certificate files. You may you need to register your licenses again for any of the following reasons:

򐂰 The server is corrupted. 򐂰 The server is moved to a different machine.

Chapter 2. Implementation planning 61

򐂰 The nodelock file is destroyed or corrupted. Tivoli Storage Manager stores

license information in the nodelock file, which is located in the directory from which the server is started.

Monitoring licenses

When license terms change (for example, a new license is specified for the server), the server conducts an audit to determine whether the current server configuration conforms to the license terms. The server also periodically audits compliance with license terms. The results of an audit are used to check and enforce license terms. If 30 days have elapsed since the previous license audit, the administrator cannot cancel the audit.

If a Tivoli Storage Manager system exceeds the terms of its license agreement, one of the following occurs:

򐂰 The server issues a warning message indicating that it is not in compliance

with the licensing terms.

򐂰 If you are running in Try Buy mode, operations fail because the server is not

licensed for specific features.

You must contact your Tivoli Storage Manager account representative or authorized reseller to modify your agreement. An administrator can monitor license compliance by:

򐂰 Auditing licenses

Use the AUDIT LICENSES command to compare the current configuration with the current licenses.

򐂰 Displaying license information

Use the QUERY LICENSE command to display details of your current licenses and determine licensing compliance.

򐂰 Scheduling automatic license audits

Use the SET LICENSEAUDITPERIOD command to specify the number of days between automatic audits.

Note: During a license audit, the server calculates, by node, the amount of backup, archive, and Space Management storage in use. This calculation can take a great deal of CPU time and can stall other server activity. Use the AUDITSTORAGE server option to specify that storage is not to be calculated as part of a license audit.

62 IBM Tivoli Storage Manager Implementation Guide

2.12 Other considerations

There are numerous other topics to be considered when planning a Tivoli Storage Manager installation. Many of these topics are outside the scope of this book, but we mention them here for completeness.

򐂰 Staffing

Staffing requirements need to be addressed. The various functions such as operations, technical support, administration, and help desk may all be performed by one person in a small site. Larger sites may find a more specialized approach useful. To provide backup coverage, two people per function is always a good idea.

򐂰 Lead time

Some tasks such as installing a tape exit in z/OS may have considerable lead times before the change can be made. We have highlighted some of these, but check with your technical support group and your change management group for their guidelines.

򐂰 Monitoring

You may want to consider monitoring your Tivoli Storage Manager server system using a product such as Tivoli Enterprise™. We have highlighted some suggestions for this, but there are many more items that you may want to monitor. Monitoring also includes monitoring the health of the Tivoli Storage Manager software. Numerous queries are useful for displaying information about the Tivoli Storage Manager system and its operations. We have included some basic possibilities.

򐂰 Chargeback

Some Tivoli Storage Manager installations charge for their services. This is possible using the accounting records and site-specific programs. Some items you may want to consider charging for include bytes stored, CPU time per client, or tapes used.

򐂰 Code refreshes

New client code typically has been released every three months. With installations supporting large numbers of clients, keeping up with these refreshes of client code requires special consideration. Set up a procedure for tracking which clients are running which release of Tivoli Storage Manager code. Design your client installs to be as generic and as similar as possible. If an automated software install process is available, consult with the process owners regarding the best practices to use in setting up Tivoli Storage Manager clients.

Chapter 2. Implementation planning 63

򐂰 Export/Import

It is possible to export a client definition and all of its related data from one Tivoli Storage Manager server and import it into another Tivoli Storage Manager server. This facility is useful for moving clients from one server platform to another server on the same or different platform. With a large number of clients, or clients with a large amount of data, the export and import can take a significant amount of time, in the order of 24 to 48 hours. In these cases, planning and coordination need to be done as to when the exporting server ceases backups and the importing server starts backups.

򐂰 Server scripts

These are very useful for issuing Tivoli Storage Manager commands repeatedly, or with some rudimentary logic around them.

򐂰 SQL queries

These are powerful queries you can run against the Tivoli Storage Manager database to extract information.

򐂰 Problem determination

Diagnosing and resolving problems are tasks you will have to do on a regular basis. In general, once you have determined that you have a problem, install the latest level of Tivoli Storage Manager client and Tivoli Storage Manager server code and try to recreate the problem. If it still exists, you should engage formal software support procedures. Alternatively, you may search or post your problem to the Tivoli Storage Manager listserv list to see if someone else has experienced the problem or may be able to offer some suggestions.

򐂰 Disaster recovery

We recommend that planning and testing for disaster recovery be done on a regular basis. Disaster Recovery Manager (DRM) assists in gathering, maintaining, and recommending information and planning pertinent to disaster recovery.

2.13 Summary

Now that we have discussed planning and checklists in the initial chapters, as well as the need to read and understand the IBM Redbook IBM Tivoli Storage Management Concepts, SG24-4877, we can get started on the actual installation phase.

64 IBM Tivoli Storage Manager Implementation Guide

Part 2 Installation

In this part of the book we discuss the installation of the server and client code that will be used to implement IBM Tivoli Storage Manager. We provide implementation checklists and describe the various planning considerations you will need to take into account to get the best results.

Part 2

66 IBM Tivoli Storage Manager Implementation Guide

Chapter 3. Server installation

In this chapter we explain the steps relating to the basic installation of an IBM Tivoli Storage Manager server. We cover the topics of code installation and options file customization.

We assume that, before you enter into this installation, you have completed the planning worksheets, and have read and understood the IBM Tivoli Storage Management Concepts, SG24-4877. If not, please stop and take the time to do so now.

You will gain a better understanding and be more successful if you take the time to plan and design your total solution before you begin installation.

68 IBM Tivoli Storage Manager Implementation Guide

3.1 Software installation

We assume that you have read and understood the IBM Redbook, IBM Tivoli Storage Management Concepts, SG24-4877, as well as the previous chapters.

You should also use the instructions in the associated Quick Start manual for your chosen Tivoli Storage Manager server platform to install the Tivoli Storage Manager code. The Quick Start manual is shipped with the install media. The latest version of this manual is also available from the Tivoli Storage Manager Web site in either HTML or PDF format. We recommend that you download the manual to ensure that you are working with the latest information. The URL for Tivoli Storage Manager publications is:

http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?toc=/com.ibm.i tstorage.doc/toc.xml

3.2 Latest software updates

Tivoli Storage Manager server and client code fixes and enhancements are released on a regular basis. The fixes are available from IBM via the Internet or CD-ROM. Downloading from the Internet is preferable if your connection supports it. Many fixes can be quite large, as they are full or near-full code replacements. If you are unable to download from the Internet, you can order the fixes through your usual IBM service channel.

The Tivoli Storage Manager support home page has links to the latest Tivoli Storage Manager server fixes, Tivoli Data Protection for application fixes, Tivoli Storage Manager client code, and important download information. It also contains important FLASHES of late-breaking product news, which may affect your implementation. You may subscribe to updates via RSS, or regularly visit the Web site:

http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

This link will take you to the FTP server:

ftp://service.boulder.ibm.com/storage/tivoli-storage-management/maintenance/

If you have downloaded many fixes you may find it more convenient to go directly to the FTP site and navigate through the directories to quickly find the latest fixes.

Note: We highly recommend that you read the readme.1st file to see the changes in the Tivoli Storage Manager version you are about to install, the hardware and software prerequisites, and any additional installation steps that might be needed.

Chapter 3. Server installation 69

The individual fix directories in general include files listed below. The names and content of these files may vary slightly across platforms:

򐂰 readme.ftp

This file contains the download and install instructions.

򐂰 readme.1st

This file contains important information that is not yet available in manuals. This includes information such as description of code fixes, enhancements, limitations, and additions or corrections to the hardcopy publications.

򐂰 Code images

These files contain the actual code fixes. You should download and unpack these files exactly as instructed in the readme.ftp file.

If the fix is unavailable for download, or your environment is not suitable for downloading large files, you can use the fix number to order the code on CD-ROM from IBM support.

We recommend that you keep a copy of the latest server, agent, and client fix files on a suitable file server (which could be the Tivoli Storage Manager server itself) at your site. This allows easier distribution and code installation, especially for clients.

Attention: If you are using IBM tape devices such as 3580, 3592, and associated libraries, you do not need to install the Tivoli Storage Manager device driver, since these device drivers use the IBM tape driver. The IBM tape device drivers are available at the FTP site:

ftp://ftp.software.ibm.com/storage/dev/drvr

However, if you also install the Tivoli Storage Manager device driver, you will be able to use some useful utilities on the IBM tape devices.

At the time of the writing, a number of important server fixes are available to support library sharing and LAN-free environments. If you are using or planning to use these environments, we strongly recommend that you install server levels 5.2.7.1/5.3.2.3 or later.

70 IBM Tivoli Storage Manager Implementation Guide

3.3 AIX server installation

Here we show how to perform a fresh install of the Tivoli Storage Manager server code on AIX on a pSeries server with AIX V5.3 64-bit installed.

You must be logged in as root to install the Tivoli Storage Manager server code.

1. Insert the Tivoli Storage Manager server for AIX installation CD in the CD-ROM drive. From the operating system prompt, enter smitty installp. Choose Install and Update from ALL Available Software, as shown in Example 3-1.

Example 3-1 Tivoli Storage Manager installation: smitty installp

Install and Update Software

Move cursor to desired item and press Enter.

Install Software Update Installed Software to Latest Level (Update All) Install Software Bundle Update Software by Fix (APAR) Install and Update from ALL Available Software

2. Select the INPUT device where the installation packages are located. This is system dependent. Usually this will be the CD-ROM (for example, /dev/cd0) or a directory. We used the CD-ROM as our input device.

3. Select the filesets to install. Place the cursor in the Software to install option and enter F4 to display the list of available filesets. The Tivoli Storage Manager AIX server is supported on 32-bit and 64-bit platforms. For the supported filesets to select during installation or to upgrade from previous versions, see Tivoli Storage Manager AIX Installation Guide, GC32-1597.

We selected the following 64-bit filesets:

– tivoli.tsm.devices.aix5.rte Device Support - AIX 5.x, 32-bit and 64-bit – tivoli.tsm.server.com Server samples and diagnostic utilities – tivoli.tsm.server.aix5.rte64 Server runtime - AIX 5.x, 64-bit – tivoli.tsm.msg.en_US.server Message Library and help – tivoli.tsm.msg.en_US.devices SMIT menu catalogs – tivoli.tsm.license.aix5.rte64 License enablement module - 64-bit kernel

Note: You cannot install both the 32-bit (tivoli.tsm.server.rte) and 64-bit (tivoli.tsm.server.aix5.rte64) server filesets on the same machine. Use the AIX bootinfo -y command to determine whether your system is 32 bit or 64 bit.

IBM E16RMLL-I, Tivoli Storage Manager Implementation Manual

Specifications and Main Features

Frequently Asked Questions

User Manual