IBM Tivoli Storage Management Concepts

Front cover IBM Tivoli Storage Management Concepts See how IBM Tivoli Storage Manager can improve your IT operations Learn how to protect your vital applications and data Understand all aspects of storage management Roland Tretau Aezil Andal Ross Battaglia Dan Edwards Holger Speh ibm.com/redbooks

International Technical Support Organization IBM Tivoli Storage Management Concepts July 2003 SG24-4877-03

Note: Before using this information and the product it supports, read the information in Notices on page xix. Fourth Edition (July 2003) This edition applies to IBM Tivoli Manager Release 5.2.0 and related IBM Tivoli products as of May 2003. Copyright International Business Machines Corporation 1997, 2000, 2003. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

Contents Figures...................................................... xiii Tables...................................................... xvii Notices...................................................... xix Trademarks................................................... xx Preface...................................................... xxi The team that wrote this redbook................................... xxi Become a published author...................................... xxiv Comments welcome............................................ xxiv Part 1. Storage management concepts.......................................... 1 Chapter 1. Introduction to IBM Tivoli Storage Manager............... 3 1.1 Features of IBM Tivoli Storage Manager........................... 4 1.2 IBM Tivoli Storage Manager Extended Edition...................... 5 1.2.1 Disaster Recovery Manager................................ 6 1.2.2 NDMP backup for Network Attached Storage................... 8 1.2.3 Additional enhancements................................. 10 1.3 Optional additional products................................... 10 1.3.1 IBM Tivoli Storage Manager for Space Management............ 10 1.3.2 IBM Tivoli Storage Manager for Storage Area Networks......... 11 1.3.3 IBM Tivoli Storage Manager for System Backup and Recovery.... 11 1.4 Data protection product family.................................. 12 1.4.1 IBM Tivoli Storage Manager for Application Servers............ 13 1.4.2 IBM Tivoli Storage Manager for Databases................... 14 1.4.3 IBM Tivoli Storage Manager for Hardware.................... 16 1.4.4 IBM Tivoli Storage Manager for Mail......................... 16 1.4.5 IBM Tivoli Storage Manager for Enterprise Resource Planning.... 18 1.5 IBM Tivoli Storage Manager supported platforms................... 20 1.6 Conclusion................................................. 22 Chapter 2. Business requirements............................... 23 2.1 Storage consolidation........................................ 24 2.2 Data sharing............................................... 24 2.3 Data protection............................................. 25 2.4 Disaster recovery........................................... 25 Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. iii

Chapter 3. Architectural concepts................................ 27 3.1 IBM Tivoli Storage Management Enterprise Solution................ 28 3.2 IBM Tivoli Storage Manager architecture......................... 30 3.2.1 Overview.............................................. 30 3.2.2 IBM Tivoli Storage Manager server.......................... 31 3.2.3 IBM Tivoli Storage Manager administration................... 34 3.2.4 IBM Tivoli Storage Manager externalized interfaces............. 36 3.2.5 Basic concepts......................................... 37 3.2.6 Storage and device concepts.............................. 39 3.2.7 Policy concepts......................................... 43 3.2.8 Security concepts....................................... 44 3.3 Storage management........................................ 45 3.3.1 Best practices.......................................... 45 3.3.2 Selecting the most cost-effective solution..................... 47 3.3.3 IBM Tivoli Storage Manager product highlights................ 47 3.3.4 Information management for a connected world................ 51 3.4 Conclusion................................................. 53 Chapter 4. Planning concepts................................... 55 4.1 Most important: planning...................................... 56 4.2 Understanding the importance of your data....................... 56 4.2.1 Backups do not matter................................... 56 4.2.2 If backups do not matter, restores do........................ 57 4.2.3 Better backups through better planning...................... 59 4.2.4 Judging the deliverable................................... 61 4.3 Planning for IBM Tivoli Storage Manager......................... 62 4.4 Top tips for a successful implementation......................... 62 4.5 Conclusion................................................. 65 Part 2. Client architecture.................................................... 67 Chapter 5. Backup and restore operations......................... 69 5.1 Operation types............................................. 70 5.2 Traditional LAN and WAN backup topology....................... 73 5.3 SAN (LAN-free) backup topology............................... 74 5.4 Server-free backup.......................................... 76 5.5 Split-mirror/point-in-time copy backup............................ 78 5.6 NAS and NDMP............................................ 79 5.7 Image backup.............................................. 81 Chapter 6. Backup-archive client................................. 83 6.1 What is a client?............................................ 84 6.2 Client components........................................... 84 6.2.1 Interfaces............................................. 85 iv IBM Tivoli Storage Management Concepts

6.2.2 Configuration and options files............................. 90 6.2.3 Establishing the session.................................. 92 6.3 Multi-session and transaction concepts.......................... 93 6.3.1 Multi-session........................................... 93 6.3.2 Transaction............................................ 97 6.4 Backup................................................... 98 6.4.1 Incremental backup..................................... 100 6.4.2 Selective backup....................................... 101 6.4.3 Include-exclude lists.................................... 102 6.4.4 Logical volume backup.................................. 104 6.4.5 Open file backup....................................... 107 6.4.6 Adaptive subfile backup................................. 107 6.4.7 Journal-based backup................................... 111 6.4.8 Group backup......................................... 115 6.4.9 Active and inactive file versions........................... 115 6.4.10 Retention............................................ 117 6.4.11 Backup binding....................................... 118 6.4.12 Rebinding........................................... 119 6.4.13 Backup special considerations........................... 120 6.5 Archive.................................................. 121 6.5.1 Packages............................................ 121 6.5.2 Client space reduction................................... 122 6.5.3 Retention............................................. 123 6.6 Backup set................................................ 124 6.6.1 Backup set planning.................................... 125 6.6.2 Server/client media support.............................. 126 6.7 Restore.................................................. 126 6.7.1 Restartable restore..................................... 127 6.7.2 Point-in-time restore.................................... 128 6.7.3 Multi-session restore.................................... 131 6.7.4 Logical volume restore.................................. 131 6.7.5 Backup set restore..................................... 132 6.7.6 Cross-platform restore.................................. 133 6.8 Retrieve.................................................. 134 6.8.1 Retrieve key concepts................................... 135 6.8.2 Packages............................................ 135 6.9 Backup versus archive...................................... 136 6.10 Other considerations....................................... 137 6.10.1 Scheduling.......................................... 137 6.10.2 Compression......................................... 138 6.10.3 Client authentication................................... 139 6.10.4 Encryption........................................... 139 6.10.5 Windows specialities................................... 141 Contents v

Chapter 7. API client.......................................... 145 7.1 Overview................................................. 146 7.2 IBM Tivoli Storage Manager API client usage..................... 146 7.3 Understanding configuration files and options files................. 147 7.4 Setting up the API environment................................ 148 7.5 Using passwordaccess generate without TCA.................... 149 Chapter 8. IBM Tivoli Storage Manager for Space Management...... 151 8.1 Introduction............................................... 152 8.2 HSM migration............................................. 153 8.2.1 Automatic migration.................................... 154 8.2.2 Selective migration..................................... 154 8.2.3 Pre-migration.......................................... 154 8.2.4 Recall............................................... 155 8.2.5 Advanced transparent recall.............................. 156 8.2.6 Reconciliation......................................... 156 8.2.7 Options.............................................. 157 8.2.8 Backup and restore..................................... 157 8.2.9 Archive and retrieve.................................... 158 Part 3. Server architecture.................................................. 159 Chapter 9. Policy management................................. 161 9.1 Introduction............................................... 162 9.2 Data storage policy components............................... 162 9.3 Copy groups.............................................. 163 9.3.1 Backup copy group..................................... 165 9.3.2 Backup mode and frequency............................. 166 9.3.3 Archive copy group..................................... 167 9.4 Management class and explicit binding.......................... 167 9.5 Policy set................................................. 169 9.6 Policy domain............................................. 170 9.7 Policy management......................................... 172 Chapter 10. Scheduling....................................... 173 10.1 Introduction.............................................. 174 10.2 Administrative schedules.................................... 174 10.2.1 Scheduling concepts................................... 175 10.3 Client schedules.......................................... 176 10.3.1 Client polling......................................... 177 10.3.2 Server-prompted...................................... 178 10.3.3 One-time client schedule................................ 179 10.4 Frequency and duration.................................... 180 10.5 Retry and randomization.................................... 181 vi IBM Tivoli Storage Management Concepts

10.6 Event log................................................ 181 Chapter 11. Data storage...................................... 183 11.1 Storage device management................................ 184 11.1.1 Storage pool......................................... 184 11.1.2 Device class......................................... 185 11.1.3 Library.............................................. 186 11.1.4 Drive............................................... 186 11.1.5 Path................................................ 186 11.1.6 Data mover.......................................... 187 11.1.7 Server.............................................. 187 11.2 Storage pools............................................ 188 11.2.1 Primary storage pools.................................. 188 11.2.2 Copy storage pools.................................... 188 11.2.3 Simultaneous writes to copy storage pools.................. 189 11.3 Storage pool hierarchy..................................... 190 11.4 Movement of data between storage pools...................... 191 11.4.1 Migration............................................ 191 11.4.2 Maxsize............................................. 193 11.5 Reclamation............................................. 193 11.5.1 Single drive reclamation................................ 195 11.5.2 Reclamation of off-site volumes.......................... 196 11.6 Reduce restore times...................................... 197 11.6.1 Collocation.......................................... 198 11.6.2 Disk caching......................................... 200 11.6.3 Data movement....................................... 200 11.7 Disk storage protection..................................... 201 11.7.1 RAID............................................... 201 11.7.2 RAID 1.............................................. 202 11.7.3 RAID 1 + 0........................................... 202 11.7.4 RAID 5.............................................. 204 11.8 SAN exploitation.......................................... 206 11.8.1 Overview............................................ 206 11.8.2 How to use a SAN environment.......................... 207 11.8.3 SAN device mapping................................... 211 Chapter 12. User management and security...................... 213 12.1 Administrator............................................. 214 12.1.1 Authority levels....................................... 214 12.1.2 Creation............................................. 214 12.1.3 Privilege classes...................................... 215 12.1.4 Operations........................................... 217 12.1.5 Auditing............................................. 219 Contents vii

12.2 Server security........................................... 219 12.2.1 Maximum logon attempts............................... 219 12.2.2 Password expiry...................................... 220 12.2.3 Minimum password length.............................. 220 12.2.4 Web authentication timeout.............................. 220 12.3 Client security............................................ 220 12.4 Firewalls................................................ 221 12.5 Client option sets.......................................... 223 Chapter 13. Licensing......................................... 225 13.1 Licensed features......................................... 226 13.2 License compliance........................................ 226 13.3 IBM Tivoli Storage Manager licenses.......................... 227 Chapter 14. Server network.................................... 231 14.1 Enterprise administration.................................... 232 14.2 Enterprise management features............................. 232 14.3 Enterprise Administration features............................ 235 14.4 Virtual volumes........................................... 237 14.5 Data movement between servers............................. 239 14.5.1 Export/import......................................... 240 14.6 Tape library sharing........................................ 242 Chapter 15. High availability clustering.......................... 245 15.1 High availability cluster multiprocessing........................ 247 15.2 Backup-archive and HSM client with HACMP.................... 248 15.2.1 IBM Tivoli Storage Manager with Microsoft Cluster Server...... 250 15.2.2 Backup-archive client support with MSCS.................. 252 Chapter 16. Disaster Recovery Manager.......................... 255 16.1 What is disaster recovery?.................................. 256 16.1.1 Using Disaster Recovery Manager........................ 257 16.1.2 Volume tracking...................................... 259 16.1.3 Focus on recovery..................................... 264 16.1.4 Speed to recovery..................................... 265 16.2 What should be considered a disaster?........................ 266 16.2.1 Disaster recovery techniques............................ 267 16.3 Recovery strategy for the server.............................. 270 16.3.1 Creation of up-to-date disaster recovery plan................ 270 16.3.2 Additional disaster recovery issues........................ 273 Part 4. Systems management............................................... 275 Chapter 17. Reporting......................................... 277 viii IBM Tivoli Storage Management Concepts

17.1 Why IBM Tivoli Storage Manager reporting?.................... 278 17.2 Which reports are needed?.................................. 278 17.2.1 Daily summary report.................................. 278 17.2.2 Detail reports......................................... 279 17.3 Where is server information stored?........................... 280 17.3.1 Information on the server............................... 280 17.3.2 Information on the client node............................ 281 17.4 Central error logging....................................... 281 17.4.1 Central logging of client events........................... 281 17.4.2 Client and server event reporting......................... 282 17.4.3 SNMP heartbeat monitoring of server...................... 282 17.5 SQL queries and ODBC interface............................. 283 17.5.1 SELECT command.................................... 283 17.5.2 ODBC driver......................................... 283 17.6 Operational reporting....................................... 283 17.6.1 Overview............................................ 284 17.6.2 Examples........................................... 286 Chapter 18. IBM Tivoli Enterprise solutions....................... 291 18.1 Overview................................................ 292 18.2 IBM Tivoli Enterprise modules................................ 293 18.2.1 IBM Tivoli Systems Management Framework................ 293 18.2.2 IBM Tivoli Distributed Monitoring......................... 294 18.2.3 IBM Tivoli Software Distribution.......................... 295 18.2.4 IBM Tivoli Inventory.................................... 296 18.2.5 The IBM Tivoli Enterprise Console product.................. 297 18.2.6 Data Protection applications............................. 299 Part 5. Complementary products............................................. 301 Chapter 19. IBM Tivoli Storage Manager for Databases............. 303 19.1 Relational databases....................................... 304 19.1.1 Tables.............................................. 305 19.1.2 Table spaces......................................... 305 19.1.3 Log files............................................. 305 19.1.4 Control files.......................................... 306 19.1.5 Initialization parameter and configuration files............... 306 19.1.6 Backup techniques.................................... 306 19.1.7 Restore techniques.................................... 314 19.1.8 Which backup and recovery technique should you use?....... 314 19.1.9 Exploiting IBM Tivoli Storage Manager for Databases......... 315 19.2 Planning considerations.................................... 317 19.2.1 Backup requirements.................................. 318 19.2.2 Types of events....................................... 318 Contents ix

19.2.3 Speed of recovery..................................... 320 19.2.4 Backup windows...................................... 321 19.2.5 Recovery points...................................... 321 19.2.6 Units of recovery...................................... 321 19.3 DB2 data protection........................................ 322 19.3.1 IBM Tivoli Storage Manager API.......................... 323 19.3.2 DB2 UDB............................................ 323 19.3.3 Integration with IBM Tivoli Storage Manager................ 325 19.4 Data Protection for Informix.................................. 325 19.4.1 Informix online backup utilities........................... 326 19.4.2 The tbtape utility...................................... 327 19.4.3 The ontape utility...................................... 327 19.4.4 ON-Archive.......................................... 327 19.4.5 ON-Bar............................................. 328 19.4.6 Components......................................... 328 19.5 Data Protection for Oracle................................... 330 19.5.1 IBM Tivoli Storage Manager and Oracle.................... 331 19.5.2 Backup using Data Protection for Oracle................... 331 19.5.3 Oracle alter table space utility............................ 333 19.6 Data Protection for Microsoft SQL Server....................... 334 19.6.1 SQL Server overview.................................. 334 19.6.2 SQL important database options.......................... 338 19.6.3 Overview of Data Protection for SQL and LAN-free........... 339 19.6.4 Managed System for SAN Storage Agent................... 340 Chapter 20. IBM Tivoli Storage Manager for Mail................... 343 20.1 Data Protection for Lotus Domino............................. 344 20.1.1 Lotus Domino Release 6................................ 345 20.1.2 Lotus Notes data...................................... 349 20.1.3 Storage management for Lotus Notes..................... 349 20.1.4 Tivoli Storage Manager backup-archive client and Domino..... 350 20.1.5 The Data Protection for Lotus Domino component............ 351 20.2 Data Protection for Microsoft Exchange Server.................. 352 20.2.1 Exchange Application Client functions..................... 354 20.2.2 Exchange Server security............................... 355 20.2.3 Exchange Server backup strategy considerations............ 356 Chapter 21. IBM Tivoli Storage Manager for Enterprise Resource Planning 357 21.1 Overview................................................ 358 21.2 SAP.................................................... 359 21.2.1 Online backup for all major databases..................... 360 21.2.2 Methods of backing up R/3 databases..................... 361 x IBM Tivoli Storage Management Concepts

21.2.3 Data Protection for SAP R/3............................. 363 21.2.4 BACKINT File Manager................................. 364 21.2.5 Administration tools.................................... 364 Chapter 22. IBM Tivoli Storage Manager for Applications........... 367 22.1 Overview of WebSphere Application Server..................... 368 22.2 Overview of IBM Tivoli Storage Manager for Application Servers..... 374 22.2.1 Architecture.......................................... 375 22.2.2 Functions............................................ 376 22.3 Backup strategies......................................... 378 22.3.1 Full backups only..................................... 378 22.3.2 Differential backups only................................ 378 22.3.3 Differential plus periodic full backups...................... 379 Chapter 23. IBM Tivoli complementary products................... 381 23.1 IBM Tivoli Storage Area Network Manager...................... 382 23.1.1 Business purpose of IBM Tivoli SAN Manager............... 383 23.1.2 Components of IBM Tivoli SAN Manager................... 383 23.1.3 IBM Tivoli SAN Manager server.......................... 384 23.1.4 Supported devices for IBM Tivoli SAN Manager.............. 385 23.1.5 Important functions of IBM Tivoli SAN Manager.............. 385 23.2 IBM Tivoli Storage Resource Manager......................... 386 23.2.1 Business purpose of IBM Tivoli Storage Resource Manager.... 387 23.2.2 Architecture of IBM Tivoli Storage Resource Manager......... 387 23.2.3 IBM Tivoli Storage Resource Manager products............. 388 23.2.4 Components of IBM Tivoli Storage Resource Manager........ 389 23.3 IBM Tivoli SANergy........................................ 391 23.3.1 What are the benefits of IBM Tivoli SANergy?............... 392 23.3.2 Sharing disk volumes.................................. 392 23.3.3 Backup and recovery.................................. 395 23.3.4 File sharing.......................................... 395 23.3.5 IBM Tivoli SANergy requirements......................... 396 23.3.6 IBM Tivoli SANergy limitations........................... 396 23.3.7 Summary............................................ 397 23.4 Cristie Bare Machine Recovery............................... 397 23.4.1 Overview............................................ 398 23.4.2 How does it work?..................................... 399 23.4.3 The deployment steps.................................. 400 23.4.4 More information...................................... 401 23.5 Ready for IBM Tivoli products and solutions..................... 401 Chapter 24. iseries storage management solutions................ 403 24.1 Why choose an iseries system?.............................. 404 24.2 iseries with IBM Tivoli Storage Manager....................... 404 Contents xi

24.3 Portable Application Solutions Environment..................... 404 24.3.1 Advantages of OS/400 PASE porting...................... 405 24.3.2 Important PASE features............................... 405 24.3.3 Reducing time to market................................ 406 24.4 Who would use Tivoli Storage Manager on iseries?............... 406 24.5 Hardware and software requirements.......................... 407 24.6 Considerations for iseries (PASE)............................ 408 24.7 BRMS/400............................................... 409 24.8 iseries system as Tivoli Storage Manager API client.............. 411 24.9 iseries system as a Tivoli Storage Manager server............... 413 24.10 Disaster recovery for the iseries............................. 414 24.11 HSM on an iseries system................................. 414 24.12 Large database and application support....................... 415 24.13 Logical partitions......................................... 416 24.14 Integrated Netfinity Server.................................. 417 Part 6. Appendixes........................................................ 419 Appendix A. Planning and sizing worksheets..................... 421 Glossary.................................................... 427 Abbreviations and acronyms................................... 433 Related publications.......................................... 437 IBM Redbooks................................................ 437 Other publications............................................. 438 Online resources.............................................. 440 How to get IBM Redbooks....................................... 442 Help from IBM................................................ 443 Index....................................................... 445 xii IBM Tivoli Storage Management Concepts

Figures 1-1 IBM Tivoli Disaster Recovery Manager functions.................. 7 1-2 Topology for NDMP using IBM Tivoli Storage Manager............. 9 3-1 IBM Tivoli Storage Management Enterprise Solution.............. 29 3-2 IBM Tivoli Storage Manager server............................ 31 3-3 IBM Tivoli Storage Manager client GUI interface.................. 33 3-4 IBM Tivoli Storage Manager client command line interface (Windows). 33 3-5 IBM Tivoli Storage Manager client interface Web client............ 34 3-6 IBM Tivoli Storage Manager administration client Web interface..... 35 3-7 IBM Tivoli Storage Manager command line administrative interface... 35 3-8 Progressive backup methodology vs. other backup schemes........ 38 3-9 IBM Tivoli Storage Manager storage management concepts........ 40 3-10 Storage pool collocation..................................... 42 3-11 Space reclamation......................................... 43 3-12 Policy relationships and resources............................ 44 4-1 Divisions of the IBM Tivoli Storage Manager database............. 58 4-2 IBM Tivoli Storage Manager progressive incremental backup........ 60 4-3 IBM Tivoli Storage Manager point-in-time restore................. 61 5-1 IBM Tivoli Storage Manager LAN and WAN backup............... 73 5-2 IBM Tivoli Storage Manager LAN-free backup................... 74 5-3 IBM Tivoli Storage Manager server-free backup.................. 77 5-4 IBM Tivoli Storage Manager split-mirror/point-in-time copy backup.... 78 5-5 IBM Tivoli Storage Manager and NDMP backup.................. 80 6-1 Windows interface showing collapsible directories................ 86 6-2 Windows interface showing directories available to restore......... 87 6-3 Web backup-archive client................................... 90 6-4 Client with configuration and options files....................... 91 6-5 Client presents node name and is accepted..................... 92 6-6 Establishing a client session................................. 93 6-7 Producer-Consumer model.................................. 94 6-8 Multithreaded backup....................................... 96 6-9 Transaction processing..................................... 98 6-10 Backup in progress........................................ 99 6-11 Incremental backup processing.............................. 101 6-12 Selective backup processing................................ 102 6-13 Include-exclude list and rules................................ 103 6-14 Image backup and restore.................................. 105 6-15 Options for image backup.................................. 106 6-16 Adaptive sub-file backup architecture......................... 108 Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. xiii

6-17 Adaptive sub-file backup and restore.......................... 110 6-18 Active and inactive files.................................... 117 6-19 RETEXTRA and RETONLY expiration processing............... 118 6-20 Binding files to management classes.......................... 119 6-21 Archive in progress....................................... 121 6-22 Packaging files........................................... 122 6-23 Archiving unnecessary files................................. 123 6-24 Archiving long-term files.................................... 124 6-25 Portable client backup set.................................. 125 6-26 Restore in progress....................................... 127 6-27 Restartable restore processing.............................. 128 6-28 Expiration and point-in-time restore........................... 129 6-29 Point-in-time rules........................................ 130 6-30 Point-in-time restore examples.............................. 131 6-31 Cross-platform restore..................................... 134 6-32 Retrieve in progress....................................... 135 6-33 Retrieval from GUI........................................ 136 8-1 IBM Tivoli Storage Manager for Space Management concept...... 152 9-1 Data storage policy relationships and resources................. 162 9-2 Data storage policy components............................. 163 9-3 Data flow through copy groups.............................. 164 9-4 Binding data to the management class structure................. 168 9-5 Policy set structure........................................ 170 9-6 Policy domain structure.................................... 171 10-1 Client schedules.......................................... 175 10-2 Client schedule types...................................... 177 10-3 Client polling scheduling................................... 178 10-4 Server-prompted scheduling................................ 179 10-5 Schedule frequency....................................... 180 11-1 IBM Tivoli Storage Manager storage objects.................... 184 11-2 Simultaneous write........................................ 189 11-3 Possible hierarchical arrangement of different storage devices..... 191 11-4 Migration between storage pools............................. 192 11-5 Reclamation on two fragmented volumes...................... 194 11-6 Single drive reclamation example............................ 196 11-7 Reclamation of off-site volumes.............................. 197 11-8 Storage pool collocation on a client level....................... 199 11-9 RAID 1 (mirroring) user-usable space = 1/2 total disk space........ 202 11-10 RAID 1 + 0, mirror and stripe................................ 203 11-11 RAID 5 stripe showing how parity is distributed.................. 205 11-12 Remotely connected tape library............................. 208 11-13 Meshed switch topology.................................... 209 12-1 Administrative privileges................................... 215 xiv IBM Tivoli Storage Management Concepts

12-2 Client access authority and client owner authority................ 217 14-1 IBM Tivoli Storage Manager enterprise console................. 232 14-2 Server-to-server communications............................ 236 14-3 Server-to-server virtual volumes............................. 237 14-4 Export data from server 1, use volumes, import data to server 2.... 240 14-5 Tape library sharing....................................... 243 15-1 HACMP and IBM Tivoli Storage Manager server configuration...... 247 15-2 HACMP and IBM Tivoli Storage Manager client configuration...... 249 15-3 MSCS and IBM Tivoli Storage Manager server configuration....... 251 15-4 MSCS and IBM Tivoli Storage Manager client configuration........ 253 16-1 Disaster recovery terminology............................... 257 16-2 IBM Tivoli Storage Manager Extended Edition.................. 258 16-3 IBM Tivoli Storage Manager disaster recovery flow............... 259 16-4 Tape movement and the Courier state........................ 261 16-5 Off-site tape states........................................ 263 16-6 Recovery order and possibilities............................. 265 16-7 Recovery time........................................... 267 16-8 Sending data to off-site location.............................. 269 16-9 Restoring an IBM Tivoli Storage Manager server................ 272 17-1 Operational report Web summary page........................ 286 17-2 Operational reporting hourly monitor.......................... 287 17-3 Operational reporting daily report summary..................... 288 17-4 Operational reporting daily report load summary................. 289 18-1 IBM Tivoli Enterprise architecture............................ 293 18-2 IBM Tivoli Enterprise Systems Management Framework.......... 294 19-1 Fundamental structure of a database......................... 304 19-2 Backup techniques to be considered.......................... 307 19-3 Other backup techniques................................... 308 19-4 Techniques for using Tivoli Storage Manager to back up databases. 316 19-5 Shared-nothing parallel architecture.......................... 324 19-6 IBM Tivoli Storage Manager interface with DB2................. 325 19-7 Data Protection for Informix integration with Informix............. 329 19-8 Oracle7 and Oracle8 interfacing with IBM Tivoli Storage Manager... 332 19-9 Alter table space script backup option......................... 333 19-10 SQL database physical structure............................. 337 19-11 SQL database logical structure.............................. 337 19-12 LAN-free backup for SQL................................... 340 20-1 Logical components of Data Protection for Domino............... 345 20-2 Lotus Notes 6 Welcome Page............................... 347 20-3 Lotus Domino Administrator................................. 348 20-4 Data Protection for Domino GUI............................. 352 20-5 Overview of Data Protection for Exchange operating environment... 353 21-1 SAP R/3 components...................................... 360 Figures xv

21-2 SAP logical flow of BACKINT operation........................ 362 22-1 IBM WebSphere Application Server components................ 368 22-2 IBM Tivoli Storage Manager for Application Servers architecture.... 375 23-1 IBM Tivoli Storage Resource Manager Architecture.............. 387 23-2 IBM Tivoli Storage Resource Manager components.............. 389 23-3 Sharing volumes from heterogeneous hosts with SANergy......... 392 23-4 Locally attached storage compared to exploiting a NAS appliance... 393 23-5 Sharing files with SANergy and storage area networks............ 395 23-6 Cristie Bare Machine Recovery with IBM Tivoli Storage Manager.... 398 24-1 Basic components of BRMS................................ 410 24-2 BRMS Application Client................................... 411 24-3 iseries data before and after storage is freed................... 415 24-4 Logical partition overview................................... 416 24-5 Windows NT server running on IPCS......................... 417 xvi IBM Tivoli Storage Management Concepts

Tables 5-1 Summary of client backup and restore operations................. 70 7-1 Options files............................................. 147 7-2 API environment variables.................................. 149 11-1 Reconstructing a failed data disk from the parity disk............. 204 21-1 SAP R/3 backup alternatives with IBM Tivoli Storage Manager..... 362 22-1 IBM Tivoli Storage Manager for Application Servers features....... 376 23-1 IBM Tivoli SAN Manager................................... 382 24-1 BRMS and IBM Tivoli Storage Manager terminology............. 409 24-2 Client requirements worksheet.............................. 422 24-3 Storage policy requirements worksheet........................ 423 24-4 Database worksheet...................................... 423 24-5 Recovery log worksheet.................................... 423 24-6 Device configuration and volume history worksheet.............. 424 24-7 Total IBM Tivoli Storage Manager disk required worksheet........ 424 24-8 Tape drive configuration worksheet........................... 425 24-9 Administrator IDs worksheet................................ 425 24-10 License requirements worksheet............................. 426 Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. xvii

xviii IBM Tivoli Storage Management Concepts

Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. xix

Trademarks The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Approach AIX AIX 5L AS/400 Domino Domino Designer DB2 DB2 Universal Database DPI Enterprise Storage Server ^ FlashCopy FICON IBM ibm.com Informix iseries Lotus Notes Lotus MQSeries MVS Netfinity NetView OS/2 OS/390 OS/400 PowerPC pseries Redbooks Redbooks (logo) RISC System/6000 RS/6000 S/390 SysBack SANergy Tivoli Tivoli Enterprise Tivoli Enterprise Console TotalStorage VisualAge WebSphere xseries z/os zseries The following terms are trademarks of other companies: Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. SET, SET Secure Electronic Transaction, and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC. Other company, product, and service names may be trademarks or service marks of others. xx IBM Tivoli Storage Management Concepts

Preface This IBM Redbook describes the features and functions of IBM Tivoli Storage Manager. It introduces IBM Tivoli Storage Management concepts for those new to storage management in general, and to IBM Tivoli Storage Manager, in particular. This easy-to-follow guide gives a broad understanding of IBM Tivoli Storage Manager software: the key technologies to know and the solutions available to protect your business. You will gain a broad understanding of the way IBM Tivoli Storage Manager works in heterogeneous environments including Windows, UNIX/Linux, OS/400, and z/os platforms as well as mission-critcal applications such as DB/2, Oracle, Lotus Domino, Microsoft Exchange, SAP, and more. The book introduce you to storage management software and explains the concepts, architecture, and systems management features of IBM Tivoli Storage Manager. Additionally, it discusses available complementary products and helps you design solutions to protect your data holdings from losses ranging in scale from those caused by user error through complete site disasters. A companion redbook is available, IBM Tivoli Storage Manager Implementation Guide, SG24-5416, that addresses the practical hands-on side of planning, implementing, and maintaining an IBM Tivoli Storage Manager environment in Windows, AIX, and Linux environments. 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. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. xxi

Figure 1 The team, from left to right: Dan, Aezil, Ross, Holger, and Roland Roland Tretau is a Project Leader with the IBM International Technical Support Organization, San Jose Center. Before joining the ITSO in April 2001, Roland worked in Germany as an IT Architect for Cross Platform Solutions and Microsoft Technologies. He holds a Masters degree in Electrical Engineering with a focus in telecommunications. He is a Red Hat Certified Engineer (RHCE) and a Microsoft Certified Systems Engineer (MCSE), and he holds a Masters Certificate in Project Management from The George Washington University School of Business and Public Management. Aezil Andal is an IT Specialist at IBM Philippines. She holds a Bachelor of Science Degree in Computer Science from De La Salle University, Manila, and is completing her Masters degree. She has experience in storage and systems management since 2001. She is an IBM-certified specialist in TSM and a Cisco Certified Network Associate. Her areas of expertise include storage, systems management, and networking solutions. Ross Battaglia is the co-founder of IBM Business Partner Tivoli Associates, a division of ETI-NET, in Boca Raton, Florida. His 24-plus years of experience xxii IBM Tivoli Storage Management Concepts

include developing the Tandem Tivoli Storage Manager client. He is an IBM Certified Expert, an Authorized Education Center for IBM Software Instructor, and a member of the IBM Professional Certification Test writing team. Areas of expertise include software development in data and storage management, and he has written extensively about disaster recovery and storage management. Dan Edwards is a Consulting IT Specialist with IBM based in Ottawa, Canada. He has 25 years of experience in the computing industry, with the past 12 years spent working on storage and UNIX solutions. He holds multiple product certifications including Tivoli, AIX, and Oracle. He is also an IBM Certified Professional and sits as a member of the IT Specialist Certification Board. Holger Speh is an IT Specialist at IBM Germany. He has experience in the systems and storage management field since 1999. He holds a Masters degree in Computer Science from the Technical University of Brunswick. He also holds a Masters Certificate in Project Management from The George Washington University School of Business and Public Management. His areas of expertise include all subjects of IBM Tivoli storage products on distributed platforms. The authors of the previous editions of this redbook: Arnold Balingit, Ross Battaglia, Charlotte Brooks, Hans Gross, J.P. Houle, Mathis Landzettel, Roland Leins, Armando Lemos da Silva Filho, Rod MacLeod, Andy Pattinson, Patrick Randall, Raghavendra Rao, Anna Seok Hoe Tan, and Phil Thomas. Thanks to the following people for their contributions to this project: Yvonne Lyon, Emma Jacobs, Deanna Polm, Charlotte Brooks, Barry Kadleck International Technical Support Organization, San Jose Center Betsy Thaggard International Technical Support Organization, Austin Center Tim Donofrio, Freddy Saldana, Scott Petersen, Dale Mark Mock, Susan Chen, Katherine Keaney, Marsha Vasquez, Yolanda Martinez, Mike Collins, Ken Hannigan, Andy Raibeck, Cydnee White, Dave Oswald, Morris Thompson, Harley Puckett, Tricia Jiang, Michael Barton IBM US Tony Rynan IBM Australia Ian Cameron Cristie Data Products Preface xxiii

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 will team with IBM technical professionals, Business Partners and/or customers. Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you will 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 e-mail to: redbook@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California 95120-6099 xxiv IBM Tivoli Storage Management Concepts

Part 1 Part 1 Storage management concepts In this part of the book we discuss total storage management solutions, from backup and restore to disaster recovery and space management. We cover, using broad, creative thinking, the ways to design a solution for your environment using IBM Tivoli Storage Manager. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 1

2 IBM Tivoli Storage Management Concepts

1 Chapter 1. Introduction to IBM Tivoli Storage Manager IBM Tivoli Storage Manager is a full-function storage software product that addresses the challenges of complex storage management across distributed environments. It protects and manages a broad range of data, from the workstation to the corporate server environment. More than 39 different operating platforms are supported; all include a consistent graphical user interface (GUI). Tivoli Storage Manager provides: Centralized administration for data and storage management Efficient management of information growth High-speed automated server recovery Full compatibility with hundreds of storage devices, as well as LAN, WAN, and SAN infrastructures Customized backup solutions for major groupware, enterprise resource planning (ERP) applications, and database products Tivoli Storage Manager is a premier choice for complete storage management in mixed platform environments. It is used by more than 80 of the Fortune 100 companies, and it protects more than one million systems around the world. Today, Tivoli Storage Manager features are more powerful, modular, flexible, and easy to use than ever before. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 3

1.1 Features of IBM Tivoli Storage Manager IBM Tivoli Storage Manager protects an organization s data against hardware failures and other errors by storing backup and archive copies of data in offline storage. It can scale to protect hundreds of computers from laptops to mainframes, running a dozen different operating systems, connected via the Internet, WANs, or LANs. The centralized Web-based management, smart data move and store techniques, and comprehensive policy-based automation work together to minimize data protection administration costs and the impact on both computers and networks. Optional modules enable business-critical applications that must run 24x7x365 to utilize IBM Tivoli Storage Manager centralized data protection with no interruption to their service. Progressive backup methodology Saves time and disk space by backing up only new files and modified files. The progressive backup feature uses its own relational database to track data wherever it is stored, delivering direct one-step file restore. This eliminates the need for base-plus-incrementals tapes, commonly used for restore procedures in other storage management products. Tape resource sharing Enables multiple Tivoli Storage Manager servers to use the same tape library and drives. This improves tape hardware asset utilization, recovery performance, and tape hardware asset utilization. Network-free rapid recovery Supports high-speed client data recovery directly from a tape or CD-ROM. This minimizes recovery time by eliminating the use of network and central services resources. LAN-free data transfer Effectively exploits SAN environments by moving back-end office and IT data transfers from the communication network to a dedicated data network or SAN. Internet Protocol (IP) communication bandwidth can then be used to improve service levels for end users and customers. Dynamic multithreaded transfer Permits multiple clients to simultaneously transfer data to and from the same Tivoli Storage Manager server. This new feature boosts performance backups to more than three times faster than the rate of a single-threaded session. This speed is achieved because the number of IBM Tivoli Storage Manager data transfer sessions is transparently optimized based on available system resources. 4 IBM Tivoli Storage Management Concepts

Adaptive differencing technology Changes the way data is transferred throughout the enterprise. Data is transferred by byte, block, or file level, based on data size and network characteristics. This newly patented technology supports a variety of connectivity strategies, including LANs, WANs, SANs, Internet, and dial-up connections. Adaptive Differencing technology is designed for mobile computer users and other users with a need to minimize data transmitted over the network. Enterprise administration Simplifies centralized control across multiple Tivoli Storage Manager implementations without sacrificing network performance. This enables high-performance backups to locally attached storage devices using a minimum of network resources. You can find more information on the following Web site: http://www-3.ibm.com/software/tivoli/products/storage-mgr/ 1.2 IBM Tivoli Storage Manager Extended Edition The Extended Edition of IBM Tivoli Storage Manager expands on the features and possibilities of the Basic Edition described in the previous section. The following sections show how the effect of the Extended Edition on a comprehensive enterprise storage solution. Tivoli Storage Manager Extended Edition increases data protection beyond the Basic Edition s specifications to thousands of computers and adds SANs to the interconnection list. In addition to the features and options offered in the Basic Edition, optional software extensions enable SAN-connected computers to use the SAN for data protection data movements, and provide Hierarchical Storage Management to automatically move unused data files from online disk storage to offline tape storage. Tivoli Storage Manager Extended Edition expands on the data backup and restore, and managed data archive and retrieve capabilities of the basic Tivoli Storage Manager by adding, disaster planning capability, NDMP control for network-attached storage (NAS) filers and support for large tape libraries. You can find more information on the following Web site: http://www-3.ibm.com/software/tivoli/products/storage-mgr-extended/ Chapter 1. Introduction to IBM Tivoli Storage Manager 5

1.2.1 Disaster Recovery Manager The Disaster Recovery Manager component of IBM Tivoli Storage Manager Version 5 Extended Edition provides disaster recovery for the IBM Tivoli Storage Manager server and assists in disaster recovery for clients. Disaster Recovery Manager offers various options to configure, control, and automatically generate a disaster recovery plan file containing the information, scripts, and procedures needed to automate restoration and help ensure quick recovery of data after a disaster. It also manages and tracks the media on which the data is stored, whether on-site, in-transit, or in a vault, so that required data can be located easily if disaster strikes. The scripts can help document the basic Information Technology recovery strategy, the steps to rebuild core systems, as well as the critical machines that must be recovered. One of the key features of Tivoli Storage Manager and Disaster Recovery Manager is the ability to track media in all possible states, such as on-site, in transit or in a vault. Because of the criticality of data in the production environment, controls are needed to ensure that all previously backed-up data can be found and restored in a reasonable amount of time. Disaster Recovery Manager functions help maintain business continuance by: Establishing and helping to automate a thorough server disaster recovery plan clients can then subsequently restore their data from the server if required Ensuring that customer-provided information is available in the same plan Automating vital recovery steps to bring the Tivoli Storage Manager server and backup environment back to normal operation Managing and indentifying off-site media needed for recovery Tracking and reporting destroyed systems in the event of a disaster Storing client configuration information and assigning client recovery priorities With Disaster Recovery Manager you can recover at an alternate site, on replacement computer hardware, using different hardware configuration at the recovery site, and with people who are not familiar with the applications. You can also use the disaster recovery plan for audits to certify the recoverability of the server. The disaster recovery plan can be re-created easily every day so that it stays up-to-date. Figure 1-1 on page 7 illustrates the main functions of Disaster Recovery Manager. 6 IBM Tivoli Storage Management Concepts

BACKUP ENVIRONMENT 1. DISASTER RECOVERY PLANNING Clients Admin "prepare" 2. OFF-SITE MEDIA MANAGEMENT IBM Tivoli Storage Manager Server D R M ON-SITE RETRIEVE VAULT EACH VOLUME TRACKED DB 3. AUTOMATED RECOVERY OF IBM TIVOLI STORAGE MANAGER SERVER IBM Tivoli Storage Manager Database IBM Tivoli Storage Manager Storage Pools Figure 1-1 IBM Tivoli Disaster Recovery Manager functions During a real disaster, errors commonly encountered include: The disaster recovery plan was not tested. The testing team s skills were not sufficient to perform and evaluate testing. The recovery plan is out-of-date. Disk volume definitions for the recovery site are not known. Location of recovery tapes is not known. It is not known which tapes are to be applied first. Disaster Recovery Manager will help answer questions such as: Where is the current server configuration information located? What are the current server database volumes? What is my recovery sequence? Is my recovery plan current; is this guaranteed? What was the client and server machine configuration like? Who should be contacted in a disaster? Where is the recovery media located? Can I restore my environment to any point in time? During recovery from a disaster, Disaster Recovery Manager automates the following procedures to restore the Tivoli Storage Manager servers: Restores Tivoli Storage Manager server s key option files. Chapter 1. Introduction to IBM Tivoli Storage Manager 7

Copies files from alternate locations to production locations. Initializes Tivoli Storage Manager database and log volumes. Matches sizes and locations of Tivoli Storage Manager database and log volumes. Launches current DB restore automatically. Tracks media needed and availability. Registers installed Tivoli Storage Manager server features. Returns server state to a valid license configuration. Updates Tivoli Storage Manager volume catalog information. Marks volume information for recovery; for example, is it destroyed or not? Rebuilds Tivoli Storage Manager hierarchical storage configuration. Re-creates customer backup environment. A detailed description, recovery scenario, and recovery plan built with Disaster Recovery Manager can be found in the Disaster Recovery Strategies with Tivoli Storage Management, SG24-6844. Also, recommendations and examples of using Disaster Recovery Manager to store client machine information in the Disaster Recovery Manager plan file for use during a client disaster recovery are given in the same book. In summary, Disaster Recovery Manager will systematically re-build the storage management server environment and ensure that current application data for the entire enterprise is available for recovery. This is all possible from a single scripted command, automatically. 1.2.2 NDMP backup for Network Attached Storage IBM Tivoli Storage Manager Extended Edition uses Network Data Management Protocol (NDMP) to perform high-performance, scalable backups and restores. These backups and restores minimize network traffic and transfer data outboard of the Tivoli Storage Manager client and server. NDMP enables a full and differential file-system image backup and restore of Network Appliance file servers with operating system Data ONTAP 6.1.1 or higher. Multiple backup and restore operations can be performed simultaneously. This product s code is a combination of Tivoli Storage Manager Extended Edition server and client code. No extra code has to be installed on the server, client, or NAS appliance. When doing backups and restores, the NAS device and the Tivoli Storage Manager server and client all have specific roles, as shown in Figure 1-2 on page 9. 8 IBM Tivoli Storage Management Concepts

Topology for NDMP Operations using IBM Tivoli Storage Manager IBM Tivoli Storage Manager Client Displays NAS nodes and file systems User interface for backup/restore Monitors backup/restore Can cancel backup/restore Request TCP/IP IBM Tivoli Storage Manager Server Accepts requests from client Provides backup/restore commands Runs backup/restore as TSM process Initiates and monitors NDMP sessions Controls library/tape operations Stores meta-data for stored images Manages policy NDMP Control (TCP/IP) NAS Device (Data Mover) Accepts requests from Tivoli Storage Manager Server Performs tape/library operations Transfers data during backup/restore Reports results to TSM server Control Data Flow Data Transfer (SCSI/FC) Tape Library (can be shared) Data format is NETAPPDUMP NAS File System Figure 1-2 Topology for NDMP using IBM Tivoli Storage Manager It currently offers the ability to do file-level and full/differential file-system image backups and restore of servers that support the NDMP protocol. Multiple backup and restore operations can be performed in parallel. During backup and restore operations, data flows directly between the tape drive and the NAS appliance. NDMP for NAS backup uses either a SCSI-attached tape device local to the NAS appliance, or a SAN-attached SCSI or ACSLS device that can be shared with the IBM Tivoli Storage Manager server. Library robotics can be controlled directly by the Tivoli Storage Manager server or by passing SCSI commands via a NAS file server. Drives must be supported by both the NAS appliance and the NAS operating system. Drives can be dedicated to NDMP operations from a single NAS file server or can be shared. Multiple NAS appliances can share tape resources if they have FC access to the drive and if backups are performed via the same Tivoli Storage Manager server. Drives can be shared with LAN-free backup/restore operations, provided that the library is controlled directly by the Tivoli Storage Manager server. Chapter 1. Introduction to IBM Tivoli Storage Manager 9

1.2.3 Additional enhancements Other differences between the Basic and the Extended editions of IBM Tivoli Storage Manager are mostly license-based. The Extended Edition s purpose is its enterprise-wide integration even in large environments. Therefore it supports more drives and larger libraries and the ability to share them among different IBM Tivoli Storage Manager servers. 1.3 Optional additional products IBM Tivoli Storage Manager can be integrated with several optional applications that together form a powerful integrated storage management solution. These include: IBM Tivoli Storage Manager for Space Management IBM Tivoli Storage Manager for Storage Area Networks IBM Tivoli Storage Manager for System Backup and Recovery For a full product listing, visit:: http://www-3.ibm.com/software/tivoli/products/ 1.3.1 IBM Tivoli Storage Manager for Space Management IBM Tivoli Storage Manager for Space Management provides hierarchical storage management to automatically migrate rarely accessed files to alternate storage without disrupting the most frequently used files in local storage. Migrated files are automatically and transparently recalled to primary storage when needed by applications or users, freeing administrators and users from manual filing tasks. Some percentage of your data is inactive that is, it hasn't been accessed in weeks, if not months. IBM Tivoli Storage Manager for Space Management (formerly known as hierarchical storage management, or HSM) can automatically move inactive data to less-expensive offline storage or near-line storage, freeing online disk space for more important active data. IBM Tivoli Storage Manager for Space Management frees administrators and users from manual file system pruning tasks, and defers the need to purchase additional disk storage, by automatically and transparently migrating rarely accessed files to Storage Manager storage, while the files most frequently used remain in the local file system. IBM Tivoli software now offers increased scalability and performance via parallel migrations, improved candidate search, and optimized synchronization between the IBM Tivoli Storage Manager server and the hierarchical storage management (HSM) client. 10 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Manager for Space Management complements both IBM Tivoli Storage Manager and IBM Tivoli Storage Manager Extended Edition. 1.3.2 IBM Tivoli Storage Manager for Storage Area Networks The IBM Tivoli Storage Manager for Storage Area Networks extension enables SAN-connected IBM Tivoli Storage Manager servers and client computers to make maximum use of their direct network connection to storage. This software extension enables both servers and client computers to make the bulk of their backup/restore and archive/retrieve data transfers over the SAN instead of the LAN, either directly to tape or to the IBM Tivoli Storage Manager disk storage pool. This ability greatly reduces the impact of data protection on the LAN while also reducing CPU utilization on both client and server. For computers running Windows, some SAN configurations will allow specific SAN-devices to perform data movements directly to and from some tape devices, further reducing client and server CPU utilizations. Should a tape library be connected directly to a SAN, this software extension also allows multiple IBM Tivoli Storage Manager servers to share the library over this high-bandwidth data connection. Core Functions: LAN-free backup/restore SAN-connected tape library 1.3.3 IBM Tivoli Storage Manager for System Backup and Recovery IBM Tivoli Storage Manager for System Backup and Recovery (SysBack ) empowers you with a flexible backup method for your AIX systems to help protect your data and provide bare machine recovery capabilities. It offers a comprehensive system backup, restore, and reinstallation tool. SysBack is a simple-to-use, yet highly effective, tool. Any feature may be executed from either the AIX command line or by using the SMIT menu interface. Protect your most vital asset: your data A company s data is its lifeblood, regardless of company size, so data protection is vital. The loss of critical data from equipment failure or environmental factors can be a damaging or fatal event. These circumstances make strong backup and recovery systems imperative, but due to the high cost of personnel time, these services need to be as simple and automated as possible. Backup and recovery options via a simple, efficient interface SysBack enables you to choose from several types of backups, including full system (installation image), volume group, file system, file or directory, and raw logical volume. SysBack enables recovery of all or part of the system and is flexible enough to allow a system installation image from one system to be Chapter 1. Introduction to IBM Tivoli Storage Manager 11

installed onto another system with either identical or different hardware configurations (cloning). Backup and recovery options are performed via a simple System Management Interface Tool (SMIT) menu-driven interface or via a command line. Central management and automation tools SysBack provides utilities to create backup scripts and schedules for easier task automation. Furthermore, backup, list, and verify operations are quickly assessed via a completion status-tracking log. SysBack s pull client backups enable the administrator to manage backup operations centrally from a single server (remote or local). By combining all of these features, administrators are provided with a complete central management system. Network boot and install features in support of RS/6000 SP SysBack provides network boot features for administrators who choose not to boot from locally attached tape devices. Network boot options allow remote via SysBack functions (Classic Boot) or by utilizing existing Network Installation Management (NIM) resources (NIM Resource Boot). Using the SysBack NIM Resource Boot functionality, SysBack provides IBM RS/6000 SP system specific network boot and installation utilities for nodes. The SP boot and install utilities allow for smooth installation and cloning processes for nodes within the same, or between different, SP complexes. Offline Mirror Backup options The Offline Mirror Backup option splits specified AIX mirrors to enable SysBack access to inactive copies of data. This allows simultaneous user and system access to the active copies. 1.4 Data protection product family Using its Data Protection components, IBM Tivoli Storage Manager provides data protection for a wide variety of applications, databases, mail, and hardware, ensuring that data is safe and secure no matter where it is located or how it is stored. These products interface directly with the applications using their backup-certified utilities and interfaces, simplifying online backup and restore procedures. These products are now called: IBM Tivoli Storage Manager for Application Servers IBM Tivoli Storage Manager for Databases IBM Tivoli Storage Manager for Hardware IBM Tivoli Storage Manager for Mail IBM Tivoli Storage Manager for Enterprise Resource Planning 12 IBM Tivoli Storage Management Concepts

1.4.1 IBM Tivoli Storage Manager for Application Servers IBM Tivoli Storage Manager for Application Servers (formerly Tivoli Data Protection for WebSphere Application Servers) is a software module that works with IBM Tivoli Storage Manager to better protect the infrastructure and application data and improve the availability of WebSphere Application Servers. It works with the WebSphere Application Server software to provide an applet GUI to do reproducible, automated online backup of a WebSphere Application Server environment, including the WebSphere administration database (DB2 Universal Database), configuration data, and deployed application program files. Changes to the WebSphere environment, such as the addition of applications, are automatically detected and included in the data backup schedule to help keep backed-up data current. If data loss or data corruption occurs, IBM Tivoli Storage Manager for Application Servers can automatically restore the necessary data from offline storage to the WebSphere Application Server environment's online storage. IBM Tivoli Storage Manager for Application Servers provides the following features. Data Integrity The dynamic extraction of WebSphere Application Server configuration information ensures that all critical data is backed up. The dynamically generated XML file contains all required information to detect all WebSphere Application Servers in the backed-up domain, including the administration database and all WebSphere application data. WebSphere Application Server Online Backup/Restore This IBM Tivoli product provides the ability to back up all WebSphere Application Servers online (hot backup). This means that the WebSphere administration database and all WebSphere Application Servers are backed up during normal operation. No server shutdown is required. Therefore, this product supports 24x7 availability of the complete WebSphere environment. Furthermore, high backup/restore performance helps minimize availability impacts, even in disaster recovery scenarios. Fully automated backup process Tivoli Storage Manager for Application Servers ensures a fully automated backup process. The ability to configure scheduled backups together with the automatic detection of all linked WebSphere Application Servers eliminates the need to provide customer-maintained scripts. Manual interventions are no longer required because all actions are triggered from a central point of control. Chapter 1. Introduction to IBM Tivoli Storage Manager 13

LAN-free support IBM Tivoli Storage Manager for Application Servers has the capability of performing the backup and restore directly through the SAN, instead of going through the LAN. In a SAN environment, this product s data movers can be directly connected over the SAN to the respective storage devices. In this scenario, the data is transferred over the SAN, whereas the metadata flows over the LAN to the Tivoli Storage Manager server. The major benefits of this option include: Offloading the LAN from network traffic by sending the data directly through the SAN Using a centralized Tivoli Storage Manager server, while keeping the read/write load on WebSphere Application Servers 1.4.2 IBM Tivoli Storage Manager for Databases IBM Tivoli Storage Manager for Databases is a software module that works with IBM Tivoli Storage Manager to protect a wide range of application data via the protection of the underlying database management systems holding that data. IBM Tivoli Storage Manager for Databases exploits the backup-certified utilities and interfaces provided for Oracle, Microsoft SQL Server, and Informix. In conjunction with Tivoli Storage Manager, this module automates data protection tasks and allows database servers to continue running their primary applications while they back up and restore data to and from offline storage. (This same functionality is included in the IBM DB2 Universal Database package, enabling it to work directly with Tivoli Storage Manager without the need to buy any additional modules.) Regardless of which brand of database is used, IBM Tivoli Storage Manager for Databases allows the centralized and automated data protection capabilities of Tivoli Storage Manager to be applied to up-and-running database servers. Data Protection for Informix Informix-certified Data Protection for Informix provides centralized, online, incremental backup capabilities for restoring and managing Informix server databases and logical logs. It provides both parallel backup and restore and automatic backup of logical logs via the Informix ON-Bar utility. ON-Bar uses the X/Open Backup Services Application Program Interface (XBSA) to communicate with the Tivoli Storage Manager, where backups are stored. Visit http://www-3.ibm.com/software/data/informix/ids/ for more information about Informix Dynamic server. 14 IBM Tivoli Storage Management Concepts

Data Protection for Oracle Data Protection for Oracle applies the centralized, online, incremental, and backup capabilities, as well as the automated storage management function, of IBM Tivoli Storage Manager to Oracle8, Oracle8i, and Oracle9i databases using the Oracle Recovery Manager (RMAN). The data may be stored on a wide variety of storage devices. RMAN functions and features include: Full or table space backup of a database while it is online or offline Full database restore while it is online or offline Table space restore while database is offline Backups of archive log files Block-level incremental backup of changed database pages Ability to use the duplex copy feature of RMAN 2.0, making it possible to send a backup to two separate storage tapes simultaneously Optimized performance with tunable multi-buffer caching during backups Synchronization utility to reconcile inventory between the IBM Tivoli Storage Manager server and the Oracle catalog Data Protection for Microsoft SQL Server Data Protection for Microsoft SQL Server enables online backups of the SQL databases to Tivoli Storage Manager storage. Data Protection for SQL features: Full and transaction log backup support provided Maintain multiple versions of your SQL database and transaction logs GUI and command line interfaces to give you point-and-click ease Support for IBM Tivoli Storage Manager s automatic expiration and version control by policy, which frees users from having to explicitly delete most backup objects in the IBM Tivoli Storage Manager server Support for Microsoft SQL Server 7.0 and SQL Server 2000 Microsoft Cluster Server (MSCS) support for failover Differential backup/restore of SQL databases Backup/restore of individual file groups and individual database files SQL Data Striping for high performance Restore to a standby SQL Server Restore to a different SQL Server or to different physical file names Chapter 1. Introduction to IBM Tivoli Storage Manager 15

1.4.3 IBM Tivoli Storage Manager for Hardware IBM Tivoli Storage Manager for Hardware improves the data protection of your business-critical databases and ERP applications that require 24x7x365 availability. This software module helps IBM Tivoli Storage Manager and its other data protection modules to perform high-efficiency data backups and archives of your most business-critical applications while eliminating nearly all performance impact on database or ERP servers. This elimination of server performance impact is accomplished by coupling the FlashCopy function of IBM Enterprise Storage Server (ESS) with IBM Tivoli Storage Manager and its database protection capabilities for DB2, Oracle, and SAP R/3 databases. Similarly, this module couples EMC Symmetrix TimeFinder with IBM Tivoli Storage Manager and its data protection capabilities for Oracle and SAP R/3 databases. The IBM Tivoli Storage Manager for Hardware module works with and requires both IBM Tivoli Storage Manager (or IBM Tivoli Storage Manager Extended Edition) and either of the other data protection modules IBM Tivoli Storage Manager for Databases or IBM Tivoli Storage Manager for ERP to provide a near zero-impact data backup and archive process. 1.4.4 IBM Tivoli Storage Manager for Mail IBM Tivoli Storage Manager for Mail is a software module for Tivoli Storage Manager that automates the data protection of e-mail servers running either Lotus Domino or Microsoft Exchange. This module utilizes the application program interfaces (APIs) provided by e-mail application vendors to perform online hot backups without shutting down the e-mail server and improve data-restore performance. As a result, it can help protect the growing amount of new and changing data that should be securely backed up to help maintain 24x7x365 application availability. For Lotus Domino databases, this module exploits Domino s transaction logging feature, enabling the capture of just the database changes for logged databases. Thus, full database backups are not required as frequently as in previous Domino releases. For Microsoft Exchange, IBM Tivoli Storage Manager for Mail supports both Microsoft Exchange Server 5.5 and Microsoft Exchange Server 2000. It uses the backup APIs provided by Microsoft to create a copy of the Exchange server storage group along with the associated transaction logs. The module can produce the different types of backups specified by Microsoft backup APIs: Full Backups, Incremental Backups, Differential Backups, Copy Backups and Database Copy Backups. Whether used with Microsoft Exchange or Lotus Domino, IBM Tivoli Storage Manager for Mail enables the continued 24x7x365 operation of e-mail servers while performing data backups and restores. 16 IBM Tivoli Storage Management Concepts

Data Protection for Lotus Domino Data Protection for Lotus Domino, a successor to Tivoli Data Protection for Lotus Notes, takes advantage of significant changes in the Lotus Notes R5 server architecture. These include transaction logging for interactions with Notes databases as well as a new application program interface (API) for backup and recovery of Notes databases. Data Protection for Lotus Domino helps protect and manage Lotus Domino Release 5.x Server data by making it easy to: Implement centralized, online, incremental backup of Lotus Domino databases Maintain multiple versions of Domino databases Archive Domino transaction log files, when archival logging is in effect Restore backup versions of a Domino database and apply changes made since the backup from the transaction log Restore Domino databases to a specific point in time Recover to same or different Domino server Expire database backups automatically based on version limit and retention period Expire archived transaction logs when no longer needed Obtain online context-sensitive, task, and conceptual help View Data Protection for Domino online documentation Automate scheduled backups Recover one or more archived transaction logs independent of a database recovery Recover from the loss of the transaction log Archive the currently filling transaction log file Supports Domino Individual Mailbox Restore Data Protection for Lotus Domino provides two types of database backup, incremental and selective, and a log archive function. Incremental backup provides a conditional backup function that creates a full online backup of Domino databases when necessary. The specific conditions that determine when a new backup is necessary vary depending on whether the database is logged or not. Selective backup unconditionally backs up the specified databases, unless they are excluded from backup through exclude statements. When archival logging is in effect, changes to logged databases can be captured between full backups by archiving the transaction log. Chapter 1. Introduction to IBM Tivoli Storage Manager 17

Data Protection for Microsoft Exchange Server Data Protection for Microsoft Exchange Server provides complete integration with Microsoft Exchange APIs by offering: Centralized online backups (full, copy, incremental, and differential) of Exchange Directory and Information Stores to Tivoli Storage Manager server storage Automatic expiration and version control by policy Failover for Microsoft Cluster Server (MSCS) Parallel backup sessions for high performance Automated transaction log file management LAN-free backup Windows GUI Data Protection for Exchange Server supports Microsoft Exchange Individual Mailbox Restore in combination with the Tivoli Storage Manager backup-archive client and the Microsoft ExMerge tool. 1.4.5 IBM Tivoli Storage Manager for Enterprise Resource Planning IBM Tivoli Storage Manager for Enterprise Resource Planning (ERP) is a software module that works with IBM Tivoli Storage Manager to better protect infrastructure and application data and improve the availability of SAP R/3 Servers. Specifically designed and optimized for the SAP R/3 environment, Tivoli Storage Manager for ERP provides automated data protection, reduces the CPU performance impact of data backups and restores on the R/3 server, and greatly reduces administrator workload necessary to meet data protection requirements. Tivoli Storage Manager for ERP builds on the SAP database, a set of database administration functions integrated with R/3 for database control and administration. The Tivoli Storage Manager for ERP software module allows multiple R/3 servers to utilize a single Tivoli Storage Manager server to automatically manage the backup of R/3 data. As the intelligent interface to the R/3 database, Tivoli Storage Manager for ERP is SAP-certified in heterogeneous environments, supporting large-volume data backups, data recovery, data cloning, and disaster recovery of multiple SAP R/3 servers. Tivoli Storage Manager for ERP offers the following features: It can handle large amounts of data reliably to minimize downtimes and operational cost, and it flexibly adapts to changing requirements in a dynamic system infrastructure. 18 IBM Tivoli Storage Management Concepts

Unlike other offerings that merely provide an interface to a generic storage management tool, Tivoli Storage Manager for ERP is specifically designed and optimized for the R/3 environment, delivering business value by focusing on automated operation, built-in productivity aids, optimum performance and investment protection. Multiple management classes provide a library structure for sets of device parameters, which means allowing for the device parameters can be called by class names. Multiple path/session support provides one path or session per tape device, thus maximizing backup and restore performance. Multiple server operations enable multiple IBM Tivoli Storage Manager servers to be used in parallel for backup and restore, thus eliminating capacity bottlenecks. Multiplexing merges multiple data streams into one data stream, thereby exploiting the full write bandwidth of storage devices and minimizing backup window times. Multiple log files store log files in two management classes, thus providing additional security through redundancy of log files. SAN support and integration allows the use of SAN fiber channels with high bandwidth, thus freeing up the LAN. Centralized management with administration assistant enables policies and processes to be managed from a central point, thus achieving consistent backup and recovery of critical data, even in lights out operations. Policy-controlled file migration across storage hierarchies uses the most cost-effective storage media based on retention periods and resource usage, thus decreasing the cost of ownership. Support for Flash Copy and split mirror technology creates an additional disk for backup purposes, leaving R/3 applications and performance unaffected during the backup. Standby servers can be switched to within seconds during a failure, thus achieving 100 percent availability of R/3 applications. Adaptive file sequencing sorts and sequences files to be backed up according to the overall situation of the path and session load, thereby optimizing resource usage and decreasing total backup and restore times. SNMP traps enable communication with other applications, making control of the data management system available for other applications. Chapter 1. Introduction to IBM Tivoli Storage Manager 19

1.5 IBM Tivoli Storage Manager supported platforms IBM Tivoli Storage Manager server and client software is available on many different operating system platforms and can exploit different communication protocols. IBM Tivoli Storage Manager, Version 5.2 servers These are the supported platforms for IBM Tivoli Storage Manager, Version 5.2 severs: IBM AIX 5L Version 5.1 or later (32-bit or 64-bit), AIX 5.2 (32-bit and 64-bit) HP -UX 11.0 (32-bit and 64-bit) or 11.11 (11i Version 1.0) (32-bit and 64-bit) Windows Server 2003 Standard Edition - 32-bit, Datacenter Edition (32-bit and 64-bit), Enterprise Edition (32-bit and 64-bit) Windows 2000 Professional, Server, Advanced Server, Datacenter Server Sun Solaris 8 (64-bit), and Solaris 9 (64-bit) OS/400 PASE V5R1 and V5R2 OS/390 z/os V1R1 or later, V2R10 or later Linux on pseries : SuSE Enterprise Server 8 Linux on xseries : Red Hat Linux Advanced Server 2.1 or 2.4.9-e.10 enterprise SMP, SuSE Enterprise Server 7 or SuSE Enterprise Server 8/United Linux 1.0 Linux on zseries : SuSE Linux Enterprise Server 8 You can find more detailed server requirements at: http://www-1.ibm.com/support/search.wss?rs=663&tc=ssgsg7&atrn=keywords& atrv=serverrequirements IBM Tivoli Storage Manager, Version 5.2 clients These are the supported platforms for IBM Tivoli Storage Manager, Version 5.2 clients: AIX 5L versions 5.1 and 5.2 (32-bit and 64-bit) HP-UX 11.0 and 11i ( 32-bit and 64-bit) Linux x86 2.4 kernel (Red Hat 7.2, 7.3, 8, and Advanced Server 2.1; SuSE 7.3, 8.0, 8.1, and SLES 7 and 8; TurboLinux 7.5, and 8.0) Linux for pseries 2.4 kernel (SuSE 8.0) Linux/390 and zseries 2.4 kernel (SuSE Linux Enterprise Server 7 and 8) Macintosh OS X(10).x 20 IBM Tivoli Storage Management Concepts

Novell NetWare 5.1 and 6 OS/390, zseries USS (S/390 V2R10 with SMP/E, z/os V1R1, V1R2, V1R3, and V1R4) OS/400 5.1 or 5.2 API client SGI IRIX UNIX, Release 6.5 with EFS or XFS File Systems (with V5.1 functional client) Sun Solaris, 7, 8, and 9 (32-bit and 64-bit) Tru64 UNIX, Version 5.1A (with V5.1 functional client) Windows XP (32-bit and 64-bit), Windows Server 2003 (32-bit or 64-bit), Windows 2000 Professional, Server, Advanced Server, and Datacenter Server Windows NT 4.0 SP5 and SP6a (with V5.1 functional client) Novell NetWare 5.1 and 6 You can find more detailed server requirements at: http://www-1.ibm.com/support/search.wss?rs=663&tc=ssgsg7&atrn=keywords& atrv=clientrequirements V5.1 clients not migrated that can be used with V5.2 servers These are the V5.1 clients not migrated that can be used with V5.2 servers: AIX 4.3.3 Solaris 2.6 Macintosh 9 Windows IBM Tivoli Storage Manager, Version 5.2 API These platforms support the IBM Tivoli Storage ManagerV 5.2 API: All supported IBM Tivoli Storage Manager clients except Macintosh IBM Tivoli Storage Manager supported devices These are the devices supported by IBM Tivoli Storage Manager. Follow the Web links for the most recent updates. AIX, HP, SUN, and Windows http://www-3.ibm.com/software/sysmgmt/products/support/ibm_tsm_suppo rted_devices_for_aixhpsunwin.html iseries http://www-3.ibm.com/software/sysmgmt/products/support/ibm_tsm_suppo rted_devices_for_iseries.html Chapter 1. Introduction to IBM Tivoli Storage Manager 21

Linux http://www-3.ibm.com/software/sysmgmt/products/support/ibm_tsm_suppo rted_devices_for_linux.html IBM Tivoli Storage Manager, complementary products, and add-on products continuously evolve to better support your ever-changing environment. For more information and currently supported platforms and operating systems, visit: http://www-3.ibm.com/software/tivoli/products/storage-mgr/platforms.html 1.6 Conclusion As data storage management grows more sophisticated, it also becomes more complicated. The key to properly managing a complex storage environment is to approach it strategically. This book discusses a number of ways to begin this approach that can make storage management easier, more efficient, and more effective. Further, this book discusses several benefits that come from adopting a strategic storage management solution. Once implemented, this solution gives IT managers the best chance for increasing the effectiveness and value of their business. More information can be found at: http://www-3.ibm.com/software/tivoli/ Next we look at business practices and the requirements for backup and recovery in your environment. 22 IBM Tivoli Storage Management Concepts

2 Chapter 2. Business requirements In this chapter we discuss business requirements and the need to define them for better understanding of your total storage management solution design. This chapter gives you a view of the impact your solution will or will not have on your business. Over time, as storage systems have evolved and customers have experienced certain growth in their business, a common thread arises regardless of the industry. These growing problems have been grouped into four categories. Regardless of the customer, each business will at one time or another experience one, several, or all of these problems. This chapter is designed to guide you in these critical areas: Storage consolidation Data sharing Data protection Disaster recovery Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 23

2.1 Storage consolidation In an environment comprised of distributed servers and fragmented storage, storage capacity is often underutilized, and reallocating or reconfiguring storage resources often causes both disruptions and downtime. How do you improve asset utilization, lower operating costs by centralizing capital and people, and automatically reallocate storage resources as your business needs dictate? IBM Storage Network Solutions address consolidation needs with solutions for all sizes of enterprises, based on the broad range of NAS, NAS Gateway, iscsi and SAN products and services, and IBM Tivoli Storage Management Software. IBM Storage Network Solutions offer the following storage-consolidation benefits: Multiple storage systems appear as one pool of storage resources, representing a warehouse of capacity. Enable you to reallocate storage resources as the business requires. Improve asset utilization and lower operating costs by centralizing capital and operating staff. Enable centralized data and application management via IBM Tivoli Storage Manager and other storage management software. 2.2 Data sharing In today s e-commerce-driven business climate, information is stockpiling at an unprecedented pace. The challenge is to make this stored information available on demand to anyone in an enterprise who needs it. How do you increase network response time, improve hardware and software utilization, reduce data duplication, and improve information availability and data currency? IBM Storage Network Solutions offer Tivoli SANergy, which enables sharing of SAN-based storage arrays, file systems, and files across multiple systems simultaneously. Storage Network Solutions offer the following data-sharing benefits: Enable any-to-any access with load balancing. Provide key business value in single view of data. Increase the overall reliability, availability, and implementation flexibility of a SAN environment. Enable sharing of storage, file systems, and files to help reduce the total amount of storage, the cost of connected computers, and the time and personnel required to administer and maintain storage. Tivoli SANergy broadens data availability protection to any application. 24 IBM Tivoli Storage Management Concepts

2.3 Data protection As the value of strategic information rises, so does the value of fast, reliable backup. How do you free up server cycles, offload your data network, provide mission-critical backup/restore, and better utilize expensive storage resources? IBM meets critical data protection requirements with complete IBM Storage Network Solutions for all sizes of enterprises, based on the broad range of IBM NAS, NAS Gateway, iscsi and SAN products and services, and IBM Tivoli Storage Management Software. Storage Network Solutions offer the following data-protection benefits: A dedicated data network with a possible 5-20 times reduction in backup time LAN-free backup to reduce LAN traffic for increased performance Fewer tape libraries for backup than traditional storage, to ultimately eliminate CPU cycles from the process as serverless backup options become prevalent A reduction in management costs over time as you consolidate distributed backup islands and utilize tape resources and to centrally manage all backup and restore processes A reduction in network IP traffic Faster realization of SAN benefits as these implementation and operation services help customers increase speed to deployment and ease managing the environment 2.4 Disaster recovery Losing access to a key division or enterprise data repository because of a disaster can cost a business in both the short and long terms. When strategic information drives success and business is conducted 24x7x365, any downtime can be costly. To design a disaster tolerance-strategy with no single point of failure that can easily and flexibly accommodate an evolving business, using IBM Storage Network Solutions presents a full range of hardware, software, and services offerings to address disaster-tolerance needs. Storage Network Solutions offer the following disaster-recovery benefits: Elimination of single-point-of-data failure to help ensure data integrity Enabling clustered servers to be in different locations Mirrored-disk configurations and elimination of the need for shared disks Proactive monitoring of server uptime Reduction of total cost of ownership through clustered server ownership Chapter 2. Business requirements 25

Scaling from departmental-level fault tolerance utilizing clustering techniques to highly robust distance clustering with remote mirroring Priority restoration of critical information for a faster return to business as usual Strategic outsourcing offerings, such as Managed Storage Services, that provide more choices for storing and recovering data. 26 IBM Tivoli Storage Management Concepts

3 Chapter 3. Architectural concepts This chapter gives a high-level technical introduction to IBM Tivoli Storage Manager. It positions IBM Tivoli Storage Manager within the total IBM Tivoli Storage Management Solution, provides an overview of its architecture, the base concepts, the interfaces, and supported environments, and shows IBM Tivoli Storage Manager interaction with other products of the IBM Tivoli Storage Management product set. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 27

3.1 IBM Tivoli Storage Management Enterprise Solution Data has become the key asset of companies and one of the most important competitive differentiating factors. Temporary inaccessibility or, worse, the complete loss of data has a huge financial impact and can even drive companies out of business. The inability to manage data can limit a company s ability to grow. Storing, protecting, and managing data growth has become one of the major challenges of today s businesses. Based on this requirement, IBM defined its Information Integrity Initiative: The IBM Tivoli Storage Management Initiative provides an end-to-end software management solution with proven methodologies to help customers link storage management policies with key business practices, to enable them to use information to drive business, rather than simply support it. Major solution components of IBM Tivoli Storage Management are: Centralized, comprehensive management Broad hardware support Highly scalable Intelligent data movement Intelligent data storage Policy-based automation Enterprise protection Application protection SAN management Figure 3-1 on page 29 shows the structure of the IBM Tivoli Storage Manager Solution and how it fits into the IBM Tivoli Storage Management Enterprise Solution. 28 IBM Tivoli Storage Management Concepts

Data Protection and Storage Administration Backup and manage application-specific data IBM Tivoli Data Protection for LAN Policy-Based Data, Storage and Disaster Recovery Management Automatically prepare disaster recovery plan and scripts daily IBM Tivoli Disaster Recovery Manager IBM Tivoli Storage Manager Progressive backups Automated collocation and tape reclamation IBM Tivoli SANergy IBM Tivoli SAN Manager IBM Tivoli System Backup and Recovery IBM Tivoli Space Manager Transparent migration of inactive files to the IBM Tivoli Storage Manager Server storage repository LAN-free Backup SAN Figure 3-1 IBM Tivoli Storage Management Enterprise Solution IBM Tivoli Storage Manager was designed as an enterprise-wide storage management application that focuses its resources on recovery. Four key architectural features unique to IBM Tivoli Storage Manager make it the most efficient and intelligent distributed storage management solution on the market: Its database A progressive backup methodology Collocation Reclamation Enterprise protection implements an enterprise-wide solution for data protection, disaster recovery, space management,and record retention. It covers all types of heterogeneous system platforms from mobile systems to large-scale enterprise servers, and it supports all types of storage resources (locally attached as well as network- or SAN-attached). Flexible storage management policies support business needs and powerful automation features by eliminating labor and cost-intensive manual storage management tasks. Chapter 3. Architectural concepts 29

Strategic business applications are typically complex collections of interdependent components from both commercial and proprietary software that span desktop, distributed, and mainframe computing environments. Application protection is concerned with data availability, performance, and recoverability, and it integrates application data management into enterprise data protection. SAN is an architecture that puts storage on a separate dedicated network to enable businesses of all sizes to share data, regardless of operating systems, as a significant step toward coping with the explosive growth of information in the e-business age. SAN management is concerned with the efficient management of the Fibre Channel based SAN environment. Physical connectivity mapping, switch zoning, performance monitoring, error monitoring, and predictive capacity planning are among the most important features. Workgroup protection provides a reliable and easy-to-use backup, recovery, and disaster-recovery solution for stand-alone mobile, desktop, and small-server systems. It is targeted to small and medium businesses (under 800 nodes) and any enterprise with large numbers of remote, stand-alone servers. Combined with IBM Tivoli Storage Management Enterprise Solution, IBM Tivoli Storage Management becomes an integrated management suite that transforms Information Technology into a strategic business resource. 3.2 IBM Tivoli Storage Manager architecture IBM Tivoli Storage Manager is implemented as a client-server software application consisting of an IBM Tivoli Storage Manager server software component, IBM Tivoli Storage Manager Backup-Archive client, and other complementary IBM Tivoli and vendor software products. 3.2.1 Overview IBM Tivoli Storage Manager server software, illustrated in Figure 3-2 on page 31, builds the data management backbone by: Managing the storage hardware Providing a secure environment Providing automation, reporting, and monitoring functions Implementing the storage management policies Storing all object inventory information in the IBM Tivoli Storage Manager database 30 IBM Tivoli Storage Management Concepts

The IBM Tivoli Storage Manager client software and complementary products implement data management functions such as data backup and recovery, archival, hierarchical space management, and disaster recovery. IBM Tivoli Storage Manager Data Management Policies Relational Database Storage pools Policy Placement and Recovery SAN SAN Data Storage Hierarchy Enterprise Web Administrator LAN-Free RLog IBM Tivoli Storage Manager Server SAN SAN WAN WAN Interfaces: Command line GUI WEB Batch API LAN-SAN Clients Mobile Clients Business Application Servers Figure 3-2 IBM Tivoli Storage Manager server LAN WAN SAN The client software can run on different systems, including laptop computers, PCs, workstations, and server systems. The client and server software can also be installed on the same system for a local backup solution or to implement LAN-free backup solutions exploiting SAN infrastructure. It is also possible to define server hierarchies or multiple peer-to-peer servers in order to provide a multi-layer storage management solution or an electronic vaulting solution. 3.2.2 IBM Tivoli Storage Manager server One of the principal architectural components of the IBM Tivoli Storage Manager server software is its built-in relational database. The storage manager database was especially designed for the task of managing data, and it implements zero-touch administration. All policy information, logging, authentication and security, media management, and object inventory is managed through this database. Most of the fields are externalized through IBM Tivoli Storage Manager high-level administration commands, SQL SELECT statements, or, for reporting purposes, using an ODBC driver. Chapter 3. Architectural concepts 31

Managed datais stored in the storage repository. The storage repository is designed from any combination of disk, optical, tape, or robotic storage devices, which are locally connected to the server system or accessible through a SAN. Exploiting the SAN technology, the server software has features implemented to dynamically share SAN-connected automated tape library systems among multiple IBM Tivoli Storage Manager server systems. The server software provides built-in drivers for more than 390 different device types from every major manufacturer. Within the storage repository the devices can operate as stand-alone or can be linked together to form one or more storage hierarchies. The storage hierarchy is not limited in the number of levels, and it can span multiple servers using so-called virtual volumes. IBM Tivoli Storage Manager backup-archive client Data management functions are implemented using IBM Tivoli Storage Manager client software and complementary IBM Tivoli and non-tivoli products, which work together with the IBM Tivoli Storage Manager server backbone product. The IBM Tivoli Storage Manager backup-archive client, included with the server program, provides the operational backup and archival function. All backup-archive clients are implemented as multi-session clients, which means that they are able to exploit the multithreading capabilities of modern operating systems. This enables the running of backup and archive operations in parallel to maximize the throughput to the server system. Depending on the client platform, the backup-archive client may provide a graphical, command line, or Web user interface. Many platforms provide all three interfaces. The command line interface is useful for experienced users, and it allows generation of backup or restore scripts for scheduled execution. The graphical interface is designed for end-user ease of use for ad hoc backups and restores. The Web client is especially useful for those clients, such as NetWare, where no native GUI is available, or for performing remote backup/restore operations, such as in a help desk environment. Backup-archive client user interfaces The IBM Tivoli Storage Manager backup-archive client provides separate but consistent user interfaces to access and execute commands. The following figures show the common GUI interface (Figure 3-3 on page 33), the command line interface, and the Web client interface. 32 IBM Tivoli Storage Management Concepts

Figure 3-3 IBM Tivoli Storage Manager client GUI interface The backup-archive client user interface can also be command-line, as shown in Figure 3-4. Figure 3-4 IBM Tivoli Storage Manager client command line interface (Windows) IBM Tivoli Storage Manager also provides a Web browser client interface, shown in Figure 3-5 on page 34, that can be used remotely or locally for access to IBM Tivoli Storage Manager backup-archive client. Chapter 3. Architectural concepts 33

Figure 3-5 IBM Tivoli Storage Manager client interface Web client Some UNIX-based clients use a new plug-in architecture to implement an image backup feature for raw device backup. This enables you to back up and recover data that is not stored in file systems or supported database applications. It also provides an additional method to make point-in-time backups of entire file systems as single objects and recover them in conjunction with backed-up data by using the progressive backup methodology. 3.2.3 IBM Tivoli Storage Manager administration For the central administration of one or more IBM Tivoli Storage Manager instances as well as the whole data management environment, IBM Tivoli Storage Manager provides command line or Java -based administration interfaces, also called administration clients. 34 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Manager administration interfaces Using the unique enterprise administration feature it is possible to configure, monitor, and manage all server and client instances from one administrative interface, known as the enterprise console. It includes: Enterprise configuration Administrative command routing Central event logging functions Figure 3-6 IBM Tivoli Storage Manager administration client Web interface Figure 3-7 shows the IBM Tivoli Storage Manager command line administrative interface. Figure 3-7 IBM Tivoli Storage Manager command line administrative interface The enterprise configuration enables server configurations to be defined centrally by an administrator and then propagated to other servers. This significantly simplifies the configuration and management of multiple IBM Tivoli Storage Manager servers in an enterprise. Chapter 3. Architectural concepts 35

Administrative command routing enables administrators to issue commands from one server and route them to other target servers. The commands are executed on the target servers, and the output is returned and formatted on the server where the command was issued. In an enterprise environment with multiple IBM Tivoli Storage Manager servers, client and server events can be logged to a central management server through server-to-server communications, thereby enabling centralized event management and automation. 3.2.4 IBM Tivoli Storage Manager externalized interfaces IBM Tivoli Storage Manager provides a data management application programming interface (API), which can be used to implement application clients to integrate popular business applications, such as databases or groupware applications, into the IBM Tivoli Storage Management solution. The API is also published to enable customers or vendors to implement specialist clients for special data management needs or non-standard computing environments. In general we distinguish between Data Protection for application software products and the API exploitation through vendor applications. Data Protection for applications are separate program products delivered by IBM Tivoli Storage Manager to connect business applications to the IBM Tivoli Storage Manager data management API. Such applications (for example, Oracle, Lotus Notes and Domino, Microsoft Exchange, and Microsoft SQL Server) have their own storage management interfaces that are used to interface to IBM Tivoli Storage Manager. On the other hand, many vendor applications also exploit the IBM Tivoli Storage Manager data management API by integrating it directly into their software product to implement new data management functions, or to provide backup and archival functionality on additional system platforms. Some examples are IBM CommonStore for R/3 data archival, IBM BRMS/400 to provide an AS/400 backup solution, and ETI-NET Backhome for TSM Client (Backhome) for Tandem Guardian for data backup and recovery. IBM Tivoli Storage Manager offers multiple interfaces for event logging, reporting, and monitoring the data management environment. In general, activities of the IBM Tivoli Storage Manager server and client are logged into the server database and can be sent for reporting and monitoring purposes to external event receivers using event filter mechanism. Potential event receivers include IBM Tivoli Enterprise framework, SNMP-based systems management software packages, the Windows NT event log, and user-written applications. 36 IBM Tivoli Storage Management Concepts

To integrate IBM Tivoli Storage Manager storage management with external library management applications, IBM Tivoli Storage Manager offers an external library manager interface. Using this interface it is possible to integrate the IBM Tivoli Storage Manager server into third-party storage management environments. 3.2.5 Basic concepts This section gives a high-level introduction to the basic data and storage management paradigms used by IBM Tivoli Storage Manager to implement its functionality. We will cover data protection (backup), record retention (archival), storage management, policy, and security. Backup and archival concepts Backup, in IBM Tivoli Storage Manager terms, means creating an additional copy of a data object to be used for recovery. A data object can be a file or a user-defined data object such as a database table. The backup version of this data object is stored separately in the IBM Tivoli Storage Manager server storage repository. Potentially, you can make several backup versions of the data, each version at a different point in time. These versions are closely tied together and related to the original object as a group of backups. If the original data object is corrupted or lost on the client system, restore is the process of sending a backup version of the data from the server back to the client. The most current version of the data is normally restored, but you can choose to restore from any of the existing backup versions. The number of backup versions is controlled by server definitions. Old backup versions may be automatically deleted as new versions are created. You may also delete them after a certain period of time. For file-level-based backup the main difference from many other backup applications is that IBM Tivoli Storage Manager uses the progressive backup methodology. As shown in Figure 3-8 on page 38, after the first necessarily full backup, IBM Tivoli Storage Manager then operates with incremental backups only. In consequence, only those files that have changed since the last backup will be backed up. Chapter 3. Architectural concepts 37

Full+Incremental Backup Full+Differential Backup Progressive Backup Methodology Backup cycle Full Backup #1 Full Backup #1 Base Backup #1 Incremental #2 Incremental #2 Incremental #1 #2 Incremental #3 Differential #3 Incremental #1 #2 Incremental #4 Differential #4 Incremental #1 #2 Data and tape consolidation New full backup #7* New full backup #7* Point-in-time** restoration of all data Server internal tape reorganization #1 #2 Full backup & 3 incrementals #1... #4 Full backup & 1 differential #1 #4 Point-in-time data only #1 #2 * assuming 5 incrementals between full backups, ** after the 3rd incremental Figure 3-8 Progressive backup methodology vs. other backup schemes The reorganization of the physical storage media to store each client s data physically together on a small number of media in order to provide faster access in the case of a complete system recovery is done transparent to the client and is completely automated on the server using data metainformation stored in the server database. IBM Tivoli Storage Manager s file-level progressive backup methodology, in comparison with other methods such as Full+Incremental or Full+Differential backup schemes, prevents unnecessary backups of unchanged data to reduce and consolidate the recovery tape-set. It also offers a more efficient use of storage resources by not storing redundant data and a faster recovery by not restoring multiple versions of the same file. At any point in time IBM Tivoli Storage Manager enables the creation of a complete set of client files (backup set) on the server system using the most 38 IBM Tivoli Storage Management Concepts

recent backup versions stored in the server storage repository. These backup sets can be used to retain a snapshot of all client files for a longer period of time (Instant Archive) or for LAN-free recovery of a client system by copying this backup set onto portable media and restoring them locally (Rapid Recovery). File archive means creating a copy of a file as a separate object in the storage repository to be retained for a specific period of time. Typically you would use this function to create an additional copy of data to be saved for historical purposes. Vital records (data that must be kept for legal or other business reasons) are likely candidates for the archive process. You can specify to delete the original copy of the data on the source system once the archive copy is created on the server. Therefore, you can use archive to make additional space available on the IBM Tivoli Storage Manager client system. However, archive should not be thought of as a complete space management function, because transparent automatic recall is not available. You can access archived data by using retrieve to return it to the IBM Tivoli Storage Manager client, if the data is needed at some future time. To locate the archived data within the storage repository, IBM Tivoli Storage Manager allows you to add a description to the data and to form archive packages of related files. You can then use this description to search the server database for matching packages to determine which data to retrieve. Therefore, the difference between backup and archive is that backup creates and controls multiple backup versions that are directly attached to the original file; whereas archive creates an additional file that is normally kept for a specific period of time, as in the case of vital records. 3.2.6 Storage and device concepts All IBM Tivoli Storage Manager-managed client data are stored in the IBM Tivoli Storage Manager storage repository, which can consist of different storage devices, such as disk, tape, or optical devices, and is controlled by the IBM Tivoli Storage Manager server. To do this, IBM Tivoli Storage Manager uses its own model of storage to view, classify, and control these storage devices and to implement its storage management functionality. (See Figure 3-9 on page 40.) Storage hierarchy The main difference between the storage management approach of IBM Tivoli Storage Manager and other commonly used systems is that IBM Tivoli Storage Manager concentrates on managing data objects instead of managing and controlling backup tapes. Data objects can be files, directories or raw logical volumes that are backed up from the client systems; they can be objects such as tables or records from database applications, or simply a block of data that a client system wants to store on the server storage. Chapter 3. Architectural concepts 39

Client System Storage Repository Storage Pool Volume WAN, LAN, SAN Device Class Storage Pool Storage Pool Data Object Server System Migrate & colocate Relocate Storage Pool Copy Storage Hicharchy Device Class Figure 3-9 IBM Tivoli Storage Manager storage management concepts To store these data objects on storage devices and to implement storage management functions, IBM Tivoli Storage Manager has defined some logical entities to classify the available storage resources. Most important is the logical entity called a storage pool. A storage pool describes a storage resource for one single type of media; for example, a disk partition or a set of tape cartridges. Storage pools are the place where data objects are stored. A storage pool is built up from one or more storage pool volumes. For example, in the case of a tape storage pool, this would be a single physical tape cartridge. To describe how IBM Tivoli Storage Manager can access those physical volumes to place the data objects on them, IBM Tivoli Storage Manager has another logical entity called a device class. A device class is connected to a storage pool, and it specifies how volumes of this storage pool can be accessed. IBM Tivoli Storage Manager organizes storage pools in one or more hierarchical structures. This storage hierarchy can span multiple server instances and is used to implement management functions to migrate data objects automatically completely transparent to the client from one storage hierarchy level to another; or, in other words, from one storage device to another. This function 40 IBM Tivoli Storage Management Concepts

may be used, for example, to cache backup data (for performance reasons) onto an IBM Tivoli Storage Manager server disk space before moving the data to tape cartridges. The actual location of all data objects is automatically tracked within the server database. Another important storage management function implemented within the IBM Tivoli Storage Manager server is the ability to copy data objects asynchronously and to store them in different storage pools or on different storage devices, either locally at the same server system or remotely on another server system. It is especially important for disaster recovery reasons to have a second copy of data available somewhere in a secure place in case any storage media or the whole storage repository is lost. This function is fully transparent to the client and can be performed automatically within the IBM Tivoli Storage Manager server. Collocation IBM Tivoli Storage Manager has implemented additional storage management functions for moving data objects from one storage volume to another. As discussed in the previous section, IBM Tivoli Storage Manager uses the progressive backup methodology to back up files to the IBM Tivoli Storage Manager storage repository. The reorganization of the data and storage media for fast recovery happens completely within the server. For this purpose, IBM Tivoli Storage Manager has implemented functions to relocate data objects from one volume to another and to collocate data objects that belong together, either at the client system level or at the data group level. The collocation function is designed to optimize the performance of the storage pool for multiple clients. It gives administrators a way to store all of the files belonging to a specific client on a minimal number of sequential access volumes (usually tapes). The collocation option generally would be used in situations where the client requires a fully optimized recovery time. Collocation also makes it possible to avoid conflicts in the restore process, such as when a single tape volume would have to be mounted to restore data for two different clients. When the collocation feature is used, each client s restore can be completed simultaneously and independently. Figure 3-10 on page 42 illustrates the basic operation of the collocation option as backup data is migrated from one storage pool to the next. Chapter 3. Architectural concepts 41

Storage Pool - Collocation Disk pool B A C B C B A A C B Hi Threshold Lo Threshold Migration Migration Tape pool Client A Client B Client C A A A B B B C C C B A B C Client A Client B Client C Figure 3-10 Storage pool collocation Tape reclamation In optimizing their data storage requirements, administrators face the key challenge of using tape media efficiently. Often a particular tape volume will contain files that expire on different dates. As a result, when these files reach their expiry date, virtual empty spaces begin to appear on the tape volume; this fragmentation wastes space on the tapes and slows the restore process because of the time required to skip over empty spaces. Because tapes are sequential media (that is, they can be written only from beginning to end), it is not possible to rewrite new data into the spaces occupied by expired files. IBM Tivoli Storage Manager addresses this challenge with an innovative tape reclamation feature used to free up entire tape (or optical) volumes in sequential storage pools. As individual files get marked for expiration, the amount of space that can be reclaimed on a volume increases over time. After this available space reaches a specified threshold, IBM Tivoli Storage Manager automatically initiates a process to reclaim the volume. Remaining active files on the tape volume are rewritten to other tape volumes, then the original volume is returned to scratch. Figure 3-11 on page 43 illustrates this process for a single tape volume. 42 IBM Tivoli Storage Management Concepts

Space Reclamation Figure 3-11 Space reclamation + = + = 100% 25% 70% full full 95% full 3.2.7 Policy concepts A data storage management environment consists of three basic types of resources: client systems, rules, and data. The client systems contain the data to be managed, and the rules specify how the management must occur; for example, in the case of backup, how many versions should be kept, where they should be stored, and so on. IBM Tivoli Storage Manager policies define the relationships between these three resources. Figure 3-12 on page 44 illustrates this policy relationship. Depending on your actual needs for managing your enterprise data, these policies can be very simple or very complex. Chapter 3. Architectural concepts 43

Policy set Copy group Management class Nodes Machines Policy domain Rules Copy group Rules Management class Data Data Copy group Management class Rules Data Figure 3-12 Policy relationships and resources IBM Tivoli Storage Manager has certain logical entities that group and organize the storage resources and define relationships between them. Client systems, or nodes in IBM Tivoli Storage Manager terminology, are grouped together with other nodes with common storage management requirements into a policy domain. The policy domain links the nodes to a policy set, a collection of storage management rules for different storage management activities. A policy set consists of one or more management classes. A management class contains the rule descriptions called copy groups and links these to the data objects to be managed. A copy group is the place where all the storage management parameters, such as number of stored copies, retention period, storage media, and so on, are defined. When the data is linked to particular rules, it is said to be bound to the management class that contains those rules. Another way to look at the components that make up a policy is to consider them in the hierarchical fashion in which they are defined; that iss, consider the policy domain containing the policy set, the policy set containing the management classes, and the management classes containing the copy groups and the storage management parameters. 3.2.8 Security concepts Because the IBM Tivoli Storage Manager storage repository is the place where all enterprisedata is stored and managed, security is a very vital aspect for IBM Tivoli Storage Manager. To ensure that data can only be accessed from the 44 IBM Tivoli Storage Management Concepts

owning client or an authorized party, IBM Tivoli Storage Manager implements, for authentication purposes, a mutual suspicion algorithm, which is similar to the methods used by Kerberos authentication. Whenever a client (backup-archive or administrative) wants to communicate with the server, an authentication has to take place. This authentication contains both-sides verification, which means that the client has to authenticate itself to the server, and the server has to authenticate itself to the client. To do this, all clients have a password, which is stored at the server side as well as at the client side. In the authentication dialog these passwords are used to encrypt the communication. The passwords are not sent over the network, to prevent hackers from intercepting them. A communication session will be established only if both sides are able to decrypt the dialog. If the communication has ended, or if a timeout period without activity is passed, the session will be terminated automatically and a new authentication will be necessary. 3.3 Storage management Applying the discipline of storage management, combined with the appropriate technology and a well-crafted set of storage management best practices, can provide significant business value by helping enterprises increase revenues and decrease costs. This section discusses common approaches to storage management as well as best practices that can be used to enhance the business value of both storage technology and stored data. It also discusses the key functionality to consider when selecting a storage management product. 3.3.1 Best practices The following sections describe some common approaches to best practices in the storage management area. Introduction The exploding growth of corporate data combined with the falling price of storage has created both an opportunity and a challenge for ITmanagers. More-affordable storage technology enables IT managers to buy more storage devices for rapidly increasing volumes of corporate data, but managing these expanding storage networks becomes a complex, resource-intensive task. In many organizations, storage management is executed without strategy, reducing cost-effectiveness and efficiency. Applying the discipline of storage management, combined with the appropriate technology and a well-crafted set of storage management best practices, can Chapter 3. Architectural concepts 45

provide significant business value by helping enterprises increase revenues and decrease costs. This paper discusses common approaches to storage management as well as best practices that can be used to enhance the business value of both storage technology and stored data. It also discusses the key functionality to consider when selecting a storage management product. The most valuable asset The expanding range of IT devices, platforms, and applications in use across the enterprise complicates the storage management picture. Data can reside in geographically diverse locations and on technologically disparate devices; managing these resources across the corporate information grid is no easy task. But the complexities of managing heterogeneous technology networks are not the IT manager s most pressing challenge for, despite the user community s growing understanding of distributed computing, more than anything users require a responsive, available application environment. Applications have the most direct effect on the corporate bottom line, enabling employees to efficiently communicate, handle tasks, and work to expand revenues and decrease costs. Businesses depend heavily on their employees ability to access data and process it through an application. Poor storage management practices can act as a stone dropped into the enterprise s financial pool, creating a potentially disastrous ripple effect throughout the business processes. Unavailable data spreads harmful effects to corporate applications, rendering them ineffective; this can slow or even halt business operations, impairing the enterprise s financial success in one continuous stream. Consider the example of an online auction service that joins buyers and sellers electronically. Through a Web application, the service collects data from thousands of auction participants; if the application becomes inaccessible, the company s business transactions stop, cutting off cash flow. Without protecting the data that feeds the applications, the online auction service is out of business. Developing a strategic storage management approach IT managers must develop a strategic approach and several best practices that protect their most important asset: the data supporting applications. Many storage management tools are available to protect data through routine backups and centrally manage the information grid, but such tools alone are insufficient for organizations to stay competitive in the 21st century. The strategic approach, a distributed storage management solution, ensures not only that the data is backed up but also that the entire information grid can be re-created in business-need priority in case of disaster. By implementing a strategic storage management approach, IT managers can do the following: Minimize the resources consumed for storage management operations by transferring and storing the least amount of information necessary to protect the information grid. 46 IBM Tivoli Storage Management Concepts

Extend the life of their current network infrastructure and processing power. Produce greater returns with lower media costs on the company s investment in secondary tape resources. These benefits can be achieved in a centrally managed environment by selecting the right storage management solution and implementing the best practices described in the following section. 3.3.2 Selecting the most cost-effective solution Many vendors offer distributed backup products, but only IBM Tivoli Storage Manager was developed from the ground up as a comprehensive storage management solution. More than just a distributed backup product, IBM Tivoli Storage Manager is a distributed data backup, recovery, and storage management solution. Unlike other storage products, IBM Tivoli Storage Manager is built on a common, highly portable code base that is consistent across all IBM Tivoli Storage Manager server platforms. This common code base enables IBM Tivoli Storage Manager to manage thousands of desktop clients or a single large database server. 3.3.3 IBM Tivoli Storage Manager product highlights IBM Tivoli Storage Manager was designed as an enterprise-wide storage management application that focuses its resources on recovery. Four key architectural features unique to IBM Tivoli Storage Manager make it the most efficient and intelligent distributed storage management solution on the market: Its database A progressive backup methodology Collocation Reclamation Database The specially designed IBM Tivoli Storage Manager database retains information about all client system and user files, business policies, disaster recovery, and the scheduling of client and administrative tasks. This database retains information called metadata, which means data that describes data. The flexibility of the IBM Tivoli Storage Manager database enables customers to define storage management policies around business needs for individual clients or groups of clients. Client data attributes such as storage destination, number of versions, and retention period can be assigned at the individual file level and stored in the database. Chapter 3. Architectural concepts 47

The IBM Tivoli Storage Manager database also ensures reliable storage management processes. To maintain data integrity, the database uses a recovery log to roll back any changes made if a storage transaction is interrupted before it completes. This is known as a two-phase commit. Also, both the IBM Tivoli Storage Manager database and recovery log can be mirrored for availability, providing automatic volume switching after a media failure. In the unlikely event of an IBM Tivoli Storage Manager database recovery, operators can restore the database to the exact point of a failure by rolling the recovery log forward after restoring from the latest database backup. Progressive backup methodology The IBM Tivoli Storage Manager architecture uses an intelligent backup methodology that provides efficiencies during both the backup and restoration of client data. During the initial client backup, IBM Tivoli Storage Manager backs up all eligible files, creating a full backup. Subsequently, files are backed up again only if they are new or have changed since the last backup. IBM Tivoli Storage Manager maintains a pointer in its database to the latest version of each file for each client, eliminating the need for another full backup to consolidate the files into a single image. Other backup products require an initial full backup, followed by regular incremental or differential backups (usually once a day), and then additional periodic full backups (usually once a week). This less-efficient backup method results in redundant weekly full backups of files that have not changed, wasting both network and media resources. The multistep restore process of such products requires restoration of the last full backup, along with more-recent incremental or differential backups, to recover the latest version of a file or an entire system. Collocation and reclamation Collocation and reclamation features are powered by the intelligence of the IBM Tivoli Storage Manager database. Collocation consolidates all data belonging to a particular client onto the same tape or group of tapes. So although a client might perform progressive backups over a long period, the number of tapes used by a given client remains small. Reclamation is the process by which the IBM Tivoli Storage Manager server monitors the utilization of tapes in its inventory. As backup versions expire, the server tracks the amount of free space on tape volumes. When the amount of free space reaches a customer-defined threshold, the IBM Tivoli Storage Manager server automatically mounts that tape and moves the remaining data to another eligible tape, consolidating and defragmenting data stored on the tape. 48 IBM Tivoli Storage Management Concepts

The combination of collocation and reclamation enhances the efficiency and speed of client data recovery, because the client data can be restored from the smallest number of tapes possible. Along with the unique architectural features described above, other exclusive functions of the IBM Tivoli Storage Manager base product further differentiate it from its competitors. Media management IBM Tivoli Storage Manager provides sophisticated media management capabilities that enable IT managers to do the following: Track multiple versions of files (including the most recent version). Respond to online file queries and recovery requests. Automatically move files to the most cost effective storage media. Expire backup files that are no longer needed. Recycle partially filled volumes. IBM Tivoli Storage Manager provides these capabilities for all backup volumes, including on-site volumes inside tape libraries, volumes that have been checked out of tape libraries, and on-site and off-site copies of the backups. IBM Tivoli Storage Manager provides a powerful media management facility that can be used to create multiple copies of all client data stored on the IBM Tivoli Storage Manager server. Enterprises can use this facility to back up primary client data to two copy pools: one stored in an off-site location, and the other kept on-site for possible recovery from media failures. If a file in a primary pool is damaged or resides on a damaged volume, IBM Tivoli Storage Manager automatically accesses the file from an on-site copy if it is available or indicates which volume needs to be returned from an off-site copy. IBM Tivoli Storage Manager also provides a unique capability for reclaiming expired space on off-site volumes without requiring the off-site volumes to be brought back on-site. IBM Tivoli Storage Manager tracks the utilization of off-site volumes just as it does for on-site volumes. When the free space of off-site volumes reaches a determined reclamation threshold, IBM Tivoli Storage Manager uses the on-site volumes to consolidate the valid files onto new volumes, then directs the new volumes to be taken off-site. When the new tapes arrive off-site, IBM Tivoli Storage Manager requests the return of the original off-site volumes, which can be reused as scratch volumes. Enterprise Administration IBM Tivoli Storage Manager Enterprise Administration enables an administrator to manage multiple IBM Tivoli Storage Manager servers from any platform in the enterprise using a Web-based interface. IBM Tivoli Storage Manager servers can be deployed near their data for high-performance backups to locally attached devices with minimal network usage, which means that the product does not Chapter 3. Architectural concepts 49

sacrifice network performance for central control. Unlike other distributed backup products, IBM Tivoli Storage Manager Enterprise Administration does not create a master/slave single-point-of-failure dependency between the managing server and the managed servers. Managed servers remain independent and can function normally even if the managing server is unavailable. IBM Tivoli Storage Manager Enterprise Administration provides centralized management, facilitates consistent backup policies, and provides enhanced protection of critical data by electronically vaulting data between servers. Administrators can centrally define common policies and configuration information at one IBM Tivoli Storage Manager server and then propagate them to other IBM Tivoli Storage Manager servers. This multi-tiered inheritance structure speeds the dissemination of policy changes and ensures accuracy and consistency of policies within groups. Additional automated functions relieve administrators from repetitive, time-consuming tasks by enabling them to run server scripts from the Enterprise Administration Console. Instant archive IBM Tivoli Storage Manager can execute a restore from almost any point in time the customer chooses. An extension of the point-in-time restore capability, instant archive enables the customer to create a virtual full backup (or client archive) from data already stored at the IBM Tivoli Storage Manager server. Simply put, the IBM Tivoli Storage Manager server executes a restore operation specified by the customer. The difference is that the data is not sent back to the client, but is sent instead to another tape or CD on the IBM Tivoli Storage Manager server; customers can create a full backup tape without actually making a full backup. Customers who use this function are often preparing for a disaster recovery situation, creating baseline copies of a system for long-term archival, or getting ready to restore a remote or mobile computer. Instant archive allows all of these capabilities by using data already stored on the IBM Tivoli Storage Manager server without having to move that data across the network. Rapid recovery Rapid recovery is an integrated attribute of the instant archive media described above. Besides a full copy of information from a given point in time, these pieces of media also contain all necessary inventory information so they can perform a restore without interacting with the IBM Tivoli Storage Manager database. The IBM Tivoli Storage Manager client also can read the instant archive media directly, which means that in case of a disaster, or in remote areas without sufficient bandwidth to transmit a full restore over a network, the instant archive media can be removed from the IBM Tivoli Storage Manager server and 50 IBM Tivoli Storage Management Concepts

mounted directly to the client machine. This enables a rapid full restore without any interaction with the IBM Tivoli Storage Manager server or the network. Mobile backup: Adaptive Differencing technology IBM Tivoli Storage Manager provides a new, patented technology called Adaptive Differencing that dynamically transfers client data at a byte, block, or file level based on its size. By definition, implementing a mobile backup means an administrator must manage backup and restore services for machines that are rarely seen; this makes it crucial to require minimal interaction with the machine. With the mobile backup capability, administrators can enable and disable client functions, such as Adaptive Differencing and data encryption, remotely from the IBM Tivoli Storage Manager administrative interface. Using this same interface, administrators can also remotely monitor the success or failure of backup operations. SAN tape resource sharing The IBM Tivoli Storage Manager SAN tape resource sharing capability delivers immediate benefits by reducing the traffic on the IP network and enabling shared utilization of resources over a SAN. SANs remove the overhead commonly found with slow, overworked communication networks and facilitate quicker access time. Tape library and drive resources are used more efficiently because they can be shared by multiple IBM Tivoli Storage Manager servers across the SAN. LAN-free data transfer LAN-free data transfer provides an alternative path for moving data between the IBM Tivoli Storage Manager client and server. LAN-free data transfer exploits the SAN path by enabling the client to back up and restore data directly to and from SAN-attached storage, which is shared between the IBM Tivoli Storage Manager server and client and managed by the server. The existing local area network (LAN) connection is used to exchange control information, such as policy information and metadata about the objects being backed up, but the data transfer uses the SAN to write directly to the storage media. 3.3.4 Information management for a connected world IBM Tivoli Storage Manager offers sophisticated functionality to reduce the total cost of ownership of distributed storage management in the following key areas. Tape library slots usage When IBM Tivoli Storage Manager consolidates files onto fewer volumes, more slots become available for other tapes. Customers can keep more data and more scratch volumes in the library. Using scratch tapes enables a given growth cushion to be met with fewer tape volumes. Chapter 3. Architectural concepts 51

Operator time Because IBM Tivoli Storage Manager can support a backup system using fewer tape volumes, less operator time is spent checking volumes into and out of a tape library. Also, when IBM Tivoli Storage Manager detects a media-read error in a backup copy of data, it automatically requests the data from the on-site or off-site backup copy of that data; the operator does not have to look up the location of the backup copy. Because IBM Tivoli Storage Manager keeps track of all backup volumes, both on-site and off-site, operators do not have to spend time manually keeping track of volume names and locations. Administration IBM Tivoli Storage Manager also saves administrator time in keeping track of backup files as they move from volume to volume during tape (or optical) reclamation. Also, the IBM Tivoli Storage Manager Enterprise Administration centralized control feature reduces the overall IT cost and workload, enabling the customer to add IBM Tivoli Storage Manager servers without adding administrators. Media Using its database, progressive backup methodology, collocation, and reclamation, IBM Tivoli Storage Manager can support a given amount of backed up and archived data using fewer volumes than other backup products, reducing the cost of media. Media rotation/migration IBM Tivoli Storage Manager uses its storage hierarchy migration automation to migrate data from one media type (such as DLT) to another media type (such as LTO). Using this capability, IBM Tivoli Storage Manager also can move data from old volumes to new volumes of the same media type, freeing the administrator from tracking the volumes or files. Managing off-site tape volumes IBM Tivoli Storage Manager tracks files on off-site tape volumes that expire because of age or version number. The product initiates reclamation of tape space automatically without retrieving off-site volumes, which protects the off-site copies and reduces the volume and cost of off-site storage. Copying backups for on-site and off-site storage IBM Tivoli Storage Manager automates scheduling for the copying of backed-up and archived data for both on-site and off-site storage. Administrators and operators are freed from managing this data on a volume-by-volume basis, which saves time and reduces the chance of error. 52 IBM Tivoli Storage Management Concepts

Keeping disaster recovery plans current Enterprises that back up some data every day also must update the disaster recovery plan to reflect the daily tape volume serial numbers. IBM Tivoli Storage Manager tracks all of this information, consolidating it with other information stored in the disaster recovery plan and reducing the cost of manually updating the plan. IBM Tivoli Storage Manager can even schedule off-site shipment of the daily plan. 3.4 Conclusion IBM Tivoli Storage Manager is a complete storage management solution that is designed to use many components to handle individual circumstances and special needs. As we move forward we will see that IBM Tivoli Storage Manager is uniquely designed to provide a compete and full solution. As we all know, no one product will be able to resolve every problem or handle every situation. IBM Tivoli Storage Manager is constantly adding and filling in gaps and weakness with new features and add on products to fulfill your storage management solution needs. We move forward to planning and the importance of ensuring that your goals and requirements are realistic and obtainable with the hardware, software, and resources at your disposal. Chapter 3. Architectural concepts 53

54 IBM Tivoli Storage Management Concepts

4 Chapter 4. Planning concepts This chapter gives a view of some of the planning that is required for successful IBM Tivoli Storage Manager implementation. It helps assess the business s requirements and assists in planning for necessary resources. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 55

4.1 Most important: planning One of the things that makes IBM Tivoli Storage Manager such a great tool for storage management is that it can be customized to fit business requirements, instead of requiring a business to conform to its requirements. A successful implementation of IBM Tivoli Storage Manager benefits enormously from planning prior to attempting to set up the environment. The planning for which equipment you will need such as hardware platform, size of processor, network connectively and tape library should all be done prior to trying to make IBM Tivoli Storage Manager work in an environment that may not be suitable. 1. The most important thing to ensure a successful implementation of IBM Tivoli Storage Manager in your environment is planning. 2. The most important thing to ensure a successful implementation of IBM Tivoli Storage Manager in your environment is planning. 3. The most important thing to ensure a successful implementation of IBM Tivoli Storage Manager in your environment is planning. Did we mention that the most important thing to ensure a successful implementation of IBM Tivoli Storage Manager in your environment is planning? 4.2 Understanding the importance of your data Most companies do not really understand their business needs when it comes to backups and data storage. Almost everyone you speak to about backup and restores will tell you that they make a full backup of everything every week and keep it for three or four weeks, and during the week they make backups of changes and keep those until the next full backup. This was call the grandfather, father, son method of backup rotation. It required lots of time to complete, used lots of tapes, and was only as good as the person who guessed at the requirements. Your business needs vary based on many factors, including government regulations, regional demands, and industry and competitive pressures. Backup and restore needs vary from industry to industry, from division to division, and even from department to department within the same company. 4.2.1 Backups do not matter There is a simple statement that is an undisputable fact that no one individual or company can dispute: Backups do not matter. What does matter is what you can restore. No one makes backups because they want to; they make backups 56 IBM Tivoli Storage Management Concepts

because they have to. Either government regulation requires you to save data such as payroll and employee information for a specific length of time, or you need to save data in order to support your business. Now that we understand that backups do not matter, how do you determine what is important to back up and what isn t? Many IT managers do not understand what is important any more because of the complexity of the business and the technologies being used to support the business. So they take a guess, or in some cases they ask the users. Unfortunately, most users do not know either. Most users will tell you that everything is important and that they need everything forever. This prevents them from worrying about anything, and they will always be able to restore anything they might need someday. Just look at most e-mail folders for proof. Users have copies of jokes and replies to those jokes dating back years. If it wasn t for business policies, users would require millions of gigabytes of storage just for e-mail. Business policies are sometimes dictated by financial constraints. Data storage is quite costly, so companies sometimes require that data be destroyed or removed in order to save space, thus saving additional costs for new storage. Sometimes backups are controlled by the volume of tape or available tape drives. IBM Tivoli Storage Manager is designed to use policies determined by your business needs and requirements, so your data is stored in a manner that makes sense to your business. In addition to backing up data, IBM Tivoli Storage Manager manages unwanted or unused data. IBM Tivoli Storage Manager for Space Management migratse unused or unwanted data to less-expensive storage devices, then automatically tracks the data in case it is needed again in the future. 4.2.2 If backups do not matter, restores do In a storage management system, it s restores that really matter good, quality restores. In addition to making good backups, IBM Tivoli Storage Manager keeps track of data storage locations as part of its built-in media management. The IBM Tivoli Storage Manager database stores all policies for handling your data, as well as the information about each node or client s files for which it manages data. Its database also keeps track of file locations for each clientand storage durations for each file. For the sake of simplicity, think of the database as having three sections, as shown in Figure 4-1 on page 58: rules and policies, files and data information, and location tracking. Chapter 4. Planning concepts 57

IBM Tivoli Storage Manager Recovery Log Data Management Policies Relational Database IBM Tivoli Storage Manager Server Database has three sections for simplicity Files or Data Information Storage pools Policy Placement and Recovery LAN-SAN Clients Data Storage Hierarchy Polices or Rules Tracking or location Figure 4-1 Divisions of the IBM Tivoli Storage Manager database We call the first section the Rules section, because it contains the set policies that IBM Tivoli Storage Manager must follow for each client. This section contains information about what to back up, when and how often; where and how long the data is to be stored; and how many versions or changes of the same data are to be kept.. The second section is the Files or Data Information section. It contains all of the metadata about the files of each client or node that IBM Tivoli Storage Manager will be backing up. IBM Tivoli Storage Manager backups first inspect the client system to determine what data exists on the node, then transmit that metadata to the IBM Tivoli Storage Manager server and store it in the database. The third section is called the Tracking section because it keeps track of where IBM Tivoli Storage Manager has stored the backed-up or migrated copy of the data that it receives from the client node. When the IBM Tivoli Storage Manager client node makes contact with IBM Tivoli Storage Manager, the IBM Tivoli Storage Manager server first must check in with the database to see whether the client node is registered and authorized to work with this server. The client nodes are listed or registered in this Rules section, 58 IBM Tivoli Storage Management Concepts

which contains instructions, policies, and schedules that the server must follow in order to complete the request it received from the client node. The server then sends back an acknowledgement to the client node that confirms that the client node is registered and authorized to work with this server. Now the IBM Tivoli Storage Manager client issues the request for a backup or a restore. The client pushes out the data to the IBM Tivoli Storage Manager server over the communication method that it has been configured to use. The IBM Tivoli Storage Manager server and client node now have two sessions going between them: one to move metadata and the other to move data. Once the request has begun, the IBM Tivoli Storage Manager database looks at the rules section again to determine where to put the backup copy of the data. Following the policies found in the rules section, the IBM Tivoli Storage Manager server moves the data from the server to the storage pool previously defined for that client node. Meanwhile, the server also looks into the database to store the metadata from this client node. Each file or object that it receives from this client node is noted in the files section with all of the relevant attributes about it. The IBM Tivoli Storage Manager database stores the file by client node, date and time, file size, file creation date and time, file modification date and time, file location structure on the client node, and other client-relevant information. When the file or object has been committed to a storage pool device, the IBM Tivoli Storage Manager database is updated to keep track of its location in the database Tracking section. Each section is cross-referenced to maintain information that relates to the policies set up to service the client node. This is how IBM Tivoli Storage Manager also knows what data it needs to back up and what data it can skip. IBM Tivoli Storage Manager uses progressive backup methodology, which saves time and disk space by backing up only new and modified files. The progressive backup feature uses its own relational database to track data wherever it is stored, delivering direct one-step file restore. This eliminates the need for base-plus-incremental tapes, commonly used for restore procedures in other storage management products. 4.2.3 Better backups through better planning With a better understanding of the technology and methodology that is used in IBM Tivoli Storage Manager, you can plan your backups better. We stated previously that most IT managers and end users do not know what they need to back up or how long they need to keep it. This is one of the most important parts of IBM Tivoli Storage Manager planning: getting to know your data. Ask your users several important questions about the data: how it is created, used, and accessed, and what happens when it is missing or corrupt. With that Chapter 4. Planning concepts 59

information you can also find out how long it takes to recreate or whether there is a system in place in the end-user application or order entry that stores the input or output that can be used to recreate the data. Planning requires the time to become knowledgeable about the customers (end users) for whom you providing this service. It takes less time to plan correctly than to recover without the proper data. IBM Tivoli Storage Manager saves changed files; how long it saves those files is determined in the policies you set for each customer. Every end user is a customer and every policy contains the service level agreement that you provide to that customer. Later in, Chapter 9, Policy management on page 161 we discuss policy management and how it relates to your deliverable. IBM Tivoli Storage Manager uses by default the intelligent Progressive Incremental backup strategy. Only files that have changed or are new are backed up, therefore eliminating unnecessary data transfers that rob the network and CPUs of vital power and productivity. Progressive Incremental backup does away with unneeded full + incremental backups, and produces faster restores because it only needs to restore the version of the file requested, as shown in Figure 4-2. Progressive Incremental backup backs up less data, saving network bandwidth, tapes, and management overhead. Progressive Incremental Backup Monday: Initial progressive incremental backup (only changed or new items backed up from now on) Tuesday: Next progressive incremental backup Wednesday: Next progressive incremental backup Thursday: Next progressive incremental backup (No need to backup entire closet again) Friday: Next progressive incremental backup Figure 4-2 IBM Tivoli Storage Manager progressive incremental backup 60 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Manager database and the client communicate back and forth throughout the entire backup-and-restore process to keep the data updated and catalogued. Restores are simple to request through the GUI with a expandable tree that shows all files that have been backed up. Requesting point-in-time restores allows for automatic selection of all of the files that were present at the selected time and should be restored. IBM Tivoli Storage Manager database selects each file using the data that was backed up closest in time to the request (or using a file that was backed up much sooner but did not change before the point in time requested. Figure 4-3 shows point-in-time restore with progressive backups. Point-in-time restore Desired Point-in-Time file A file B file C file D Day 1 Day 2 Day 3 Day 4 x x x x x x x x x A 1 B 1 C 1 D 1 Collocation Group (1 tape) B 2 file A x file B x file C x file D x Restore 4 files Figure 4-3 IBM Tivoli Storage Manager point-in-time restore D 2 C 2 B 3 D 3 4.2.4 Judging the deliverable The most important thing to keep in mind with IBM Tivoli Storage Manager is planning, but where do you start? At the end. Start by asking such questions as: What is the objective of your storage management solution? Will the end user require a four-hour restore of their server in the event of a total disaster? Do users need to have multiple versions of the changed data? Can the application recover without full data restores or are they co-joined? When you have determined the deliverable, you will be able to complete the objectives within the required time frame with the current network connection speeds. Chapter 4. Planning concepts 61

Each individual end user s requirement may require a separate Policy and Storage Pool design to accommodate their needs. This book looks at each piece of IBM Tivoli Storage Manager to ensure that you can properly plan your storage management solution. The redbook IBM Tivoli Storage Manager Implementation Guide, SG24-5416, demonstrates how to implement IBM Tivoli Storage Manager in your environment. 4.3 Planning for IBM Tivoli Storage Manager In order to plan for IBM Tivoli Storage Manager in your environment you need to understand your environment and how IBM Tivoli Storage Manager will be used in that environment. Each component of IBM Tivoli Storage Manager has specific requirements that relate to the overall planning of the solution. For example, the IBM Tivoli Storage Manager database has to be planned out before allocation in order to ensure proper size and performance considerations keeping in mind that for each record or file that IBM Tivoli Storage Manager backs up, 800 bytes of information are written to the database about that file. You also should know that each copy of the backed-up file records an additional 200 bytes of information into the database. Each IBM Tivoli Storage Manager component has unique properties to learn, and as your experience with IBM Tivoli Storage Manager grows, so will your skill in implementing a successful solution. Worksheets and planning checklists found in Appendix A, Planning and sizing worksheets on page 421 can assist in your planning efforts, as will the companion redbook, IBM Tivoli Storage Manager Implementation Guide, SG24-5416. 4.4 Top tips for a successful implementation This section discusses tips and recommendations to use when implementing an enterprise storage solution with IBM Tivoli Storage Manager. As the product of choice in many companies for accomplishing efficient and effective enterprise-wide storage solutions, IBM Tivoli Storage Manager is a very powerful tool with lots of flavors and colors, bells and whistles, features and functions, so to a certain degree, it is complex. While planning for this solution, you can circumvent some roadblocks to help save time and avoid frustration: 1. Embrace the progressive incremental backup paradigm The architecture of IBM Tivoli Storage Manager and its progressive incremental backup paradigm is unique. It is very important to understand and use this powerful method. 62 IBM Tivoli Storage Management Concepts

A misunderstanding would probably lead to implementing traditional backup strategies that include weekly full backups even though little has changed, represented by selective backups in IBM Tivoli Storage Manager. Furthermore, this type of thinking leads to too much backed-up data and, therefore, more IBM Tivoli Storage Manager database objects than needed. This will increase the database unnecessarily and hinder IBM Tivoli Storage Manager performance. More backup data than necessary leads to more tape usage than is actually required. This will unnecessarily burden and/or complicate tape management processes and tape vaulting. 2. Learn about IBM Tivoli Storage Manager functionality Common sense dictates the importance of understanding a product's functionality in order to use it optimally. Especially for storage management products such as IBM Tivoli Storage Manager, you need to know what the different implemented commands affect. It is important to understand the differences between backup and archive to avoid confusion about which to use. IBM Tivoli Storage Manager includes powerful functions for disaster recovery management, including tape vaulting. Needless to say, these tape volumes for disaster recovery should be kept off-site. Another common mistake is overworking your backups that is, backing up or archiving everything on a system. You should outline your requirements for restore, retrieve, and disaster recovery to define the data that actually must be backed up. 3. Leverage IBM Tivoli Storage Manager functionality Misunderstanding of functionality often leads to its misuse. Even though IBM Tivoli Storage Manager offers a lot of functions and features, you should not overuse them. Too often, an IBM Tivoli Storage Manager implementation contains too many definitions for domains, schedules, storage pools, or device classes. This complicates administration and operation. Knowing what your deliverable is will help you plan the end result better. Collocation, for example, is an expedient feature, but if it is used on all tape volumes it will waste tapes. Collocation will direct all data of a client onto the same tape whenever possible, even if there are minimal amounts of data to back up. Large volume tapes such as LTO can have huge amounts of unused space if collocation is used too liberally. Moreover, migration from disk to tape will extraordinarily increase tape mounts, which may decelerate data processing. The same applies for direct backup to tape. Direct backup to tape is only recommended when streaming a lot of continuous data, so the tape drive doesn't have to rewind and reposition its read head incessantly. Most IT environments include some special data processing applications such as databases or mail servers. To support backup procedures for these Chapter 4. Planning concepts 63

kinds of applications, you should use the additional data protection modules offered by IBM Tivoli Storage Manager to prevent misusing the common backup-archive client for these special data operations. 4. Carefully estimate backup performance Performance depends on various factors, including the IBM Tivoli Storage Manager server and client hardware, network, attached storage devices, and operating systems. When calculating the actual data processing performance, each system included in the storage management environment should be treated separately or in groups of similar system types. Do not assume the same performance for every single system. If there is not a dedicated network for backup purposes, the actual network bandwidth is shared between different systems with different applications. For performance and time calculations, the real available network bandwidth has to be figured out. Even when using separate networks there are factors that decrease the theoretical network bandwidth, such as protocol overhead. File level backup performance depends heavily on the current storage device hardware, protocol, attachment, and file system type. Assuming that all files will be processed at the same speed can lead to a miscalculated result. 5. Carefully estimate restore performance The performance considerations for backup also apply to restores. Most restore requests will be processed through a tape device, so some additional factors have to be considered, such as robotics and tape mount delays, device read speed, and position delays. 6. Test restore in production situations In an enterprise storage management environment, backup and archive are implemented toward a single purpose: restore. In case of a failure of any kind, you want to be able to restore all of your lost data, so it is advisable to test the individual implementation, and to test it in production environment. Most test scenarios are only organized under lab conditions, not real-world situations. This could lead to the incorrect assumption that your restore procedures will work in any failure. In complex environments, data relationship between different systems or applications also must be considered. In case of failure, a misoriented or misordered restore sequence would lead to an inconsistent data environment. Restore can cover a huge area of scenarios from single file to bare metal restore. Disaster recovery strategies and methods have to be well-considered, implemented, documented, and tested. Essentially, all procedures should be documented and revised regularly to ensure their validity. 64 IBM Tivoli Storage Management Concepts

7. Train staff prior to implementation IBM Tivoli Storage Manager is a powerful and complex product when it is implemented and used by well-trained staff, so it is highly recommended that the responsible personnel should be educated in IBM Tivoli Storage Manager products before using them in a production environment. Skill in installing common software under specific operating systems and knowledge about other backup products is good but will not suffice. Hasty implementations will lead to wasted money, wasted time, frustration, and even data loss, not to mention poor performance by the product. 8. Schedule and monitor daily housekeeping activities Once IBM Tivoli Storage Manager is implemented and set up, it must be managed and maintained. Poor data and storage management practices will compromise your business data. Even after executing backups, the data, and therefore IBM Tivoli Storage Manager, has to be administered. Some processes, such as tape vaulting, are daily processes that your business relies on in case of a disaster. 4.5 Conclusion 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, and of course IBM 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 Chapter 4. Planning concepts 65

66 IBM Tivoli Storage Management Concepts

Part 2 Part 2 Client architecture In this part we discuss how the IBM Tivoli Storage Manager client is used and how it functions in your backup and recovery solution. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 67

68 IBM Tivoli Storage Management Concepts

5 Chapter 5. Backup and restore operations This chapter discusses the different types of data movement operations that can be performed by an IBM Tivoli Storage Manager client. We describe how data is extracted from a dedicated client system, and look at state-of-the-art methodologies to move data from systems within an enterprise environment to a storage server for backup or archive purposes and back again for restore activities. These strategies are more topology-related, and they detail the ways client-extracted data flows to the IBM Tivoli Storage Manager server for safekeeping. We do not cover scenarios with local attached storage devices because these implementations require a backup storage device for each system to be backed up. Furthermore, the amount of time and effort for administrating this kind of approach can be heavy. So we concentrate on enterprise-wide solutions with a more centric view on network-based data movement for mission-critical data. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 69

5.1 Operation types It is important to understand IBM Tivoli Storage Manager options for client backup and restore operations, as well as the characteristics of each of these operations because each method may have an effect on backup and restore efficiency, retention periods, portability, CPU utilization, connection time, and network utilization. Table 5-1 describes the various client backup and restore operations supported with IBM Tivoli Storage Manager and lists description, usage, and restore options. IBM Tivoli Storage Manager uses progressive incremental backup as its standard backup method. Table 5-1 Summary of client backup and restore operations Type of backup operation Description Usage Restore options Progressive incremental backup The standard method of backup used by the IBM Tivoli Storage Manager backuparchive client. The first, full backup of a client system is followed by incremental backups. Incremental backup by date is also available. No additional full backups of a client are required after the first backup. Helps ensure complete, effective, policy-based backup of data. Eliminates the need to retransmit backup data that has not been changed during successive backup operations. The user can restore only the version of the file that is needed (depending on the retention parameters). IBM Tivoli Storage Manager does not need to restore a base file followed by incremental backups. This means reduced time and fewer tape mounts, as well as less data transmitted over the network. Selective backup Backup of files that are selected by the user, regardless of whether the files have changed since the last backup. Enables users to protect a subset of their data independent of the normal incremental backup process. The user can restore only the version of the file that is needed. IBM Tivoli Storage Manager does not need to restore a base file followed by incremental one. This means reduced time, fewer tape mounts, and less data over the network. 70 IBM Tivoli Storage Management Concepts

Type of backup operation Description Usage Restore options Adaptive subfile backup Backs up only the parts of a file that have changed since the last backup. The server stores the base file and subsequent subfiles (the changed parts) that depend on the base file. The process works with both the standard progressive incremental backup or with selective backup. Maintains backups of data while minimizing connect time and data transmission for the backup of mobile and remote users. Applicable to clients on Windows systems. The base file plus a maximum of one subfile is restored to the client. Journalbased backup Aids all types of backups (progressive incremental backup, selective backup, adaptive subfile backup) by basing the backups on a list of changed files. The list is maintained on the client by the journal engine service of the IBM Tivoli Storage Manager backup-archive client. Reduces the amount of time required for backup. The files eligible for backup are known before the backup operation begins. Applicable to clients on Windows NT and Windows 2000 systems. Journal-based backup has no effect on how files are restored; this depends on the type of backup performed. Image backup Full volume backup. Nondisruptive, online backup is possible for Windows 2000 and Linux clients by using the Tivoli Storage Manager snapshot function. Allows backup of an entire file system or raw volume as a single object. Can be selected by backuparchive clients on UNIX and Windows systems. Used by Windows clients that are using server-free data movement. The entire image is restored. Image backup with differential backups Full volume backup that can be followed by subsequent differential backups. Used only for the image backups of NAS file servers, performed by using NDMP. The full image backup plus a maximum of one differential backup are restored. NDMP backup An image backup for NAS devices that supports full and differential processing. Regardless of the mode the backup always results in one single entity on the IBM Tivoli Storage Manager server. NAS filers may not allow third-party software, so an IBM Tivoli Storage Manager client could not be installed. In this case, standardized NDMP protocol offers a possibility for making backups. Full image restore or file level restore is possible. Depending on the NAS filer even new data created after the last image backup can be merged with the restored image. Chapter 5. Backup and restore operations 71

Type of backup operation Description Usage Restore options Backup using hardware snapshot capabilities A backup method that exploits the capabilities of IBM Enterprise Storage Server FlashCopy and EMC TimeFinder to make copies of volumes used by database servers. IBM Tivoli Storage Manager uses the volume copies to back up the database volumes. Implements highefficiency backup and recovery of businesscritical applications while virtually eliminating backup-related downtime or user disruption on the database server. See 5.5, Split-mirror/point-in-time copy backup on page 78 for details. Archive Creates a copy of files and stores them for a specific time. Use for maintaining copies of vital records for legal or historical purposes. If you frequently create archives for the same data, consider using instant archive (backup sets) instead. Frequent archive operations can create a large amount of metadata in the server database resulting in increased database growth and decreased performance of expiration server operations. The selected version of the file is retrieved on request. Instant archive Creates a backup set of the most recent versions of the files for the client, using files already in server storage from earlier backup operations. Use when portability of the recovery media or rapid recovery of a backuparchive client is important. Also use for efficient archiving. Files are restored directly from the backup set. The backup set resides on media that can be mounted on the client system, such as CD, tape drive, or file system. The IBM Tivoli Storage Manager server does not have to be contacted for the restore process, so the network and IBM Tivoli Storage Manager server are not used. 72 IBM Tivoli Storage Management Concepts

5.2 Traditional LAN and WAN backup topology In a traditional LAN and WAN environment the IBM Tivoli Storage Manager backup and archive client or application would read data from locally attached disks and send it over the LAN to the IBM Tivoli Storage Manager backup server as shown in Figure 5-1. The server receives the data then writes it out to its storage pool tape, disk, or optical media based on predefined policies and server configuration. Data is read and written by both the IBM Tivoli Storage Manager client and IBM Tivoli Storage Manager server machines. In addition, control information is also sent over the LAN to the IBM Tivoli Storage Manager server. LAN/WAN (TCP/IP) Client Backup Server Data Tape Figure 5-1 IBM Tivoli Storage Manager LAN and WAN backup Data Flow Restore operations follow the same path in the opposite direction. Data is read by the IBM Tivoli Storage Manager server, sent via the LAN to the client system, and is written there on local attached storage devices. This conventional approach has the advantages of introducing a central storage management that can share central installed backup devices. Only the backup server uses them but, from a backup perspective, all client systems are using these devices through this central backup server. Most system environments already have LAN/WAN topologies in place so this solution can be implemented with little additional effort in network devices. The simplicity of using an already installed LAN also may be a disadvantage. In addition to the previous data transferred via the LAN now the backup data has to Chapter 5. Backup and restore operations 73

be transferred via the same resource. This might lead to a network bottleneck for all applications based on the LAN. 5.3 SAN (LAN-free) backup topology SAN technology provides an alternative path for data movement between the IBM Tivoli Storage Manager client and the server. Shared storage resources (disk, tape) are accessible to both the client and the server through the SAN. Data movement is off-loaded from the LAN and from the server processor and allows for greater scalability. LAN-free backups decrease the load on the LAN by introducing a Storage Agent. The Storage Agent can be thought of as a small IBM Tivoli Storage Manager server (without a database or recovery log) that is installed and run on the IBM Tivoli Storage Manager client machine. The Storage Agent handles the communication with the IBM Tivoli Storage Manager server over the LAN but sends the data directly to SAN attached tape devices, relieving the IBM Tivoli Storage Manager server from the actual I/O transfer. A LAN-free backup environment is shown in Figure 5-2. LAN/WAN (TCP/IP) Client Backup Server SAN FC Device Data Tape Data Flow Control Flow Figure 5-2 IBM Tivoli Storage Manager LAN-free backup As with LAN-based restore, the LAN-free restore data flow runs the same path as during backup but in the opposite direction. The client system reads the desired 74 IBM Tivoli Storage Management Concepts

data directly from the SAN attached backup devices and writes it back to the initial source storage devices. If the SAN path is not available, the restore operation can also be performed via the LAN, as described in section 5.2 on page 73. The main advantage of this approach, compared to the traditional LAN-based implementation, is the shift of backup data transfer from the LAN to the SAN so that the LAN is only burdened with negligible control or metadata. Furthermore, the backup server does not have to process all backup data because it is transferred directly to the attached backup devices. This approach and Figure 5-2 on page 74 show a tape device as the destination for LAN-free stored data, but you could also use a disk device as the destination. Regardless of the underlying hardware, IBM Tivoli Storage Manager requires a sequential storage pool for LAN-free backups, which can be fulfilled for tape devices but not for disk devices per se. A disk device is a random access device, and even the corresponding device class in IBM Tivoli Storage Manager reflects this feature. IBM Tivoli Storage Manager offers the possibility of emulating a sequential storage pool on a random access disk device by using the device class FILE. However, even when using a storage pool based on FILE deviceclass, the LAN-free clients have to access the underlying storage device directly. Additionally, not only do LAN-free clients have to access the same device, but also the same file system at the same time. So the challenge is to implement a file-sharing mechanism on a heterogeneous SAN environment that is different from traditional LAN-based file-sharing protocols such as NFS or CIFS. To implement this scenario and enable IBM Tivoli Storage Manager to perform LAN-free operations directly to a SAN attached disk device, you would need to use IBM Tivoli SANergy. IBM Tivoli SANergy leverages on the sharing abilities of LAN (using NFS and CIFS) with the guaranteed delivery, high bandwidth, and low processor overhead of SANs to provide high performance LUN, disk volume, and file sharing capabilities in heterogeneous environments. The redirection of data I/O is transparent to the hosts operating systems and applications. The applications see the disk volumes as if they are accessing them using a traditional LAN-based configuration. If an application has locking semantics for concurrent file access, SANergy even enables the transparent sharing of the exact files at the same time across platforms. IBM Tivoli SANergy is described in more detail in 23.3, IBM Tivoli SANergy on page 391 and these Redbooks: Using Tivoli Storage Manager in a SAN Environment, SG24-6132 Chapter 5. Backup and restore operations 75

A Practical Guide to Tivoli SANergy, SG24-6143 IBM Tivoli Storage Manager Implementation Guide, SG24-5416 Implementing the IBM TotalStorage NAS 300G: High Speed Cross Platform Storage and Tivoli SANergy!, SG24-6278 From a technical point of view a SAN topology also offers higher bandwidth and therefore faster speed availability for data movement. In reality this depends heavily on attached storage device technology and the nature of the transferred data. Usually, large files such as databases are transferred faster via SAN than LAN. When transferring small files, SAN performance may radically decrease. However, LAN-free backups operating on a SAN environment adds complexity to an IBM Tivoli Storage Manager implementation. You must be aware of how you would like to utilize your SAN-attached backup storage devices because bad resource planning can create a storage device overload. Also, tape library sharing between multiple IBM Tivoli Storage Manager server requires proper planning. Instead of only one IBM Tivoli Storage Manager server and its LAN-free clients using the attached library, multiple servers and their clients are sharing the storage device. 5.4 Server-free backup In a server-free backup environment, data is copied directly from the SAN attached IBM Tivoli Storage Manager client disk to the SAN attached tape drive via an additional data mover component as shown in Figure 5-3 on page 77. This enables IBM Tivoli Storage Manager to perform backup without the data stream leaving the SAN or passing any application server. Therefore both IBM Tivoli Storage Manager client and server machines do not have to read and write the data at all. The IBM Tivoli Storage Manager server sends commands to the data mover device to tell it which blocks to move from which SAN attached disk to which SAN attached tape device. The data is actually copied rather then moved from one location to another. This provides a way to back up and restore large volumes of data between client-owned disks and storage devices using a method that considerably reduces overhead on the IBM Tivoli Storage Manager server and the client. Only volume images, and not individual files, can be moved by server-free data movement. The data is transferred block by block rather than by doing file I/O. Both raw and NTFS volumes can be backed up using server-free data movement. 76 IBM Tivoli Storage Management Concepts

LAN/WAN (TCP/IP) Client Backup Server SAN FC Device Data Tape Data Mover Data Flow Control Flow Figure 5-3 IBM Tivoli Storage Manager server-free backup Data that has been backed up using server-free data movement can be restored over a server-free path, over a LAN-free path, or over the LAN itself. So even in case of data mover or SAN failure you can still restore your data as long as the LAN is available. The impact on application servers is now minimized with server-free data movement. It reduces both IBM Tivoli Storage Manager client and server CPU utilization. The data mover device must support the SCSI-3 EXTENDED COPY command, which conforms to the ANSI T10 SPC-2 standard. The use of a SCSI-3 extended copy command causes data to be transferred directly between devices over the SAN or SCSI bus. The data mover device can be anywhere in the SAN, but it has to be able to address the LUNs for both the disk and tape devices it is moving data between. Tape libraries such as the IBM Ultrium Scalable Tape Library 3583 are able to host a data mover module, and in that case the data mover unit is directly integrated into the tape library. The overall advantage of this strategy is the absence of backup I/O on the IBM Tivoli Storage Manager client system as well as on the IBM Tivoli Storage Manager server system. Data streams are wholly handled between storage Chapter 5. Backup and restore operations 77

devices within the SAN itself. This relieves application server systems significantly. Nevertheless, the extended copy feature is still an upcoming technology, rarely spread and heavily hardware dependent as of this writing. Deployment has to be well-planned and harmonized with already installed storage hardware. Furthermore, server-free backup is not transparent to applications or databases because data movement is performed on a block basis and not on file level. 5.5 Split-mirror/point-in-time copy backup A split-mirror/point-in-time backup occurs when a copy volume generated by operating system mirroring or a hardware-assisted instant copy function (as found on many of today s high-end storage systems) is backed up to an IBM Tivoli Storage Manager server, as shown in Figure 5-4. Such a backup method virtually eliminates the backup-related performance impact on the production host. This approach is facilitated and automated with the IBM Tivoli Storage Manager for Hardware components by coupling the FlashCopy function of IBM Enterprise Storage Server with IBM Tivoli Storage Manager and its database protection capabilities for DB2, Oracle, and SAP R/3 databases. This copy-backup procedure adds value to storage and backup procedures, because it helps ensure that essential applications can continue to run 24x7x365 with minimal backup-related impact. LAN/WAN (TCP/IP) Production host X Second Host Backup Server Data Data Tape Data Flow Figure 5-4 IBM Tivoli Storage Manager split-mirror/point-in-time copy backup This strategy requires different hardware prerequisites. Either an IBM Enterprise Storage Manager or an EMC Symmetrix has to be in place with the respective 78 IBM Tivoli Storage Management Concepts

copy function enabled. An additional host system for performing the actual backup is needed. When a backup operation is initiated for the client system, a point-in-time copy of the desired data volumes is created within the disk storage system. This process lasts only a few seconds. When this mirror copy is consistent and available the second host system can connect to the copy and perform the actual backup. This reduces CPU cycles significantly on the production system because it is not involved in the backup apart from a small initiation for the copy process. Therefore it can concentrate on processing application requests. A restore operation also can go different ways. The restore of a database that has been backed up by creating a point-in-time copy can be performed directly by the production host to the original source volumes. This is the common way of restoring data because it supports the individual application interface and is thus transparent. The data flow can run different ways; that is, via the LAN or the SAN, respectively. Both ways were described in previous sections. Otherwise the last point-in-time copy is still located on the target volumes within the storage system so the second host can also perform this restore by using the point-in-time copy mechanism to copy the data back to the original volumes without transferring data from storage devices that are controlled by the IBM Tivoli Storage Manager server. The supported features may differ depending on what storage system and database you use. Therefore split-mirror backup is very hardware- and configuration-dependent and introduces an additional level of complexity for synchronization tasks during backup activities. 5.6 NAS and NDMP The IBM Network Attached Storage products have been pre-installed with the IBM Tivoli Storage Manager client, which enables an existing or planned IBM Tivoli Storage Manager server to back up the data in the NAS system. This backup client is designed to provide file level and sub-file level backup and restore functionality. An IBM Tivoli Storage Manager environment integrated with NAS systems can be used to manage a broad range of data storage, recovery, and availability functions across the entire computing infrastructure. Based on the IBM Tivoli Storage Manager server s configuration, the final destination of the NAS appliance s backup may be located either in the IBM Tivoli Storage Manager server s disk storage or an attached tape subsystem. Persistent images must be created using the pre-loaded Persistent Storage Manager (PSM) software before activating this backup function. Automated scheduling to back up these PSM images can then be configured in the IBM Tivoli Storage Manager server. As with a standard IBM Tivoli Storage Manager client, an option file is created and stored on the NAS system. For more information about backing up Chapter 5. Backup and restore operations 79

IBM NAS appliances, see IBM TotalStorage NAS Backup and Recovery Solutions, SG24-6831. The IBM Tivoli Storage Manager Extended Edition also supports the ability to perform Network Data Management Protocol (NDMP) backups. NDMP is an industry-standard protocol that enables a network storage-management application to control the backup and recovery of an NDMP-compliant file server without installing third-party software on that server. This provides backup and recovery support for NAS file servers from Network Appliances. NAS file servers often require a unique approach to providing backup and recovery services, because these file servers are not typically intended to run third-party software. The NAS file server does not require installation of IBM Tivoli Storage Manager software. Instead, the IBM Tivoli Storage Manager server uses NDMP to connect to the NAS file server to initiate, control, and monitor a file system backup or restore operation as shown in Figure 5-5. The implementation of the NDMP server protocol enables the NAS file servers to be backup-ready and enables higher-performance backup to tape devices without moving the data over the LAN. The tape devices have to be under the direct control of the NAS filer, which means that they have to be directly attached or connected through a supported SAN environment. LAN/WAN (TCP/IP) Client NAS Device Backup Server (optional) Data Tape Data Flow Control Flow Figure 5-5 IBM Tivoli Storage Manager and NDMP backup 80 IBM Tivoli Storage Management Concepts

An NDMP backup is usually an image backup because the NAS filer performs the backup as an entity without informing the IBM Tivoli Storage Manager about the content. So the IBM Tivoli Storage Manager server administers only one image object that has been backed up. Additionally, IBM Tivoli Storage Manager can create a table of contents (TOC) during backup and stores this TOC afterwards in a dedicated storage pool. This enables IBM Tivoli Storage Manager to perform a single file restore from a NAS backup image. Each time a single file restore from an NAS image backup is performed, IBM Tivoli Storage Manager will load the TOC from the dedicated storage pool into a temporary database table. This table will be deleted after a specified amount of time that can be configured through the parameter TOCLOADRETENTION. Even without the TOC you can restore single files from a NAS backup image. In that special case exact information about the single file and the image it resides in must be provided for restore. Although an NDMP backup is usually started and controlled by an IBM Tivoli Storage Manager server, the IBM Tivoli Storage Manager Web client is also able to initiate and control an NDMP backup or restore, respectively. Using a TOC, the IBM Tivoli Storage Manager Web client provides file-level access to the TOC so that it becomes browsable. Collecting file-level information requires additional processing time, network resources, storage pool space, and possibly a mount point during the backup. You must set up policy so that the IBM Tivoli Storage Manager server stores the TOC in a different storage pool from the one where the backup image is stored. It is important to allocate adequate storage pool space for storing TOCs. To avoid mount delays, use random access storage pools (DISK device class). 5.7 Image backup An image backup is a block-by-block copy of data from the IBM Tivoli Storage Manager client to the IBM Tivoli Storage Manager backup server. One important function of an image restore is to accelerate recovery in a Disaster Recovery scenario. With image backup, the IBM Tivoli Storage Manager server does not track individual files in the file system image. File system images are tracked as individual objects, and the management class policy will be applied to the file system image as a whole. An image backup provides the following benefits: Can provide a quicker backup and restore than a file-by-file backup as there is no overhead involved in creating individual files Conserves resources on the server during backups because only one entry is required for the image Provides a point-in-time picture of your file system, which may be useful if your enterprise needs to recall that information Chapter 5. Backup and restore operations 81

Restores a corrupt file system or raw logical volume. Data is restored to the same state it was when the last logical volume backup was performed. On the Windows 2000 client platform a Logical Volume Storage Agent (LVSA) has been introduced that is capable of taking a snapshot of the volume while it is online. Optionally, only occupied blocks can be copied. If the snapshot option is used (rather than static), then any blocks that change during the backup process are first kept unaltered in an Original Block File. In this way the client is able to send a consistent image of the volume as it was at the start of the snapshot process to the IBM Tivoli Storage Manager server. 82 IBM Tivoli Storage Management Concepts

6 Chapter 6. Backup-archive client This chapter covers the main client concepts for performing backup and restore operations. For more details about implementation, see IBM Tivoli Storage Manager Implementation Guide, SG24-5416. The backup-archive client is the software program that helps you protect information on your workstation. IBM Tivoli Storage Manager enables you to submit and receive information, to and from an IBM Tivoli Storage Manager server, by controlling the transmission back and forth. You use the IBM Tivoli Storage Manager backup-archive client to maintain backup versions of a machine s files. Then you can recover older file versions in the event that those files are lost or damaged. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 83

6.1 What is a client? IBM Tivoli Storage Manager is a client-server program. The client product, which must be installed on the machine you want to back up, is responsible for sending and receiving data to and from the IBM Tivoli Storage Manager server. The backup-archive client has two distinct features: The backup feature enables users to back up (and manage) a number of versions of their data onto the IBM Tivoli Storage Manager server (or servers) and to restore from these if the original files are lost or damaged. Some examples of loss or damage are hardware failure, theft of computer system, and virus attack. The archive feature enables users to keep a copy of their data for long-term storage and to retrieve the data if necessary. Examples of this need may be to meet legal requirements, to return to a previous working copy if the software development of a program is unsuccessful, and to archive files that are not needed locally on a workstation. Each of these features has a complementary function as well: The restore feature enables users to recover any data that has been backed up previously. Regarding the individual implementation of IBM Tivoli Storage Manager, the user is able to recover from different versions of the lost data. The retrieve feature enables users to request formerly archived data so that this data is accessible again. The latter features are the central procedures IBM Tivoli Storage Manager is built around. Backup and archive are supporting functions for getting back lost data later on. So the client view should always start at discovering how to recover data rather than how to backup data. 6.2 Client components Each client has two major components that help you protect your important data: Software components: These are the software programs and customization files that you must have in place to use IBM Tivoli Storage Manager. The most important of these are the client interfaces. Each interface is designed so that you can perform all client operations from the one that best suits your needs. For successful interaction with the server, you must configure some basic parameters in a client options file. Operation components: When you use the IBM Tivoli Storage Manager interface to back up or archive a file, it sends a copy of the file and its 84 IBM Tivoli Storage Management Concepts

associated attributes to the IBM Tivoli Storage Manager server. The IBM Tivoli Storage Manager client can perform two types of operations to send data to its designated server: backups and archives. Although these have different purposes, you can think of them as the alternatives that you have to better control how data must be saved. All client processing is controlled and secure. A client can restore or retrieve their own files, or the files that they have been authorized to restore by the owner. Whenever a client communicates with the server, it starts a new session. The IBM Tivoli Storage Manager server tracks sessions and each client activity. The backup-archive client can be started manually by the user, by an Administrator, or even automatically by the operating system. The backup-archive client provides support for errors such as communications errors, unreadable client files during backups, or volumes that are unavailable on the IBM Tivoli Storage Manager server during restore. 6.2.1 Interfaces There are three ways you can interact with the IBM Tivoli Storage Manager server to run a backup/restore or archive/retrieve operation: Graphical userinterface (GUI) Command line interface (CLI) Web client interface (Web client) There are minor differences between the backup-archive client code among the platforms. For example, in Windows NT/2000/XP, specific options handle the Windows Registry information, which is not found in any other platform. You use the native file formats to specify filespaces for backup (for example /usr in UNIX or \\hostname\d$ for Windows). Apart from these OS-specific considerations, commands are the same on the three client platforms. Graphical user interface The GUI is a user-friendly interface with unique features for the end user. You may use it for backup, restore, archive, and retrieve operations, and it is intuitive for you to understand which files and directories you are backing up. The GUI is equivalent between Windows and UNIX machines. Figure 6-1 on page 86 shows a Windows NT backup-archive client screen. Chapter 6. Backup-archive client 85

Figure 6-1 Windows interface showing collapsible directories When restoring, only the files that have been backed up are displayed. Figure 6-2 on page 87 shows an example of a restore window with the files in a directory available to restore. 86 IBM Tivoli Storage Management Concepts

Figure 6-2 Windows interface showing directories available to restore Command line interface The command line interface (CLI) has a richer set of functions than the GUI. The CLI has the benefit of being a character mode interface, so it is well-suited for those users who need to type the commands. You may also consider using it when you cannot access the GUI interface or when you want to automate a backup process by using a batch processing file. You may use it for backup, restore, archive, and retrieve operations, and to start the IBM Tivoli Storage Manager scheduler. There are two different methods to use the command line interface: interactive and non-interactive. The DSMC program activates both methods. The interactive method (also called loop mode) has a prompt (dsmc>) to type all IBM Tivoli Storage Manager specific commands for the client. If you use an interactive command line session, it is not necessary to precede each command with dsmc. If you use interactive mode you do not have to enter your password with each command. The following example shows an interactive command line prompt and some backups already made. When you are working from the command line in this Chapter 6. Backup-archive client 87

way, you must use the QUIT command to exit. Otherwise, DSMC waits for the next input command, as shown in Example 6-1. Example 6-1 IBM Tivoli Storage Manager client command line IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface - Version 5, Release 2, Level 0.0 (c) Copyright by IBM Corporation and other(s) 1990, 2003. All Rights Reserved. Node Name: CLYDE Session established with server IBM Tivoli Storage Manager_520_CLYDE_W2K: Windows Server Version 5, Release 2, Level 0.0 Server date/time: 04/28/2003 10:23:00 Last access: 04/28/2003 10:21:14 tsm> q filesp Num Last Incr Date Type File Space Name --- -------------- ---- --------------- 1 00/00/0000 00:00:00 NTFS \\clyde\c$ tsm> q back \\clyde\c$\tsm\ Size Backup Date Mgmt Class A/I File ---- ----------- ---------- --- ---- 0 B 04/28/2003 10:18:24 STANDARD A \\clyde\c$\tsm\aezil 0 B 04/28/2003 10:18:24 STANDARD A \\clyde\c$\tsm\dan 0 B 04/28/2003 10:18:24 STANDARD A \\clyde\c$\tsm\holger 0 B 04/28/2003 10:18:24 STANDARD A \\clyde\c$\tsm\roland 0 B 04/28/2003 10:18:24 STANDARD A \\clyde\c$\tsm\ross 4,194,304 B 04/28/2003 10:18:24 DEFAULT A \\clyde\c$\tsm\50083653.ost 4,194,304 B 04/28/2003 10:18:24 DEFAULT A \\clyde\c$\tsm\50083654.ost 4,194,304 B 04/28/2003 10:18:25 DEFAULT A \\clyde\c$\tsm\50083655.ost 2,501,300 B 04/28/2003 10:18:26 DEFAULT A \\clyde\c$\tsm\50083656.ost 4,194,304 B 04/28/2003 10:18:26 DEFAULT A \\clyde\c$\tsm\50094768.ost 4,194,304 B 04/28/2003 10:18:27 DEFAULT A \\clyde\c$\tsm\50094769.ost 4,194,304 B 04/28/2003 10:18:28 DEFAULT A \\clyde\c$\tsm\50094770.ost 4,194,304 B 04/28/2003 10:18:28 DEFAULT A \\clyde\c$\tsm\50094771.ost 3,243,929 B 04/28/2003 10:18:29 DEFAULT A \\clyde\c$\tsm\50094772.ost 4,194,304 B 04/28/2003 10:18:29 DEFAULT A \\clyde\c$\tsm\50094854.ost 4,194,304 B 04/28/2003 10:18:30 DEFAULT A \\clyde\c$\tsm\50094855.ost 4,194,304 B 04/28/2003 10:18:31 DEFAULT A \\clyde\c$\tsm\50094856.ost 4,194,304 B 04/28/2003 10:18:31 DEFAULT A \\clyde\c$\tsm\50094857.ost 3,243,931 B 04/28/2003 10:18:32 DEFAULT A \\clyde\c$\tsm\50094858.ost 4,608 B 04/28/2003 10:18:32 DEFAULT A \\clyde\c$\tsm\myfile 4,608 B 04/28/2003 10:18:32 DEFAULT A \\clyde\c$\tsm\myfile.doc tsm> The non-interactive method (also called batch mode) requires that you use the dsmc and the actual command that you want to execute. In this mode, DSMC will process the command and return to the calling program. You can have a number of DSMC commands in a batch file for automatic processing. For example, to 88 IBM Tivoli Storage Management Concepts

perform a backup-archive client QUERY operation and return to the operating system prompt, you should run the DSMC QUERY SESSION command as shown in Example 6-2. Example 6-2 IBM Tivoli Storage Manager client session information C:\Program Files\Tivoli\tsm\baclient>dsmc q sess IBM Tivoli Storage Manager Command Line Backup/Archive Client Interface - Version 5, Release 2, Level 0.0 (c) Copyright by IBM Corporation and other(s) 1990, 2003. All Rights Reserved. Node Name: CLYDE Session established with server IBM Tivoli Storage Manager_520_CLYDE_W2K: Windows Server Version 5, Release 2, Level 0.0 Server date/time: 04/28/2003 10:24:17 Last access: 04/28/2003 10:23:00 TSM Server Connection Information Server Name...: IBM Tivoli Storage Manager_520_CLYDE_W2K Server Type...: Windows Server Version...: Ver. 5, Rel. 2, Lev. 0.0 Last Access Date...: 04/28/2003 10:23:00 Delete Backup Files...: "No" Delete Archive Files...: "Yes" Node Name...: CLYDE User Name...: C:\Program Files\Tivoli\tsm\baclient> Web client interface The Web client permits an authorized administrator, help desk, or end user to run backup and restore services on any machine that supports a Java-capable browser, such as current releases of Netscape Navigator and Microsoft Internet Explorer. Multiple Web client sessions can be started simultaneously to perform different functions on separate IBM Tivoli Storage Manager clients. Figure 6-3 on page 90 shows the main Web client screen. Chapter 6. Backup-archive client 89

Figure 6-3 Web backup-archive client 6.2.2 Configuration and options files Configuration files and options files are used to specify one or more servers and communication options for backup and restore services. The file can include authorization options, backup and archive processing options, scheduling options, and, where applicable, IBM Tivoli Storage Manager for Space Management options. On the UNIX platform, the IBM Tivoli Storage Manager options reside in two options files: the client system options file (dsm.sys) and the client options file (dsm.opt). On other platforms, the options file (dsm.opt) contains all of the options. The end user sets up these files when the IBM Tivoli Storage Manager backup-archive client is first installed on the user's workstation. Figure 6-4 on page 91 shows a schematic view of the options file for the client. 90 IBM Tivoli Storage Management Concepts

Data Flow Options File System Options File IBM Tivoli Storage Manager Client "HAMBURG" Figure 6-4 Client with configuration and options files IBM Tivoli Storage Manager Server "SRV_TSM1" The minimum configuration parameters for successful communication are: Communication Protocol: Client and server using the same type IBM Tivoli Storage Manager server address: Identifying the correct IBM Tivoli Storage Manager server to use Nodename: The name by which the IBM Tivoli Storage Manager server knows the client. This information is required so that the server allows access for this client. The node name and password are set up on the server, and if different from the machine name, they also must be added in the client options file0. Figure 6-5 on page 92 shows an example of a client (HAMBURG) and its minimum configuration settings. Chapter 6. Backup-archive client 91

Options File: COMM = TCP/IP Server = SRV_TSM1 Node = HAMBURG System Options File Can I Have Access? OK? Client Nodes Allowed Access TOKYO HAMBURG PARIS IBM Tivoli Storage Manager Client "HAMBURG" IBM Tivoli Storage Manager Server "SRV_TSM1" Figure 6-5 Client presents node name and is accepted 6.2.3 Establishing the session The IBM Tivoli Storage Manager backup-archive client node is required to register with the IBM Tivoli Storage Manager server. Once registered, the IBM Tivoli Storage Manager client can start its communication with the server by first completing a sign-on process. This sign-on process requires the use of a password that, when coupled with the node name of the client, insures proper authorization when it connects to the server. Figure 6-6 on page 93 shows an example of the steps to establish a session with the IBM Tivoli Storage Manager server. 92 IBM Tivoli Storage Management Concepts

Options File: COMM = TCP/IP Server = SRV_TSM1 Node = HAMBURG System Options File Can I Have Access? OK? "Session Established" Client Nodes Allowed Access TOKYO HAMBURG PARIS IBM Tivoli Storage Manager Client "HAMBURG" Figure 6-6 Establishing a client session IBM Tivoli Storage Manager Server "SRV_TSM1" 6.3 Multi-session and transaction concepts The IBM Tivoli Storage Manager clients use various internal techniques to improve performance. In this section we describe the multi-session capabilities and client transaction concepts. 6.3.1 Multi-session IBM Tivoli Storage Manager exploits the multithreading capabilities of modern operating systems by transparently initiating multiple backup-archive or restore/retrieve sessions on the client where necessary for rapid processing and data transfers between the client and the server. The underlying multithreading model IBM Tivoli Storage Manager uses is called Producer-Consumer or Reader-Writer model. This model usually involves two basic types of threads (seen in Figure 6-7 on page 94): Producer thread that writes data to a buffer Consumer thread that reads data from a buffer Chapter 6. Backup-archive client 93

Figure 6-7 Producer-Consumer model The multi-session function involves five types of threads: main, signal waiting, producer, consumer, and performance monitor. Main thread: The main thread handles common housekeeping tasks such as general system initialization, processing options, authentication with IBM Tivoli Storage Manager server, command parsing, and policy set retrieval. It also creates the producer thread and the performance monitor thread, and it queues up file specifications to be processed by the producer thread. Signal Waiting thread: The signal waiting thread captures signals for the command line client, such as a CTRL+C or CTRL+BREAK to cancel a session. On Windows OS, the console event handler is used instead. Producer thread: The producer thread is the front-end for further processing. It starts the consumer thread and retrieves file specifications queued up by the main thread. This thread queries the IBM Tivoli Storage Manager server and examines the file system to determine which files to back up. Finally it queues the transactions to be processed by the consumer thread. Consumer thread: The consumer thread is the back end for further processing. This thread handles file I/O and, if applicable, it compresses or encrypts data. It processes the transactions queued by the producer thread and sends and commits the data to the IBM Tivoli Storage Manager server. Performance Monitor thread: The performance monitor thread attempts to optimize performance by balancing thread usage, which can be affected by 94 IBM Tivoli Storage Management Concepts

the client option RESOURCEUTILIZATION. Periodically the performance monitor tries to optimize the current performance with the following behavior: Attempts to start a new consumer thread if a new transaction needs to be queued, but the transaction queue is full or the next transaction waiting to be processed is the same as the last time we checked. Attempts to start a new producer thread if the next file waiting to be processed is the same since the last time we checked. Quiesces a consumer thread if more than one consumer thread is running and the time since anything new has been placed on the transaction queue exceeds the threshold. Quiesces a producer thread if more than one producer thread is running, the file queue is empty, and the time since anything new has been placed on the transaction queue exceeds the threshold. Consumer and producer threads are quiesced when there is no more work to be done. Considering the above details about the thread model used in IBM Tivoli Storage Manager, the overall process of a multithreaded backup would be processed in the following way (seen in Figure 6-8 on page 96): 1. The main thread queues up file specification for processing by the producer thread. 2. The producer thread gets a file specification from the queue and determines what files in the specification to back up. 3. The producer thread builds transactions and queues them up for processing by the consumer thread. 4. The consumer thread gets a transaction from the queue and sends the data to the IBM Tivoli Storage Manager server. 5. The performance monitor thread helps determine whether a new producer or consumer thread may be started. Chapter 6. Backup-archive client 95

File spec queue File spec A File spec B File spec C... File spec n Producer main Txn queue Disk Disk Txn 1 Txn 2 Txn 3... Txn n main Consumer main Performance Monitor Figure 6-8 Multithreaded backup IBM Tivoli Storage Manager Server The administrator and the user each have controls to influence the number of sessions that a client can start. On the server, the global setting MAXSESSIONS limits the total number of sessions of any kind that may be present. The client node setting MAXNUMMP, in its server definition, controls how many mount points (for sequential devices such as tape drives) a client may allocate. Finally, the RESOURCEUTILIZATION setting in the client option file increases or decreases the ability of the client to create multiple sessions. Keep in mind that increasing the value for RESOURCEUTILIZATION might result in an adaptation for MAXNUMMP. If the client opens more sessions for data transfer it might need more mount points for storing the data. Therefore attention has to be paid to the individual settings for these parameters in comparison to the available mount points and the number of clients to be processed. Additionally, reading and processing one physical disk with more than one consumer thread might decrease local disk performance instead of increasing the overall performance. Whenever there is more than one physical disk to be processed by one client, more than one consumer thread is recommended, and the system variable RESOURCEUTILIZATION value should increase. 96 IBM Tivoli Storage Management Concepts

6.3.2 Transaction All data sent to IBM Tivoli Storage Manager storage during a backup or archive session is done within the bounds of a transaction. That means that not every single file is sent to the server separately. IBM Tivoli Storage Manager combines multiple files in one transaction to reduce overhead and to increase performance. When the client starts sending or receiving data, it pays attention to both sides of the communication (the server and the client). All operations are controlled in such a way that IBM Tivoli Storage Manager can detect any data inconsistency during the transfer (due to a network problem, full hard drive, or a file that already exists, for example). This provides a high level of data integrity for the IBM Tivoli Storage Manager product. A single transaction is an atomic action, the smallest possible unit of work. Data sent within the bounds of a transaction is either committed completely to the system at the end of the transaction, or it is all rolled back if the transaction is ended prematurely. Figure 6-9 on page 98 shows an example of two backup transactions (Transaction 001 and Transaction 002) that are on their way to the server. Neither of them has finished yet, because the client is still sending the files related to those transactions. As the server receives the files, it saves them in storage, but it will only commit the transaction in the server database after receiving all of the associated files. Chapter 6. Backup-archive client 97

IBM Tivoli Storage Manager Client "HARRY" B C D E F 02 A Transaction 001 Transaction 002 File00A File001 File00B File002 File00C File003 File00D File004 File00E File005 File00F... File00G FIle00H A B C D E F G H Transaction 001 G H Figure 6-9 Transaction processing The size of a transaction is controlled by the server setting TXNGROUPMAX, which sets the maximum number of client files that can comprise a single transaction, and the client setting TXNBYTELIMIT, which sets the maximum number of bytes that can be sent. Whichever limit is hit first as the client is sending its files will determine the complete transaction. 6.4 Backup IBM Tivoli Storage Manager can perform backups of both files and raw logical volumes. When backing up files, the IBM Tivoli Storage Manager server database keeps a list of all files and their attributes (time, date, size, access control lists, extended attributes). At each file backup operation, this list is compared to the current file system on the client workstation to determine new, deleted, and changed files. Raw logical volumes are treated as separate entities, and the management class policy is applied to the entire image as a whole. There is no tracking of individual files in an image backup; that is, it is treated as a separate object. More details on image and raw logical volume backup are given in 6.6, Backup set on page 124. 98 IBM Tivoli Storage Management Concepts

During backup, the client first establishes a session with the IBM Tivoli Storage Manager server. After that, it sends the data using the transaction controls as explained in 6.3.2, Transaction on page 97. IBM Tivoli Storage Manager stores a number of backup versions for each file or object on each client node. If and when the number of versions stored on the server exceeds the number set by the IBM Tivoli Storage Manager administrator, older versions are deleted as newer versions are made. When you back up files, IBM Tivoli Storage Manager also backs up all related directory information and access information. (See Figure 6-10.) Options File: COMM = TCP/IP Server = SRV_TSM1 Node = HAMBURG System Options File IBM Tivoli Storage Manager Client "HAMBURG" Backup IBM Tivoli Storage Manager Server "SRV_TSM1" Client Nodes Allowed Access TOKYO HAMBURG PARIS Figure 6-10 Backup in progress There are two types of file backup: incremental and selective. An incremental backup backs up files, directories, or subdirectories that are new or have changed since the last incremental backup. A selective backup backs up specific files or entire directories unconditionally. This file level backup can be extended for WAN-connected clients using sub-file backup. These clients usually possess connections to the IBM Tivoli Storage Manager server with only a small bandwidth. Using sub-file backup, only the parts of a file that have changed are transferred to the server. Another method of backup is called image or volume backup. In this case the backup process does not distinguish between single files but sends the specified volume as one single object to the IBM Tivoli Storage Manager server. Depending on your operating system the backup procedures can be extended with further features such as journal-based backup. This Windows-only feature keeps track of all changed files during their alteration. When a backup is started Chapter 6. Backup-archive client 99

using this feature, a separate process passes a list of all altered files to the backup process. So the backup process backs up just the files included in this list without searching the whole system for changes. 6.4.1 Incremental backup IBM Tivoli Storage Manager is unique in offering an incremental or progressive backup methodology for backing up client data. This approach can remove the need for periodic full dumps because only the changed files are backed up. This can have significant benefits in backup time, number of tapes used, reduced network traffic, size of backup servers, and manageability. The incremental backup operation is a full scan of the client s filesystems, which backs up all files and other information (and only those things) necessary to ensure that the IBM Tivoli Storage Manager inventory matches the current state of the client s storage. This means that the first time this is run on a new client, everything is backed up. Each time after this, only new and changed files are sent. During the incremental backup, the client queries the IBM Tivoli Storage Manager server so that it knows what files are currently stored. The client uses this information to: Back up new files Back up files whose contents have changed Expire backup versions on the server for files that were deleted from the workstation Figure 6-11 on page 101 shows an example of a daily incremental backup. On DAY1, we have two files (filea and fileb). On DAY2, filec is first written, and therefore, this is when it is first backed up. When we move to DAY3, fileb and filec are the only files copied again, because they are the only ones that have changed since the last backup. In our example, filea has never changed, so IBM Tivoli Storage Manager only stores one copy of this file. However, the changed files, fileb and filec, have two copies stored in the server. 100 IBM Tivoli Storage Management Concepts

filec filec Workstation data fileb fileb fileb filea filea filea Day1 Day2 Day3 Server storage filea, fileb filea, fileb, filec filea, fileb, filec fileb, filec Figure 6-11 Incremental backup processing 6.4.2 Selective backup During a selective backup, IBM Tivoli Storage Manager sends copies of the files to the server even if they have not changed since the last backup. This is useful if you want to back up many files that are not in the same directory structure, regardless of their actual status in the IBM Tivoli Storage Manager server. It may also apply where you want to enforce a complete backup. However, remember that versioning still applies. If you back up a file multiple times when it has not changed, this will result in having multiple copies of exactly the same file on the server, instead of a number of different versions of the file. This more or less defeats the purpose of IBM Tivoli Storage Manager version control. To avoid that, use the incremental backup technique command to back up only changed and new files. Typically, selective backup will only be used in special circumstances. Figure 6-12 on page 102 shows an example of a selective backup. On DAY1, filea and fileb are first backed up. Because we are running the selective command, on DAY2 they are also backed up even though they are unchanged, together with filec, which is new. The same thing happens on DAY3: filea, fileb, and filec are backed up again to IBM Tivoli Storage Manager storage. In the example, our final storage holds three identical copies of filea, three copies of fileb (two identical), and two different versions of filec. Chapter 6. Backup-archive client 101

filec filec Workstation data fileb fileb fileb filea filea filea Day1 Day2 Day3 Server Storage filea, fileb filea, fileb filea, fileb, filec filea, fileb filea, fileb, filec filea, fileb, filec Figure 6-12 Selective backup processing 6.4.3 Include-exclude lists IBM Tivoli Storage Manager gives a high level of control over which client data is actually backed up and which is excluded. It also controls the management class that is used for those files that do get backed up. The mechanism for controlling this on the client side is called the include/exclude list. Management classes are defined by the IBM Tivoli Storage Manager administrator and are described in more detail in Chapter 9, Policy management on page 161. If you do not specify any control, all locally attached client files and directories will be backed up and will be bound to a DEFAULT management class. However, this may take up too much space in server storage, or the backup operation may take too long to complete. You may only need to back up particular drives or filesystems and exclude all others. Or you may want to exclude from backup any files with a.tmp extension. You may need different management policy for certain critical files (such as spreadsheets, documents, and e-mail messages), and for ordinary files that you can easily get back if necessary (such as Internet files and temporary files). IBM Tivoli Storage Manager enables you to control how files are stored with respect to their management class. The include-exclude list is a set of references local to each client that controls which files are backed up and what management policy is used. If you do not select any special management, IBM Tivoli Storage Manager uses a DEFAULT management class. Figure 6-13 on page 103 shows how the backup-archive client decides which files are stored in the server and how they are stored. The INCLUDE rules explicitly tell how to handle data. The EXCLUDE rule forces IBM Tivoli Storage Manager to skip those objects. Everything else that is not defined in these rules is included by default. 102 IBM Tivoli Storage Management Concepts

In the example, files from the /home directory are bound to the PERSONAL management class. All files from the /public directory are bound to the SHARED management class. Because the include-exclude list does not reference any other special management class for files, all others are directly bound to the DEFAULT management class in the server, except the /temp directory, which is prevented from being backed up. Client IBM Tivoli Storage Manager client How do I manage file??? & HSM DRM files Exclude rules Include-exclude list... EXCLUDE all files from /temp INCLUDE all files from /home (they are PERSONAL) INCLUDE all files from /public (they are SHARED) All of the rest can be treated as DEFAULT Include rules Figure 6-13 Include-exclude list and rules Include-exclude rules are checked from the bottom up until a match is found. If a match is found, the processing stops and checks the option. If it is INCLUDE, the file is backed up to either a specified management class or the DEFAULT, if omitted. If the option is EXCLUDE, the file is not backed up. Any files that do not match any rule are backed up to the DEFAULT management class. Suppose that you have the following include-exclude rules: (3) include /temp/filedir/* (2) exclude /temp/filedir/project/* (1) include /temp/work/* Because IBM Tivoli Storage Manager performs include-exclude processing from bottom-up, it starts validating rule (1) through rule (3). Therefore, if we have a file called /temp/work/file1, it is included by rule (1). On the other hand, if we have a Chapter 6. Backup-archive client 103

file called /temp/filedir/project/newfile, this one is excluded by rule (2). A file called /temp/filedir/otherfile is included by rule (3). The include-exclude list is a very powerful tool for specifying exactly what a client is allowed to (or at least should) back up. Because you can use this function with many different commands, some special considerations should be mentioned: You can also specify include-exclude options within a server-based client option set. These statements have priority over the include-exclude statements in the local client options file. The server include-exclude statements are always enforced, placed at the bottom of the include-exclude list, and evaluated before the client include-exclude statements. To enable encryption for specific files or directories you have to use the include.encrypt option. The exclude.dir statements override all include statements that match the pattern. IBM Tivoli Storage Manager processes exclude.dir and other include-exclude statements first. For example, consider the following include-exclude list: exclude c:\test\file.txt include.compression c:\test\file.txt include.encryption c:\test\file.txt include.subfile c:\test\file.txt IBM Tivoli Storage Manager examines the exclude c:\test\file.txt statement first and determines that c:\test\file.txt is excluded from processing and is not a candidate for compression, encryption, or adaptive subfile backup processing. 6.4.4 Logical volume backup IBM Tivoli Storage Manager enables you to back up a file system or raw logical volume as a single object from your client machine. The IBM Tivoli Storage Manager client accomplishes this by dynamically loading an image plug-in utility that sends the object to the server using the IBM Tivoli Storage Manager API. This capability is currently available for the AIX, HP-UX, Solaris, Linux, and Windows 2000/XP clients and can be used on a logical volume whether or not there is an associated file system. This will ensure a clean backup. Windows clients require configuring an additional service that comes with the IBM Tivoli Storage Manager client. Figure 6-14 on page 105 shows the operation of the image backup and restore operation as a single object. 104 IBM Tivoli Storage Management Concepts

Server Database 1 entry DB Storage Pool 1 object Client FS 1 or /dev/hd9 Figure 6-14 Image backup and restore Logical volume backup has the advantages of improved backup and restore speeds and conserving server resource because the entire backup is treated as a single object and individual files are not processed during backup or restore. Similar to the standard incremental and selective backup filtering options, you can include specific logical volumes, assign a Management Class to image objects, and exclude file systems or a raw device from being backed up by specifying in the client include/exclude list as in the following examples: INCLUDE.IMAGE /.../* ImageMC EXCLUDE.IMAGE /dev/hd5 Setting the Copy Serialization parameter in your Management Class (see Chapter 9, Policy management on page 161 for more information) as Static (or Shared Static), directs that the filesystem (if one exists) will be unmounted first and remounted automatically as read-only before the backup proceeds. When the image backup is completed, the file system is remounted as it was originally. If the Copy Serialization parameter in your Management Class is Dynamic (or Shared Dynamic), the client performs the backup of the file system even if it is in use. This is not recommended as it will probably lead to an inconsistent backup image. The automatic mounting and unmounting operations are not applicable for raw devices image backup because there is no associated filesystem. Chapter 6. Backup-archive client 105

You can consider full logical volume backup (mode=selective) on its own or in combination with progressive backup operations based on your requirements, as in the following: Perform regular logical volume backup for raw devices used for application managed data spaces. Examples are offline backup of raw logical volumes used in database applications. Note that there is no incremental option in raw logical volume backup. Perform a combination of progressive and occasional image backup of your file system. This provides fast recovery as well as file level restore capability. Perform a combination of daily incremental-by-last-image-date backup with periodic image backup. The MODE option in the backup image command determines whether the backup is a full file system image backup (selective) or an incremental-by-last-image-date backup (incremental). This provides fast backup and recovery of the entire filesystem. File level restore is limited to files changed since the last full image backup. It is important to note that for incremental-by-last-image-date backup to work, it must not have any previous incremental backup of the filesystem using the incremental command. These options are illustrated in Figure 6-15. 1. Logical volume backup of raw-devices Restore of raw devices 2. Progressive incremental + periodical backup image Fast restore in case of disaster recovery scenario Unique command to restore at the point in time 3. Backup image + incrbydate backup Very fast backup No versioning tracking No file level restore 1 2 3 Client Server Figure 6-15 Options for image backup Only a UNIX root user can perform the backup and restore image operations. When you restore from an image backup, the entire previous contents of the logical volume or filesystem will be overwritten. 106 IBM Tivoli Storage Management Concepts

6.4.5 Open file backup Some files on your system might be in use when you try to back them up. These are called open files because they are opened by an application for its use. The IBM Tivoli Storage Manager client for Windows 2000/XP comes with a Logical Volume Snapshot Agent (LVSA) that performs a snapshot backup of files that are open (or locked) by other applications. Windows XP and Windows Server 2003 include the Microsoft Volume Shadow-Copy Service (VSS) that is able to perform online backup of in-use files via snapshot. The snapshot allows the backup to be made from a point-in-time copy that matches the file system at the time the snapshot is taken. Subsequent changes to the file system are not included in the backup. If the LVSA is not installed or in use: While IBM Tivoli Storage Manager attempts to back up open files, this is not always possible. Some files are open exclusively for the application that opened them. If IBM Tivoli Storage Manager encounters such a file, it cannot read it for backup purposes. If you are aware of such file types in your environment, you should exclude them from backup to avoid seeing error messages in the log file. Even when using the LVSA to support open file backup keep in mind that this might result in an inconsistent state backup. Locked files have to be reusable after doing a restore; otherwise, they are useless. If an application locks more than one file that is backed up using the LVSA, these files may have a different state because of the sequential order during backup processing. 6.4.6 Adaptive subfile backup As the number of laptop PCs approaches 20 percent of the PC install base, many central support organizations will need to provide storage management services for their mobile and remote workers. Mobile and remote computers have limited access to the infrastructure that serves the rest of the company. Some limitations include being attached to the corporate network with reduced bandwidth, limited connect time, and minimal assistance to perform the backup. This limited access both increases the criticality of storage management services and limits the applicability of traditional methods and policies. IBM Tivoli Storage Manager helps resolve these problems with its adaptive sub-file backup feature, which reduces the amount of data transferred while backing up changed files. This features enables the backup-archive client (Web client, command line, or GUI) to back up only the changed portion of a file, either on byte level or on block level, instead of transferring the whole file to the server every time. The changed file portion is backed up as a differential backup relative to the last complete backup of the file (base or reference file) and it is called delta file. All changes Chapter 6. Backup-archive client 107

since the last complete backup of the file are included in this delta file. In the case of a restore, this allows for the restore of the whole file by restoring only two sub-file components, one delta file and the last complete backup of the whole file, the base file (see Figure 6-16). changed file differencing algorithm client reference cache reference file IBM Tivoli Storage Manager Client digital signature sub-file backup server database digital signature IBM Tivoli Storage Manager Server server storage base file delta file logical file group Figure 6-16 Adaptive sub-file backup architecture The decision to base the differential on byte level or block level will be made at the backup of the base file, and it depends on the size of the file. Sub-file backup technology is not used for very small files (less than 1 KB in size) or for very large files (bigger than 2GB). If the delta file size exceeds 60 percent of the base file at the last sub-file backup, a new base file will be transferred. The adaptive sub-file backup, as well as the restore of a file consisting of a base file and the delta file, is completely transparent to the end user. All necessary file data separations or reconstructions happen under-the-covers of the backup-archive client. Also, all other IBM Tivoli Storage Manager features, such as policy management or fault-tolerant backup and restore, still fully apply. Adaptive sub-file backup is used for incremental as well as for selective backup. It is aware of multithreading and will work together with client data compression and encryption. 108 IBM Tivoli Storage Management Concepts

Sub-file backup and restore When a user attempts to back up a file having adaptive sub-file backup enabled, one of two kinds of backups can occur. The user has no influence on this; the backup-archive client itself decides, based on built-in rules, which of the following backup steps will occur: Back up the file as a base file component. Back up the file as a delta file component. The first step is always to make a backup of the entire file. This backup is considered to be the base file backup. Subsequent backups use delta file backups. Delta file backups take a delta of what has changed relative to and based on the reference file. The delta file backup can occur up to 20 times before a new base file backup occurs again. However, if the changes to the file are too numerous, and at the last delta file backup a compression of at least 40 percent could not be achieved, then a new base file backup will be performed. The base file and delta file represent versions of the same file. To restore a file version that has been backed up using adaptive sub-file technology, IBM Tivoli Storage Manager does not create incremental delta chains from all of the backed-up sub-file components. This means that in the case of three delta files backed up on three consecutive days, the backup-archive client does not have to restore three delta files in order to recreate the latest version of the file. Rather, only the base file and the delta file of the last day are restored. The delta file of the last day contains all changes that delta file 2 and delta file 1 contain. (See Figure 6-17 on page 110.) The differencing is performed only on the file data, and not on any other control data associated with the file such as ACL and DACL. During the restore operation, the control data of the delta file is preserved, as it represents the most current version of the control data. Chapter 6. Backup-archive client 109

Backup: file on client backed-up object Day 4 delta file 3 Day 3 delta file 2 Day 2 delta file 1 Day 1 base file Restore & Reconstruction: Day 5 backed-up objects 3 base file + = delta file file on client Figure 6-17 Adaptive sub-file backup and restore Adaptive sub-file backup considerations When using adaptive sub-file backup technology with mobile system backup, keep the following in mind. Scheduling of mobile backup Backups of mobile systems can be scheduled using the IBM Tivoli Storage Manager scheduling wizard. However, because mobile systems might not be reachable from the server due to the lack of communication, various other methods should be considered. Versioning and expiration process Because delta files are useless without the corresponding base file, the server processes the expiration of base files differently. Using the new server feature, logical file grouping, the server recognizes a base file as eligible for expiration but does not delete the file until all of its dependent delta files have expired. Adding sub-file components to backup sets When a delta file component is added to a backup set, the server also includes its corresponding base file with the backup set. If the base file and dependent 110 IBM Tivoli Storage Management Concepts

delta files are stored on separate volumes when a backup set is created, additional volume mounts may be required to create the backup set. Handling of non-file data Non-file data, such as alternate file streams or ACL information, is not processed by adaptive sub-file backup. Non-file data is restored directly from the delta file component, because there is no way to copy non-file data from one place to another on the file system. Restore limitations When restoring adaptive sub-file backup files to the client system, multiple file copies are stored in the temporary reconstruction directory. In extreme cases this leads to 2.7 times over-committing of the file system size. If the file system fills up, the restore will stop. Reducing the number of files restored at once is thus recommended. Another limitation occurs when the client runs under a different user than the user who originally created the file version that the client is attempting to reconstruct. In this case, it can cause permission problems when renaming a file back to its original name. If the restore session stops for any unexpected reason, the temporary files will remain in the temporary directory. If the user does not restart the restore session, the client will not clean up this directory, and the file system can fill up. For further details, refer to Tivoli Storage Manager Version 3.7.3 + 4.1 Technical Guide, SG24-6110. 6.4.7 Journal-based backup Journal-based backup provides an alternative to traditional progressive incremental backup, which under certain circumstances may dramatically increase overall backup performance. The main difference between journal-based backup and progressive incremental backup is the method in which the list of backup candidate objects is derived. The backup candidate list specifies objects for a particular filesystem that are to be backed up, expired, or updated on the IBM Tivoli Storage Manager server by an IBM Tivoli Storage Manager backup-archive client. Progressive incremental backup derives the backup candidate list by building and comparing the list of active previously backed-up objects stored on the Tivoli Storage Manager server with the list of objects currently residing on the local filesystem. Chapter 6. Backup-archive client 111

The server list is obtained over the network and the local list is obtained by scanning the local filesystem. Objects that exist in the local list but do not exist in the server list are added as backup candidates to the candidate list. Objects that exist in both lists but differ in some way (such as attributes, policy, and size) are also added as backup candidates unless only the IBM Tivoli Storage Manager database attributes differ, in which case they are added as attribute update candidates. Objects that exist in the server list but don't exist in the local list are added as expiration candidates. Under journal-based backup, the IBM Tivoli Storage Manager backup-archive client obtains the backup candidate list by contacting the Journal Based Backup Daemon. This is a local background process (a service on Windows NT/2000) that manages and maintains a journal database of change activity for each file system being journaled. Journal database entries are generated by real-time file system change activity, and they specify objects to back up or expire. (Attribute update actions are not currently supported.) The type of change activity that generates journal entries is configurable by the user and may consist of any combination of the following: Objects created, deleted, or renamed on the file system Size changes Modification time/date changes Access time/date changes Attribute changes Security (ACL) changes Once a journal entry has been processed successfully, the IBM Tivoli Storage Manager backup-archive client notifies the Journal Based Backup Daemon to remove the journal entry from the journal database. Notes: IBM Tivoli Storage Manager does not use the journaling facility inherent in Windows NTFS Version 5 file systems or any other journaled file system. Journal-based backup uses supported Microsoft Window APIs to monitor and update a local database. If the Journal Engine Service is installed and running, then by default the incremental command performs a journal-based backup on any journaled file systems. 112 IBM Tivoli Storage Management Concepts

Advantages of journal-based backup Journal-based backup can improve incremental backup performance in most environments. With journal-based backup, the client does not scan the local file system or obtain information from the server to determine which files to process. As such, journal-based backup reduces network traffic between the client and server. The backup-archive client, as always, still sends data (files) to the IBM Tivoli Storage Manager server and, as has always been the case, the IBM Tivoli Storage Manager server populates the IBM Tivoli Storage Manager database with the file details and location. As the backup-archive client does not carry out the initial metadata conversation, the backup-archive client does not have to sit idle. The backup-archive client is able to begin sending the files to the IBM Tivoli Storage Manager server as soon as the journal-based backup is initiated. This means faster backup times and less backup-archive client idle time. Previously, this file list construction and processing could severely impact any IBM Tivoli Storage Manager backup-archive clients that were memory- or CPU-bound. Journal-based, incremental, and incremental-by-date backup An incremental-by-date backup takes less time to process than a full incremental backup and requires less memory, because a list of all files is not required from the IBM Tivoli Storage Manager server. This is also now the case for journal-based backup. An incremental-by-date backup backs up new and changed files with a modification date later than that of the last incremental backup stored at the server. There will be occasions where a new file that has been created by copying another file will not be picked up by the incremental-by-date backup. A journal-based backup backs up any file that the traditional incremental would back up. An incremental-by-date backup does not update the server with the date of the last full incremental. Therefore, the next incremental-by-date backup will back up these files again. This was originally called the differential backup. The longer the period between traditional incremental or journal-based backup, the more data will be backed up. If the same objects change every day, neither the journal backup nor the incremental-by-date backup will increase in size. Chapter 6. Backup-archive client 113

Comparing the incremental-by-date and the journal-based backup to a traditional incremental backup shows that they do not maintain current server storage of all of your workstation files because: Incrbydate does not expire backup versions of files that are deleted from the workstation. Journal-based backup does, except for depending on the INCRThreshold setting. The default setting for INCRThreshold is 0. It does not rebind backup versions to a new management class if the management class has changed. This is not true for journal-based backup. It does not back up files with attributes that have changed, unless the modification dates and times have also changed. This is not true for journal-based backup. It ignores the copy group frequency attribute of management classes, unless it is set to 0 (default). This is also true for journal-based backup. Previously, it was recommended that if you had limited time during the week to perform backups but had extra time on the weekends, you could use an incremental-by-date backup on weekdays and a full incremental backup on weekends to maintain current server storage of your workstation files. Therefore, when time is a critical factor and there is insufficient time to perform a traditional incremental backup, it is recommended that journal-based backup now be used in preference to the incremental-by-date backup. An incremental with journaling active can take less time to complete than an incremental-by-date because the incremental-by-date is actually a differential backup. For this reason, if repeated over several days, the size of the backup actually grows. Under the same circumstances the journal-based backup will process fewer files and complete in less time. Journal-based backup differs from the traditional incremental backup in the following ways: It does not enforce non-default copy frequencies (other than 0) with journal-based backup. Attribute changes to an object require a backup of the entire object with journal-based backup. Monitored attributes may be different from those of the traditional incremental backup. For these reasons, you may want to use the nojournal option to perform a traditional incremental backup on a semi-regular basis, depending on the INCRThreshold setting. For more, see Tivoli Storage Manager Version 4.2 Technical Guide, SG24-6277. 114 IBM Tivoli Storage Management Concepts

6.4.8 Group backup A group backup enables you to create a consistent point-in-time backup of a group of files that is managed as a single logical entity: All objects in the group are assigned to the same management class. Existing exclude statements for any files in the group are ignored. All objects in the group are exported together. All objects in the group are expired together as specified in the management class. The group backup function also supports differential and full backup. You usually restore the entire group to get a consistent point-in-time restore, but IBM Tivoli Storage Manager supports single file restore from a group as well. The group backup function is similar to the well-established archive function of IBM Tivoli Storage Manager. The archive function described in 6.5, Archive on page 121 groups files together as one current state. Archive does not support differential backup, and archive objects cannot be rebound to another management class. 6.4.9 Active and inactive file versions One of the most important concepts in IBM Tivoli Storage Manager data management is the difference between an active backup version and an inactive backup version. Assume a new file is created on your workstation. The next time you run a backup operation (say, Monday at 9 p.m.), IBM Tivoli Storage Manager server stores this file. This copy of the file is known as the ACTIVE version. When you run an incremental backup again (say, Tuesday at 9 p.m.), IBM Tivoli Storage Manager uses this ACTIVE version already stored to check back with your workstation to determine whether the file has changed since the last backup. If it has, it is backed up again. This version now becomes the ACTIVE version and the copy from Monday becomes an INACTIVE. The most recent backed-up version of the file is always the ACTIVE version, as long as it still exists on the original client. IBM Tivoli Storage Manager will keep storing a new ACTIVE version and inactivating the previous active version, up to the limit of the total number of versions defined to be retained in the management class. Once this limit is exceeded, the oldest INACTIVE version is deleted from IBM Tivoli Storage Manager storage and will no longer be able to be restored. This process of maintaining the ACTIVE and INACTIVE versions (up to the management class limit) continues until the file is deleted from the original client. If this occurs, when the next incremental backup is run, the server detects that Chapter 6. Backup-archive client 115

the file no longer exists on the client. All stored versions of the file now automatically become INACTIVE, and some of the oldest versions of the file may also be deleted. This would happen if the management class setting for number of versions of a deleted file to retain is less than the number of versions of an existing file to retain. Therefore, an ACTIVE file version is stored along with INACTIVE versions as long as the file is still resident on the client system. If the file is deleted, then only INACTIVE version(s) of the file will exist in server storage. The absence of an ACTIVE file version in IBM Tivoli Storage Manager storage indicates that the file has been deleted from the client machine, so the only copy is now in IBM Tivoli Storage Manager storage. IBM Tivoli Storage Manager controls the retention of its ACTIVE and INACTIVE versions of a file that exist on a client machine by using two criteria defined in the Management Class: How many versions: The parameter that controls the number of backup versions is called VEREXIST. This may be set at a specific number or to UNLIMITED. How long to keep: The RETEXTRA parameter controls how much time must elapse before an INACTIVE file version is considered expired. This parameter controls how long to retain all remaining inactive files and may be set at a specific number of days or to NOLIMIT, meaning they will never be expired. Important: An ACTIVE file version is never expired. Even if you never change a particular file after the first incremental backup, IBM Tivoli Storage Manager will keep this file version indefinitely. For a file deleted on a client machine, IBM Tivoli Storage Manager uses different criteria: How many files: The parameter that controls the number of inactive backup versions is called VERDELETED. This number is normally less than or equal to the number you have for VEREXIST. How long to keep files: The RETEXTRA parameter controls how much time must elapse before an INACTIVE file version is considered expired. This parameter controls how long to retain all remaining inactive files except for the last one and may be set at a specific number of days or to NOLIMIT, meaning they will never be expired. How long to retain the last file: The RETONLY parameter controls the last inactive copy of a file. As files get expired by RETEXTRA, you can configure IBM Tivoli Storage Manager to manage the last inactive copy differently, so that you can keep that file for a longer period of time. It may be set at a specific number of days or to NOLIMIT, meaning they will never be expired. 116 IBM Tivoli Storage Management Concepts

Typically, configure RETONLY to be either the same value or longer than RETEXTRA because it functions as a grace period before expiring the file. Figure 6-18 shows an example of a file (file1) that was first backed up on January 1 and then on January 5, 15, 20, and 22. On January 22, the backup procedure had four versions of the same file (January 22 being the active and most recent copy, and the January 1 copy being expired due to VEREXIST limits). When file1 is deleted on the client on January 23 and expiration runs, all file1 versions become inactive and the IBM Tivoli Storage Manager server uses the VERDELETED information to reduce the number of inactive files. Because VERDELETED is set as 2, old versions of the file are immediately expired. Now file1 has only two versions in the IBM Tivoli Storage Manager server (January 20 and January 22). These files are now handled by RETEXTRA until their expiration value is reached. Version control File exists 22/Jan Policy Settings: verexist = 4; verdel = 2; retextra = 30; retonly = 45 File deleted 23/Jan File1 File1 File1-01/Jan expired (not accessible) File1-05/Jan expired (not accessible) File1-05/Jan File1-15/Jan File1-15/Jan File1-20/Jan Inactive copies File1-20/Jan File1-22/Jan File1-22/Jan Inactive copies Active copy (verexist & retextra) (verdel, retextra, & retonly) Figure 6-18 Active and inactive files 6.4.10 Retention The retention period of a file version is the length of time in which that file is maintained by IBM Tivoli Storage Manager and accordingly is available to be restored to the client. When a file version is no longer retained, then it is expired from the IBM Tivoli Storage Manager database. A file version is expired either Chapter 6. Backup-archive client 117

because it is superseded by version control (VEREXISTS, VERDELETED) or it is older than the retention period (RETEXTRA, RETONLY). Retention only applies to INACTIVE files because ACTIVE files are never expired. The retention period is measured from the time when the file version becomes inactive. In our example, Figure 6-19 shows a scenario in which the last inactive backup copy of file1 will be kept up to March 9th, 2000. Deleted file : Policy Settings: verexist = 4; verdel = 2; retextra = 30; retonly = 45 Dates File1-05/Jan File1-15/Jan File1-20/Jan expired (not accessible) 22/Jan - file still active 23/Jan - file deleted ( enforce verdel=2 ) 24/Jan - server expire inventory... 21/Feb - server expire inventory (delete 20/Jan file1 version) 23/Feb - server expire inventory (RETONLY control takeover) 24/Feb - RETONLY control... 08/Mar - RETONLY last day control (23/Jan + 45 days) 09/Mar - server expire inventory 09/Mar - File1 Last inactive copy deleted File1-22/Jan/1999 Last Inactive Copy (retonly) Figure 6-19 RETEXTRA and RETONLY expiration processing Usually, VEREXIST should be greater than or equal to VERDELETED (VEREXIST >= VERDELETED) and RETONLY should be greater than or equal to RETEXTRA (RETONLY >= RETEXTRA). 6.4.11 Backup binding Any object stored in the IBM Tivoli Storage Manager server is controlled by specific criteria in such a way that the server knows how long that object must be kept. In other words, a backup file, directory, and any other object stored in IBM Tivoli Storage Manager has one management class reference that dictates how many copies can be kept and how long a backup file must exist in the server. The link process between the file and the management class is called binding. The binding process occurs when you perform an incremental backup. The IBM Tivoli Storage Manager client checks both the server management classes and the client include-exclude list or client option files to perform the binding process. 118 IBM Tivoli Storage Management Concepts

Figure 6-20 shows an example of many files and their management class bindings. In the example, files from the /home directory are bound to the PERSONAL management class. All files from the /public directory are bound to the SHARED management class. Because the include-exclude list does not reference any other specification for files, our /adsm directory is implicitly bound to the assigned default management class in the server. An object can only ever be bound to one management class. Binding Concepts IBM Tivoli Storage Manager client IBM Tivoli Storage Manager server Management Classes /public /public/itsm_guide : : /home /home/lucia/project_plan99 /home/lucia/old_plan98 : /itsm /itsm/bin/dsm.opt /itsm/bin/dsm.sys : include-exclude list /home - personal /public - shared <assigned default> Server Database : /home/lucia/project_plan99 (personal) /home/lucia/old_plan98 (personal) : /public/itsm_guide (shared) : /itsm/bin/dsm.sys (<default>) /itsm/bin/dsm.opt (<default>) SHARED:... PERSONAL:... : <default>:... Figure 6-20 Binding files to management classes 6.4.12 Rebinding Because a file stays bound to one single management class, every time you run a new incremental backup operation, the server checks to see if the file still belongs to the same management class and changes the class if necessary. This Chapter 6. Backup-archive client 119

process is transparent to the user and is called rebinding the file. A file or directory will be rebound in the following cases: Include-exclude list: If you change the management class for a file, this affects all previous backup versions of that file and all future backup operations for that file as well. Changes in the number of management classes: If you delete or rename a management class, the server rebinds the files to either a DEFAULT class or uses grace periods in the policy domain to control retention. In this case, the server controls data by retention and not by versions. This may not be desirable, since you do not have a management class controlling those files. Although the rebinding process for this case was unsuccessful, IBM Tivoli Storage Manager still controls the file by other means. For further details on management classes and settings, see 9.4, Management class and explicit binding on page 167. 6.4.13 Backup special considerations The IBM Tivoli Storage Manager incremental backup actually offers two options, complete and date only. These are also known as full and partial incrementals, or full incremental and incremental-by-date. Normally you would use the default, the complete or full incremental, which is described in 6.4.1, Incremental backup on page 100. Many attributes of each file are examined to determine whether it has changed and would need to be backed up. In a partial incremental operation, the client only asks the server for the date and time of the last incremental backup. If a file s last changed date and time is after that of the last backup, the file is backed up. Otherwise it is not, even if the file is new to the workstation. Because changes to ACL or file permissions do not change the last changed date and time attributes, a partial incremental would not detect this, so the file would not be backed up. A file that is copied or created on the client with an older date/time stamp than the date/time of the last backup also would not be sent. In a partial backup, deleted files from the client are not recognized, and no version expiry or rebinding takes place. Because a partial incremental backup only performs a fraction of the processing of the normal full backup, it does not ensure that the files contained in the server storage exactly match the current state of the files on the client. For example, files that normally would be backed up during a full incremental might not be backed up during a partial incremental; and old files that should be deleted from the server might not be deleted. Since this is the case, why have the partial incremental possibility at all? The reason is that this operation takes less time to complete than the regular full backup. So, in some particular circumstances where there is a problem meeting a limited backup window, you might use a partial incremental operation. If you do this, you must remember to periodically 120 IBM Tivoli Storage Management Concepts

run full incremental backups to bring the IBM Tivoli Storage Manager server in line with your workstation s status. For example, if you have only a limited time during the week to perform backups, but have extra time on the weekend, you can use partial backups on the weekdays, and then use full incremental backups on the weekends. However, if there is not a problem with the backup window, then always run the full incremental option. 6.5 Archive The IBM Tivoli Storage Manager Archive function stores selected files unconditionally on the server according to the applicable management class limits. Unconditionally means that there is no version limit and they will be retained for the defined time period regardless of whether they are deleted on the client. Archived files are useful if you want to take a snapshot of particular files, or if you want to delete files to free space, yet still have the ability to retrieve them if required. It is common to have legislative requirements to archive business records for long periods of time, and the archive function is ideal for this purpose. Figure 6-21 shows a schematic archive operation. Options File: COMM = TCP/IP Server = SRV_TSM1 Node = HAMBURG System Options File Backup Client Nodes Allowed Access TOKYO HAMBURG PARIS IBM Tivoli Storage Manager Client "HAMBURG" Figure 6-21 Archive in progress IBM Tivoli Storage Manager Server "SRV_TSM1" 6.5.1 Packages Archive packages are groups of files archived together with a common description. The system automatically supplies a description consisting of the time and date stamp, but you can override this with your own meaningful Chapter 6. Backup-archive client 121

description. This description is used for easy searching and selection of archive packages to retrieve. You can add to an existing package on a subsequent archive operation by supplying an existing archive package description. You can retrieve individual files within a package and delete files from a package. Figure 6-22 shows a summary of the packaging features. Archived files with common description Archive or retrieve complete package Retrieve individual files in package Add files to existing package Delete files from package Package Description Created using unique archive description Default description Archive Date: mm/dd/yyyy Time: hh:mm:ss Retrieve using the GUI client Display archived files hierarchically Grouped by archive descriptions file Archive Description Figure 6-22 Packaging files 6.5.2 Client space reduction You can use archives to release storage space on your workstation and delete files as you archive them. This is useful when you know in advance that it is no longer necessary for a file to stay in the workstation, but it may still be important to keep the file for some time. You can archive and delete any file and use any retention period available in the archive management classes. Figure 6-23 on page 123 shows an example of an employee who has left the company. Because this employee had many files that may be needed, all files are saved for 30 days and deleted from the fileserver to make room for other users. The archive function includes an option to automatically delete the files after they are successfully received at the server. 122 IBM Tivoli Storage Management Concepts

Corporate Fileserver mailbox files fileb filec Spreadsheets filea "delete from client" Employee: LUCIE Personal files: keep for 30 days Figure 6-23 Archiving unnecessary files 6.5.3 Retention When you archive a file, you can select from among the available management classes that your client machine has access to. This makes it possible for you to select the retention period (according to the retention period in days specified in the archive copygroup) for all of the data you are archiving. Archiving is different from file backup in that the user may select from the available management classes to determine the retention. For file backup, the user may not control the management class to which the files are bound. Typically, you might use archives to save information that has either a legal requirement (such as account information, annual reports, billing information, and annual customer reports) as shown in Figure 6-24 on page 124, or even an internal audit requirement (to keep application logs, user activity information, employee files, and so on). Chapter 6. Backup-archive client 123

file Accounts Payable 2002-2003 keep for 3 years Figure 6-24 Archiving long-term files 6.6 Backup set IBM Tivoli Storage Manager enables you to generate a copy of your client s most recent backup from the IBM Tivoli Storage Manager server onto sequential media. This is accomplished using the generate backupset command, which copies all active file versions of the fileset from server storage onto the media. This copy of the backup, also called backup set or portable backup, is self-contained and can be used independent from IBM Tivoli Storage Manager to restore the client s data from a locally attached device that can also read this media, such as a CD-ROM. This technique provides IBM Tivoli Storage Manager client rapid recovery with no server and network dependency. You can also transfer the backup set from one server to another by generating the backup set on the source server, then transporting the backup set volume and defining it to the destination server, assuming both servers have the same media type, as shown in Figure 6-25 on page 125. The same node name is required to be registered on both servers. 124 IBM Tivoli Storage Management Concepts

Storage Pool Different End user client A I A A I tsm> generate backupset A restore backup set with or without access to the IBM Tivoli Storage Manager Server Original End user client A A Backup set IBM QIC-5010 Data Cartridge Figure 6-25 Portable client backup set Note: LAN-free restore of a backup set still requires the IBM Tivoli Storage Manager client to be installed. Therefore the portable backup set does not provide a bare machine recovery capability. 6.6.1 Backup set planning Each backup set is tracked as a single object in IBM Tivoli Storage Manager and has a retention value associated with it. As such, backup set is also called instant archive because it can be used as an archive of client data retained for a defined period of time. The retention value only governs how long the IBM Tivoli Storage Manager server retains the backup set in its volume history. If the retention period of the backup set expires, those volumes return to scratch status and become available for reuse. However, because each backup set is self-describing, the retention period has no significance to the backup set as long as the backup set volumes have not been reused, such as if you have copied the backup set to a local file or to CD media. At any point in time, the backup set can be redefined to the same or different server using the define backupset command. You can use this feature to provide an instant archive for your IBM Tivoli Storage Manager client and to keep the backup for as long as its required. A new retention period is assigned each time the backup set is defined. Chapter 6. Backup-archive client 125

6.6.2 Server/client media support If you want to restore the backup set directly onto the client without requiring contact with the IBM Tivoli Storage Manager server, then the media that you use to create the portable backup set must be available and supported on both the server and client. There are a few ways to do this: Use a tape device that is available on both client and server. There are limitations on the exact devices supported for this, so you should consult the IBM Tivoli Storage Manager Web pages for up-to-date information. Use a sequential device class written to disk to transfer the files to the client disk. Either create the backup set on disk and use a CD-writer program to copy the set onto CD, or if the operating system supports writing directly to CD or Jaz or Zip drive, use it directly in IBM Tivoli Storage Manager by defining a REMOVABLEFILE device class. This type of class is also useful for transferring backup sets between IBM Tivoli Storage Manager servers. 6.7 Restore To restore a file, a directory, or even the whole machine, you need to know two things: what you want to restore (file name, directory), and, optionally, from when (point in time) if you want to restore a file other than the most recent one. You do not need to know where the data actually is. When you request a file, IBM Tivoli Storage Manager finds out the location of that particular file version from its database. To restore files, specify the directories or selected files, or select the files from a list or GUI window. By default, only ACTIVE file versions will be available for selection; however, INACTIVE versions can be specified easily. You can restore files to their original location or specify a different directory. Collision options control whether existing files of the same name are replaced. Figure 6-26 on page 127 shows a schematic of the restore operation. 126 IBM Tivoli Storage Management Concepts

Options File: COMM = TCP/IP Server = SRV_TSM1 Node = HAMBURG System Options File Restore Client Nodes Allowed Access TOKYO HAMBURG PARIS Figure 6-26 Restore in progress IBM Tivoli Storage Manager client "HAMBURG" IBM Tivoli Storage Manager server "SRV_TSM1" You can restore using the command line interface, GUI, or Web browser interface (where available on the client operating system platform). The browser interface enables you to initiate the restore remotely so that you do not have to be physically located at the system being restored. 6.7.1 Restartable restore When you are running a normal file-restore operation, IBM Tivoli Storage Manager keeps track of the files that you have already restored, so that it can retry the operation should you have any network problems. If the restore operation terminates prematurely for any reason, such as network failure, the session state remains in the database so that it can be restarted from the last completed transaction. This is known as a restarting the restore and saves you from having to re-send files that were already restored to the client before the session aborted. Figure 6-27 on page 128 shows how a restartable restore is handled. There is a separate option in both the GUI and CLI for resuming the restore operation. Chapter 6. Backup-archive client 127

Resumes at point of interruption Restore states Active Restartable Restarts on transaction boundary Transparent to client 1 2 Restore failure Point of restart Transactions Restore progress Figure 6-27 Restartable restore processing 6.7.2 Point-in-time restore A point-in-time operation restores the specified objects to the state that existed at a specific date/time. A point-in-time restore is supported on the filespace, directory, or file level. You must specify a sufficiently long retention period in the management class to enable this to occur. To provide a point-in-time restore capability for, say, up to one month previously, set the parameters VEREXISTS and VERDELETED to NOLIMIT and RETEXTRA, and RETONLY to at least that number of days. This way, it does not matter how many times the files change in the restorable period because you will always have enough versions stored to be able to perform the restore. Figure 6-28 on page 129 shows a situation where data is being expired as new files are backed up. IBM Tivoli Storage Manager can restore any file version from January 7th to January 3rd (but not January 2nd or January 1st because they are already expired due to the RETEXTRA parameter). 128 IBM Tivoli Storage Management Concepts

Retain extra versions for 4 days file backup file file file file file file file Expired (not available) Client filespace Jan 7 Jan 6 Jan 5 Jan 4 Jan 3 Jan 2 Jan 1 Figure 6-28 Expiration and point-in-time restore Suppose that we have many backup versions stored, as shown in Figure 6-29 on page 130. We had only filea and fileb existing on our client at the previous backup. On DAY1, fileb is deleted, which is picked up during the DAY1 backup. On DAY2 filec was created. Sometime after this, filed, filex, and filey are also created and backed up. We also update filea, creating a newer version, and delete filec. So, at the present, DAY10, we have filea, filed, filex, and filey on our workstation. We now request a point-in-time restore for DAY2 of this directory. IBM Tivoli Storage Manager restores filec, which had been deleted, and replaces filea with the older version (option replace=yes). Our machine now has filea and filec as at DAY2, and filed, filex, and filey from the most recent day. A point-in-time restore observes the following rules: 1. A file created after DAY2 is not restored; only the changes made before the date/time are restored (filea in our example). 2. Files that were created on the client after the point-in-time date are not deleted (filed, filex, and filey in our example). 3. A point-in-time restore will restore files deleted after the point-in-time date (filec), but not files deleted before (fileb). 4. IBM Tivoli Storage Manager restores file versions from the most recent backup before the specified point-in-time date. Chapter 6. Backup-archive client 129

Workstation data 3 filea fileb filec filea filec filea filed 1 Incremental Backup Day1 Day2 Dayn ADSM Point-in-Time 4 Point-in-Time Request Workstation data (Day 10) filed filex filey 2 filec filex filey filea filea filed Day 10 Position (before restoring Day2) After Restore Figure 6-29 Point-in-time rules You must perform incremental file backups on an IBM Tivoli Storage Manager Version 3 or later server in order to support a point-in-time restore. The server is only notified when files are deleted from a client filespace or directory during an incremental backup. Selective and incremental-by-date backups do not notify the server about deleted files. Run incremental backups at a frequency consistent with possible restore requirements. For more information, see 6.4.13, Backup special considerations on page 120. Figure 6-30 on page 131 shows another scenario for point-in-time restore. If we try to restore a file from January 18th, it can use Monday s position to recover that file. On the other hand, if you need a file from January 22nd, the most recent image that IBM Tivoli Storage Manager can use is the data from the previous day (January 21st) because we have not yet run a backup on January 22nd. 130 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Manager server Examples 18/Jan/1999, 10:30 - (use monday's backup) 20/Jan/1999, 10:00 - (use monday's backup) 20/Jan/1999, 11:10 - (use wednesday's backup) 21/Jan/1999, 11:00 - (use thursday's backup) 22/Jan/1999, <any time> - (use thursday's backup) & H SM D RM W hat date and time? no backup perform ed 10:00 11:00 07:00 no backup performed Monday 18/Jan/1999 Tuesday 19/Jan/1999 W ednesday 20/Jan/1999 Thursday 21/Jan/1999 Friday 22/Jan/1999 Figure 6-30 Point-in-time restore examples 6.7.3 Multi-session restore Multi-session restore enables the backup-archive clients to perform multiple restore sessions for no-query restore operations, increasing the speed of restores. This is similar to the multiple backup session support. Multi-session restore exploits the mount points available on the server. If the data to be restored resides on several tapes, there are sufficient mount points available, and the restore is done using the no-query restore protocol, then multiple sessions can be used to restore the data. Another prerequisite for doing a multi-session restore is the data spreading. The data being restored has to be saved on more than one sequential volume or on a random access volume so that the client is able to connect via more than one session. Otherwise the IBM Tivoli Storage Manager client would start a standard single session restore. Note: Multiple restore sessions can only be no-query operations. 6.7.4 Logical volume restore IBM Tivoli Storage Manager gives you the option to restore the entire logical volume from the full image backup, typically for a raw logical volume, or with options to restore and bring the logical volume status to the most current backup status (for a filesystem). Where there is a filesystem associated with the logical Chapter 6. Backup-archive client 131

volume, if you have also been doing regular incremental backups of that filesystem, you can use the INCREMENTAL option in the restore image command. This requests changes to files recorded at the server since the full image backup was made and restores these after the image restore so to bring it up to date. You can also specify the DELETE option with the restore image command, which will query the server for files deleted since the image was made and remove these files. Note that the restore image command will completely overwrite the existing logical volume and its filesystem. When performing an image restore, consider the following: Restoring the image of a volume will restore the volume to the same state that it was in when you performed your last image backup. Be absolutely sure that you need to restore an image, for it will replace your entire current file system or raw volume with the image on the server. 6.7.5 Backup set restore Ensure that the file system or volume to which you are restoring the image is at least the same size as the image that is being restored. Image restores are always offline. Ensure that the file system is not in use. The client locks the file system before starting the restore. If the file system is in use when the client attempts to lock the file system, the restore will fail. The client unlocks the file system after the restore completes. You cannot restore an image to the location where the IBM Tivoli Storage Manager client program is installed. If you created an image of the system drive, you cannot restore the image to the same location because the client cannot have an exclusive lock of the system drive. Also, because of different system component configurations, the system image may not be consistent across components (such as Active Directory). Some of these components can be configured to use different volumes where parts are installed on the system drive and others to non-system volumes. If you have run progressive incremental backups and image backups on your file system, you can perform an incremental restore of the file system. This process updates the original image with individual files backed up after the last image backup. Optionally, if files were deleted after the original backup, the incremental restore can delete those files from the base image. Incremental backups and restores can be performed only on mounted file systems, not on raw logical volumes. Restoration of a backup set can be performed on a complete filespace level or by selecting individual files. You can restore from backup set using either: Server-based backup set restore from IBM Tivoli Storage Manager server 132 IBM Tivoli Storage Management Concepts

Local backup set restore directly via the IBM Tivoli Storage Manager client from locally attached devices without contacting the server To restore from the backup set, the node name of the client must match the one that was defined in the backup set. If using LAN-free restore, the backup volumes are mountedon the client by the backup-archive client through normal operating system device drivers and file system media such as CD-ROM, Jaz, Zip, and disk. 6.7.6 Cross-platform restore IBM Tivoli Storage Manager enables... you to restore files from one client node to another client node. The restoring client node must be able to understand the filesystem of the original backup. For example, you could restore a FAT filesystem made from a Win98 client onto an Windows NT client, since Windows NT understands the FAT filesystem. However an NTFS backup could not be restored onto a UNIX system because it is not compatible. You can specify the source and destination for a restore operation and provide a different destination directory path. You are prompted for your password using this feature, but ownership is not changed. For example, suppose that you back up a UNIX file (/home/alemos/file1) from user alemos, and this user has an identification number 201 (UID=201). If you try to restore this file to another UNIX machine, then it will still be UID=201, even if the user (UID=201) does not exist, or if it is another one (for example UID 201=CLAUDIA). This means that whenever you restore a file from another platform to a machine with different authorization rules, you must check the permissions and also the ownership for those files in the new machine. Important: IBM Tivoli Storage Manager offers multiple ways for accessing files being backed up by another node. The recommended way is to use the -fromnode function. When using the -virtualnode function the receiving client must use the same operating system as the original (source) client; otherwise, a cross-client restore with different operating systems runs the risk that the original client will no longer be able to access its data. This is because IBM Tivoli Storage Manager internally changes the associated operating system for the client node to the one accessed. Figure 6-31 on page 134 shows a machine (HAMBURG) being restored to another machine (PARIS). In our example, both machines are from the same operating system release and all users are exactly the same, thus recovery is straightforward. Chapter 6. Backup-archive client 133

BACKUP IBM Tivoli Storage Manager Server RESTORE Client: HAMBURG Figure 6-31 Cross-platform restore Client: PARIS 6.8 Retrieve The retrieve command obtains copies of archived files from the IBM Tivoli Storage Manager server. You can specify either selected files or whole directories to retrieve archived files. The description option enables you to search for the descriptions assigned to the files when they were archived; you may decide to replace the files into the same directory from which they were archived, or into a different directory. Figure 6-32 on page 135 shows a schematic view of the retrieve processing. 134 IBM Tivoli Storage Management Concepts

Options File: COMM = TCP/IP Server = SRV_TSM1 Node = HAMBURG System Options File Retrieve Client Nodes Allowed Access TOKYO HAMBURG PARIS IBM Tivoli Storage Manager Client "HAMBURG" IBM Tivoli Storage Manager Server "SRV_TSM1" Figure 6-32 Retrieve in progress 6.8.1 Retrieve key concepts 6.8.2 Packages The retrieve option obtains copies of archived files from the IBM Tivoli Storage Manager server. You can specify either selected files or whole directories to retrieve files. Use options such as the description option that enable you to search for descriptions assigned to the files when they were archived. As explained in 6.5.1, Packages on page 121, you can search for a specific file within a package, or even retrieve the whole package. When you retrieve one or multiple files, IBM Tivoli Storage Manager locates the volume where both directories and files are, so you do not need to know which tape holds the data. Figure 6-33 on page 136 shows a retrieve window where you can examine all the previously archived packages. A search filter is also provided so that you only look for packages matching a certain string. You can see a series of entries of the same file with different weekly dates attached. Chapter 6. Backup-archive client 135

Figure 6-33 Retrieval from GUI 6.9 Backup versus archive IBM Tivoli Storage Manager manages backup and archive objects differently with respect to their versioning and retention. Use IBM Tivoli Storage Manager backup/restore when you want to control the number of versions and retention period for files. IBM Tivoli Storage Manager uses the management class definitions to enforce both the number of versions for a file (active and inactive) and the retention period. Because the incremental function rebinds the files to one management class, it is not possible to have different management classes for the same file. (IBM Tivoli Storage Manager incremental rebinds all versions.) You can run backups to save changing files and use the management classes to have different controls for different files. Use IBM Tivoli Storage Manager archive/retrieve when you want to store a group of files for a period of time. IBM Tivoli Storage Manager uses the management class definitions to enforce only the retention period. There is no way to specify version control for an archive file. The archive function does not use the bind/rebind concept. The only case in which an archive file is managed differently 136 IBM Tivoli Storage Management Concepts

is when you delete the archive management class that was controlling files. In this case, those files are controlled by grace period settings. Think of backup as the process for storing all of your vital and ever-changing data, which is normally performed by the daily backup process. All other long-term retention requirements (weekly, monthly, yearly) can be handled by the archive function. The portable client backup set (described in 6.6, Backup set on page 124) is an alternative to the archive function. The advantage is that you can create this set from the files already present in the IBM Tivoli Storage Manager storage pools, so no re-sending of the client data is required. The disadvantage is that the backup set can be made only at the filespace level, so this granularity may be not suitable for your needs. It is important to understand that the primary intent for backup is the ability to restore from some kind of data loss. The backup function is not designated for keeping long-term data. This would heavily increase the number of managed versions on your IBM Tivoli Storage Manager, which then increases the number of managed objects in the IBM Tivoli Storage Manager Database. Each object allocates a specific amount of space in this database, and the more objects the server has to manage, the more the database grows. So use archive for long-term data storage whenever possible. 6.10 Other considerations In this section we cover other subjects that affect all of your client operations. 6.10.1 Scheduling In our examples of the various client operations, we have shown how they operate from an end-user perspective that is, by using the different interfaces available. In a typical production environment, the backup and other operations that protect the client data should be scheduled, so that we can be sure they regularly execute and can see if or when something goes wrong. IBM Tivoli Storage Manager provides you with a client scheduling interface, which interacts with the server s Central Scheduler for this purpose. Another option for scheduling is to use your own or a third-party scheduler to run scripts on your clients, comprising the appropriate client commands. If you use IBM Tivoli Storage Manager s own central scheduling, the administrator defines appropriate schedules on the server to perform the IBM Tivoli Storage Manager tasks automatically. Central scheduling is a cooperative effort between the server and each client node in that the client must run its own scheduler process so that the client and server can contact each other to correctly run the scheduled operation. The client scheduling process normally Chapter 6. Backup-archive client 137

should be configured to start automatically each time the client boots to avoid missing schedule execution and compromising data security. There are two methods used to control how the client and server make contact to run a schedule: client polling and server prompted. These options, and scheduling in general, are discussed further in Chapter 10, Scheduling on page 173. 6.10.2 Compression You have the option to specify that each client should compress its files or other objects before sending them to the IBM Tivoli Storage Manager server. Compression is available for both backup and archive operations. Enabling client compression will decrease the network traffic between client and server (because you are sending a smaller quantity of data) at the expense of requiring more client CPU resources to perform the operation. Therefore, the decision to enable client compressions must be made individually for each configuration. If you are using client compression, then the client will also automatically decompress any objects that are sent back to it from the server when the reverse restore or retrieve operation is requested. Objects that are compressed also ultimately take up less storage space in the IBM Tivoli Storage Manager server storage pools, reducing resource requirements. If you do not enable client compression, the files will be sent at their full size to the IBM Tivoli Storage Manager server. It is likely that the sequential storage device, for example a tape drive, can perform hardware compression. If this is the case, you will still get the benefit of reduced space required in the storage pool. Note that if a client has already compressed the files, then a compression-enabled tape drive normally will not be able to compress it further. Compression rates vary considerably depending on the type of data presented. When using client compression (compression set to yes), be aware that some files may actually grow when you try to compress them.this normally happens when the file has already been compressed by some other mechanism, such as ZIP or TAR, and cannot be compressed further. IBM Tivoli Storage Manager detects this condition and enables you to set options for the client that determine what should happen. You can either roll back the file and send it again without compressing or you can continue the compression operation to completion. Rolling back the file will cause a retry operation to be signalled and will probably increase your backup time if there are a lot of this type of file. On the other hand, forcing the compression operation when it ends up increasing the size of the file means using more space in your storage pools. You should pick the option that best meets your file mix and environment. 138 IBM Tivoli Storage Management Concepts

6.10.3 Client authentication A client is required to authenticate itself to the IBM Tivoli Storage Manager server before being allowed to send or receive objects. The mechanism for this is a password, which is associated with each client when it is registered to the server. The password/authentication exchange guards against impersonation on either side by ensuring both that the client is a legitimate node and that the server is in fact the real server. The authentication mechanism does not transmit the actual password across the network so there is no risk of interception. The IBM Tivoli Storage Manager administrator can disable authentication completely, which means that no password is required; however this normally is not recommended. Assuming that you are using authentication, the password access option can be set to prompt or generate. If it is set to prompt, which is the default, then the IBM Tivoli Storage Manager server asks you to supply a password each time you request backup, restore, archive, and retrieve services. If it is set to generate, then IBM Tivoli Storage Manager automatically generates a new password for your client node each time it expires, encrypts, and stores the password in a file on the client. The encrypted password is retrieved automatically from the file whenever you request services, so you are not prompted for the password. This option is particularly useful for scheduled operations. As we have discussed in 6.10.1, Scheduling on page 137, we want to have the scheduler client started automatically whenever the client is booted. Setting the PASSWORDACCESS option to generate avoids having to manually supply the password or include it in startup scripts. When using the IBM Tivoli Storage Manager Web backup-archive client, you should set this option to generate, as well. 6.10.4 Encryption In order to make the backed-up data more secure, the IBM Tivoli Storage Manager client implements an encryption function, which allows for encrypting data before it is sent to the Tivoli Storage Manager server. This helps secure backed up-data during transmission, and it means that the data stored on the Tivoli Storage Manager server is encrypted and thus is unreadable by any malicious administrators. The function uses a standard 56-bit DES routine to provide the encryption. It enables the user to choose which files are subject to encryption via include/exclude processing. The encryption uses a very simple key management system, which means that the user either must remember the encryption key password during restore or store it locally on the client system. The encryption processing is the last task on the client system before the data is sent to the server; other client operations such as compression happen before encryption is done. Encryption works for backup as well as for archive. Chapter 6. Backup-archive client 139

Key management and data restoration The key is only used at the client; it is not transferred or stored at the server. The encryption key password is either provided every time a file is encrypted or decrypted via a prompt, or it is locally stored on the client system. The client will create the key from it and keep the key on an internal key-ring cache as long the client program is running. Files are only restored if the matching key is found on the key-ring, or if the user can supply a proper decryption key password after being prompted. The encryption function is able to differentiate between invalid data and data that was decrypted with an incorrect user key. Information stored in the file stream on the server indicates that encryption was used and which type. The key-ring on restore caches potential user keys and uses the information in the file stream to determine whether the encryption key password supplied by user is incorrect. Unlike the IBM Tivoli Storage Manager user password, the encryption key password is case-sensitive. If the password is lost or forgotten, the encrypted data cannot be decrypted, which means that the data is lost. Encryption considerations When using encryption while backing up data, consider the following: Encryption is computing-intensive Because of the nature of the encryption process, it adds a lot of additional computing requirements on the client CPU. The user should decide very carefully which data items really need to be encrypted and control them using the include/exclude statements. The administrator has the option to overwrite client selections using client options sets. Encryption and archiving Especially in the case of long-term archiving of data, problems can occur with the simple key management scheme. If data is archived using encryption, organizational rules have to ensure that the encryption key password remains available for retrieve. Cyclic password changes or no external password management can cause situations in which data cannot be retrieved successfully. Encryption and unattended restore When restoring data using the scheduling function, it is possible that files will not be restored because the needed encryption key password is not stored locally (PROMPT mode) or the restored files are encrypted with a different key than the stored encryption key password. 140 IBM Tivoli Storage Management Concepts

6.10.5 Windows specialities Now to discuss some Windows-specific issues. Windows System Object A System Object is a collection of files and/or databases that represent a logical entity and help the system achieve a consistent state. The System Objects can be part of larger, distributed entity known as System State. You can back up Windows 2000 and Windows XP system objects together or individually. Microsoft recommends that all system objects be backed up together to maintain a consistent system state. These are valid system objects: Active Directory (domain controller only) Certificate server database Cluster Database (cluster node only) COM+ database Event logs (system, security, and application) Registry System and boot files System Volume Removable Storage Management Database (RSM) Replicated file systems (FRS) Windows Management Instrumentation (WMI) Backup and restore of all Windows system objects, except the Windows Registry, require the user to have Administrator privileges. Backup and restore of the Windows Registry can be performed by a member of the Backup Operators group. The backup of system objects that contain a large number of files, for example BACKUP SYSFILES, may require a larger IBM Tivoli Storage Manager server recovery log. Also, the size can be larger than the normal transaction buffer size. Objects can be backed up in any order. The system object files are all contained within the SYSTEM OBJECT filespace on the IBM Tivoli Storage Manager server. You can assign the system objects to a specific management class for easier control of the restore function. For further details, refer to the redbook Tivoli Storage Manager Version 4.2 Technical Guide, SG24-6277. System state and system services IBM Tivoli Storage Manager supports the Microsoft Volume Shadowcopy Service (VSS) on Windows Server 2003. IBM Tivoli Storage Manager uses VSS to back up all system state components as a single object, to provide a consistent Chapter 6. Backup-archive client 141

point-in-time snapshot of the system state. You can back up all system service components (the default) or individual components. System state components include the following: Active Directory (domain controller only) System Volume Certificate Server Database COM+ database Registry System and boot files The list of system state components is dynamic and may change depending on service pack and operating system features installed. IBM Tivoli Storage Manager allows for the dynamic discovery and backup of these components. Automated System Recovery (ASR) ASR is a restore feature of Windows XP Professional and Windows Server 2003 that provides a framework for saving and recovering the Windows XP or Windows Server 2003 operating state in the event of a catastrophic system or hardware failure. IBM Tivoli Storage Manager creates the files required for ASR recovery and stores them on the IBM Tivoli Storage Manager server. The goal of ASR as stated by Microsoft is to return the operating system to the point of last backup. ASR is not used to recover application or user data. Such data is recovered via normal IBM Tivoli Storage Manager restore procedures after successful completion of ASR recovery. ASR is a two-phase process: 1. Windows installs a temporary operating system image using the original operating system media. 2. Windows invokes IBM Tivoli Storage Manager to restore the system volume and system state information. ASR recovery of a Windows system should only be performed after all other repair alternatives have been exhausted, such as the startup options Safe Mode and Last Known Good Configuration. The process of recovering a system with ASR is a cooperative effort between Windows and IBM Tivoli Storage Manager. ASR basically provides a framework for recovery that a vendor backup product plugs into. Windows provides the capability to recover the system to a bootable minimal function state. Then the backup product is installed and called upon to restore system state and system critical volumes (as defined by ASR). ASR s role ends at the point of providing the operating system in a fully functional state recovered to the point of last backup. The scope of ASR does not include the recovery of user data volumes. The backup product is used in a non-asr scenario to recover data. 142 IBM Tivoli Storage Management Concepts

Here are the steps involved in ASR recovery. The responsible parties are indicated in brackets. During backup: 1. [IBM Tivoli Storage Manager] Generate the ASR files. Place IBM Tivoli Storage Manager installation and restore commands in the ASR.sif file. 2. [IBM Tivoli Storage Manager] Store the ASR files on the IBM Tivoli Storage Manager server. 3. [IBM Tivoli Storage Manager] Facilitate the creation of the ASR diskette for later use. During recovery: 1. [Windows] Reboot machine from the CD drive using the Windows installation CD. Press F2 to enter ASR recovery mode. 2. [IBM Tivoli Storage Manager] Insert the IBM Tivoli Storage Manager-generated ASR recovery diskette into the drive. 3. [Windows] Drives are repartitioned and reformatted according to information stored in the asr.sif file. 4. [Windows] Minimal operating system is installed. 5. [Windows] Insert the IBM Tivoli Storage Manager installation CD into the drive. 6. [IBM Tivoli Storage Manager] IBM Tivoli Storage Manager is installed using the installation command given in asr.sif. 7. [IBM Tivoli Storage Manager] Critical volumes (as specified in asr.sif) are restored from IBM Tivoli Storage Manager. 8. [IBM Tivoli Storage Manager] System state is restored from IBM Tivoli Storage Manager. 9. [Windows] System is rebooted into the recovered state. Chapter 6. Backup-archive client 143

144 IBM Tivoli Storage Management Concepts

7 Chapter 7. API client The IBM Tivoli Storage Manager application program interface (API) enables an application client to use its storage management functions. It is provided and documented to enable customers or ISVs to interface their own specialized applications with IBM Tivoli Storage Manager. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 145

7.1 Overview The API can be run in single or multithreaded mode, which allows applications to create multiple sessions with the IBM Tivoli Storage Manager server within the same process. Note: When using LAN-free with an API client application, multithreading is prerequisite. The API consists of a set of function calls that an application can use to perform the following operations: Start or end an IBM Tivoli Storage Manager session. Assign management classes to objects before storing them on an IBM Tivoli Storage Manager server. Back up or archive objects to an IBM Tivoli Storage Manager server. Restore or retrieve objects from an IBM Tivoli Storage Manager server. Query the server for information about objects stored there. Manage file spaces. When you, as an application developer, install the IBM Tivoli Storage Manager API, you receive the following files that an application end user would need: API shared library and associated files Sample client options files Documentation: The source code for the API header files that the application needs The source code for a sample application and the makefile to build it The API code is packaged with the backup-archive client code. Applications that have been written using a particular version of the API may not work with later API versions. It is important to find out which API version is supported and tested for a particular application. It is possible to use an earlier version API concurrently with a later version backup-archive client if this is required for support of a particular API application. 7.2 IBM Tivoli Storage Manager API client usage The IBM Tivoli Storage Manager API client can be used by any application in order to add the IBM Tivoli Storage Manager functions directly into that 146 IBM Tivoli Storage Management Concepts

application. Users can add the API to their program applications to automatically call IBM Tivoli Storage Manager to initiate a backup, restore, archive, or retrieve of a file, without having to leave (or close) the application. This is useful to applications that do not have an IBM Tivoli Storage Manager component available to them, or to applications that need to back up or restore data between processing steps of an application job flow. 7.3 Understanding configuration files and options files Configuration files and options files enable you to set the conditions and boundaries under which your IBM Tivoli Storage Manager session runs. The IBM Tivoli Storage Manager administrator, the end user, or the developer can set the available options. The values of various options enable the following functions to be performed: Initiate the connection to an IBM Tivoli Storage Manager server. Control which objects are sent to the server and with what management class they are associated. On the UNIX platform, the IBM Tivoli Storage Manager options reside in two separate options files, the client system options file (dsm.sys) and the client options file (dsm.opt). On other platforms, the options file dsm.opt contains all of the options. The end user sets up these files when the IBM Tivoli Storage Manager API is first installed on the user s workstation. The same option can derive from more than one configuration source. When this happens, the source with the highest priority takes precedence, as in the sequence shown in Table 7-1. Table 7-1 Options files UNIX Other platforms 1. dsm.sys (client system options) 1. N/A 2. option string (client options) 2. option string (all options) 3. API configuration file (client options) 3. API configuration file (all options) 4. dsm.opt (client options) 4. dsm.opt (all options) Chapter 7. API client 147

The different configuration sources, in order of decreasing priority, include: Client system options (UNIX only). Options that an IBM Tivoli Storage Manager or system administrator sets. 1. The API options list takes effect when it is passed to a dsminit() or dsminitex() call as a parameter. The list can contain client options, such as: compressalways servername (UNIX only) tcpserveraddr (non-unix) 2. The API options list enables an application client to make changes to the values of the options in the API configuration file and the client options file. For example, your application might query the end user for the user-preferred format for displaying dates and times. On the basis of the end user s answers, you can construct an API options list with these two options and pass it into the call to dsminit(). You can also set the options parameter to NULL, indicating that there is no API options list for this IBM Tivoli Storage Manager session. 3. The values in the API configuration file override the values set in the IBM Tivoli Storage Manager client options file. Set up the options in the API configuration file to have values that you think will be appropriate in the end user s Tivoli Storage Manager session. The values take effect when the API configuration file name is passed as a parameter in the dsminit() call. 4. You can also set this parameter to NULL, indicating that there is no API configuration file for this IBM Tivoli Storage Manager session. 5. On the UNIX platform, dsm.opt contains only the user options file. On other platforms, dsm.opt contains all of the options. You can override the options in these files using the methods mentioned above. 7.4 Setting up the API environment The API uses unique environment variables to locate files. This enables you to use different files for API applications than the interactive client uses. Table 7-2 on page 149 lists the API environment variables by platform. 148 IBM Tivoli Storage Management Concepts

Table 7-2 API environment variables Variables UNIX Windows NetWare DSMI_CONFIG The fully qualified name for the client option file The fully qualified name for the client option file There are no environment variables. The dsm.opt, dscameng.txt, and dsierror.log files reside in the same directory as the dsmapi.nlm file. This directory becomes the search path for these files. DSMI_DIR Points to the path containing dsm.sys, dsmtca, the en_us subdirectory, and any other NLS language. The en_us subdirectory must contain the dsmclientv3.cat file. Points to the path containing dscameng.txt and any NLS message file. DSMI_LOG Points to the path for the dsierror.log file. Points to the path for the dsierror.log file. OBJECT_MOD E=64 Support for 64-bit environment (where available) and commmethod is TCP/IP 7.5 Using passwordaccess generate without TCA The Trusted Communication Agent (TCA), a child process that runs on UNIX clients only, normally controls access to the protected password file. It is possible to have the passwordaccess generate function without starting the TCA. To do this: 1. Write the application using the dsmsetup() call to pass argv[0], containing the name of the executable. The application is permitted to run as IBM Tivoli Storage Manager authorized; however, the administrator should decide the login name for the IBM Tivoli Storage Manager-authorized user. 2. Set the S bit (set the effective user ID) to On for the application executable. The owner of that executable can then become an IBM Tivoli Storage Manager authorized user. This enables the user to create a password file, update passwords, and run applications. The owner of the application executable should be the same as the user ID running the program. For example, User is User1, the name of the executable is dapimsp, and User1 has read-write permissions on the /home/user1 directory. Chapter 7. API client 149

3. Instruct the users of the application to use the IBM Tivoli Storage Manager authorized name to log in. IBM Tivoli Storage Manager verifies that the login ID matches the application executable owner before it permits access to the protected password file. 4. Set the passworddir option in the dsm.sys file to point to a directory where this user has read-write access. For example, under the server stanza in dsm.sys, you would enter: passworddir /home/user1 The permissions on dapismp are: -rwsr-xr-x user1 group1 dapismp 5. Start the password file and ensure that the IBM Tivoli Storage Manager authorized user owns the file. 6. Run dapismp logged on as User1. 7. Call dsmsetup() and pass in argv. Note: When running in a multithreaded mode, and passwordaccess is generate, only the root, or IBM Tivoli Storage Manager authorized user, is permitted access so that the TCA child process is not started. 150 IBM Tivoli Storage Management Concepts

8 Chapter 8. IBM Tivoli Storage Manager for Space Management In this chapter, we discuss the complementary IBM Tivoli Storage Manager product, IBM Tivoli Storage Manager for Space Management (formerly Hierarchical Storage Manager or HSM client). We introduce the concept of IBM Tivoli Storage Manager for Space Management and discuss various features of the product. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 151

Figure 8-1 IBM Tivoli Storage Manager for Space Management concept 8.1 Introduction Disk subsystems are becoming less expensive every day. The cost per byte of data stored on a disk has dropped dramatically from just a few years ago. At the same time, both the amount of data being stored on disk and the cost to manage and administer this stored data is increasing dramatically. Even with the reduction in hardware costs, the increase in the amount of data is taxing the ability of file servers to hold and manage this data. File owners have been and continue to be uninterested in actively managing their storage requirements due to factors such as lack of knowledge, more-pressing priorities, and a lack of tools. They want to be able to find their data quickly and access it without the hassles of swapping disks and mounting tapes. These attitudes lead significant amounts of data being stored on disk, not because data needs to be there or is actively being used, but because it is convenient to do so and no one is concerned with removing old or unneeded data. More than 20 years ago, mainframe computer sites faced a similar situation: explosive data growth and the requirement for fast access to older data, but with 152 IBM Tivoli Storage Management Concepts

extremely expensive disk devices. The industry came up with the concept of having the computer manage the data storage by moving infrequently accessed data to lower-cost storage media while presenting to the end user the impression that the data was still on disk. This became known as hierarchical storage management (HSM). IBM Tivoli Storage Manager for Space Management maximizes usage of existing storage resources by transparently migrating data off workstation and file server hard drives based on size and age criteria, leaving only a stub file. If and when the migrated data is accessed, IBM Tivoli Storage Manager for Space Management transparently migrates data back onto the local disk. In doing so, IBM Tivoli Storage Manager for Space Management relieves users from the task of manually deleting and archiving data on their workstations. IBM Tivoli Storage Manager for Space Management is a complementary product that is available on all IBM Tivoli Storage Manager servers. The Space Manager (HSM) client is currently available on AIX and Sun Solaris operating systems. Therefore, the supported HSM clients can send data to any IBM Tivoli Storage Manager server that also has installed the IBM Tivoli Storage Manager for Space Management. IBM Tivoli Storage Manager is a prerequisite to implementing IBM Tivoli Storage Manager for Space Management. IBM Tivoli Storage Manager for Space Management provides the basic functionality of space management by automatically migrating data based on file size, number of days since it was last accessed, or a combination of both. Once migrated, IBM Tivoli Storage Manager for Space Management automatically recalls a file if it is accessed and restores it to its original location in the file system. IBM Tivoli Storage Manager for Space Management maintains data integrity and security of data by working closely with the operating system. It provides a GUI and commands that can be used to display information about files, including whether they have been migrated. 8.2 HSM migration Files are migrated by IBM Tivoli Storage Manager for Space Management from the original file system to storage devices connected to an IBM Tivoli Storage Manager server. Each file is copied to the server and a stub file is placed in the original file s location. Using the facilities of storage management on the server, the file is placed on various storage devices such as disk and tape. Chapter 8. IBM Tivoli Storage Manager for Space Management 153

IBM Tivoli Storage Manager for Space Management migrates only regular files on locally mounted file systems. It does not migrate character special files, block special files, FIFO special files (named pipe files), or directories. There are two types of HSM migration: automatic and selective. 8.2.1 Automatic migration With automatic migration, IBM Tivoli Storage Manager for Space Management monitors the amount of free space on your file systems. When it notices free space shortage, it migrates files off the local file system to the IBM Tivoli Storage Manager server storage based on the space management options that have been chosen. IBM Tivoli Storage Manager for Space Management monitors free space in two ways: threshold and demand. Threshold Threshold migration maintains your local file systems at a set level of free space. At an interval specified in the options file, IBM Tivoli Storage Manager for Space Management checks the file system space usage. If the space usage exceeds the high threshold, files are migrated to the server by moving the least-recently used files first. When the file system space usage reaches the set low threshold, migration stops. Threshold migration can also be started manually. Demand IBM Tivoli Storage Manager for Space Management checks for an out-of-space condition on a file system every two seconds. If this condition is encountered, IBM Tivoli Storage Manager for Space Management automatically starts migrating files until the low threshold is reached. As space is freed up, the process causing the out-of-space condition continues to run. You do not receive out-of-space error messages while this is happening. 8.2.2 Selective migration 8.2.3 Pre-migration You can tell IBM Tivoli Storage Manager for Space Management to selectively migrate a file immediately to the server s storage. As long as the file meets the space management options, it will be migrated. The file does not need to meet age criteria, nor does the file system need to meet space threshold criteria. Migration can take a long time to free up significant amounts of space on the local file system. Files need to be selected and copied to the IBM Tivoli Storage Manager server, which may involve tape mount, and a stub file must be created in place of the original file. To speed up the migration process, IBM Tivoli Storage 154 IBM Tivoli Storage Management Concepts

Manager for Space Management can be told to implement a pre-migration policy. After threshold or demand migration completes, IBM Tivoli Storage Manager for Space Management continues to copy files from the local file system until the pre-migration percentage is reached. These copied files are not replaced with the stub file, but they are marked as pre-migrated. The next time migration starts, the pre-migrated files are chosen as the first candidates to migrate. If the file has not changed since it was copied, the file is marked as migrated, and the stub file is created in its place in the original file system. No copying of the file needs to happen, as the server already has a copy. In this manner, migration can free up space very quickly. 8.2.4 Recall Recall is the process for bringing back a migrated file from IBM Tivoli Storage Manager to its original place on the local file system. A recall can be either transparent or selective. Transparent From a user or running process perspective, all of the files in the local file system are actually available. Directory listings and other commands that do not require access to the entire file will appear exactly as they would if the HSM client was not installed. When a migrated file is needed by an application or command, the operating system initiates a transparent recall for the file to the IBM Tivoli Storage Manager server. The process is temporarily halted while the file is automatically copied from the server s storage to the original file system location. Once the recall is complete, the halted process continues without requiring any user intervention. In fact, depending on how long it takes to recall the file, the user may not even be aware that HSM is used. After a recall, the file contents are on both the original file system and on the server storage. This allows IBM Tivoli Storage Manager for Space Management to mark the file as pre-migrated and eligible for migration unless the file is changed. Selective Transparent recall only recalls files automatically as they are accessed. If you or a process need to access a number of files, it may be more efficient to manually recall them prior to actually using them. This is done using selective recall. IBM Tivoli Storage Manager for Space Management batches the recalled file list based on where the files are stored. It recalls the files stored on disk first, then recalls the files stored on sequential storage devices such as tape. Chapter 8. IBM Tivoli Storage Manager for Space Management 155

8.2.5 Advanced transparent recall Advanced transparent recall is available only on AIX platforms. There are three recall modes: normal, which recalls a migrated file to its original file system; migrate-on-close; and read-without-recall. Migrate-on-close When IBM Tivoli Storage Manager for Space Management uses the migrate-on-close mode for recall, it copies the migrated file to the original file system, where it remains until the file is closed. When the file is closed and if it has not been modified, IBM Tivoli Storage Manager for Space Management replaces the file with a stub and marks the file as migrated (because a copy of the file already exists on the server storage). Read-without-recall When IBM Tivoli Storage Manager for Space Management uses read-without-recall mode, it does not copy the file back to the originating file system, but passes the data directly to the requesting process from the recall. This can happen only when the processes that access the file do not modify the file, or, if the file is executable, the process does not execute the file. The file does not use any space on the original file system and remains migrated (unless the file is changed; then IBM Tivoli Storage Manager for Space Management performs a normal recall). 8.2.6 Reconciliation IBM Tivoli Storage Manager for Space Management uses reconciliation to maintain synchronization of the local file system and IBM Tivoli Storage Manager. Reconciliation builds a migration candidates list. Reconciliation can be started manually or automatically at intervals set in the options file and before threshold migration if the migration candidate list is empty. Synchronization Synchronization involves maintaining the IBM Tivoli Storage Manager for Space Management database in sync with the actual files on the original file system. It ensures that: For every stub file there is a valid file copy kept For every original file on the original file system there are no database entries For pre-migrated files there is an entry in the IBM Tivoli Storage Manager for Space Management database It also updates status fields in the database. 156 IBM Tivoli Storage Management Concepts

For example, if you recall a file, change it, and immediately migrate it, IBM Tivoli Storage Manager for Space Management has two copies of the file in its storage: the most recent one, which is valid, and an obsolete one. Reconciliation will remove this obsolete file after its expiration interval has passed. Building a new migration candidates list IBM Tivoli Storage Manager for Space Management uses the reconciliation process to build a prioritized list of files on the original file system that are eligible for automatic migration. The list is created based on management class criteria and minimum file size. It is ordered according to the number of days since the file was last used, the file size, and the migration factors set in the options file. During threshold and demand migration, the list is used to select files to migrate in prioritized order. As the file is selected, it is checked again to ensure that it still meets the migration criteria. A new migration candidate list is created each time reconciliation runs. The list can also be created at any time. 8.2.7 Options Options to control IBM Tivoli Storage Manager for Space Management are set in the client options file. These options set items such as which IBM Tivoli Storage Manager server to use for IBM Tivoli Storage Manager for Space Management functions, space management options, migration options, excluded file lists, and assigning management classes to files. 8.2.8 Backup and restore You should not consider use of HSM and IBM Tivoli Storage Manager for Space Management as a replacement for backup. It should be viewed as a form of space extension of local disk storage. When a file is migrated to the HSM server, there is still only one copy of the file available, because the original is deleted on the client and replaced by the stub. Also, IBM Tivoli Storage Manager for Space Management maintains only the last copy of the file, giving no opportunity to store multiple versions. Therefore, the IBM Tivoli Storage Manager backup-archive client must be used for file backup or archive before or after the file has been migrated by IBM Tivoli Storage Manager for Space Management. You can specify that a file is not eligible for HSM migration unless a backup has been made first with the backup-archive client. If the file is migrated and the save IBM Tivoli Storage Manager server destination is used for both backup and HSM, the server can copy the file from the migration storage pool to the backup destination without recalling the file. Chapter 8. IBM Tivoli Storage Manager for Space Management 157

Both files and stub files can be restored from an IBM Tivoli Storage Manager backup. If you restore the entire file, it will become a normal resident file on the client, and the migrated copy will be deleted from the HSM pool during the next reconciliation. If you do not want to restore the actual file data, you can use options on the HSM client to restore just the stub file without re-creating the file contents. In this case, the file will remain in its migrated state. 8.2.9 Archive and retrieve The IBM Tivoli Storage Manager backup-archive client enables you to archive and retrieve copies of migrated files without performing a recall for the file first, providing the save IBM Tivoli Storage Manager server is used for both HSM and backup-archive. The file will simply be copied from the HSM storage pool to the archive destination pool. 158 IBM Tivoli Storage Management Concepts

Part 3 Part 3 Server architecture In this part we describe how the IBM Tivoli Storage Manager is architected and how it functions as a storage management solution. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 159

160 IBM Tivoli Storage Management Concepts

9 Chapter 9. Policy management In this chapter we introduce the policy management of IBM Tivoli Storage Manager, which manages all the rules where data is being stored and how long it is being stored. This is one of the core paradigms of IBM Tivoli Storage Manager that provides the basis of its behavior. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 161

9.1 Introduction A data storage environment consists of three types of resources: machines, rules, and data. The machines are computers that contain data that must be backed up. The rules specify how the backed-up data is to be treated. Basically, a data storage policy defines the relationships between these three resources as illustrated in Figure 9-1. IBM Tivoli Storage Manager has entities that group and organize the resources and define relationships between them. A machine, or node in IBM Tivoli Storage Manager terminology, is grouped together with other nodes into a policy domain. The domain links the nodes to a policy set that consists of management classes. A management class contains rules called copy groups that it links to the data. Nodes Machines Policy Domain Policy Set Copy Group Rules Copy Group Rules Management Class Management Class Data Data Copy Group Rules Management Class Data Figure 9-1 Data storage policy relationships and resources 9.2 Data storage policy components The hierarchical structure of the IBM Tivoli Storage Manager policy components is represented graphically in Figure 9-2 on page 163. If we were discussing the technical steps required to configure a policy domain, it would be natural for us to start at the top and work our way down, because the policy domain has to exist before the policy set, and so on. Examining the diagram leads to the realization that most of the data storage policy components exist solely to provide flexibility in our configuration or to serve as containers for rules. For the purpose of understanding the concepts behind the IBM Tivoli Storage Manager hierarchy, we will begin our discussion with copy groups and work outward toward the policy domain. 162 IBM Tivoli Storage Management Concepts

Policy Domain Policy Set Management Class Backup Copy Group Archive Copy Group Management Class Backup Copy Group Archive Copy Group Management Class Backup Copy Group Archive Copy Group Node Node Figure 9-2 Data storage policy components 9.3 Copy groups The copy groups consist of rules used to govern the retention of data. There are two types of copy groups: a backup copy group holds the rules for backup data, and an archive copy group holds the rules for archive data. While these two copy groups serve different purposes, they also share some common ground. They both specify where to store the data sent to them from backup/archive operations. The copy group destination parameter specifies a valid primary storage pool to hold the backup or archive data. The copy group bridges the gap between data files and storage pools as illustrated in Figure 9-3 on page 164. It shows different types of data flowing through the copy groups and into the storage pools. Note that there is not necessarily a one-to-one relationship between copy groups and storage pools. It is possible to have just one storage pool that is the destination for all of the copy groups. Chapter 9. Policy management 163

Policy Domain Policy Set Backup/Archive Data File Copy File Copy File Copy Management Class Management Class Backup Copy Group Archive Copy Group Backup Copy Group Archive Copy Group File Copy File Copy Storage Pool X Management Class Backup Copy Group Archive Copy Group File Copy Storage Pool Y Node Node Figure 9-3 Data flow through copy groups Both copy groups also need to know what to do with files that are modified during a backup or archive operation. When we say that a file is modified during backup, we mean that it is modified after IBM Tivoli Storage Manager examined it for its details but before it was completely backed up to the server. This sort of backup is referred to as a dirty backup because the file is in an inconsistent state and may not restore properly. The copy serialization parameter provides four options to deal with this problem: The shrstatic setting specifies that a file will not be backed up if it is modified during backup, but multiple attempts will be made to back up the file. If the file continues to be modified through each of these attempts, the file will not be backed up. The number of attempts can be controlled using the changingretries option in the client options file. The static setting specifies that a file will not be backed up if it is modified during backup and no additional attempts will be made. The shrdynamic setting specifies that a file will be backed up if it is modified during backup but multiple attempts will be made to back it up without modification first. If that cannot be done, then the file will be backed up anyway. 164 IBM Tivoli Storage Management Concepts

The dynamic setting specifies that a file will be backed up even if it is modified during backup. There is no preliminary attempt to back up the file unmodified; it is backed up on the first attempt. Note that the copy serialization works differently when doing an image backup. For an explanation, see 6.4.4, Logical volume backup on page 104. 9.3.1 Backup copy group The backup copy group is concerned with two logical objects: the file and the file copy. A file is the actual data on a client node, while a file copy is a point-in-time copy of the file stored on the server. Another way to think of it is that the IBM Tivoli Storage Manager server contains file copies and nodes contain files. A file can be in one of two possible states: existing or deleted. When we talk about an existing file on a node, we mean a file that has been previously backed up and still exists on the node. A deleted file is a file that has been previously backed up and subsequently deleted from the node. This simple concept is important when discussing data storage rules. A file copy can be in one of three states: active, inactive, or expired. An active file copy is the most current copy of the file, an inactive file copy is a previous copy or version of the file, and an expired file copy is a copy to be removed from the IBM Tivoli Storage Manager server. A backup file copy is set to the expired state when it no longer conforms to the rules specified in the backup copy group. Whether the file exists or is deleted, the file copy will always pass through the same states in the same order. A file copy will start out as active because it will be the first copy of the file and therefore the most current. Once the file changes and we make another file copy, the first file copy will change to inactive because we have a more-recent one. Eventually, the first file copy will be expired based on one of two limits placed on it by our rules: number of copies or retention period. The number of copies that we set in our rules specifies the total number of file copies to maintain in the IBM Tivoli Storage Manager database. It is important to note that the specified number includes the active file copy. Thus, when we set the number of file copies to three, we are keeping one active copy and two inactive copies. When the number of copies is exceeded, the oldest copies are removed from the database. The retention periods that we set in our rules will specify the length of time that we will retain inactive file copies. It is important to note that there is no retention period for active file copies; they exist as long as the file exists on the node. Chapter 9. Policy management 165

Whether the file exists on the node will affect which rules are used to expire the file copies. If the file exists, the following two backup copy group parameters are in effect: verexists: specifies the number of file copies, or versions, to keep. This number includes active and inactive file copies. retextra: specifies how long to keep inactive file copies. When a file changes from active to inactive, it will be kept for retextra days and then removed. It is important to note that the retention period starts from when the file copy becomes inactive, not from its original backup date. If the file has been deleted, the active file copy will be made inactive. At this point, there are only inactive file copies for this data in the IBM Tivoli Storage Manager server, and the following parameters apply: verdeleted: specifies the number of file copies to keep after the file has been deleted. retonly: specifies how long to maintain the last file copy of the data. This is the number of days to keep the last copy only and does not apply to other inactive file copies. 9.3.2 Backup mode and frequency The backup copy group defines two other attributes that control the way that backup data is handled: mode and frequency. The mode parameter specifies how files are to be selected for incremental backup. Setting the mode to modified will allow a file to be backed up only if it has changed since the last backup. The absolute setting will allow files to be backed up regardless of whether they have changed or not. The latter value would only be used for special cases; the default value is modified. The frequency parameter specifies how often to allow a file to be incrementally backed up. This parameter only affects client-selected incremental backups; it does not apply to selective backups, because this backs up data regardless of whether it has changed or not. For a file to be backed up during an incremental operation from a node, it has to satisfy three conditions: Domain and include-exclude statements allow the file to be considered for backup. The file satisfies the mode setting. That is, if the mode is set to modified, the file must have changed to qualify for backup. If the mode is set to absolute, then the file is automatically allowed to be backed up. Difference between the server time and the active file copy timestamp must be greater than frequency setting. The frequency is converted to hours to compare to the timestamp difference. 166 IBM Tivoli Storage Management Concepts

For example, consider a file called /home/admin/redbook.doc that is eligible for backup in the include-exclude list and that has changed since the last backup at 8 a.m. this morning. The server time is 11 a.m. when an incremental backup is started, so the difference between server time and the file copy time is three hours. If the frequency is set to one day, then 24 hours must pass between incremental backups before a file is backed up again. Therefore, the file called /home/admin/redbook.doc will not be backed up, since three hours is less than 24 hours. The default setting for this parameter is 0, which means that there is no minimum required elapsed time between backups. 9.3.3 Archive copy group The archive copy group works with entire archives as single unique entities, so it has fewer rules. There is only ever one copy of a particular archive, so we do not have to worry about rules to manage versioning. We still have to specify the retention period for the archive object and that is done with the retver setting. It specifies the number of days to retain the archive copy from the day of the archive operation. There are three other parameters that the archive copy group uses to handle archive data: mode, frequency, and copyserialization. The mode parameter has been discussed, but the archive copy group only allows the value to be set to absolute. This makes sense, since the archive copy group does not link previous archives to the current archive and therefore cannot determine whether anything has been modified. The archive copy group has a frequency parameter, but it can only be set to the value CMD, which means that the archive can be performed on demand. Copyserialization operates in the same way as for backup and has already been discussed in 9.3, Copy groups on page 163. 9.4 Management class and explicit binding The management class serves two purposes: it contains copy groups and associates data to them. A management class must contain at least one copy group. This copy group could be for backup or archive, or the management class could contain both a backup and an archive copy group. Figure 9-4 on page 168 shows the basic structure of a management class with both copy groups defined. It also illustrates how a management class links the backup/archive data to the rules defined in a copy group. The link is very granular and can be assigned to a single file or groups of files. When a file is linked to a management class, it is said to be bound to the management class. Chapter 9. Policy management 167

Data Binding Management Class Backup Copy Group Archive Copy Group Figure 9-4 Binding data to the management class structure There is a special instance of a management class called the default management class. There is only one for each logical grouping of nodes (policy domain), and it contains the rules that you want used for your data unless you explicitly bind it to another management class. Therefore, there are two ways of binding data to a management class: default and explicit. Unless an object is explicitly defined, the default management class is used. Explicit binding to a management class can be accomplished using three different methods: one for backup data, one for archive data, and one for directory data. While you are not required to use any of these methods, they are very powerful and important tools for effective data storage management. Binding your backup data to different management classes enables you to manage different types of files with different sets of rules. Backup data is bound to a management class using the include option of the IBM Tivoli Storage Manager client s include-exclude list. Example 9-1 shows an example of an include statement that assigns the backup file /home/admin/redbook.script to a management class called redbook while allowing the rest of the backup files in /home/admin to go to the default management class. The binding is actually done during the backup operation. Example 9-1 Include option example include /home/admin/.../* include /home/admin/redbook.script redbook Image backups are also bound using the include/exclude list, however, the include.image directive is used. Example 9-2 shows how to bind all image backups to the imagemc management class. Example 9-2 Image management class example include.image /.../* imagemc Archive data is bound to a management class using the archmc command line option as illustrated in Example 9-3 on page 169. The file /home/admin/redbook.doc will be bound to the management class 168 IBM Tivoli Storage Management Concepts

redbookarchive. Without the archmc option, this data would have been bound to the default management class. Example 9-3 Archive management class example dsmc archive -archmc=redbookarchive /home/admin/redbook.doc Directory data can be bound to a management class using the dirmc client option as illustrated in Example 9-4. All of the directories from this client will be bound to the directory management class. Without this option, the directory information would go to the management class with the longest retention period. You can use this option to speed up your restores by binding your directory data to a management class that uses only a primary disk storage pool instead of tape. Directory information does not take up very much space so only a small storage pool is required. The directory information is the first thing that is rebuilt during a restore, and by making it rapidly accessible, your restore time will be improved. Example 9-4 Directory management class example dirmc directory 9.5 Policy set A policy set is a group of management classes. There can be multiple policy sets within a policy domain, but only one of them can be active at a time. That is to say, the active policy set contains the only group of management classes that can be bound to the data within the domain. Management classes in other policy sets are not available unless you activate the policy set that contains them. A policy set can contain many management classes but only one of them can be the default. The basic structure of a policy set is shown in Figure 9-5 on page 170 and illustrates that the policy set is used primarily for flexibility. It allows us to group management classes and assign one of them as a default for the policy domain. Chapter 9. Policy management 169

Policy Set Management Class Backup Copy Group Archive Copy Group Management Class (Default) Backup Copy Group Archive Copy Group Management Class Backup Copy Group Archive Copy Group Figure 9-5 Policy set structure The active policy set is a special entity in the policy domain, and it cannot be changed directly. To change it, you must define your rules in a policy set that is subsequently validated and activated. The activation process takes a snapshot of the policy set and places it in the active policy set. It is important to note that the active policy set is a point-in-time snapshot of the originating one. Therefore, further changes to the originating policy set will have no effect on the active policy set until the changed one is validated and activated. The validation process checks that your policy set is complete and valid. It checks the management classes and copy groups and ensures that the policy set has a default management class. It also ensures that the copy groups point to valid primary storage pools. The activation process verifies that the default management class and copy group definitions are correct (using the same checks as the validation process) before activating the policy set. Activating the policy set means that it is copied to the active one. 9.6 Policy domain A policy domain is a way to group IBM Tivoli Storage Manager clients depending on how you want to treat their data. It also contains policy sets that have all of the rules that you want to apply to your data. Figure 9-6 on page 171 shows a simplified view of a policy domain with multiple policy sets and nodes contained within it. As discussed, there can be many policy sets but only one is active. 170 IBM Tivoli Storage Management Concepts

Policy Domain Policy Set Node Node Figure 9-6 Policy domain structure A policy domain enables you to logically group the machines in your organization according to: Default policy the default set of rules to apply to the clients. The rules define the storage management policy including how many copies of data to keep and how long to keep them. The default management class of the active policy set contains the default rules applied to the domain. Administrative control access to the client data and the policy rules can be restricted to certain administrators by allowing or disallowing the administrators access to the policy domain. Let us consider a typical organization consisting of UNIX and Windows NT machines. The UNIX machines are large file servers that need many copies of their data maintained for a long period of time. The UNIX support group is the only group authorized to access the UNIX machines. The UNIX policy domain would hold all of the UNIX machines, and would only be accessible to the UNIX IBM Tivoli Storage Manager administrators. The default policy in this domain would apply only to the UNIX machines. The Windows NT machines are workstations that need a few copies of their data maintained for a short period of time. The Windows NT support group is the only group authorized to access the Windows NT machines. The Windows NT policy domain would hold all of the Windows NT machines, and access to it would be restricted to the Windows NT IBM Tivoli Storage Manager administrators. The default policy in this domain would only apply to the Windows NT machines. This is a good example of how default policy and administrative control can be used to break up your organization into policy domains. Chapter 9. Policy management 171

9.7 Policy management The policy domain and all of its subordinate entities contain your data storage definitions but it does not actually enforce them. The copy group rules are used during the client backup process to mark inactive file copies as expired. They can be expired based on the number of copies or retention period. Then a server process, called inventory expiration, is executed to actually remove the database references for the file copies. This process will remove backup and archive data entries in the database. It is important to note that the actual data is not removed from the storage pools; only the pointer in the database is deleted. The inventory expiration process can be run manually, automatically, or by schedule. By default, an IBM Tivoli Storage Manager server will run this process daily but that can be controlled using the EXPINTERVAL parameter in the server options file that specifies the number of hours between automatic expiration processing. The inventory expiration process can be quite CPU intensive, so the preferred method for running it is to use the IBM Tivoli Storage Manager scheduler to define this operation to run at a pre-determined, convenient time for your environment. 172 IBM Tivoli Storage Management Concepts

10 Chapter 10. Scheduling This chapter describes the automation mechanisms IBM Tivoli Storage Manager provides to get certain actions such as backup activities scheduled throughout the timeline. We also discuss the different means of communication between IBM Tivoli Storage Manager server and clients. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 173

10.1 Introduction IBM Tivoli Storage Manager includes a central scheduling component that allows the automatic processing of administrative commands and client operations during a specific time period when the schedule is activated. An administrator is responsible for creating and maintaining the schedules in each policy domain. IBM Tivoli Storage Manager scheduling is split into two categories: administrative scheduling and client scheduling. The two categories differ in two key areas: Execution location: An administrative schedule performs some action on the IBM Tivoli Storage Manager server while the client schedule can only execute on the IBM Tivoli Storage Manager client. Domain privilege: An administrative schedule can only be managed by an administrator with system privilege, while the client schedule can be managed by an administrator with policy privileges in the client s domain. The granularity provided by this feature can be very useful when distributing management control across a large enterprise. For both types of schedules, there are four key pieces of information: A command to be executed When the command executes How long the command takes to complete How often the command should be repeated The command that you run may be an incremental backup (client schedule) or a storage pool migration (administrative schedule) that should be run every day at a particular time. You will also have to estimate how long the command will run so that you can synchronize your schedules and balance load on the server. All schedule start times are based on the IBM Tivoli Storage Manager server clock, regardless of the time zones where the clients are located. 10.2 Administrative schedules An administrative schedule is a directive to trigger some sort of action on the IBM Tivoli Storage Manager server. It consists of a command or sequence of commands and some details about when the actions should happen. Any actions that are used on a regular basis to manage the Tivoli Storage Management environment should be defined as an administrative schedule. Administrative commands can be scheduled for use in tuning operations and to start functions that require significant server or system resources. Automating these operations 174 IBM Tivoli Storage Management Concepts

to occur in a quiet period, such as overnight, enables the administrator to ensure that server resources are available when needed by clients. 10.2.1 Scheduling concepts The example in Figure 10-1 shows a series of operations that could occur in an IBM Tivoli Storage Management environment and the sequence for those operations. The circle represents a clock, and the tick marks indicate the hours of the day. The actual start time and duration of the various operations are subject to your scheduling requirements, and the sequence should be carefully considered. 22 23 00 01 02 Backup 18 19 17 20 16 21 Clients Operating Expiration Reclamation performed on storage pool TAPEDATA Incrementally back up all clients on the network Reclamation performed on copy pool OFFDATA Migration forced from DISKDATA to TAPEDATA Reclaim OFFDIRS 03 Backup stgpool DSKDIRS (RAID) DISKDIRS 04 Backup stgpool DISKDATA Backup stgpool TAPEDATA Backup Database Clients resume normal operations 08 (RAID) DISKDATA 05 06 07 TAPDATA(LIBRARY) PRIVATE SCRATCH DB DB COPY Delete volhist and backup devconfig OFFDIRS Backup Backup OFFDATA (USED) (FREE) OFFDATA Create list of tapes for vault and return Return Reusable Tapes DBBACKUP 15 09 Send copy to vault 14 13 12 11 10 Figure 10-1 Client schedules Chapter 10. Scheduling 175

10.3 Client schedules A client schedule is a directive to trigger an action on one or more IBM Tivoli Storage Manager client machines. It is different from an administrative schedule in that it specifies that an action be performed on the IBM Tivoli Storage Manager client. The client scheduling system consists of a server portion and a client portion. The server part is integrated into the IBM Tivoli Storage Manager process and is responsible for defining the schedule parameters and associating nodes with the schedule. The client scheduler is a separate process on the IBM Tivoli Storage Manager client that provides communication between the server and client. A client must be running its scheduler process to be able to execute scheduled operations. Otherwise, the operation will fail and will be logged as such in the IBM Tivoli Storage Manager server. The success or failure of each scheduled operation is recorded in the server event log, so the administrator can query to find out which, if any, failed. The client also keeps a local record of scheduled operations. The definition of the client schedule includes the actions that are to be performed. This can include a single native IBM Tivoli Storage Manager backup, restore, archive, or retrieve command; a macro, which is a collection of native commands; or a command script. A scheduled command script is simply any script that could be executed within the client operating system, such as a Windows batch command file or a UNIX shell or perl script. The command script itself could contain IBM Tivoli Storage Manager client commands plus logging, setup, error detection, post-backup procedures and so on, or might be used to schedule functions totally unrelated to IBM Tivoli Storage Manager functions if required. It is therefore a very flexible general purpose scheduler. A schedule is defined within the policy domain, so that only the client nodes contained within that domain are eligible to execute that schedule. After defining the schedule, the administrator then needs to specify which client nodes (from those in the domain) should execute the schedule. This action is called associating clients with a schedule. The administrator may choose to associate all of the nodes in the domain or just a subset, according to requirements. The associations can be changed at any time. There are two scheduling modes available for establishing communication between the client and server to start a scheduled event, as shown in Figure 10-2 on page 177. The selection of which mode to use is set in the client options file and is also dependent on the basic communication protocol used between the client and server. If the communication method is anything other than TCP/IP, then only the client polling method may be used. If TCP/IP is used, then the client may select either method. Optionally, the server can override the client s preference if required. 176 IBM Tivoli Storage Management Concepts

Client Scheduler (Schedule start time based on Tivoli Storage Manager server clock) Client Polling Server Scheduler Service 12 12 11 1 11 1 10 2 10 2 9 3 9 3 8 4 8 4 7 5 7 5 6 6 Client Options File Scheduling Parameters Server Status Scheduling Parameters Figure 10-2 Client schedule types Server Prompted (TCP/IP protocol only) 10.3.1 Client polling Client polling means that the client contacts the server to find out whether there is a schedule defined for him and when he should run it. So that the client can respond dynamically to any amendments made to its schedules by the administrator, the client continues to contact the server at regular intervals set in the options file. When a contact is made, if there is a schedule to execute, the client receives a start time from the server clock. The client then counts down to the start time, when it will perform the actions defined by the schedule. If there is no scheduled action to run between the time of contact and the next contact time, the client returns to sleep. For example, a daily schedule may back up all of the client s file systems incrementally. Figure 10-3 on page 178 shows a client polling schedule configuration in which the client keeps querying the IBM Tivoli Storage Manager server from time to time about the next operation to run. In this case, the IBM Tivoli Storage Manager server informs the client when the scheduler must run, but if it is not the right server time, the client waits for the right moment. This mode s advantage is that you can have the server automatically assign random start times for each client s schedule execution within a proportion of the Chapter 10. Scheduling 177

schedule s window. This is useful if many clients have to execute the same scheduled operation and you do not want to overload the server by starting them all simultaneously. This randomization function is not available when the schedule mode is server-prompted. Client Polling IBM Tivoli Storage Manager Client IBM Tivoli Storage Manager Server 1) What is the next schedule? 12 11 10 9 8 7 6 1 2 3 4 5 & HSM DRM server clock 2) "incremental, 8:00" Figure 10-3 Client polling scheduling 10.3.2 Server-prompted In server-prompted mode, the client first contacts the server to notify that it is running and is able to receive new schedule notifications. The client then sleeps until the server contacts it. When the server detects that a new schedule is ready to run, it contacts the client and informs that a new scheduling operation must be started. The client gets all of the schedule definitions and starts the operation. Figure 10-4 on page 179 shows an example of a scheduled operation that the client must run. 178 IBM Tivoli Storage Management Concepts

& HSM Server Prompted IBM Tivoli Storage Manager Client I AM HARRY. I am ready to receive new schedules IBM Tivoli Storage Manager Server 10 9 8 11 7 12 6 1 2 3 4 5 server clock 11:40 HSM DRM HARRY IBM Tivoli Storage Manager Client & HSM DRM Session IBM Tivoli Storage Manager Server It's 12:10. You have a new schedule 10 9 8 11 7 12 6 1 2 3 4 5 server clock 12:10 DRM & HARRY Figure 10-4 Server-prompted scheduling If you use server-prompted scheduling, you can quickly and easily rerun a failed backup process because you can restart it from the server. The other advantage of server-prompted scheduling is that you do not have the continued regular polling traffic from each client that is required by the client polling method. 10.3.3 One-time client schedule As well as regularly scheduled operations, you may also define a schedule for one-time-only processing, on a single client or set of clients. This is called a CLIENTACTION schedule. Unlike the regular client schedule, the definition of a one-time client schedule and association of the nodes with it is done as a single command by the administrator. Once the schedule is defined, the client nodes associated with the schedule that are using server-prompted mode receive the schedule and Chapter 10. Scheduling 179

process the command virtually immediately. Clients using the client polling mode will receive the command the next time they poll the server. The length of time the CLIENTACTION schedule exists on the server is defined by another administrator-defined parameter. After this time, the database will automatically remove it whether associated nodes have run the schedule or not. 10.4 Frequency and duration The administrator defines the time period (that is, the duration) during which a schedule can start, and how often to repeat the schedule (the frequency). An example of a typical schedule frequency could be every night at midnight. The start time is 00:00, the period between startup windows is 24 hours, and the duration is set to two hours, as shown in Figure 10-5. Figure 10-5 Schedule frequency The actual time that a scheduled operation will start can be at any time during the duration window. If it is unable to start in this window, then it will be missed and recorded as such. After the period parameter between schedules has passed, the schedule will attempt to start again. The duration window therefore allows handling of a situation where the client is not running its scheduler process when the schedule is supposed to start (for example, if it has been powered off). So long as the client is available at some time before the end of the duration window, the schedule will be able to start. 180 IBM Tivoli Storage Management Concepts

The actual time that a scheduled event will end is dependent only on how long it takes the scheduled process to complete. It has no relation to the duration window. This is shown in Figure 10-5 on page 180. 10.5 Retry and randomization You can specify the maximum number of concurrent clients allowed to log on to IBM Tivoli Storage Manager, as well as the maximum number of scheduled sessions allowed. If you restrict the number of scheduled sessions allowed on the server, a client is prevented from running a schedule when the maximum number of sessions has been reached. Through options that can be set globally at the server or individually for each client, the client can retry a certain number of times to run the schedule, with a specified time interval between retries. With the retry and randomization options, you have considerable flexibility to balance the network load. Consider a scenario where an administrator associates 100 workstations with a backup schedule that has a window of 2 a.m. through 6 a.m. every Friday. You can use the randomization option to tell IBM Tivoli Storage Manager to stagger the start times of 100 backup sessions so that they start at different times. This way, you prevent a big bottleneck, which would occur if the 100 schedules started at 2 a.m., all at once. 10.6 Event log Scheduled operations are recorded centrally in the event log at the server. You can view which schedules ran successfully, were missed, and are scheduled to run in the future. You can create an exception reporting list. In this way you can view only those schedules that failed. Detailed reports of the schedule are logged at client level. High-level results are sent to an event log so you can view whether or not schedules ran successfully. You determine how long a record is retained in the event log. Chapter 10. Scheduling 181

182 IBM Tivoli Storage Management Concepts

11 Chapter 11. Data storage IBM Tivoli Storage Manager represents data storage with administrator-defined objects: storage pools and storage pool volumes based on physical data storage objects such as libraries and tapes or disks. In the following sections we discuss how IBM Tivoli Storage Manager automatically manages these pools and how you can define and check that the command used has performed the changes you require. We also discuss some IBM Tivoli Storage Manager concepts related to storage pools: how to use fewer tapes (reclamation) and how to reduce a client s restore time (collocation). We provide a brief outline for protecting disk storage by using some form of redundant array of independent disks (RAID). Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 183

11.1 Storage device management The IBM Tivoli Storage Manager devices and media are represented by objects that you have defined that are stored in the database. The objects contain information about the devices and media. You can query, update, and delete the objects. Figure 11-1 shows an overall view of the IBM Tivoli Storage Manager storage objects and their mutual relationships. Logical Layer Storage Pool Volumes Physical Layer Storage Pools Random Acc Sequential 3 Storage Pool Volumes stgvol01.dsm stgvol02.dsm Deviceclass Deviceclass stgvol02.dsm. stgvoln.dsm Files Library Library Tapes Drives Drives Path Figure 11-1 IBM Tivoli Storage Manager storage objects 11.1.1 Storage pool A storage pool is a collection of storage pool volumes; each storage pool represents one type of media. For example, a storage pool for a 4-mm digital audio tape device (DAT) represents collections of only 4-mm tapes, and a storage pool for an IBM 3590 represents collections of only 3590 tapes. A storage pool created on a disk has files formatted under IBM Tivoli Storage Manager as volumes and are collectively grouped in the storage pool. 184 IBM Tivoli Storage Management Concepts

You can add or remove volumes without interrupting server operations. In this way you can increase or decrease the size of a storage pool dynamically without any interruption to the IBM Tivoli Storage Manager service. The two main categories of devices supported for storage pools are random access and sequential devices. Random access devices refer to magnetic disks. Sequential devices usually refer to tape devices and/or optical devices that require manual configuration. It is also possible to configure a disk in a way that it will be accessed sequentially (a FILE device class). Storage pools in IBM Tivoli Storage Manager are defined on a wide range of different devices that may be attached locally to the server or accessed via a storage area network (SAN). 11.1.2 Device class Storage pools are based on a device class that defines the type of storage hardware used for this storage pool. The device class not only includes the storage device type but also points to a special storage device defined to the IBM Tivoli Storage Manager server. Each device defined to IBM Tivoli Storage Manager is associated with one device class. That device class specifies a device type and media management information, such as recording format, estimated capacity, and labeling prefixes. IBM Tivoli Storage Manager provides a set of specified removable media device types, such as 8MM for 8-mm tape devices, or REMOVABLEFILE for Jaz or Zip drives. Magnetic disk devices are the only random access devices. All disk devices share the same device type and predefined device class: DISK. When using a sequential media type, a device class usually points to an associated library that will store the data from the storage pools that base on this device class. Mixed media libraries Mixed media in an IBM Tivoli Storage Manager server describes devices that use different device types (from define devclass) in the same logical library. Ultrium1 and SDLT are examples of two devices that need different device classes but can co-exist in the same library. Mixed generation devices A mixed generation device in an IBM Tivoli Storage Manager server describes devices that use the same device types despite capacity differences. In order to Chapter 11. Data storage 185

have mixed generation devices in the same device class, the media types must be distinguishable. Note: In mixed generation environments, the current generation device can generally read and write current and previous generation media. The previous generation device can only read and write previous generation media. LTO Ultrium devices are an example of mixed generation devices. For further details about implementing LTO devices and IBM Tivoli Storage Manager, refer to the redbook Using IBM LTO Ultrium with Open Systems, SG24-6502. 11.1.3 Library 11.1.4 Drive 11.1.5 Path A library represents a storage entity that contains drives and tapes for storing data. You cannot use a library without defining drives to it. Notice that a defined library only represents a logical object with at this point no connection to real-world hardware. It represents a physical object, but the direct link between the logical and the physical library will be defined later by the path objects. A drive is part of a library that is used to write and read data to and from tape volumes stored in the associated library. The special hardware-based format used by the tape device is represented in the corresponding device class. Though a device class has no direct connection to a device object they are linked by the library object that contains the drives. As described in the Library section, a drive is only a logical object at this point. The direct connection will be established later by the path object. Paths allow access to drives and libraries. A path definition specifies a source and a destination. Thus a path connects the logical layer within the IBM Tivoli Storage Manager server with the real-world physical hardware. Through this concept all storage devices on the server are shareable between different IBM Tivoli Storage Manager servers, storage agents, and clients. All of them use the same logical object but the individual connection to the associated hardware is established with an individual path definition for each of them. The source accesses the destination, but data can flow in either direction between the source and destination. Here are a few examples of paths: In LAN operations and most SAN operations, control data and client data flow across a path from the IBM Tivoli Storage Manager server to an automated 186 IBM Tivoli Storage Management Concepts

library that is defined to the server. During a restore, client data also flows from the library back to the server. In NDMP operations, backup data flows across a path between the source, a data mover defined for an NAS file server, and the destination, a tape drive. Restore data flows back across the path from the tape drive to the NAS file server. Paths can address the same destination device from different sources. For example, in NDMP operations, paths are always required between the data movers that represent NAS file servers and the drives to which the file servers transfer data for backup. Paths can point from multiple NAS file server data movers to the same tape drive. 11.1.6 Data mover Data movers are devices that accept requests from Tivoli Storage Manager to transfer data on behalf of the server. Data movers transfer data: Between storage devices Without using significant IBM Tivoli Storage Manager server or client resources Without using significant network resources For NDMP operations, data movers are NAS file servers. The definition for an NAS data mover contains the network address, authorization, and data formats required for NDMP operations. A data mover enables communication and ensures authority for NDMP operations between the IBM Tivoli Storage Manager server and the NAS file server. 11.1.7 Server The server-to-server communication capabilities between different IBM Tivoli Storage Manager servers can also be used for data transfer and data storage purposes. Thus other IBM Tivoli Storage Manager servers also represent a storage device that can be used through a special device class. You must define a server object for the following purposes: To use a library that is on a SAN and is managed by another IBM Tivoli Storage Manager server. You must define that server and then specify it as the library manager when you define the library. To use LAN-free data movement: Define the storage agent as a server. To store client data in the storage of another IBM Tivoli Storage Manager server. Chapter 11. Data storage 187

11.2 Storage pools IBM Tivoli Storage Manager has two types of storage pools: Primary storage pools Copy storage pools 11.2.1 Primary storage pools When a client node backs up, archives, or migrates data, the data is stored in a primary storage pool. When a user tries to restore, retrieve, or export file data, the requested file is obtained from a primary storage pool if possible. Primary storage pool volumes are always located on-site. A primary storage pool can use random access storage (DISK device class) or sequential access storage (for example, tape, optical, or FILE device classes). 11.2.2 Copy storage pools A copy storage pool provides an additional level of protection for client data. It is created by the administrator backing up a primary storage pool. The copy storage pool contains all current versions of all files, active and inactive, exactly as they appear in the primary storage pool. A copy storage pool provides recovery from partial and complete failures in a primary storage pool. An example of a partial failure is a single tape in a primary storage pool being lost or defective. When a client attempts to restore a file that was on this volume, the server will automatically switch to the right copy storage volume if it is available to seamlessly restore the client s data. If a complete primary storage pool is destroyed (for example, in a major disaster), the copy storage pool is used to recreate the primary storage pool. A copy storage pool can use sequential access storage (for example, tape, optical, or FILE device classes). Copy storage pools can also be created remotely on another IBM Tivoli Storage Manager server, thus providing electronic vaulting. See 14.4, Virtual volumes on page 237 for more information. Copy storage pool volumes can be moved off-site and still be tracked by IBM Tivoli Storage Manager. This is done by using the offsite access mode to ensure that IBM Tivoli Storage Manager does not request a volume mount. Moving copy storage volumes off-site provides a means of recovering from a disaster at your primary site. Disaster Recovery Manager (see Chapter 16, Disaster Recovery 188 IBM Tivoli Storage Management Concepts

Manager on page 255 for more information) helps automate off-site media tracking and storage pool recovery. Copy pools are not part of the storage migration hierarchy. Files are not migrated to or from copy storage pools. There are two ways to store files in a copy storage pool: Copy the primary storage pool to a copy storage pool using the BACKUP STGPOOL command. Simultaneous write to copy storage pools during client data transfer activity. 11.2.3 Simultaneous writes to copy storage pools IBM Tivoli Storage Manager can simultaneously store a client s files to each copy storage pool specified for the primary storage pool where the client s files are written. The simultaneous write to the copy pools only takes place during backup or archive from the client (in other words, when the data enters the storage pool hierarchy). It does not take place during data migration from an HSM client nor on a LAN-free backup from a storage agent. Up to 10 copy storage pools can be specified for each primary storage pool. This is not a replacement for the BACKUP STGPOOL operation.the BACKUP STGPOOL command cannot write to multiple copy storage pools at the same time. C B A COPYPOOL1 C B A C B A DISKPOOL C B A IBM Tivoli IBM Tivoli Storage Storage Manager define stgpool client diskpool Manager server copystgpools=copypool1,copypool2 Figure 11-2 Simultaneous write COPYPOOL2 How to use simultaneous writes to copy storage pools Careful consideration should be used with simultaneous write or copy pool duplexing. The data is written to the copy storage pool and primary storage pool simultaneously. The backup performance will only be as good as the slowest device being used for any of the pools. There also have to be enough mount Chapter 11. Data storage 189

points available; otherwise, only the client, not the server, will issue the ANS1312E message: ANS1312E Server media mount not possible Note: If you have multiple clients backing up to the same primary pool and the copy pools are tape-based, each client requires multiple mount points to be able to write the data to the copy pool simultaneously. The number of mount points allowed for a node is restricted by the node parameter MAXNUMMP. 11.3 Storage pool hierarchy IBM Tivoli Storage Manager enables you to configure storage pools to provide the best combination of performance throughput and data permanence. In most cases, keeping client data on tape or optical media is a requirement. However, making the backups direct to tape may not give the best performance, especially where there are many clients to back up concurrently, and many small files are being backed up. Therefore, IBM Tivoli Storage Manager provides a storage pool hierarchy, whereby a client initially backs up to a storage pool, usually on disk. When this storage pool fills up, IBM Tivoli Storage Manager will automatically migrate files to the next storage pool in the hierarchy (usually on tape or optical) while the client continues its backup operation. This migration process is controlled by high and low thresholds set on the storage pool. The management class (see 9.2, Data storage policy components on page 162) determines where the client data enters the storage hierarchy. Figure 11-3 on page 191 shows a configuration where five storage pools are defined. The default management class sends backups first to storage pool A, which are then migrated by the server to pool B and finally to pool C. The other management class uses storage pool D for space managed files, whereas backups are sent directly to Tape_Pool. This would be appropriate for large client files (for example, application database files) that can exploit the streaming performance capacity of the tape device. 190 IBM Tivoli Storage Management Concepts

Storage Pool Assignment Pool_A Pool_B MC BKUP_DEST default Space_DEST Pool_D CLIENT MC Space_DEST BKUP_DEST ARCH_DEST Pool_C Tape_Pool Figure 11-3 Possible hierarchical arrangement of different storage devices 11.4 Movement of data between storage pools There are two controls available to help you automatically control the space in the storage pools: 11.4.1 Migration Migration Maxsize Migration helps you control the amount of free space within a storage pool. You can define a high and a low migration threshold for each storage pool in the hierarchy. These thresholds tell IBM Tivoli Storage Manager when to move data from one storage pool to another, as illustrated in Figure 11-4 on page 192. When the amount of data in a storage pool reaches the high threshold, IBM Tivoli Storage Manager moves client data to the next storage pool until the first storage pool reaches the low threshold. The objective is to clear as much space as quickly as possible. To do this, IBM Tivoli Storage Manager picks the client node whose collection of data occupies the most space in that storage pool and Chapter 11. Data storage 191

migrates the largest filespace of that client data. It then picks the next client node that has the most data and migrates it. The migration continues until it reaches or surpasses the low threshold and is always done at a filespace level of granularity. This operation not only clears space quickly but also keeps a client s data close together in the hierarchy. This mechanism in turn reduces the number of media mounts required during client data restoration. For random access storage pools only, you can specify the number of processes that are used for migrating files from this storage pool. This parameter is optional, and the default value is 1. You can use a migration process value equal to or less than the number of drives in the next storage pool you are migrating to; these processes are performed in parallel to improve data transfer rates. Be aware that if you have two tape drives in the target storage pool, and if you have set this parameter to 2, this will interfere with any other requests for this tape device until the migration process is completed. If your disk pool is sufficiently sized and disk caching is on (see 11.6.2, Disk caching on page 200), or a migration delay value set, then this may minimize the potential for such problems. You can specify the number of days to delay migration for files in a storage pool; this ensures that files stay in a pool for a minimum number of days. Setting this parameter may imply that a larger space is required for your disk storage pool to be able to keep the files there. The benefit is that required files can be restored faster if they have not yet been migrated from the disk storage pool. DISK TAPE High Threshold 70% Low Threshold 30% MIGRATION High Threshold 70% AFTER MIGRATION Low Threshold 30% Figure 11-4 Migration between storage pools 192 IBM Tivoli Storage Management Concepts

11.4.2 Maxsize If you assign a MAXSIZE value to a storage pool, files can be placed in that storage pool provided they are equal or less than the assigned MAXSIZE. If compression is used, the uncompressed size of the file is used for comparison. If a file is too large for the first storage pool it will go straight to the next storage pool defined. This is another way to improve performance by not wasting time writing large files to the first pool, only to trigger an immediate migration when the storage pool is filled. This parameter is not required. If you do not assign a MAXSIZE, and a file entering the storage pool causes it to exceed its high threshold, migration will automatically occur to move data to the next storage pool. 11.5 Reclamation Reclamation is used to free complete tape (or optical) volumes in sequential storage pools. Because IBM Tivoli Storage Manager keeps a defined number of versions of files as it does incremental backups, the oldest copy of a file (beyond the defined number of versions to keep) gets marked for expiry. This file will then be deleted when the next expiration occurs. It is common for a tape volume to have files that will expire on different dates. Therefore, as these files reach their expiry date and the expiration process occurs, virtual empty spaces appear on the tape volume. Fragmentation may also appear on the volume through file deletion on the client causing the removal of many file versions because of management class definitions, or by complete filespace deletion. Fragmentation is undesirable on tapes or optical disks because it makes for slower restores due to the need to skip over the empty spaces, and it increases the total number of volumes required for data storage. It is not possible to go back and rewrite new data in these empty spaces as these are sequential media and can only be written from the beginning to the end. The amount of space that can be reclaimed on a volume increases as files on the volume are deleted. When the percentage of space that can be reclaimed on a volume rises above the value for the reclaim threshold set for the storage pool, that volume is reclaimed. Active files on the volume are rewritten to other volumes in the storage pool, making the original volume empty. Typically it will return to a scratch status, meaning that it is available to be reused for any IBM Tivoli Storage Manager function requiring it. See Figure 11-5 on page 194, which shows reclamation on two fragmented volumes to produce a 95 percent full volume and a free volume. Chapter 11. Data storage 193

It is recommended that you specify a value of 50 percent or greater for this parameter so that files stored on two volumes can be combined onto a single output volume. Reclaim threshold 60% free This volume has more than 60% free space This volume is now empty and can be reused + = + 25% full 70% full 0% full 95% full (Reclaim value 75%) + = + (Rec. value 30%) Figure 11-5 Reclamation on two fragmented volumes (Rec. value 100% - but will not be eligible for reclamation until volume has refilled once more) (Rec. value 5%) For volumes that are not marked as off-site volumes, reclamation can occur only after the volume has been filled and then begins to empty because of file deletion. The reclamation process is very device-intensive, as it normally requires at least two available drives in the library. This might unnecessarily delay other critical IBM Tivoli Storage Manager operations (for example, a client restore) if all drives were engaged in reclamation. So we usually recommend disabling reclamation by setting the storage pool reclamation threshold to 100. At a suitable time, say on Saturday afternoons, reclamation can be enabled by running an administrative schedule to lower this threshold to a suitable value, which automatically triggers reclamation to start. The threshold can then be reset back to 100 for normal operations during the week. For off-site volumes, reclamation can occur regardless of whether the volume has ever been filled. An off-site volume is eligible for reclamation when the percentage of unused space on the volume is greater than the reclaim parameter value. The unused space includes both space that has never been used on the volume and space that has become empty because of file deletion. To avoid excessive reclamation on copy storage pools, it is also recommended to disable reclamation except for certain defined periods as described in the previous paragraph. Another reason to control reclamation in off-site volumes is explored in 11.5.2, Reclamation of off-site volumes on page 196. 194 IBM Tivoli Storage Management Concepts

11.5.1 Single drive reclamation Reclamation requires two or more drives to work most efficiently. Nevertheless, reclamation can be performed by a single drive in IBM Tivoli Storage Manager by specifying the RECLAIMSTGPOOL parameter. This parameter allows another storage pool to be used as the holding area for the sequential volume being consolidated. The storage pool specified as the reclaim storage pool must be a primary sequential storage pool on the system. Typically, it is a new primary storage pool created for this purpose. Since it must be a sequential disk, in order to use a disk as a staging area, a devicetype of FILE is required. When the amount of reclaimable space on a media volume exceeds the reclamation threshold, IBM Tivoli Storage Manager automatically begins the reclamation process. The volume to be reclaimed is mounted in the drive, and the active data is moved to the reclaim storage pool. If the reclaim storage pool is filled, the volume being reclaimed is dismounted, and a new volume in the same tape pool is mounted. The reclaimed data in the reclaim pool is then migrated to that tape volume. Once this process is complete, it repeats until all valid data has been reclaimed from the source volume being reclaimed. If the reclaim storage pool is not filled before the source volume is emptied, another source volume is mounted and reclamation continues. This process continues until either the reclaim storage pool is filled or all expired data within the storage pool has been removed. When defining the reclaim storage pool you must also define the NEXTSTGPOOL parameter pointing back to the pool being reclaimed. Thus the reclaimed data can be migrated back to the original storage pool. See Figure 11-6 on page 196. Chapter 11. Data storage 195

Reclaim storage pool Enables data to be reclaimed within the hierarchy Must be sequential access media Has the pool being reclaimed as its NEXT storage pool RECLAIMSTGPOOL= FILEPOOL TAPEPOOL NEXTSTGPOOL= TAPEPOOL FILEPOOL Figure 11-6 Single drive reclamation example In the example, TAPEPOOL is a storage pool defined within a single drive library. TAPEPOOL is define with FILEPOOL as its RECLAIMSTGPOOL, and the FILEPOOL is defined with the TAPEPOOL as its NEXTSTGPOOL storage pool. We should note that single drive reclamation is itself a time-consuming process, so to avoid having to do this we would always strongly recommend IBM Tivoli Storage Manager configurations with two or more drives in each library. 11.5.2 Reclamation of off-site volumes Care must be taken in reclaiming off-site copy storage volumes. IBM Tivoli Storage Manager cannot physically move the data from one of these volumes to another because they are in a vault, not available in the library. IBM Tivoli Storage Manager manages reclamation for an off-site copy pool by obtaining the active files from a primary storage pool or from an on-site volume of a copy pool. These files are then written to a new volume in the copy pool, and the database is updated. A message is then issued that an off-site volume was reclaimed. The new volume will get moved to the off-site location, and the off-site volumes, whose active data it has combined, will be moved back to the scratch pool on-site when the reuse delay parameter has been satisfied. (See Figure 11-7 on page 197.) 196 IBM Tivoli Storage Management Concepts

Primary or on-site copy Copy Pool (on-site) 2 000129 moves offsite Copy Pool (off-site) File A 1 000129 000012 File A Reclamation using on-site copies B File A 000013 B B Database updated Database File A Vol 000129 File B Vol 000129 Recl Vol 000012 Recl Vol 000013 Scratch Pool (on-site) 000012 000013 Figure 11-7 Reclamation of off-site volumes 3 After delay reuse period is satisfied, 000012 and 000013 move back into on-site scratch pool for re-use However, if a disaster occurs, there could be a problem: If the reclaimed volumes have already been returned to the scratch pool and the new volume has not yet been taken off-site, we have lost any off-site backup. This is the reason for the delay reuse period for tapes returning to the scratch pool. Also, be aware that to use the off-site tape volumes 000012 and 000013 in the event of a disaster, you need the database backup that pointed to the files on these volumes. This can be achieved by controlling when reclamation will occur by scheduling it properly. Basically, you must ensure that you have performed a backup of all on-site storage pools to their off-site copy pools, then perform a database backup so that the off-site database copy points to all of the files in their new locations. Then you can perform reclamation. The reuse delay period defined on the storage pools must be long enough to ensure that the reclaimed volumes do not return to the scratch pool before another database backup is made. 11.6 Reduce restore times Storage pool configuration can reduce restore times by these techniques: Collocation by minimizing the number of tape volumes used to store a client s data. Chapter 11. Data storage 197

Disk caching by restoring data from disk even if it has already been migrated. Moving data to fast access storage pools or consolidating data before restoring them 11.6.1 Collocation Collocation is a process in which the server attempts to keep all files belonging to a client node on a minimal number of sequential access storage volumes. To collocate data when files from different client nodes are mixed in the same storage pool, set collocation to yes when you define or update a sequential storage pool. By using collocation, you reduce the number of volume mount operations required when users restore or retrieve many files from the storage pool. Collocation thus improves access time for these operations. See Figure 11-8 on page 199. You can choose to have the IBM Tivoli Storage Manager server collocate at the client or filespace level. To have collocation set at the filespace level, set collocate to filespace. If this is defined, the server attempts to put data for one node and filespace on one volume. If a node has multiple filespaces, the server attempts to place data for each filespace on different sequential volumes in the storage pool. When collocation is disabled, the server attempts to use all available space on each volume before selecting a new volume. While this process provides better utilization of individual volumes, user files can become scattered across many volumes, so to restore a client completely may require many volume mounts. 198 IBM Tivoli Storage Management Concepts

Storage Pool - Collocation BKUP_SP1 B A B C C B A A C B Hi Threshold Lo Threshold Migration Migration TAPE_SP1 Client A Client B Client C A A A B B B C C C B A B C Client A Client B Client C Keep workstation data together Reduce tape mounts during restore Selectable option at storage pool level Figure 11-8 Storage pool collocation on a client level Collocation also means that IBM Tivoli Storage Manager attempts to use at least one tape volume for each client. If you have a limited time for backup, more media mounts will be required with collocation, which may not be desirable. If you first back up to a disk pool and then migrate to a sequential pool, collocation works well because of the way migration works on a client-by-client level. Collocation also requires more volumes, as well as capacity to store these additional volumes in an automated library. However, restore times are usually critical, and collocation can provide a significant time saving. Collocation also helps avoid the situation in which two clients attempt to recover a file that resides on the same tape volume. There are special considerations when using collocation on copy storage pools. Collocation typically results in a partially filled sequential volume for each client. This may be acceptable for primary storage pools because these partially filled volumes remain available and can be filled during the next migration process. However, for copy storage pools this may be unacceptable because the storage pool backups are usually made to be taken off-site immediately. If you use collocation for copy storage pools, you will have to decide whether the overhead of taking more partially filled volumes off-site and increasing the reclamation activity is worth the benefit of recovering your most important clients quickly in the event of a disaster. Chapter 11. Data storage 199

11.6.2 Disk caching Disk caching is used for disk storage pools only. When cache is enabled, the migration process leaves behind duplicate copies of the files on disk after the server migrates these files to subordinate storage pools in the hierarchy. The copies remain in the disk storage pool, but in a cached state, so that subsequent retrieval requests can be satisfied quickly. However, if space is needed to store new data in the disk storage pool, the space occupied by cached files can be reused immediately for the new data. When space is needed, the server reclaims space by writing over the cached files. Files that have the oldest retrieval date and occupy the largest amount of disk space are overwritten first. When caching is used, the occupancy value that the server compares against the migration thresholds does not include space occupied by cached copies of files. The space utilization of the pool, however, does include the space used by any cached files in the storage pool. If you update a storage pool from cache=yes to cache=no, the cached files will not disappear immediately. The occupancy value %util remains the same. The cache space will be reclaimed over time as the server needs the space, and no additional cached files will be created. Do not use cache if you have limited database space. When you use cache, more database space is needed because the server has to keep track of both the cached copy of the file and the new copy in the subordinate storage pool. 11.6.3 Data movement As stated previously, collocation keeps a client s files close together, maybe even on one volume, which might increase restore performance. In large environments collocation is usually very tape-consuming so it is uneconomical to use. Moreover, a lot of tape mounts are required during migration and reclamation. But even in large environments collocation would be very useful for decreasing restore time. IBM Tivoli Storage Manager enables you to move data down to a level of a client s filespaces using the MOVE NODEDATA command. This offers a chance to collocate data for specified nodes only on demand so the next restore would finish faster. Using the same command, IBM Tivoli Storage Manager also enables data movement between different storage pools. As opposed to migration, selected clients data can be moved, not only the entire storage pool. This opens the ability to move data to a storage pool that offers fast and parallel access, such as a disk storage pool. So multiple clients can restore their data faster using multiple sessions. 200 IBM Tivoli Storage Management Concepts

11.7 Disk storage protection Disk technology continues to improve, in terms of capacity, speed, reliability, sharability and availability. Many businesses use enterprise storage servers, which can be attached directly via network or using a SAN. IBM Tivoli Storage Manager exploits the services provided by this technology to provide greater protection for itself and its client data. Disks are used within IBM Tivoli Storage Manager for its database, recovery log, and random access storage pools. 11.7.1 RAID To protect data on a disk-type storage device, we recommend that you use some form of RAID, which can be implemented at either a hardware or software level. Protecting data stored on a disk is a subject in itself, and below we just touch on some of the possibilities you may want to look into further. The best solution for you will depend on many factors: Server hardware and hardware RAID solutions available Operating system type and software RAID solutions available Price, performance, and redundancy level of the solution A hardware RAID solution can be beneficial for reducing the performance penalty on the server when implementing RAID. It can also provide disks and controllers that can be exchanged on the fly if they fail (also known as hot-swapping or hot-plugging). Dual-pathing, power redundancy, and hot spare features are other possibilities. You may also consider implementing managed server storage shared among a number of servers with dynamic allocation of shared storage. A software RAID solution can provide levels of redundancy with a much lower initial outlay if implemented carefully, using a number of physical disks. There are also different ways of transmitting data to the physical disks, such as SCSI, SSA, and fiber, which all have advantages and disadvantages. Whichever path you choose, we recommend that you implement one of the three following RAID levels: RAID 1 Mirror RAID 1 + 0 Mirror and Stripe RAID 5 Distributed Parity Chapter 11. Data storage 201

11.7.2 RAID 1 RAID 1, or Mirror, uses two physical disks and writes the same data to each of them. Should one fail, the other is an exact copy and the data is not lost. (See Figure 11-9.) This means that usable space will be half of your total disk space. If you have 2 x 4 GB drives mirrored, then your logical drive will only appear as 4 GB. There is also a performance penalty, as every write to disk will now incur two writes. However, there can be an improvement on reads from disk, as the data requested can be accepted from whichever drive can satisfy the request first. Should a drive fail, there is almost no performance penalty except while the rebuild is being done. This might be automatic (if hot spares are available) or require the installation of a new disk and a re-synchronization of the mirrors. Note that IBM Tivoli Storage Manager provides its own software mirroring function specifically for database and recovery log volumes. Each volume can be mirrored up to three-way. It is recommended that you use this in-built mirroring function rather than hardware or operating system software mirroring where greater availability for the database and recovery log is required. MIRROR USABLE SPACE file A 4GB file A 4GB file A 4GB PHYSICAL DISKS LOGICAL DISK Figure 11-9 RAID 1 (mirroring) user-usable space = 1/2 total disk space 11.7.3 RAID 1 + 0 RAID 1 + 0, or Mirror and Stripe, takes mirroring a stage farther by striping the data across a number of mirrored drives. See Figure 11-10 on page 203. RAID 1 + 0 requires an even number of physical disks (minimum of four with the maximum usually dependent on hardware). All disks are mirrored initially, then 202 IBM Tivoli Storage Management Concepts

should any disk in a pair fail, the data is safe. RAID 1 + 0 can withstand one disk from every pair failing. But if both disks in any pair should fail, the data is lost. These mirrored pairs of disks are written to by the controller in blocks or chunks of data at a time. For example, with six physical disks there would be three mirror sets. The controller would write a chunk of data to the first mirrored pair, then write another chunk to the second pair, then the third pair, and the fourth chunk of data would be written on the first mirrored pair again. (Refer to Figure 11-10.) This way of writing the data across the disks is called striping and it has performance advantages. Physical disks have a small amount of memory called cache where they can store data more quickly before the slower process of actually writing it onto the disk platter. Striping makes use of this characteristic; by writing data in chunks from disk to disk, it ensures that it has given the first disk time to complete its write cycle and empty its disk cache. It can then write the fourth chunk of data straight into the disk cache again without having to wait for the disk s write cycle to complete. Your logical drive or usable space will be half of your total disk space, but performance of this solution, potentially, will be better than RAID 1 or RAID 5. MIRRORSETS STRIPESET 4GB PHYSICAL DISKS 4GB Chunk 1 Chunk 4 4GB LOGICAL DISK 1 4 USABLE SPACE MIRROR 4GB 4GB Chunk 2 4GB 2 12GB PHYSICAL DISKS LOGICAL DISK MIRROR Chunk 3 3 LOGICAL DRIVE 4GB 4GB 4GB PHYSICAL DISKS LOGICAL DISK Figure 11-10 RAID 1 + 0, mirror and stripe Chapter 11. Data storage 203

11.7.4 RAID 5 RAID 5, or distributed parity, uses three or more physical disks in a stripeset. (See Figure 11-11 on page 205.) It differs from the stripeset in RAID 1 + 0, because it writes a parity check on one of the disks and the data on the others. Parity is what a RAID 5 set uses to reconstruct the data if one of the disks fails. In its simplest form it performs addition on the data of each data disk and indicates whether the result was an even or an odd number; it stores this on the parity disk. If one of the data disks fails, it can then work out what the data on the failed disk should be. Table 11-1 shows details. Table 11-1 Reconstructing a failed data disk from the parity disk Stripe Data disk 1 Data disk 2 Data disk 3 Result of addition Parity disk To maintain parity Data 2 must equal 1 1 0 1 2 EVEN 1+?+1=EV 0 2 1 1 0 2 EVEN 1+?+0=EV 1 3 1 1 1 3 ODD 1+?+1=OD 1 Disk fails After disk fails Calc. fm parity disk RAID 5 distributes this parity on a different disk for each stripe so that the same disk is not constantly being written to every time parity is updated. This can improve performance over RAID levels 3 or 4. 204 IBM Tivoli Storage Management Concepts

STRIPESET (4GB DISKS) Data 1 Parity 2 Data 5 1 USABLE SPACE PHYSICAL DISK 4 5 Data 2 Data 3 Parity 3 2 8GB PHYSICAL DISK LOGICAL DRIVE 6 Parity 1 Data 4 Data 6 3 1,2,3 Stripe 1 4,5,6 Stripe 2 PHYSICAL DISK Figure 11-11 RAID 5 stripe showing how parity is distributed Striping the data has a benefit for performance because of cache on the physical disk, as described in RAID 1 + 0. However, performance is not quite as good as RAID 1 + 0 because of the overhead involved in calculating parity. A hardware solution can take this overhead away from the server by performing the calculations on the controller. This is especially important if a disk should fail or if a failed disk is replaced and the RAID 5 set needs to reconstruct. Most enterprise disk subsystems also have large separate write caches to improve performance. The usable space in a RAID array can be calculated by removing the capacity of one of the physical disks from the total disk space. In Figure 11-11 there are 3 x 4 GB disks with a total disk space of 12 GB; removing the capacity of one of them gives you a usable space of 8 GB. If there were 8 x 4 GB disks with a total disk space of 32 GB you would follow the same rule to work out your usable space. Removing the capacity of one of them (4 GB) gives you a usable space of 28 GB. This explains why RAID 5 is widely used; it can be a more cost-effective solution. Chapter 11. Data storage 205

11.8 SAN exploitation This section discusses the basics of storage area networks and their usage within an IBM Tivoli Storage Manager implementation. 11.8.1 Overview SAN is a new architecture that puts storage on a separate dedicated network to enable businesses of all sizes to provide access to important data, regardless of operating systems, as a significant step towards helping customers cope with the explosive growth of information in the e-business age. A SAN is a dedicated network used for data movement or access purposes. This type of network is contrasted with the typical network, which in addition to data access (file serving) is used for communications functions such as e-mail, terminal connection, and application program communication. The intent of a SAN is to isolate shared data access functions from other functions to gain performance advantages while allowing the storage sharing and distances available with typical network file sharing. SAN topology enables any-to-any connections and consolidation among servers and storage systems in a networked environment. SANs de-couple ownership of storage resources from the servers. SAN architectures facilitate storage consolidation, clustering, high availability, fault tolerance, remote management, and flexible topologies, and can help eliminate scalability limitations and bandwidth concerns inherent in current environments. The industry considers Fibre Channel as the architecture on which most SAN implementations will be built. Fibre Channel is a technology standard that allows data to be transferred from one network node to another at very high speeds. Current implementations transfer data at 100 MB/s; 200 and 400 MB/s data rates have already been tested. This standard is backed by a consortium of industry vendors and has been accredited by the American National Standards Institute (ANSI). Many products are now on the market that take advantage of Fibre Channel s high-speed and high-availability characteristics. Fibre Channel architecture is often referred to as the fibre version of SCSI. Fibre Channel is an architecture used to carry IPI traffic, IP traffic, FICON traffic, SCSI traffic, and, potentially, traffic using other protocols, all at the same level on the standard FC transport. FICON is expected to be the standard protocol for 206 IBM Tivoli Storage Management Concepts

S/390, and FCP is expected to become the standard protocol for non-s/390 systems, both using Fibre Channel architecture to carry the traffic. IBM Tivoli Storage Manager provides a number of important SAN solutions continuing to exploit the technology. Many other solutions are in development and will be rolled out as SANs mature. All of these solutions address the need for efficient and reliable data protection: Tape library sharing The Tape Resource Sharing feature of IBM Tivoli Storage Manager enables administrators to pool tape resources for use by many Storage Manager servers running on heterogeneous platforms. This can improve backup and recovery performance and tape hardware asset utilization. This feature is described in 14.6, Tape library sharing on page 242. LAN-free client data transfer At the direction of the IBM Tivoli Storage Manager server, tape storage pools are dynamically allocated to IBM Tivoli Storage Manager clients. This enables backup information to be sent across the SAN directly from the client to the server storage pools. In this way the data path completely bypasses the LAN and the IBM Tivoli Storage Manager server. A lot less IP-communications bandwidth is used, and service levels for end users are improved.this method is described in 5.3, SAN (LAN-free) backup topology on page 74. 11.8.2 How to use a SAN environment This topic discusses advantages an IBM Tivoli Storage Manager implementation can derive from SAN-attached tape libraries, and eventually from disk storage. These advantages can be grouped into three main areas: Availability Performance Efficiency Availability When discussing the availability of an IBM Tivoli Storage Manager, all separate components must be covered. The server comprises the following three areas: The IBM Tivoli Storage Manager server itself, with its database and storage pool volumes The tape storage and SAN fabric System availability, which embodies all activities related to protecting the server operating system and application software Each solution discussed in the following sections refers to one of these areas. Chapter 11. Data storage 207

Remote tape library connection When implementing an IBM Tivoli Storage Manager solution, one of the most important issues is server protection. The server database and its storage pool volumes must be protected against corruption or loss. This is done by performing periodic database and storage pool backups to tape volumes, which are then moved to an off-site location. This removal of volumes, and the sometimes required recall, can lead to increased complexity and cost of the IBM Tivoli Storage Manager implementation. Using the capacity of single-mode or long-wave fiber connections, a SAN attached tape library can be placed off-site but remain connected to the IBM Tivoli Storage Manager server. This means that the actual physical checkout of volumes is no longer required, thus reducing cost and complexity. Another advantage is that, in case of primary volume unavailability, the copy pool volumes are instantly available. Figure 11-12 shows a possible setup for this solution. Main Site Offsite Vaulting Location Shortwave Fibre Channel SAN Longwave Fibre Channel to Remote Site (up to 10 kilometers) Shortwave Fibre Channel Figure 11-12 Remotely connected tape library Locally attached storage, both tape and disk, serves as primary storage space for the server. Database and storage pool backups are redirected to a SAN attached library. Making use of a switch and hub, both equipped with a single-mode fiber GBIC, the distance that can be obtained equals 10 kilometers. This means that the SAN attached library can be located in another building or secure location. 208 IBM Tivoli Storage Management Concepts

Fabric failover SAN fabrics are often described as high availability solutions. This statement derives from the fact that when creating a switched fabric, using multiple redundant paths, a switch failure can be handled by the other switches. Figure 11-13 shows such a meshed topology. In this configuration, when a link or a switch fails, other links exist, and other switches can take over the work of the failing switch. Furthermore, this recovery will be automatic. Switch 1 Switch 2 Switch 3 Figure 11-13 Meshed switch topology Switch 4 A result of a meshed or inter-switch topology and its multiple paths to each connected device is the duplicated device definition on a connected system. The operating system scans its environment and will probably find multiple devices that are in fact one and the same device but reachable via different SAN paths. So the operating system or the vendor of the connected storage device should support alternate pathing so that the operating only defines one virtual device that combines the different physical paths to the associated device. Performance One of the major advantages and goals of a SAN implementation is the performance gain obtained compared to the classic network-based solutions. The reasons for these gains are the higher throughput of the SAN fabric and the exclusive character of the fabric (fewer users than the normal network). The concept is that data is moved exclusively over the SAN, while the network only serves to transfer metadata or control data between the client and the server. Currently, two implementations of this concept are available using the Tivoli Storage Management product suite. These are the LAN-free (described in 5.3, SAN (LAN-free) backup topology on page 74) and the serverless or server-free (described in 5.4, Server-free backup on page 76) solutions. Chapter 11. Data storage 209

Efficiency By sharing libraries among several IBM Tivoli Storage Manager servers, it is clear that we will obtain higher tape drive usage than in cases where every server has its own library. This can also add a cost-reduction factor. The reason for this is that you might reduce the total overall number of required tape drives. Before looking at how we can improve the drive usage, we must decide which type of library sharing to use. There are two basic types of library sharing: Library partitioning: The library is attached to two or more servers using different connections. Logically, the library must be split into partitions, each with their own drives and library slot ranges. This means that each server will only use a small portion of the library and is unable to access drives other than those that were defined to it. When this setup uses two host machines, it often is referred to as a twin-tail configuration. In this case, you are not sharing the drives, only the library robotics. Library sharing: As defined in the IBM Tivoli Storage Manager library sharing implementation, library sharing means that all hosts attached to the library over a SAN fabric can share the entire library. This means that they have access to all library slots and all library drives. Tape volumes remain private, meaning that each server only sees the volumes that have been assigned to it. However, if the server needs new tape volumes, it can obtain them from a common scratch tape pool. How can library drive sharing improve efficiency? IBM Tivoli Storage Manager servers using non-shared tape libraries typically have a bad utilization rate for the tape devices. The reason for this is that the required number of tape devices is usually given by peak requirements rather than the required average need. An example is a situation where the requirement is that a restore must be possible without disrupting server maintenance processes. This would automatically require three tape devices (two for server processes, for example, storage pool backups, and one for the restore session). If multiple concurrent restore sessions are required, this number increases even more. Another situation could be that multiple concurrent backup sessions require direct tape drive connection, meaning that you would need at least one drive for each of these sessions. When sharing a library among different servers, the total number of tape devices can be reduced by using this shared capability. The reason for this is that usage becomes more distributed over time, and that peak requirements approach the average usage. For example, if you have two servers, each with the requirement that server maintenance operations and restore sessions can run at the same time, this would mean in a non-shared environment that you would need at least three drives per library. In a shared environment, however, a first reduction of this number can be obtained by reserving only one drive for restore. This would mean that you could work with only five drives. 210 IBM Tivoli Storage Management Concepts

A further reduction might be possible by phasing the server maintenance processes in such a way that they do not run at the same moment. As a result, the two drives required for these operations could be shared among the servers. The resulting number of tape devices for the library would then be three drives instead of the original six. In most cases, however, that calculation is not so simple. For further details and different approaches to determine the correct number of consolidated tape devices, refer to the redbook Using Tivoli Storage Manager in a SAN Environment, SG24-6132. 11.8.3 SAN device mapping In a SAN environment, device IDs can change dynamically due to device or cabling changes. IBM Tivoli Storage Manager uses a method that dynamically determines the correct device special file name (such as /dev/rmt/1stc on a Solaris system) and makes appropriate changes to the IBM Tivoli Storage Manager server database by using the device s serial number. This function can replace persistent binding, which binds a device WWN to a specific target/lun ID in certain environments. SAN device mapping functions SAN device mapping has three basic functions: Serial number autodetection and validation Element number autodetection SAN discovery Serial number autodetection and validation Serial number autodetection enables IBM Tivoli Storage Manager to automatically obtain a library or drive serial number by issuing a SCSI inquiry command during the define path command. Serial number validation automatically validates the serial number if the serial number is provided with the define/update library and define/update drive commands by issuing a SCSI inquiry command during the define path command. Device serial numbers are also automatically validated during every library or tape drive access. To avoid potential errors during device definitions or when SAN and device reconfiguration occurs, you can use the AUTODETECT function of the define path command. This function automatically updates the IBM Tivoli Storage Manager server database with the correct device special file name by using the device s serial number. Chapter 11. Data storage 211

Element number autodetection Element number autodetection enables IBM Tivoli Storage Manager to automatically obtain the drive element address by using the drive s serial number. This function automatically finds the matching element address in the serial number/element number map during the define path command. SAN discovery Restriction: At the time of writing, SAN discovery was only supported on Windows platforms with a QLogic HBA. Check the IBM Tivoli Storage Manager Web site for updates to this. Whenever an IBM Tivoli Storage Manager server opens a library or a tape drive with an invalid path error (this would happen if the device is no longer accessible via the previously defined path), a SAN discovery will be performed and device information will be collected for all devices on the SAN. If a match for the expected serial number is found on a discovered device in the SAN, this new path information will be updated in the IBM Tivoli Storage Manager database. Whenever the IBM Tivoli Storage Manager server opens a library or a tape drive successfully, a SCSI inquiry command will be issued to obtain the serial number, and it is compared to the serial number from the IBM Tivoli Storage Manager database. If mismatched, a SAN discovery will be performed and device information will be collected for all devices on the SAN. If a match for the serial number is found on a discovered device in the SAN, this new path information will be updated in the IBM Tivoli Storage Manager database. 212 IBM Tivoli Storage Management Concepts

12 Chapter 12. User management and security This chapter explains the functions of IBM Tivoli Storage Manager administrators and its client option sets as as they apply to the available security options. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 213

12.1 Administrator A IBM Tivoli Storage Manager administrator manages IBM Tivoli Storage Manager resources on the server such as storage pools, devices and data management policies. An administrator can also be responsible for backup and restore of client data. The number of administrators and their level of privileges will vary according to your environment. In a very small implementation, all of these functions could be performed by a single person. 12.1.1 Authority levels 12.1.2 Creation Administrators with system privilege can perform any IBM Tivoli Storage Manager function. Administrators with policy, storage, operator, analyst, or node privileges can perform subsets of IBM Tivoli Storage Manager functions. All administrators, even those with no specific privileges, can perform IBM Tivoli Storage Manager query functions because these need only read access. There are two ways to create an IBM Tivoli Storage Manager administrator ID: the register node and register admin commands. The register admin command is used to explicitly create an administrator ID with certain defined privileges. The register node command automatically creates an administrator ID with the same name as the node with owner access privilege to the node. This administrator ID can then be used with the client Web browser interface to perform remote backup/restore operations. If an administrator with the same name as the client node already exists during registration of a new node, then this administrator ID is automatically updated to grant owner access to it. You can optionally specify userid=none when registering new nodes to prevent creation of the administrative ID. Instead, the register admin or grant authority command can be used to create and grant access to specific nodes and their data. This is useful where there is a centrally located help desk requiring access to a number of client nodes, to assist remotely in client backup and restore functions without the need to be physically at the client location. Administrators must be registered with a name and a password. The maximum length of an administrator name and password is 64 characters each. You can specify optionally that the password be changed at first-time logon. After administrators are registered, they can make queries and request command-line help. To perform other IBM Tivoli Storage Manager functions, they must be granted authority by being assigned one or more administrative privilege classes. 214 IBM Tivoli Storage Management Concepts

At installation, the server console is defined with a special user ID, which is named SERVER_CONSOLE. This name is reserved and cannot be used by another administrator. It also cannot be deleted. At installation, the SERVER_CONSOLE user ID can be used to register other administrators and grant privileges. 12.1.3 Privilege classes Privileges are granted to an administrator through the grant authority command. You need system privileges to issue this command. Figure 12-1 shows the hierarchy of administrative privilege classes. Each box represents a privilege that could be given to an administrator. System Policy Storage Domain Storage Pool Node Analyst Operator Client Figure 12-1 Administrative privileges The policy privilege can be assigned for all domains (unrestricted privilege) or for one or more of the defined domains (restricted privilege). The storage privilege can be assigned for all storage pools (unrestricted privilege) or for one or more of the defined storage pools (restricted privilege). The node privilege can be assigned on an individual client basis. Chapter 12. User management and security 215

System An administrator with system privilege can perform any IBM Tivoli Storage Manager administrative task. All other privileges are included when an administrator is assigned system privilege. Policy An administrator can have either unrestricted or restricted policy privilege. An administrator with unrestricted policy privilege can manage the backup and archive policy definitions (for example, management classes, copygroups, and schedules) for client nodes assigned to any policy domain. When new policy domains are defined to the server, an administrator with unrestricted policy privilege is automatically authorized to manage the new policy domains. An administrator with restricted policy privilege can perform the same operations as an administrator with unrestricted policy privilege but only for specified policy domains. Storage An administrator can have either unrestricted or restricted storage privilege. An administrator with unrestricted storage privilege has the authority to manage the IBM Tivoli Storage Manager database, recovery log, and all storage pools. An administrator with unrestricted storage privilege cannot define or delete storage pools as this requires system privilege. Administrators with restricted storage privilege can manage only those storage pools to which they are authorized. They cannot manage the IBM Tivoli Storage Manager database or recovery log. Operator Administrators with operator privilege control the immediate operation of the IBM Tivoli Storage Manager server and the availability of storage media. Analyst An administrator with analyst privilege can issue commands that reset the counters that track server statistics, but otherwise can perform only query commands. Node Administrators with node privilege can remotely access a Web backup-archive client and perform backup and restore actions on that client using an 216 IBM Tivoli Storage Management Concepts

administrative user ID and password. The privilege can be for one or more specific nodes or all client nodes in a domain. Client owner authority A user with client owner authority can access the client and its data from either a remote Web client or the native backup client so that data can be restored either to the original client or to another client. Client access authority A user with client access authority can access the client and its data from the remote Web client and can only restore the client data back to the original client. Figure 12-2 demonstrates client access and owner authority. Tape Lib Tape Lib 2 "Help Desk" Issue command to restore TSM IBM Tivoli Server Storage Manager TSM 2 IBM Tivoli Server Server 3 Restore "Help Desk" Issue command to restore Storage Manager Server 3 Restore Ross's data Help Desk Web Admin Client Client Access Authority "Ross" IBM Tivoli Storage Manager Client 1 Please restore my data TSM Client "Harry" Web Admin Client Help Desk 1 Restore data to Jane's workstation Restore data to "Jane" Client Owner Authority "Jane" IBM Tivoli Storage Manager Client "Ross" IBM Tivoli Storage Manager Client Figure 12-2 Client access authority and client owner authority 12.1.4 Operations You can perform a number of operations with administrators. This section deals with those operations and some related considerations. Chapter 12. User management and security 217

Renaming an administrator An administrator is renamed through the rename admin command. System privilege is required to issue this command. You can rename an administrator ID when an administrator wants to be identified by a new ID or you want to assign an existing administrator ID to another person. You cannot rename an administrator ID to one who already exists on the system. Changing administrative authority You can extend, revoke or reduce another administrator's authority through the grant authority and revoke authority commands. System privilege is required to issue these commands. Granting authority to an administrator adds to any existing privilege classes but does not override those classes. You can reduce an administrator's authority by revoking one or more privilege classes and granting other classes as needed. Removing an administrator You can remove administrators from the server so that they no longer have access to administrator functions through the remove admin command. System privilege is required to issue this command. Where there is an administrator ID with the same name as a client node, removing the client node also causes the administrator ID to be removed. This is the reverse behavior from when a client node is created with default creation of administrative user ID. You cannot remove the last system administrator or the SERVER_CONSOLE administrative ID from the system. Locking and unlocking an administrator You can lock out administrators to temporarily prevent them from accessing IBM Tivoli Storage Manager by using the lock admin and unlock admin commands. System privilege is required to issue these commands. Use the lock admin command to prevent an administrator from accessing the server. The administrator is locked out until a system administrator uses the unlock admin command to re-establish access for the administrator. You cannot issue the lock admin command against the SERVER_CONSOLE administrative ID. 218 IBM Tivoli Storage Management Concepts

12.1.5 Auditing Requesting information about administrators You can query the server to view administrator information through the query admin command. Any administrator can issue this command. You can request information for one or more administrators, and you can query all administrators authorized with a specific privilege class. All commands issued by all administrators are logged to the server activity log. This cannot be removed or altered in any way. The information is written to the log as a message. The message contains the name of the administrator who issued the command and the full text of the command. The command is logged regardless of whether it was valid. Any passwords in the command are replaced by the special string?****?. 12.2 Server security Authentication of administrators is optional in an IBM Tivoli Storage Manager environment. The default is that authentication is required. With password authentication set to on, all administrators must enter a password when accessing the server. With password authentication set to off, administrators can access without entering a password. Authentication is controlled by the set authentication command. When security authentication is in effect, a number of security options can be specified to implement a security policy. These options are related to the use of passwords. They are explained in the remainder of this section. 12.2.1 Maximum logon attempts You can set the maximum number of logon attempts allowed before an administrator is locked. The server maintains a count of successive invalid password attempts, and when that count reaches the maximum, that administrator is locked out until another system administrator uses the unlock admin command to reestablish access for that administrator. When a successful logon occurs, the count of invalid password attempts is reset to zero. This maximum number of logon attempts option is controlled by the set invalidpwlimit command. It is a global setting. Chapter 12. User management and security 219

12.2.2 Password expiry You can set the number of days that a password is valid. When it expires, an administrator or node will be prompted for a new password upon the next logon. The password expiration option is controlled by the set passexp command. Password expiration can be set for nodes, administrators, or both. 12.2.3 Minimum password length You can set the minimum length of a password. When specifying a new password or creating an administrator, you must specify a password that contains at least the number of characters specified by this option. You can also specify that there is no minimum password length. The minimum password length option is controlled by the set minpwlength command. It is a global setting. 12.2.4 Web authentication timeout You can set the timeout interval for the Web administrative interface. After that interval has elapsed, an administrator must re-enter the administrator name and password to continue the session. The installed default is 10 minutes. You can also specify that there is no timeout value. The Web authentication timeout option is a global setting and is controlled by the set webauthtimeout command. 12.3 Client security Every client node has to be registered and assigned a password to identify itself against its designated server. To simplify administration and automation, the client password is usually stored locally on the client using passwordaccess generate option so that it can authenticate itself against the server. The password is encrypted before being stored. When the password expires the IBM Tivoli Storage Manager server and client negotiate a new random password according to the configured password rules. The client will then re-encrypt this password and store it locally. During authentication between IBM Tivoli Storage Manager client and server the client password is not sent over the network. Instead the client sends a message that is encrypted using its locally stored password. The IBM Tivoli Storage Manager server knows what the decrypted message should look like, so if the client uses the wrong password to encrypt the message, authentication will fail. 220 IBM Tivoli Storage Management Concepts

Moreover, IBM Tivoli Storage Manager enables the client system to encrypt its data during backup or archive using standard DES 56-bit encryption. If you use the DES 56-bit encryption feature to encrypt your data during backup or archive, you must have the encryption key in order to restore or retrieve the data. If the encryption key is not available on the client machine and you forgot the encryption key, then the data cannot be restored or retrieved under any circumstances. To encrypt file data, you must select an encryption key password, which IBM Tivoli Storage Manager uses to generate the encryption key for encrypting and decrypting the file data. The encryption key password can also be stored locally using the encryptkey option. 12.4 Firewalls Businesses increasingly rely on Internet technologies to interact with employees, partners, suppliers, and customers. Customers use a company s Web server to directly browse catalogs and order products, tracking them all the way to delivery. Web applications enable them to place automatic just-in-time orders to their suppliers for components required to produce their product. Employees use Web applications to select their benefits, submit their expenses, do price quotations for their customers, submit and track their orders, and do other activities in their job. Everyone knows that the Internet is indispensable for doing business. While the Internet provides many benefits and opportunities, it also opens up many threats. Web servers that provide valuable applications contain product and customer data that is private to the company and critical to their survival. Protecting that data and the systems they are stored on from competitors and hackers is of utmost importance. All companies using the Internet must employ some level of firewall security. A firewall is a device that controls the types of communication allowed between different points in a network. Firewalls are configurable to allow or disallow communications based on various characteristics. The most common criteria used for restricting communications are by ports, protocols, and direction. For example, a firewall might be configured to only allow communications from the external network (Internet) using port 80 and HTTP protocol. The Internet is referred to as "outside" the firewall and the internal network (intranet) is referred to as "inside" the firewall. In most cases, companies will have more than one firewall in place, implementing multiple layers of security between the Internet and their internal systems, each separated by a group of firewalls. These layers of security are known as demilitarized zones (DMZ), with the outer layers being least secure and the inner layers being most secure. Chapter 12. User management and security 221

Besides being able to enforce different levels of security within different zones, the use of DMZs provides additional buffers of security that a single firewall could not. Typically a network containing DMZs will be set up such that there is no direct routing allowed. This means that a system in one zone is only able to establish communications with a system in the adjacent zone. In other words, no system on the external internet would ever be allowed to directly contact a system in the intranet or most secure zone for any reason, no matter what port or what protocol they were using. This puts another challenge in the way of hackers on the internet who would like to access the company's internal systems. They cannot access the most sensitive machines by gaining access to one system in a DMZ, but would have to navigate their way through several stages. Therefore it is often undesirable to initiate sessions from inside a DMZ to the outside, even to the intranet. This complicates scheduled backup operations because the client may have to connect to its backup server. IBM Tivoli Storage Manager offers to restrict session initiation to the server, so only the server outside the DMZ contacts the client inside the DMZ, not the client from inside to the server outside. You can clearly specify the port on which the IBM Tivoli Storage Manager server and client communicate with each other. If you activate the server-only initiated session option, the client scheduler has be to placed in prompted mode, and the native GUI and the Web GUI cannot be used any more. Even when you still want to be able to use the GUI interfaces of an IBM Tivoli Storage Manager client you can establish a secure environment. IBM Tivoli Storage Manager allows individual configuration of nearly every TCP port that it uses for communication: TCP/IP port: To enable the backup-archive client, command line admin client, and the scheduler to run outside a firewall, the port specified by the tcpport server option must be opened by the firewall administrator. This port is set on the client and the server using the tcpport option. The setting must be the same on the client and server. The default TCP/IP port is 1500. HTTP port To enable the Web client to communicate with remote workstations across a firewall, the HTTP port for the remote workstation must be opened. Use the httpport option in the remote workstation s client option file to specify this port. The default HTTP port is 1581. TCP/IP ports for the remote workstation The two TCP/IP ports for the remote workstation client must be opened. Use the webports option in the remote workstation s option file to specify these ports. If you do not specify the values for the webports option, the default zero (0) causes TCP/IP to randomly assign two free port numbers. 222 IBM Tivoli Storage Management Concepts

TCP/IP port for administrative sessions Specifies a separate TCP/IP port number on which the server is waiting for requests for administrative sessions using the tcpadminport option, allowing secure administrative sessions within a private network. This includes administrative sessions, server-to-server sessions, SNMP subagent sessions, storage agent sessions, library client sessions, managed server sessions, and event server sessions. 12.5 Client option sets A IBM Tivoli Storage Manager client session has a set of options that are used during the backup, archive, restore, or retrieve processes. Options can be specified in two ways: (1) a client options file, and (2) a client options set. The first is mandatory, while the second is optional. The client options file is a configuration file (or files, in the case of UNIX clients) that is local to each IBM Tivoli Storage Manager client. It contains entries of valid client options with an associated value. It also contains include-exclude file specifications. A client option set is a set of IBM Tivoli Storage Manager client options stored in the IBM Tivoli Storage Manager database. It is used in conjunction with a client options file. An option set can be associated with one or more clients, but a client can be associated with only one option set. You use client option sets for ease of administration. Management of the environment is complex where the number of clients is growing and the number of options is increasing. The use of client option sets eases that administrative burden by centralizing the management of those options and clients. It is easier to update a client options set once than to perform the same update to the local client options file on each node. The options defined in a client option set are a subset of the available client options. Options such as communications are still stored on the client machine. When the same individual option is specified in both the local options file and the options set, the default is that the options file version is used. However, you can specify that individual options in an option set cannot be overridden in the client s local option file. Although include-exclude specifications cannot be overridden, you can specify the sequence in which the option set specifications are processed. Therefore, one set of default values can be defined for each type of client, and the client machines can still be customized, within acceptable limits. Chapter 12. User management and security 223

224 IBM Tivoli Storage Management Concepts

13 Chapter 13. Licensing This chapter focuses on the different features of IBM Tivoli Storage Manager that need licensing to function. Compliance with the IBM Tivoli Storage Manager licensing terms ensures proper system operation. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 225

13.1 Licensed features IBM distinguishes between two licenses: IBM Tivoli Storage Manager IBM Tivoli Storage Manager Extended Edition The base IBM Tivoli Storage Manager server license supports an unlimited number of administrative clients, LAN-managed systems, enterprise administration, server-to-server virtual volume support for primary storage pools, and a selection of removable media devices. For current information about supported clients and devices: Check with your authorized reseller. Visit the IBM Tivoli Storage Manager page at this Web address: http://www-3.ibm.com/software/sysmgmt/products/support/ibmtivolistor agemanager.html The extended IBM Tivoli Storage Manager license includes all the basic features plus the following additional licenses: Extended Device Support Disaster Recovery Manager NDMP Support Library Sharing All additional IBM Tivoli Storage Manager for application products include their own supplementary license which has to be registered after installation. The enrollment certificate files for all IBM Tivoli Storage Manager licenses are on the IBM Tivoli Storage Manager installation CD-ROM. You register those licenses that you are entitled to by issuing the register license command with the name of the enrollment certificate file. Once registered, the licenses are stored internally to the server. 13.2 License compliance If license terms change (for example, if a new license is defined 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 the license terms. The results of this 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. 226 IBM Tivoli Storage Management Concepts

If the server uses a licensed feature but the license is not registered, the function fails. When you issue a command associated with an unlicensed feature, IBM Tivoli Storage Manager issues a warning message, and the command fails. 13.3 IBM Tivoli Storage Manager licenses To obtain licenses for licensed features and complimentary products, you can register the following licenses: domino.lic IBM Tivoli Storage Manager for Mail (Lotus Domino) Enables Lotus certified online backups, restore and archive of Lotus Domino R5 and above Server databases and transaction logs. drm.lic Tivoli Disaster Recovery Manager: Automatically generates a disaster recovery plan containing the information, scripts, and procedures needed to automate restoration that helps ensure quick recovery of your data after a disaster. Automatically manages and tracks the media on which your data is stored whether on-site, in-transit, or off-site in a vault so that your data can be located easily if disaster strikes. Includes additional virtual volume support for copy storage pools and server database backups. emcsymm.lic IBM Tivoli Storage Manager for Hardware (EMC) Enables IBM Tivoli Storage Manager to back up databases such as Oracle or DB2 in combination with advanced features of an EMC Symmetrix hardware environment including EMC Symmetrix TimeFinder. emcsymr3.lic IBM Tivoli Storage Manager for Hardware (EMC) Extends the emcsymm.lic license for backing up SAP R/3 systems. Chapter 13. Licensing 227

ess.lic IBM Tivoli Storage Manager for Hardware (ESS) Enables IBM Tivoli Storage Manager to back up databases such as Oracle or DB2 in combination with advanced features of an ESS hardware environment including the FlashCopy function. essr3.lic IBM Tivoli Storage Manager for Hardware (ESS) Extends the ess.lic license for backing up SAP R/3 systems. informix.lic IBM Tivoli Storage Manager for Databases (Informix) Enables backup and restore of Informix databases and logical logs. It uses the Informix ON-Bar utility to perform the operations. library.lic Enables IBM Tivoli Storage Manager to use large libraries. This license comes with the IBM Tivoli Storage Manager Extended Edition. libshare.lic Enables IBM Tivoli Storage Manager to share SAN-attached libraries with other IBM Tivoli Storage Manager servers or storage agents. This license comes with the IBM Tivoli Storage Manager Extended Edition. lnotes.lic IBM Tivoli Storage Manager for Mail (Lotus Notes) Enables centralized, online, incremental backup of the complex logical structure of Lotus Notes databases. This license is appointed for Lotus Notes/Domino R4. mgsyslan.lic Enables centralized backup of LAN-attached clients that are moving their data via the LAN to the designated IBM Tivoli Storage Manager server. 228 IBM Tivoli Storage Management Concepts

mgsyssan.lic IBM Tivoli Storage Manager for Storage Area Networks Enables centralized backup of SAN-attached clients that are moving their data directly to SAN-attached storage devices and transferring only metadata via the LAN. msexch.lic IBM Tivoli Storage Manager for Mail (Microsoft Exchange) Centralized online full, copy, incremental, and differential backups of Microsoft Exchange Directory and Information Stores. mssql.lic IBM Tivoli Storage Manager for Databases (MS SQL Server) Enables centralized complete and incremental online backup of Microsoft SQL Server databases with IBM Tivoli Storage Manager. The utilities provide full online backup and restore of all databases and transaction logs. ndmp.lic Enables centralized, online backup of Network Attached Storage (NAS) devices. This license is part of IBM Tivoli Storage Manager Extended Edition. oracle.lic IBM Tivoli Storage Manager for Databases (Oracle) r3.lic Enables centralized, online, incremental, backup capabilities and automated storage management function of Oracle databases using the Oracle Enterprise Backup Utility (EBU) or Oracle8 Recovery Manager (RMAN). IBM Tivoli Storage Manager for Enterprise Resource Systems (SAP R/3) Enables data backup and recovery of R/3 databases from SAP. spacemgr.lic IBM Tivoli Space Manager (formerly HSM client) Maximizes usage of existing storage resources by transparently migrating data off client hard drives based on size and age criteria to the IBM Tivoli Storage Manager server, leaving only a stub file. When the migrated data is accessed, Tivoli Space Manager transparently migrates the data back onto the local disk from the server. Licensing this feature enables the IBM Tivoli Chapter 13. Licensing 229

Storage Manager to support space-managed clients. Not all IBM Tivoli Storage Manager clients have a space management function; visit the IBM Tivoli Storage Manager Web page for currently supported clients. was.lic IBM Tivoli Storage Manager for Application Servers (IBM WebSphere) Enables centralized, online backup capabilities and the automated storage management function of IBM WebSphere application servers. 230 IBM Tivoli Storage Management Concepts

14 Chapter 14. Server network In this chapter we discuss the enterprise-wide architecture of a network IBM Tivoli Storage Manager server. We focus on the communication and interoperability of multiple IBM Tivoli Storage Manager servers. This server-to-server communication can be utilized to centralize administration tasks and configuration management. IBM Tivoli Storage Manager can share storage resources and devices between multiple server instances if an appropriate hardware environment is provided. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 231

14.1 Enterprise administration The enterprise management capabilities in IBM Tivoli Storage Manager include comprehensive central management of multiple IBM Tivoli Storage Manager servers, lights-out server automation, and remote help desk support. These capabilities are designed to enhance ease of use, centralized but flexible control, automation, and consistency while meeting your requirements for protecting ever-increasing amounts of data in the most cost-effective manner. These features enable you to easily and cost-effectively broaden your deployment of IBM Tivoli Storage Manager servers to meet growing data availability requirements. 14.2 Enterprise management features With the Enterprise Administration feature, the IBM Tivoli Storage Manager enterprise console provides administrators with several global views of their IBM Tivoli Storage Manager deployment, as shown in Figure 14-1. Figure 14-1 IBM Tivoli Storage Manager enterprise console 232 IBM Tivoli Storage Management Concepts

The enterprise management features include: Enterprise console A key element of enterprise management is the user-friendly IBM Tivoli Storage Manager enterprise console. This administrative Web browser interface extends the capabilities of the current storage administrator command line interface. It enables the administrator to manage many IBM Tivoli Storage Manager servers and clients from any Web-enabled platform in the enterprise. The IBM Tivoli Storage Manager enterprise console is the integration point for all IBM Tivoli Storage Manager functions and commands. It combines the Web browser interface with the backup-archive client Web browser interface. The enterprise console provides centralized policy management and a global view of IBM Tivoli Storage Manager deployment. Using the IBM Tivoli Storage Manager enterprise console, the administrator can navigate, log on to, and perform functions on any IBM Tivoli Storage Manager server and IBM Tivoli Storage Manager Web backup-archive client from a supported Web browser. Some of the specific functions the administrator can perform from the enterprise console include: Regular administration functions: All administration functions can be performed from the enterprise console. Unified logon for all functions: Once the administrator has signed on to an IBM Tivoli Storage Manager enterprise console, the logon credentials are transferable to all associated IBM Tivoli Storage Manager servers and clients to which there is legitimate access. Multiple IDs and passwords do not have to be redefined or remembered. Clients have an option that enables them to restrict access based on administrator authority. Encrypted password information: Secure Socket Layer (SSL) can be selected to encrypt password information between IBM Tivoli Storage Manager servers and the enterprise console. Client operations through the Web backup-archive clients: Through the Web backup-archive clients, authorized administrators and help desk personnel can perform backup and restore functions on an IBM Tivoli Storage Manager client remotely through a Web browser interface. Security features implemented with unified logon enables help desk or administrators to recover data without having direct access to the machine while ensuring data security. Web backup-archive clients In addition to providing authorized administrator and help desk personnel with access to client functions, end users can also access client data remotely Chapter 14. Server network 233

through this Web browser interface. The enterprise console gives easy launch access for all configured Web clients. Enterprise monitoring All aspects of server operation such as server database utilization, server recovery log utilization, percentage of scratch tapes, offline drives, and license compliance across all of the servers can be monitored. Enterprise reporting Enterprise reporting mechanisms enable IBM Tivoli Storage Manager servers to route their server and client events to another server. So, one server could receive the event messages from all the servers in the network, allowing consolidated reporting and querying. Server scripts Server scripts automate IBM Tivoli Storage Manager server management operations by storing a sequence of server commands in the IBM Tivoli Storage Manager database as a script with an assigned name. An administrator can run the script from the command line and from the IBM Tivoli Storage Manager enterprise console, or schedule its execution using the administrative command scheduler in the IBM Tivoli Storage Manager server. Server scripts can include IBM Tivoli Storage Manager server commands, SQL statements, conditional logic (including return code checking) and variable substitution. Variable substitution allows scripts to become dynamic and reusable. A number of pre-defined server scripts are provided for loading into the IBM Tivoli Storage Manager server database. Here are some examples from the supplied server scripts: List nodes that have not accessed IBM Tivoli Storage Manager for a specified number of days Display nodes that have backup data exceeding a specified number of MB Display the percentage of scratch volumes in a specified library The IBM Tivoli Storage Manager enterprise console also enables administrators to create additional reporting scripts, modify existing ones and execute the scripts on any server in the environment. Additional policy constructs Additional policy constructs enable the automatic extension of the server database and recovery log when administrator-defined thresholds are reached. Triggers can be established to extend the database or recovery log when a specified capacity percentage is reached. The amount of space to be added can be specified as a percentage of the existing database or recovery log size. 234 IBM Tivoli Storage Management Concepts

Simplified volume formatting Disk storage allocation for database, recovery log, and storage pools is simplified through integration of the space format utility, DSMFMT, with the define volume command. This enables simple, one-step formatting and allocation of these types of volumes. 14.3 Enterprise Administration features The Enterprise Administration feature enables administrators to centrally manage multiple IBM Tivoli Storage Manager servers through a single enterprise console. IBM Tivoli Storage Manager enterprise administration provides the following capabilities: Enterprise configuration and policy management Enables IBM Tivoli Storage Manager policy and configuration information to be defined a single time and then propagated to any number of managed IBM Tivoli Storage Manager servers. A server option defines the configuration server. Administrators have the flexibility to choose an existing IBM Tivoli Storage Manager server or implement an additional server as a dedicated configuration server. IBM Tivoli Storage Manager servers that obtain information from a configuration server are known as managed IBM Tivoli Storage Manager servers. Policy and configuration information that can be defined centrally includes: Client option sets Backup, archive, and HSM policies Client and administration schedules Server scripts Administration definitions Policy and configuration information is grouped into one or more named configuration profiles to which managed servers subscribe. Configuration profiles give administrators the flexibility to decide which sets of information are to be administered centrally and which are to be defined locally. Enterprise command routing Enterprise command routing can greatly simplify reporting across a large IBM Tivoli Storage Manager enterprise by enabling administrators to issue one or more commands that perform tasks on a single IBM Tivoli Storage Manager server or group of servers. Results from routed commands are returned to the Chapter 14. Server network 235

request origin. A message is also returned indicating whether the commands were all successful. Command routing in IBM Tivoli Storage Manager provides a simple mechanism for querying and updating multiple servers simultaneously, as you can see in Figure 14-2. Configuration Manager Headquarters IBM Tivoli Storage Manager server Enterprise configuration (configuration distribution) Distributed server tasks Event logging and monitoring Command routing Hamburg San Francisco Tokyo IBM Tivoli Storage Manager server IBM Tivoli Storage Manager server Manager Servers IBM Tivoli Storage Manager server Figure 14-2 Server-to-server communications Enterprise logging The enterprise logging function enables more proactive management and better enterprise reporting of a dynamic environment by routing events from groups of IBM Tivoli Storage Manager servers and clients to a single IBM Tivoli Storage Manager server for viewing and reporting. IBM Tivoli Storage Manager servers in an organization can forward their events and those of their clients to a designated IBM Tivoli Storage Manager event server. This event server then displays the events through the IBM Tivoli Storage Manager enterprise console and stores them in the activity log. Events can also be routed to external managers such as SNMP managers, NetView, Tivoli Enterprise Console, and the Windows NT Event Log. 236 IBM Tivoli Storage Management Concepts

14.4 Virtual volumes IBM Tivoli Storage Manager enables a server (a source server) to store the results of various operations on another server (a target server). The data is stored in what are known as virtual volumes, which appear to be normal sequential media volumes on the source server, but are actually stored as archive files on a target server. Virtual volumes can be any of the following: Server database backups Storage pool backups Data that is backed up, archived, or space managed from client nodes Client data migrated from storage pools on the source server Any data that can be moved by EXPORT and IMPORT commands Disaster Recovery Manager plan files The source server is a client of the target server, and the data for the source server is managed only by the source server. In other words, the source server controls the expiration and deletion of the files that comprise the virtual volumes on the target server. At the target server, the virtual volumes from the source server are seen as archive data. The relationship between the source and target IBM Tivoli Storage Manager (TSM) servers is illustrated in Figure 14-3. UNIX Large Systems LAN/WAN TCP/IP Windows IBM Tivoli Storage Manager clients (Local) IBM Tivoli Storage Manager source server IBM Tivoli Storage Manager target server (Remote) Data Flow Virtual Volumes Primary Storage Pool Database Backup Copy Storage Pool Disaster Recovery Plan File Archive Objects Figure 14-3 Server-to-server virtual volumes The source server is registered as a client node (TYPE=SERVER) at the target server and is assigned to a policy domain. The archive copy group of the default management class of that domain specifies the storage pool for the data from the source server. Chapter 14. Server network 237

Note: If the default management class does not include an archive copy group, data cannot be stored on the target server. All data destined for virtual volumes is sent to the target server using virtual volumes rather than direct attached storage devices. For example, if a client is backing up data that is bound to a backup copy group using a virtual volume primary storage pool, this data will be sent to the target server. If a client needs to restore the data, the source server gets the data back from the target server. An IBM Tivoli Storage Manager client can always perform the same granularity of restore, retrieve, or recall operation, whether the data is stored on a local IBM Tivoli Storage Manager server or on a target server using server-to-server communication. That is, remote storage pools (using server-to-server communication) are transparent to the client. The only requirement is that the TCP/IP communication link between the source and target server must be working correctly. Note: Source server objects such as database and storage pool backups are stored on the target server as archived data. Therefore, the target server cannot directly restore these objects in the event of a disaster at the source server site. In such an event, the source server should be re-installed (likely at an alternate location); then objects originally stored on the target server can be restored over the network using the same server-to-server communication. Note that the server -to-server virtual volume support is only for primary storage pools in the base IBM Tivoli Storage Manager product license. You must license the Disaster Recovery Manager function that is included in the IBM Tivoli Storage Manager Extended Edition to be able to create copy storage pools or server database backups or to generate recovery plan files on another server. Using virtual volumes can benefit you in the following ways: The source server can use the target server as an electronic vault for rapid recovery from a disaster. Smaller IBM Tivoli Storage Manager source servers can use the storage pools and tape devices of larger servers. For incremental database backups, it can decrease wasted space on volumes and limited use of high-end tape drives. Be aware of the following when you use virtual volumes: If you use virtual volumes for database backups, you might have the following situation: SERVER_A backs up its database to SERVER_B, and SERVER_B backs up its database to SERVER_A. If this is the only way databases are 238 IBM Tivoli Storage Management Concepts

backed up and both servers are at the same location, a disaster at that location could leave you with no backups with which to restore your databases. A corollary to the first point is that if you are storing objects on a remote server, whether they be database backups, storage pool date, or anything else, you must have active communication between the source and target server in order to be able to store and retrieve those objects. The remote server must also be up and running. If you are relying on the source server to perform a disaster recovery, then your first step will be to establish communications between your recovery server and the target server. Moving large amounts of data between the servers may slow down your communications significantly, depending on network bandwidth and availability. High-speed, reliable networks are recommended if large volumes of data will be transmitted. You can specify in the device class definition (DEVTYPE=SERVER) how often and for how long a time the source server will try to contact the target server. Keep in mind that frequent attempts to contact the target server over an extended period can affect your communications. Under certain circumstances, inconsistencies may arise among virtual volume definitions on the source server and the archive files on the target server. You can use the RECONCILE VOLUMES command to reconcile these inconsistencies. Storage space limitations on the target server will affect the amount of data that you can store on that server. To minimize mount wait times, the total mount limit for all server definitions that specify the target server should not exceed the mount total limit at the target server. For example, a source server has two device classes, each specifying a mount limit of two. A target server has only two tape drives. In this case, the source server mount requests could exceed the target server s tape drives. 14.5 Data movement between servers IBM Tivoli Storage Manager enables you to move its data from one server to another. This function is called export/import, and with it you can transfer clients between servers (for load balancing) or move from one server operating system platform to another. Chapter 14. Server network 239

14.5.1 Export/import You can export or import administrator, node, server, or policy information, as shown in Figure 14-4. You can export the complete server or just parts of it, for example a few clients and their stored data. Even an incremental export restricted by a given time frame is possible. IBM Tivoli Storage Manager server 1 Administrator IBM Tivoli Storage Manager server 2 Server EXPORT Node IMPORT Policy Figure 14-4 Export data from server 1, use volumes, import data to server 2 The export commands create an operating-system-independent, self-describing copy of specified server information. The original database is not required to recover data from this volume, and IBM Tivoli Storage Manager does not keep track of file expiration, so the information contained can be recovered onto any server at any time. This is no substitute for disaster recovery. Export and import is a relatively time-consuming process, so it is designed primarily for one-time data movement. IBM Tivoli Storage Manager offers two ways of exporting data: Export to sequential media. Export directly to another IBM Tivoli Storage Manager server on the network. You can import to the same server platform or a different one. The server to which you are importing must support the same tape format as the server from which you exported, if you are exporting to tape media. Restrictions: Information from a later IBM Tivoli Storage Manager server cannot be imported by an earlier one, only a later one. NAS type nodes cannot be exported. Export to sequential media Server information can be exported to any sequential medium, even FILE deviceclass or opticals. The target server must support the same or a compatible 240 IBM Tivoli Storage Management Concepts

type of media. The exported data will then be imported in a separate process on the target server. Export directly to another server If there is a network connection between two IBM Tivoli Storage Manager servers the export can be executed directly via the network to the target server. This results in an immediate import process on the target server. No external media is needed to transport the data from the source to the target server. Export/import admin These commands move administrator information such as name, password, privilege classes, and whether the administrator is locked from server access. Export/import node These commands move client node definitions. Each client node definition includes the user ID, password, name of the policy domain to which the client is assigned, file compression status, backup/archive delete authority, and whether the client node is locked from server access. Client data can be exported in the same process. The following groupings of files are supported: Active and inactive versions of backed-up files, archive copies of files, and space-managed files Active versions of backed-up files, archive copies of files, and space-managed files Active and inactive versions of backed-up files Active versions of backed-up files Archive copies of files Space-managed files An incremental export can limit the amount of data being exported. In this case the export command specifies the date (FROMDATE) and time (FROMTIME) the data was stored on the server. All data stored on the server before that given date and time will not be exported. If the exported client node already exists on the target server, IBM Tivoli Storage Manager can merge the client file data during import. During that process backup objects are inserted as new active or inactive versions depending on their insertion date and time. Double archive and space management objects will be skipped. If merging is not used, IBM Tivoli Storage Manager will create a new renamed filespace for the imported client. Chapter 14. Server network 241

Export/import policy These commands move policy information from one or more policy domains. They include data such as policy domain and set definitions, management class definitions, backup, copy group and archive group definitions, schedule definitions for each policy domain, and client node associations. Export/import server These commands move all or part of the server control information and client file data (if specified). This includes: administrator definitions, client node definitions, policy definitions and schedule definitions defined for each policy domain. They can optionally include: file space definitions; access authorization information; and backed-up, archived, and space-managed files. Import client file data using the previously described procedures. 14.6 Tape library sharing Storage Area Network (SAN) technologies enable IBM Tivoli Storage Manager to share its libraries. Multiple Tivoli Storage Manager servers can dynamically share library volume and tape drive resources of one connected tape library. The hosts can thus maintain high-speed connections to the same devices through the SAN fabric. Backup and restore applications benefit immediately from this, and the effect is pronounced for environments with large amounts of data to back up over shrinking windows of time and constrained LAN bandwidth. Using the Fibre Channel technology of SANs, distances between the tape library and the IBM Tivoli Storage Manager server or servers can be extended as well. Tape libraries can reside at an alternate location. Customers can use electronic vaulting for a quick and efficient way to protect against and recover from a disaster situation. Finally, since a reliable tape drive is quite an expensive device, tape sharing can be a very important economic factor. One IBM Tivoli Storage Manager server is dedicated as the library manager to control library operations, which include mount, dismount, volume ownership, and library inventory. Other servers sharing the library are called library clients; they use server-to-server communications to contact the library manager to request the library service. 242 IBM Tivoli Storage Management Concepts

SD IBM Tivoli Storage Manager clients LAN TCP/IP: Mount, Dismount, Release, Query Volumes IBM Tivoli Storage Manager (Library Client) SAN IBM Tivoli Storage Manager (Library Server) Program Calls: Mount, Dismount Release, Query Volumes SCSI: Mount/Dismount Volumes ITSM Library Control SCSI Control Data Flow SCSI: I/O SCSI: I/O Figure 14-5 Tape library sharing Library The library manager gains full control over the library hardware. When requested by a library client, the library manager tries to mount the requested tape volume in one of the library s drives. After successful mounting the tape volume it notifies the library client and assigns access to this specific drive to the client. After finishing the operations, the client returns control of the drive back to the library manager. During this process only the metadata for requesting volumes and information about successful mounts is transferred via the LAN. The intrinsic data flow is transferred via the SAN. Though a SAN topology is commonly based on fibre-channel, the control commands are still SCSI-based. This principle is very similar to the LAN-free data transfer for IBM Tivoli Storage Manager clients described in 5.3, SAN (LAN-free) backup topology on page 74. Normally tape library sharing leads to a better and balanced resource utilization of the installed tape drives. Thus the investment in enterprise storage equipment is protected in a better way than dedicating single libraries to each IBM Tivoli Storage Manager server. Chapter 14. Server network 243

But the implementation of tape library sharing introduces a further level of complexity as well. Scheduled operations have to be balanced through all attached IBM Tivoli Storage Manager servers. Otherwise the library manager and the library itself would be overloaded with requests, and some operations may fail because of timeouts or denials of device requests. Additionally the library manager becomes the central and most important IBM Tivoli Storage Manager server. If this machine fails, no library client will be able to access tape drives or tape volumes, respectively, any more. It is highly recommended to establish a high availability solution for this library manager. 244 IBM Tivoli Storage Management Concepts

15 Chapter 15. High availability clustering What exactly is an IBM Tivoli Storage Manager cluster? In simple terms, a cluster is a group of computers that, together, provide a set of resources to a client. A cluster consists of a minimum of two and, in theory, up to any number of systems. The key point of clustering is that the client has no knowledge of the underlying physical hardware of the cluster. This means that the client is isolated and protected from changes to the physical hardware, which brings a number of benefits. Perhaps the most important of these benefits is high availability. Resources on clustered servers act as highly available versions of unclustered resources. If a node (an individual computer) in the cluster is unavailable or too busy to respond to a request for a resource, the request is transparently passed to another node capable of processing it. Clients are therefore unaware of the exact locations of the resources they are using. For example, a client can request the use of an application without being concerned about either where the application resides or which physical server is processing the request. The user simply gains access to the application in a timely and reliable manner. Another benefit is scalability. If you need to add users or applications to your system and want performance to be maintained at existing levels, additional systems can be incorporated into the cluster. A typical example would be a Web site that shows rapid growth in the number of demands for Web pages from browser clients. Running the site on a cluster would allow the growth in demand to be accommodated easily by adding servers to the cluster as needed. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 245

Whether you configure your system to include clusters depends on your business needs. A cluster can provide system-level high availability to ensure that an IBM Tivoli Storage Manager server or client can continue normal backup and restore processes without significant disruption for users and administrators. In addition to assuring the right type of hardware and the applicable software, varying failover patterns between cluster nodes exist and play different roles, such as hot-standby versus concurrent cluster operation. This section gives an overview of IBM Tivoli Storage Manager server and client clustering support and configuration using IBM high availability cluster multiprocessing (IBM Tivoli Storage Manager HACMP) and Microsoft Cluster Server (IBM Tivoli Storage Manager MSCS). 246 IBM Tivoli Storage Management Concepts

15.1 High availability cluster multiprocessing An IBM Tivoli Storage Manager server can use HACMP software for high availability. HACMP provides the leading AIX-based clustering solution, which enables automatic system recovery on system failure detection. Using HACMP with IBM Tivoli Storage Manager can ensure server availability. HACMP offers local or campus disaster survivability with real-time automated failover and reintegration within distance limitations. In an HACMP environment, TCP/IP is the communications method used to support the checking of status and availability of the production and failover server, also commonly referred to as the IBM Tivoli Storage Manager heartbeat connection. HACMP detects system failures and manages IBM Tivoli Storage Manager failover to a recovery processor with a minimal loss of end-user time. You can set up an IBM Tivoli Storage Manager server on a system in an HACMP cluster so that, if the system fails, the IBM Tivoli Storage Manager server will be brought back up on another system in the cluster. In both failover and fallback, it appears that the IBM Tivoli Storage Manager server has crashed or halted and was then restarted. Any transactions that were in progress at the time of the failover or fallback are rolled back, and all completed transactions are still complete. IBM Tivoli Storage Manager clients see this as a communications failure and try to re-establish their connections as shown in Figure 15-1. UNIX Large Systems LAN/WAN TCP/IP Windows IBM Tivoli Storage Manager Clients System Failure 1# Production IBM Tivoli Storage Manager server (HACMP) Heartbeat 2# Failover IBM Tivoli Storage Manager server (HACMP) Data Flow Direct Attached Shared Storage Figure 15-1 HACMP and IBM Tivoli Storage Manager server configuration Chapter 15. High availability clustering 247

HACMP support for the IBM Tivoli Storage Manager server on AIX has been supported officially since Verson 4.2. With Version 5.1 of IBM Tivoli Storage Manager, the server fileset provides several HACMP scriptsthat can be customized to suit the local environment. When failover occurs, HACMP calls the IBM Tivoli Storage Manager startserver script on the standby node. The script verifies the devices, breaking the IBM Tivoli Storage Manager SCSI reserves, and starts the server. On fallback, the IBM Tivoli Storage Manager stopserver script runs on the standby node, which causes the IBM Tivoli Storage Manager server to halt. Then the startserver script runs on the production node. HACMP handles taking over the TCP/IP address and mounting the shared file systems on the standby node or production node, as appropriate. By default, the startserver script will not start the server unless all devices in the VerifyDevice statements can be made available. However, you can modify the startserver script to start the server even if no devices can be made available. Both failover and fallback act as though an IBM Tivoli Storage Manager server has crashed or halted and was then restarted: Any transactions that were in-flight at the time are rolled back, and all completed transactions are still complete. IBM Tivoli Storage Manager clients see this as a communications failure and try to re-establish connection based on their COMMRESTARTDURATION and COMMRESTARTINTERVAL settings. The backup-archive client can usually restart from the last committed transaction. The clients and agents will behave as they normally do if the server was halted and restarted while they were connected. The only difference is that the server is physically restarted on different hardware. For a detailed discussion about supported environments, prerequisites, install, setup, and testing of an HACMP and IBM Tivoli Storage Manager server failover environment see Tivoli Storage Manager Version 5.1 Technical Guide, SG24-6554, and Tivoli Storage Manager for AIX Quick Start Version 5.1, GC32-0770. 15.2 Backup-archive and HSM client with HACMP As of IBM Tivoli Storage Manager Version 5.1, the backup-archive client itself (including the administrator, backup/archive, HSM, and API pieces) is supported for use in an HACMP cluster environment. This configuration enables IBM Tivoli Storage Manager scheduled client operations to continue processing in the event of a system failure on a redundant clustered failover server. See Figure 15-2 on page 249 for an illustration of how this works. 248 IBM Tivoli Storage Management Concepts

System Failure machine-a Direct Attached Shared Storage 1# Production IBM Tivoli Storage Manager client (HACMP) IBM Tivoli Storage Manager clients 2# Failover IBM Tivoli Storage Manager client (HACMP) machine-b Heartbeat LAN/WAN TCP/IP IBM Tivoli Storage Manager server Data Flow Figure 15-2 HACMP and IBM Tivoli Storage Manager client configuration The IBM Tivoli Storage Manager CLUSTERNODE option in the AIX IBM Tivoli Storage Manager client dsm.sys file determines whether you want the IBM Tivoli Storage Manager client to back up cluster resources and participate in cluster failover for high availability. If a scheduled incremental backup of a clustered volume is running on machine-a and a system failure causes a failover to machine-b, machine-b then reconnects to the server. If the reconnection occurs within the start window for that event, the scheduled command is restarted. This scheduled incremental backup will re-examine files sent to the server before the failover. The backup will then catch up to where it terminated before the failover situation. If a failover occurs during a user-initiated (that is, non-scheduled) client session, the IBM Tivoli Storage Manager client starts on the node that is handling the takeover. This allows it to process scheduled events and provide Web client access. You can install the IBM Tivoli Storage Manager client locally on each node of an HACMP environment. You can also install and configure the IBM Tivoli Storage Manager Scheduler Service for each cluster node to manage all local disks and each cluster group containing physical disk resources. Chapter 15. High availability clustering 249

HACMP support for HSM clients on AIX provides support for HACMP failover on AIX so that HSM managed filesystems can continue to operate in case of an HACMP node failover and fallback. For a detailed discussion about supported environments, prerequisites, install, setup, and testing of a HACMP and IBM Tivoli Storage Manager client failover environment, see Tivoli Storage Manager Version 5.1 Technical Guide, SG24-6554, and Tivoli Storage Manager for UNIX Backup-Archive Clients Installation and User s Guide Version 5.1, GC32-0789. 15.2.1 IBM Tivoli Storage Manager with Microsoft Cluster Server IBM Tivoli Storage Manager is a cluster-aware application that can be configured in an IBM Tivoli Storage Manager MSCS high availability environment. The administrator uses the MSCS Cluster Administrator interface and IBM Tivoli Storage Manager to designate cluster arrangements and define the IBM Tivoli Storage Manager failover pattern. The systems are connected to the same disk subsystem, and they provide a high-availability solution that minimizes or eliminates many potential sources of downtime. Microsoft Cluster Server (MSCS) is software that helps configure, monitor, and control applications and hardware components that are deployed on a Windows cluster. When you use cluster configurations, you enhance the availability of your servers. Clustering enables you to join two Windows servers, or nodes, using a shared-disk subsystem. This provides the nodes with the ability to share data, which provides high server availability. For example, in the MSCS failover environment shown in Figure 15-3 on page 251, a clustered IBM Tivoli Storage Manager server called IBM Tivoli Storage Manager SERVER1 runs on node A and a clustered IBM Tivoli Storage Manager server called IBM Tivoli Storage Manager SERVER2 runs on node B. Clients connect to SERVER1 and SERVER2 without knowing which node currently hosts their server. The MSCS concept of a virtual server ensures that the server s location is transparent to client applications. To the client, it appears that the IBM Tivoli Storage Manager server is running on a virtual server called IBM Tivoli Storage Manager SERVER1. When one of the software or hardware resources fails, failover occurs. Resources (for example, applications, disks, or an IP address) migrate from the failed node to the remaining node. The remaining node takes over the IBM Tivoli Storage Manager server resource group, restarts the IBM Tivoli Storage Manager service, and provides access to administrators and clients. If node A fails, node B assumes the role of running SERVER1. To a client, it is exactly as if node A were turned off and immediately turned back on again. 250 IBM Tivoli Storage Management Concepts

UNIX Large Systems Windows System Failure TSMSERVER1 LAN/WAN TCP/IP Cluster Interconnect 1# Production IBM Tivoli Storage Manager server (MSCS) 2# Failover IBM Tivoli Storage Manager server (MSCS) IBM Tivoli Storage Manager clients TSMSERVER2 Data Flow Direct Attached Shared Storage Figure 15-3 MSCS and IBM Tivoli Storage Manager server configuration Clients experience the loss of all connections to SERVER1, and all active transactions are rolled back to the client. Clients must reconnect to SERVER1 after this occurs, which is normally handled as an automatic attempt to reconnect by the IBM Tivoli Storage Manager client. The location of SERVER1 is transparent to the client. A node can host physical or logical units, referred to as resources. Administrators organize these IBM Tivoli Storage Manager cluster resources into functional units called groups and assign these groups to individual nodes. If a node fails, the server cluster transfers the groups that were being hosted by the node to other nodes in the cluster. This transfer process is called failover. The reverse process, failback, occurs when the failed node becomes active again and the groups that were failed over to the other nodes are transferred back to the original node. Two failover configurations are supported with MSCS and IBM Tivoli Storage Manager: active/passive and active/active. In the active/passive configuration you create one instance of an IBM Tivoli Storage Manager server that can run on either node. One system runs actively as the production IBM Tivoli Storage Manager server, while the other system sits passively as an online (hot) backup. In the active/active configuration, the cluster runs two independent instances of an IBM Tivoli Storage Manager server, one on each server. In the event of a system failure, the server on the failed instance transfers to the surviving instance, so that it is running both instances. Even if both instances are running on the same physical server, users believe they are accessing a separate server. Clusters consist of many components such as nodes, cluster objects, Microsoft Cluster Server (MSCS) virtual servers, and even the hardware and software. If Chapter 15. High availability clustering 251

any one of these components is missing, the cluster cannot work. MSCS requires each IBM Tivoli Storage Manager server instance to have a private set of disk resources. Although nodes can share disk resources, only one node can actively control a disk at a time. TCP/IP is used as the communications method in an MSCS environment with IBM Tivoli Storage Manager. MSCS does not support the failover of tape devices. However, IBM Tivoli Storage Manager can handle this type of a failover pattern with the correct setup. IBM Tivoli Storage Manager uses a shared SCSI bus for the tape devices. Each node (two only) involved in the tape failover must contain an additional SCSI adapter card. The tape devices (library and drives) are connected to the shared bus. When failover occurs, the IBM Tivoli Storage Manager server issues an IBM Tivoli Storage Manager SCSI bus reset during initialization. In a failover situation, the bus reset is expected to clear any SCSI bus reserves held on the tape devices. This enables the IBM Tivoli Storage Manager server to acquire the devices after the failover. For a detailed discussion about supported environments, prerequisites, install, setup, and testing of a MSCS and IBM Tivoli Storage Manager server failover environment, see Tivoli Storage Manager for Windows Administrator s Guide Version 5.1, GC32-0782, and Tivoli Storage Manager Version 3.7.3 and 4.1: Technical Guide, SG24-6116. 15.2.2 Backup-archive client support with MSCS The IBM Tivoli Storage Manager client is supported within an MSCS IBM Tivoli Storage Manager cluster environment. This configuration allows IBM Tivoli Storage Manager scheduled client operations to continue processing in the event of a system failure on a redundant clustered failover server as shown in Figure 15-4 on page 253. 252 IBM Tivoli Storage Management Concepts

System Failure node-1 Direct Attached Shared Storage 1# Production IBM Tivoli Storage Manager client (MSCS) IBM Tivoli Storage Manager clients 2# Failover IBM Tivoli Storage Manager client node-2 (MSCS) Cluster Interconnect LAN/WAN TCP/IP IBM Tivoli Storage Manager server Data Flow Figure 15-4 MSCS and IBM Tivoli Storage Manager client configuration In this example, the cluster contains two nodes: node-1 and node-2, and two cluster groups containing physical disk resources. In this case, an instance of the IBM Tivoli Storage Manager Backup-Archive Scheduler Service should be installed for each node and physical disk resources. This ensures that proper resources are available to the backup-archive client when disks move (or fail) between cluster nodes. The IBM Tivoli Storage Manager CLUSTERNODE option in the client option file ensures that IBM Tivoli Storage Manager manages backup data logically, regardless of which cluster node backs up a cluster disk resource. For a detailed discussion about supported environments, prerequisites, install, setup, and testing of an MSCS and IBM Tivoli Storage Manager client failover environment see Tivoli Storage Manager for Windows Backup-Archive Clients Installation and User s Guide Version 5.1, GC32-0788. Chapter 15. High availability clustering 253

254 IBM Tivoli Storage Management Concepts

16 Chapter 16. Disaster Recovery Manager One of the big challenges in information technology is to have complete backup of all data and the ability to recover it in a timely fashion. This means having controls in place to keep track of massive storage repositories in complex environments with many different machines, devices, tapes, and applications. This chapter shows how the Disaster Recovery Manager function of IBM Tivoli Storage Manager Extended Edition helps the administrator with this formidable task. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 255

16.1 What is disaster recovery? Disaster recovery is the process of restoring operations of a business or organization in the event of a catastrophe. There may be many aspects related to the restoration, including facilities, equipment, personnel, supplies, customer services, and data. One of the most valuable business assets is the critical data that resides on the computer systems throughout the company. The recovery of this data needs to be a primary focus of the disaster recovery plan. IBM Tivoli Storage Manager, along with the Disaster Recovery Manager function included in IBM Tivoli Storage Manager Extended Edition, will assist you in the technical steps that you need to make your data available to users after a widespread failure. Some generic terms and terminologies that you may find regarding disaster recovery are: Business Impact Analysis (BIA): Considers business criticality for all managed systems and information flows that are vital for business survival. One of the key points here is to evaluate and map all internal departments that may have dependency to business continuity. This is an important task in a company and it is outside the scope of IBM Tivoli Storage Manager and the Disaster Recovery Manager function included in IBM Tivoli Storage Manager Extended Edition. Business Continuity Plan / Business Recovery Plan (BCP/BRP): The result of an analysis and the documentation on how to bring the company back to normal in an orderly way, considering its priorities and requirements based on the facilities and resources required. Some of the requirements will be translated into the disaster recovery plan, which may be used by IBM Tivoli Storage Manager. Information Technology Recovery Plan or disaster recovery plan: Defines what you have to rebuild and how to do it for the business side, such as database applications, spreadsheet data, and user files. This is the component where IBM Tivoli Storage Manager and the Disaster Recovery Manager function included in IBM Tivoli Storage Manager Extended Edition are of principal assistance. Figure 16-1 on page 257 shows the relationships between these entities. As you can see, although the Disaster Recovery Manager function included in IBM Tivoli Storage Manager Extended Edition plays an important role, there are many other issues to consider. 256 IBM Tivoli Storage Management Concepts

Business Impact Analysis Business Continuity Plan Disaster Management Business Recovery Plan Disaster Recovery Plan Figure 16-1 Disaster recovery terminology Distributed data recovery restores data to workstations, application servers, and file servers in the event of data loss due to accidental erasure, media failures, sabotage, and natural disasters. It involves creating, managing, and recovering copies of distributed data. These copies should be taken off-site to minimize the chance that a disaster may destroy backup copies along with primary copies. Many data administrators also choose to keep backup copies on-site to expedite recovery from smaller media failures. Disaster recovery requires, at a minimum, creating copies of primary data. Many businesses and backup products stop here. To achieve a complete recovery solution for distributed data, several additional features must be considered. 16.1.1 Using Disaster Recovery Manager IBM Tivoli Storage Manager Extended Edition delivers disaster recovery with its Disaster Recovery Manager function. This feature can also be licensed to your base product. It offers various options to configure, control, and automatically generate a disaster recovery plan containing the information, scripts, and procedures needed to automate restoration and help ensure quick recovery of your data after a disaster. It also manages and tracks the media on which your data is stored, whether on-site, in transit, or in a vault, so that your data can be easily located if disaster strikes. The scripts can help you document your basic information technology recovery strategy, the steps to rebuild your core systems, and the critical machines that you must recover. Chapter 16. Disaster Recovery Manager 257

Disaster Recovery Manager enhances IBM Tivoli Storage Manager tape controls and offers extra options such as the recovery plan file seen in Figure 16-2. IBM Tivoli Storage Manager IBM Tivoli Storage Manager for Space Management Media Management and Tracking Other IBM Tivoli complementary products Disaster Recovery Manager function as part of IBM Storage Manager Extended Edition Disaster Recovery Plan Figure 16-2 IBM Tivoli Storage Manager Extended Edition One of the key features of IBM Tivoli Storage Manager and Disaster Recovery Manager is their ability to track media in all states that it could possibly be, such as on-site, in transit or in a vault. Because of the criticality of data in the production environment, you need to implement controls to make sure that all previously backed up data can be found and restored in a reasonable amount of time. Figure 16-3 on page 259 shows a typical scenario using Disaster Recovery Manager. There are two main data objects that IBM Tivoli Storage Manager and Disaster Recovery Manager will look after for you: IBM Tivoli Storage Manager server database backups: The heart of IBM Tivoli Storage Manager, database backup is vital for server recovery. Copy storage pool data: As IBM Tivoli Storage Manager backs up the clients, new data is stored in the primary pools. For off-site storage requirements, use copy storage pools. The BACKUP STORAGEPOOL command copies all new primary storage pool files to the copy storage pool. This ensures that the copy storage pool is an up-to-date reflection of your most recent backup. Each time the primary pool is backed up to the copy storage pool (and this is recommended to be performed daily), the newly generated tapes should be sent off-site. 258 IBM Tivoli Storage Management Concepts

In addition, Disaster Recovery Manager enables you to document and prioritize your inventory of critical client nodes and their hardware and software recovery requirements. Therefore, in a typical protected IBM Tivoli Storage Manager environment, after each night s normal client backup, the copy storage pools are also updated with the newly arrived data. Then a server database backup is done. The latest generated volumes are sent to a safe location and a recovery plan file is regenerated by Disaster Recovery Manager to make sure it includes the latest information. As data expires from the on-site pools, it also expires from the off-site pools, as well as unneeded database backups. Disaster Recovery Manager also tracks such media as they become empty so that you can report on free tapes that can be brought back on-site for re-use. IBM Tivoli Storage Manager Server DRM Copy Storagepool volumes Plus Database volumes and Disaster Recovery Plan Database Disaster Recovery Plan Stores all three Together off-site Prepare Storagepools Returning Expired Volumes Figure 16-3 IBM Tivoli Storage Manager disaster recovery flow 16.1.2 Volume tracking Disaster Recovery Manager provides several levels of volume tracking. Although we refer to tape volumes here and in following sections, we can just as easily use optical volumes or even virtual volumes for off-site data requirements. Disaster Recovery Manager volume management includes: Identifying which off-site volumes are needed for a given recovery: Disaster Recovery Manager knows the volumes that are associated with each primary Chapter 16. Disaster Recovery Manager 259

storage pool so that you can initiate a complete recovery of all storage pools, or only a partial recovery, depending on the extent of the disaster. You can also configure Disaster Recovery Manager to track volumes only from certain storage pools. This might be useful if you have some critical client nodes where you offer full off-site protection, and other, less-critical nodes where limited or no off-site protection is available. In this case, you would separate the two sets of clients to use different primary storage pools and only use Disaster Recovery Manager for the critical. Integrating with tape management systems: Since Disaster Recovery Manager is fully integrated with tape management, so every time a new tape is created in the corresponding copy storage pools, it is automatically eligible for off-site movement. Recycling partially filled volumes: off-site volumes are reclaimed just as on-site volumes are. Disaster Recovery Manager enables you to see which volumes have reached an empty state because of reclamation, so that you can request them to be returned on-site. Tracking off-site volumes: This is one of Disaster Recovery Manager s strongest features. Disaster Recovery Manager manages tapes by assigning a special, predefined set of states to each off-site tape. Depending where the tape should be, there are two possible directions for a tape: from on-site to off-site and from off-site to on-site. The first starts during normal backup processing to save up-to-date data to the copy storage pool. The tapes pass through a number of states in their journey from the production tape library to the safe vault. Then, time elapses while the tape remains off-site, ready to be used for restore in the event of disaster. During this time, data is gradually expiring from the tape. When the tape finally reaches its reclamation threshold, it is reclaimed by normal processes. Once empty, it moves in the reverse direction, that is, it is returned on-site for reuse. On-site -> off-site Tapes are transitioned in the following order: Mountable, NotMountable, Courier, Vault:. 1. Mountable: Newly created copy storage pool and database backup tapes are in a mountable state as long as they are still online in the tape library. An on-site disaster would destroy these tapes as they have not yet been taken safely off-site. Therefore Disaster Recovery Manager knows that these tapes are not part of the guaranteed recovery set when creating its recovery plan. The next step for these tapes is to remove them from the tape library, and, using Disaster Recovery Manager commands, change them to the NotMountable state. 2. NotMountable: The volumes are still in the on-site location but are not online to IBM Tivoli Storage Manager. They could be in the datacenter itself, in a 260 IBM Tivoli Storage Management Concepts

locked room near the tape library or on a different floor waiting to be taken off-site. The actual physical location is not important for IBM Tivoli Storage Manager. What is important is that volumes are still on-site and it is assumed that they would also be destroyed in a disaster. This state only changes when they are taken off-site, usually by courier pickup. A Disaster Recovery Manager command will change the state of the eligible volumes. 3. Courier: An intermediate situation in which you consider the tapes as being in transit. This means that you are still considering the physical transition from your on-site location to the vault as a potential risk. For example, suppose that you have a service agreement with an external company to deliver those tapes for you. Although you rely on the staff and the company to safely move all tapes, some (or all) tapes could be lost or damaged during transportation. This is a critical step for tape movement (and proper disaster recovery) because you cannot assume that a tape in the courier state has safely reached its destination. This is a protection that Disaster Recovery Manager takes into account if you create a recovery plan file just after changing the tape state to Courier. Once you are sure that all tapes have reached their destination, it is safe to change to the next and final state. Figure 16-4 illustrates a tape movement still in Courier state. Figure 16-4 Tape movement and the Courier state 4. Vault: Once you have acknowledgement that the volumes have been safely received, you can change them to the Vault state, which is the final state in sending a tape from an on-site location to off-site. Chapter 16. Disaster Recovery Manager 261

Once the volumes are off-site, they stay there until they are eventually reclaimed (or are required for an actual recovery). When they are empty, they are then ready to begin the reverse trip. Disaster Recovery Manager query commands enable you to see which volumes can be retrieved so you can issue a list to your vault administrators. Off-site -> on-site Tapes are returned on-site in the following order: VaultRetrieve, CourierRetrieve, OnsiteRetrieve. 1. VaultRetrieve: When all data in an off-site tape is no longer valid, the tape state is automatically changed to VaultRetrieve, meaning that it is available to be brought back on-site for usage. This happens for both IBM Tivoli Storage Manager expired database backups and empty reclaimed copy storage pool tapes. Typically you would send this list to your storage vault administrators, maybe once a week, so they know which tapes to find and send back to you. Tapes that are in VaultRetrieve status are still part of the safe recovery set until they are physically removed from the vault. 2. CourierRetrieve: Change a tape to this state when you know that it has been taken from the vault and is in transit back on-site. Similar to the Courier state, these tapes may or may not be preserved safely in the event of a disaster, so it is important to know which they are. Once the volumes are correctly acknowledged upon delivery on-site, they are ready for the next state. 3. OnsiteRetrieve: Once the volumes are back on-site, you can use them as scratch tapes. Usually they will be loaded back into the tape library. Figure 16-5 on page 263 shows the complete life cycle of a tape volume and the associated states. 262 IBM Tivoli Storage Management Concepts

Database Not mountable Courier Backup of Database IBM Tivoli Storage Manager Server Backup of Storagepools DR Plan DRM Tape Library Mountable Onsite retrieve Vault Storagepools Courier retrieve Expired And Reclamation Vault retrieve Figure 16-5 Off-site tape states Disaster Recovery Manager enables you to skip some intermediate transition states. For example, you could choose to change your tapes directly from the Mountable to the Vault state. However, we do not recommend you do this, because it means less control over exactly which tapes are and are not safely available for recovery in the event of a disaster. Disaster Recovery Manager uses the PREPARE command to generate a plan file that will contain critical information needed for recovery. Information in the plan is arranged in stanzas, which can be somewhat like headers. For example, the PLANFILE.DESCRIPTION stanza shown in Example 16-1 provides summary information about the plan file as a whole. Example 16-1 DMR plan file example stanza begin PLANFILE.DESCRIPTION Recovery Plan for Server RADON_SERVER1 Created by DRM PREPARE on 07/26/2002 18:30:58 Chapter 16. Disaster Recovery Manager 263

DRM PLANPREFIX C:\DRM\PLAN\RADON Storage Management Server for Windows - Version 5, Release 1, Level 1.0 end PLANFILE.DESCRIPTION 16.1.3 Focus on recovery Facilitating data recovery is one of the most critical customer requirements in the area of storage management. Perhaps the most common recovery scenario is the restoration of user files. Another common scenario in the distributed world is restoration due to the loss of a disk drive. Recovery scenarios come in many varieties, and a complete solution should accommodate them all. A system administrator should also be able to recover the storage management server inventory. They should be prepared for less-frequent catastrophic disasters, where the client and/or server environment is lost. Figure 16-6 on page 265 illustrates two recovery possibilities for data recovery. One is to recover the IBM Tivoli Storage Manager server with the assistance of recovery plan files created by Disaster Recovery Manager, so that you can recover all of your vital data. The other possibility is to use IBM Tivoli Storage Manager backupset features to recover directly from locally attached tape drives. This situation does not necessarily require the Disaster Recovery Manager recovery plan file because backup sets can be used independently of the IBM Tivoli Storage Manager server. Both scenarios could be used simultaneously, depending solely on your backup/recovery strategy and criticality. 264 IBM Tivoli Storage Management Concepts

1. Get Data from Off-site Location IBM Tivoli Storage Manager Server Database 2. Rebuild Server Infrastructure Using device Config file Storagepools 3. Rebuild Backup Server from DR plan using media retrieved from Off-site location 4. Restore Data Resume normal Operations Server Single Server * * Single Server * Single Server Single Server Single Server ** * * Single Server ** Single Server * Single Server Network Server Client Network * * s Server * Client * * s * Network Server Network Server Client s * * Client * * * s * Network Server Client * * s * Network Server Client * * s * LAN-Free Rapid Restore Network Server * Client * s * Server * Single Network Server * Client * s * Network Server Single Server * Network Server Client * * s * * Client * s * Figure 16-6 Recovery order and possibilities You should also have a plan for a minor disaster in which only a small portion of your data has been lost but you can continue to use the same hardware (machine, tapes, and so forth). IBM Tivoli Storage Manager supports recovery to the state of the last backup for files, directories, logical volumes, disks, or an entire system image. This includes file and file system attributes. Optionally, a system administrator should be able to recover to the time of any of the last several backups. Another function would be restoration of a file only if the version stored on the server is a more recent backup version than that already existing on the client. This "restore if newer" feature could be run in a situation where the extent of file loss or corruption is unknown. 16.1.4 Speed to recovery One of the most important requirements for disaster recovery is to minimize the time to recovery. This is done through planning, preparing, and testing for recovery, not just for backup. A complete recovery solution should not stop once backups are complete; but instead should assist in preparing a disaster recovery plan and then help recover the data when needed. It should also do everything possible to automate and facilitate the recovery. Chapter 16. Disaster Recovery Manager 265

As data recovery scenarios are often unique, part of speeding recovery is to be flexible in the way restores are done. For example, authorized administrators should be allowed to restore on behalf of clients in the event an owner of shared data is unavailable. It is not always possible to recover all lost data immediately. Administrators should also be able to schedule restores to enable highest-priority data to be restored first. This is why the preliminary steps, including the Business Impact Analysis, are so important:: to prioritize the recovery requirements. Some applications are critical enough to warrant hot site recovery for the storage management server. This requires a second storage management server at a remote site that is ready to go online immediately upon failure of the primary storage management server. The secondary server might not be a true mirror of the primary server due to network delays in server updates. A hot site recovery requires a higher investment in hardware and software, but can be viable for certain business applications. 16.2 What should be considered a disaster? A disaster is a catastrophic interruption of business processing that destroys the IBM Tivoli Storage Manager server, clients, or both. There are many levels to consider for a disaster. You can imagine a situation where a user deletes a file and requests a restore (to the user it might indeed be a disaster ). A complete directory might be lost; an application server might be infected with a virus, causing an unknown extent of damage; a disk might be lost on a fileserver; or a full datacenter building with many machines might be completely destroyed. Depending on the business requirement, you will need to answer bigger questions, such as what kind of recovery do you need and how long do you have to provide it. Figure 16-7 on page 267 shows the time it may take to recover using some of the well-known techniques that you can apply to your environment to safeguard from data loss. 266 IBM Tivoli Storage Management Concepts

Recovery Window x Customers 60% 50% 40% 30% 20% 10% 0% Techniques Implemented 39% 46% Recovery window is the time from disaster striking until you are back in full production. 12% 3% < 24 Hrs 24-72 Hrs 3-7 Days 1 Week or more Mirror... Vaulting... Hot Site... Cold Site... Reconstruction Figure 16-7 Recovery time 16.2.1 Disaster recovery techniques Disaster Recovery Manager can assist you in the following situations: Reconstruction: This means rebuilding your previous working environment at the same place and to the same state as it was before. This also means that you do not have all of the required machines available to start and, therefore, you will have to contact local dealers to provide all of the hardware and software you lack. Assuming that you have saved your vital data to an alternate off-site location, Disaster Recovery Manager will help you rebuild your IBM Tivoli Storage Manager server, so that you can then restore the client nodes up to the last known saved position. Cold site: In this scenario, you may have all spare hardware and software available, but not properly configured or ready for usage. Some preliminary steps are still required to prepare the infrastructure. In this case, IBM Tivoli Storage Manager will have to be installed with all additional required software. You then restore your latest database backup and restore the storage pools using the Disaster Recovery Manager recovery plan. You can then restore the clients, starting with the most critical. Chapter 16. Disaster Recovery Manager 267

Hot site: Generally, a hot site will have all of the infrastructure hardware and software in place, so that you can focus on business information recovery rather than infrastructure. However, you must still bring your data to the hot site location. Assuming that your hot site has all basic software installed (IBM Tivoli Storage Manager included), you will recover your backup server and application data by using the recovery plan file and database backups. Vaulting: This provides all hardware, software, and data requirements for recovery. In this case, you concentrate solely on business recovery as all data is already available to you. Disaster Recovery Manager offers a complete set of tape state controls to make tape vaulting easy and precise. All off-site tapes can have one of the following stages: Mountable, NotMountable, Courier, CourierRetrieve, Vault, VaultRetrieve, OnsiteRetrieve. This governs how the recovery will be affected if, for example, the volumes are in transit to off-site (Courier) and did not reach the off-site location (Vault). Mirror: A mirror site normally replicates all required data simultaneously, so that whenever you have a failure in the primary image, the copy (or copies) can be used without interruption of business activity. This is the only situation in which you may not need Disaster Recovery Manager at all as you already have an alternate, secure, and up-to-date condition for your data. However, you could still consider using Disaster Recovery Manager to control other machines that are not being mirrored to this site. Backup operations can guarantee the first level of protection, in which main data is lost, inconsistent, or damaged. Unfortunately, if your backup tapes are located in the same place as your production data, then you risk losing your only safeguard. Figure 16-8 on page 269 shows a typical situation where off-site data storage is used. The latest file changes are sent to the off-site location, so that you can use it together with previous data sent. 268 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Manager Server Off-Site Recovery Data Prepare Database DR Plan SCRATCH TAPES DATABASE BACKUP VOLUMES vault DATA VOLUMES Figure 16-8 Sending data to off-site location Backup data is located off-site to protect it from damage. Data does not have to be lost or destroyed in order to be unavailable. In recent disasters, data inaccessibility appeared to be caused as much by condemned buildings and evacuations as by destruction. Companies need to plan for the physical accessibility of data, not just the survival of data. In today s world, however, it all depends on who you are, where you are, and what you were doing. Today s disaster can be characterized by the business you are in (for example, banking, e-commerce, distribution, or manufacturing). In banking or e-commerce, time is very important. One hour of downtime from any cause can mean business loss amounting to millions of dollars. In the e-commerce world, if you cannot satisfy your customer s requests, they may go to a competitor and never return to your site. The potential losses may not be as large in manufacturing or distribution. But whatever the business is, the longer the downtime, the greater the loss that the business incurs and the greater the risk that the business may never recover from the loss. Disaster recovery management is accomplished with IBM Tivoli Storage Manager by a combination of: Backing up client data to the IBM Tivoli Storage Manager server Chapter 16. Disaster Recovery Manager 269

Backing up the server database to removable media and storing the media off-site Backing up the primary storage pools and storing the media off-site Using the disaster recovery plan file to assist with the IBM Tivoli Storage Manager server recovery Optionally using LAN-free recovery options, such as backupsets where available and appropriate to improve recovery Optionally using virtual volumes to save data, recovery plan files, and database information electronically to an alternate IBM Tivoli Storage Manager server 16.3 Recovery strategy for the server Disaster Recovery Manager simplifies the disaster recovery planning process for the IBM Tivoli Storage Manager server by generating a recovery plan file that is based on a pre-defined recovery strategy. The recovery plan file contains the information and procedures necessary to help restore the key components of the IBM Tivoli Storage Manager server. The content of the plan file includes: Installation-specific server recovery instructions List of IBM Tivoli Storage Manager database backup and copy storage pool volumes required to perform the recovery, including the off-site location where the volumes reside Devices required to read the database backup and copy storage pool volumes Space requirements for the IBM Tivoli Storage Manager database and recovery log Copy of IBM Tivoli Storage Manager configuration files Shell scripts and IBM Tivoli Storage Manager macros for performing server database recovery and primary storage pool recovery 16.3.1 Creation of up-to-date disaster recovery plan To make the creation and maintenance of the server disaster recovery plan easier, the prepare command automatically queries the required information from the IBM Tivoli Storage Manager server and creates the recovery plan file. The prepare command can be scheduled using the IBM Tivoli Storage Manager central scheduling capabilities. 270 IBM Tivoli Storage Management Concepts

Auditable plan for IBM Tivoli Storage Manager server The recovery plan file contains the information and procedures necessary to assist with the recovery of the Tivoli Storage Manager server. The information in the plan file includes site-specific server recovery instructions and information as defined by the administrator (for example, contact names and telephone numbers for critical people and their backups). The sequence of steps necessary to recover an IBM Tivoli Storage Manager server is: List of IBM Tivoli Storage Manager database backup and copy storage pool volumes required to perform the recovery (including the off-site location where the volumes reside) Devices required to read the database backup and copy storage pool volumes Space requirements for the IBM Tivoli Storage Manager database and recovery log Copy of IBM Tivoli Storage Manager server options file, device configuration file, and volume history information file Shell scripts (on UNIX), REXX scripts and JCL (on MVS ), and IBM Tivoli Storage Manager macros for performing server database recovery and primary storage pool recovery Off-site recovery media management Knowing the location of off-site recovery media is critical to the successful implementation of a disaster recovery management plan. The off-site recovery media management function provides: Determination of which database and copy storage pool volumes need to be moved off-site and back on-site Automatic ejection of volumes from an automated library Tracking of the media location and state in the IBM Tivoli Storage Manager database This function allows database backup volumes and copy storage pool volumes to be treated as logical collections that are selected to move off-site for safekeeping and on-site for use. The reclamation of off-site volumes includes the capability to specify the number of days to retain an IBM Tivoli Storage Manager database backup series. After the expiration interval is reached, the data on the media is no longer considered to be valid. The media can then be reused. Figure 16-9 on page 272 illustrates how your off-site data could be used to recover your environment. Note that "V1" is the point in time requested; therefore, you can not only rebuild the latest one, but also data from any specific Chapter 16. Disaster Recovery Manager 271

point in time that you still have saved. The execution of the recovery scripts (which perform the Automatic Recovery Steps in the figure) starts after you have re-installed the operating system and IBM Tivoli Storage Manager server code on your replacement server hardware. Recovering the Server O N S I T E O F F S I T E DISASTER Storage Pools RECOVERY PLAN restore stgpool... restore db... Server MOUNTABLE V1 V3 V2 DISASTER RECOVERY PLAN DISASTER RECOVERY PLAN DISASTER RECOVERY PLAN DB IBM Tivoli Storage Manager Database Automatic Recovery Steps Restore Options, Volume History, and Device Configuration Files Create Volumes for Database and Recovery Log Restore Database Start Server Create Volumes for Storage Pools Define Primary Volumes Restore Primary Storage Pools Figure 16-9 Restoring an IBM Tivoli Storage Manager server Storage of client recovery information Disaster Recovery Manager enables the machine information needed to help recover the IBM Tivoli Storage Manager clients to be stored in the IBM Tivoli Storage Manager database. This information includes: IBM Tivoli Storage Manager client machine location, machine characteristics, and recovery instructions Business priorities associated with the IBM Tivoli Storage Manager client machines Description, location, and volume/diskette labels of IBM Tivoli Storage Manager client boot media Centralized management of the disaster recovery process 272 IBM Tivoli Storage Management Concepts

Based on the server information contained in the recovery plan file and the client information stored in the IBM Tivoli Storage Manager database, a centrally managed, pre-defined disaster recovery management strategy can be implemented. Disaster Recovery Manager assists customers with the recovery of the IBM Tivoli Storage Manager server by providing: off-site media requirements This includes the name and location of the server database and copy storage pool volumes. Sequence of steps to recover the IBM Tivoli Storage Manager server machine The recovery plan file contains the sequence of steps necessary to recover an IBM Tivoli Storage Manager server. Automated command generation The prepare command automatically generates and saves commands for performing server database recovery and primary storage pool recovery. Disaster Recovery Manager also assists customers with recovery of IBM Tivoli Storage Manager client machines: Performing damage analysis Disaster Recovery Manager provides query capabilities to determine what client machines were lost in the disaster and need to be recovered. Reporting recovery requirements for client machines Based on the information acquired in the damage analysis step, Disaster Recovery Manager reports machine requirements and off-site boot media requirements. Recovery order based on business priorities Disaster Recovery Manager allows priorities to be associated with client machine definitions. This information is used to determine the order to recover machines. 16.3.2 Additional disaster recovery issues Disaster recovery goes far beyond simple technical measures. To have a fully operational and prepared environment, you must also pay attention to additional issues, as highlighted. Hardware system requirements Disaster Recovery Manager creates a recovery plan file based on the information and space allocation on the IBM Tivoli Storage Manager production server machine. This means that you must evaluate whether to have a similar machine for off-site recovery and make the changes to fit the new environment. Additional operating system recovery steps Depending on the operating system on which IBM Tivoli Storage Manager is installed, you may need to send special compact disk (CD) or tape images (for Chapter 16. Disaster Recovery Manager 273

the specific OS recovery steps) to the off-site location. For example, this would be fully supported on an AIX machine by using the mksysb operating system command to produce a valid, bootable tape image of your present configuration. Recovery testing A recovery solution must be tested before it is actually needed. A good approach is to create all documents, operating system tapes, special hardware requirements, and installations scripts, and and send them to the off-site location labeled as a Disaster Recovery starter kit. Then, perform a complete recovery test once a year to ensure that the documents are accurate for recovery, and incorporate any changes that were uncovered during your test. 274 IBM Tivoli Storage Management Concepts

Part 4 Part 4 Systems management This part discusses the ways to actually manage an IBM Tivoli Storage Manager environment not the daily operating tasks, but the way to integrate IBM Tivoli Storage Manager into a systems management environment. Additionally, we discuss the reporting possibilities of IBM Tivoli Storage Manager. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 275

276 IBM Tivoli Storage Management Concepts

17 Chapter 17. Reporting This chapter covers basic IBM Tivoli Storage Manager reporting and explains which reports may be useful. It also shows the facilities that can be used for reporting that are included with the base IBM Tivoli Storage Manager product. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 277

17.1 Why IBM Tivoli Storage Manager reporting? As with any application, an IBM Tivoli Storage Manager environment includes a series of tasks that must be performed regularly. To perform these tasks in a timely and efficient way requires a set of resources, such as space in storage pools or in the IBM Tivoli Storage Manager database, and tape drives and volumes. Scheduled operations must complete in a timely manner and without failures. In large environments the number of operations can be quite high, and managing them effectively can be quite complex. Reports can be very useful for verifying that the tasks set up for IBM Tivoli Storage Manager to perform are carried out in a timely and efficient way. 17.2 Which reports are needed? Reports and their content are very subjective; they depend on the installation s requirements and on each administrator s personal approach to use IBM Tivoli Storage Manager. One of the first things to determine is the kind of operations IBM Tivoli Storage Manager performs in each installation. For example, is IBM Tivoli Storage Manager used only to back up files, or is IBM Tivoli Storage Manager for Space Management used as well? Is data being archived and are disaster protection procedures in place? The answers to these and other questions will help build a set of reports that is appropriate to the specific installation requirements. Describing the exact commands required to generate these reports is beyond the scope of this book; however, they can all be done using standard IBM Tivoli Storage Manager administrative commands and SQL queries. More information about reporting queries is available in the companion redbook IBM Tivoli Storage Manager Implementation Guide, SG24-5416. 17.2.1 Daily summary report The daily summary report or overview report is the most basic type of report. From this report it can be seen whether IBM Tivoli Storage Manager is doing all that it is expected to do and give a summary of all failed operations, such as missed backups or server errors. The daily summary report should be as short as possible, to facilitate reading and understanding the information, and can show such information as a list of all scheduled events that failed: Files that failed during backup Summary information about the amount of data transferred to the IBM Tivoli Storage Manager server 278 IBM Tivoli Storage Management Concepts

Space usage trends on the IBM Tivoli Storage Manager server Removable media (tape) errors Server error messages All information in the daily summary report relates to the last 24-hour period. A report can also be generated once a week, in which case, of course, it should contain a summary of all activities and problems that occurred during the week. 17.2.2 Detail reports Detail reports help explain a particular aspect of the IBM Tivoli Storage Manager environment. There are many possible detail reports, but they can be classified into the following categories: Client activity and traffic reports: These reports detail the activities performed on individual clients or groups of IBM Tivoli Storage Manager clients. They can show the amount of data transferred to and from the server, categorized by activity type, such as backup, archive, or HSM. They are helpful in identifying delays in client activity and the reason for the delay. Server background processes: These reports show the activities performed on the server to manage the data that arrives from individual clients. Examples of these activities are migration, reclamation, and storage pool backup. It is useful to know when these activities run and their duration. This information can be used for estimating the impact of new workloads or server processes on current server activities. Server storage pool space utilization: These reports show server storage pool space utilization by total storage pool space, or by client node, client filespace, or storage pool. They can be point-in-time or trend reports. They are useful in determining the amount of storage media required to accommodate current or new workloads. Server database utilization: These reports can be used to monitor IBM Tivoli Storage Manager server database and log utilization, to ensure that adequate space is always available. IBM Tivoli Storage Manager will not work properly if the database or log fills up, so this should be avoided. Backup/archive schedules: These reports refer to operations scheduled on the client nodes through the IBM Tivoli Storage Manager scheduler. The reports show scheduled events that failed, which is the basic exception report to monitor, and all scheduled events that occurred. Events scheduled using utilities, such as a UNIX cron job or a third-party scheduling package, are not logged on the IBM Tivoli Storage Manager server, so another reporting mechanism must be used. Chapter 17. Reporting 279

Administrative schedules: Administrative operations can be automated with the administrative scheduling facility. IBM Tivoli Storage Manager reports an administrative event as completed when the scheduled operation is started, not when it has completed. You therefore want reports that show whether administrative schedules completed successfully. Server configuration: These static reports show IBM Tivoli Storage Manager server configuration parameters such as management. These can be used as references when analyzing other reports. 17.3 Where is server information stored? Most of the information used to create reports is stored on the IBM Tivoli Storage Manager server, but some of it is stored only on client nodes. 17.3.1 Information on the server The IBM Tivoli Storage Manager server has three main sources of information for creating reports: Database: This is the most important source. The IBM Tivoli Storage Manager database contains all server and most client definitions. It is the prime source of static information. When database information is requested and given, it is in the form of snapshot or point-in-time data; trends cannot be seen. Activity log: The IBM Tivoli Storage Manager activity log contains all server messages for the past several days. The number of days to keep this information is predefined and can be customized by using a server command. Messages are logged for client sessions, scheduled operations, automated server processes, and any errors that may occur. The activity log displays historical information: The progress of operations over time can be seen. With IBM Tivoli Storage Manager, client messages can be logged as events in the activity log. Commands are available to select all, none, or a subset of events to be logged. Accounting log: IBM Tivoli Storage Manager accounting can be activated with a server command. Once started, records are automatically collected and the log is written to a file called dsmaccnt.log in the server installation directory. The dsmaccnt.log file contains one record for each client session that terminates. The record consists of text and numeric values separated by commas, which is a convenient format for loading into a spreadsheet or other data analysis package. It offers summary information for the activities performed during a session, such as files and bytes backed up, archived, or migrated, session wait times, and total data transferred. 280 IBM Tivoli Storage Management Concepts

17.3.2 Information on the client node The IBM Tivoli Storage Manager client has two main sources of information: Client error log: On the client node, IBM Tivoli Storage Manager writes error information to the dsmerror.log file, usually for situations where the client did not succeed in contacting the server. By default it is written to the IBM Tivoli Storage Manager client installation directory; however, it can be stored on any drive or directory accessible to the client (for example, a shared network drive) by setting a client option. Scheduler log: Also on the client node is the dsmsched.log file, which contains information for all scheduled operations, such as the name of files that are backed up or archived, failures and errors, and backup summary statistics. This file is called dsmsched.log, and by default it is written to the current directory where the client scheduler is started. However, it can be stored on any drive or directory accessible to the client (for example, a shared network drive) by setting a client option. IBM Tivoli Storage Manager client sessions that are not started with the scheduler do not write output to a file by default. The output will be lost unless the messages are saved in some way, such as by redirecting standard output and errors to a file. With IBM Tivoli Storage Manager, error and summary information is propagated from the client to the server activity log. Client error and information messages are identified in the server activity log by the prefix characters ANE. This information is stored for both scheduled and nonscheduled IBM Tivoli Storage Manager client sessions. 17.4 Central error logging IBM Tivoli Storage Manager events can be centrally logged, monitored, and reported by using industry-standard interfaces. Thus, IBM Tivoli Storage Manager implementations can be integrated with system management applications, and centralized control is facilitated. 17.4.1 Central logging of client events Certain IBM Tivoli Storage Manager client messages can be logged as events on the server. Client messages can be collected in one central point. The intention of client message logging is to log problems encountered during an IBM Tivoli Storage Manager client operation. Therefore only messages indicating an error condition are logged as events. The only exception to this is client backup statistics, which also can be centrally logged. Chapter 17. Reporting 281

All events that are to be logged must be enabled by either message number or severity. Enabled client events that are logged to the IBM Tivoli Storage Manager server are, by default, stored in the activity log and displayed on the server console. 17.4.2 Client and server event reporting To take advantage of standard systems management interfaces, IBM Tivoli Storage Manager provides the ability to send client and server events to external interfaces. Supported interfaces are Simple Network Management Protocol (SNMP) managers such as NetView for AIX, CA Unicenter, or HP OpenView; Tivoli Enterprise Console; NetView for MVS; the NT event log; a user-written exit; or direct to a file. Interfaces that receive event data are called event receivers. Each event message, whether client or server, can be enabled for any of the supported receivers. It is possible to enable one message or a group of messages for more than one receiver. As with client event logging, events are enabled for receivers by message number or severity. The concept of redirecting event messages to external interfaces enables IBM Tivoli Storage Manager implementations to be integrated with systems management reporting tools. 17.4.3 SNMP heartbeat monitoring of server SNMP is also used to monitor network elements from a central point. It enables the monitored systems to send traps notifying the SNMP manager about events taking place on the local system. In addition to sending traps, a heartbeat monitor can be established to monitor whether managed IBM Tivoli Storage Manager servers are still alive. To enable IBM Tivoli Storage Manager to take advantage of SNMP monitoring, it includes an interface for SNMP. The interface is distributed with the server in the form of an SNMP subagent. It is supported for the server running on AIX, HP-UX, Solaris, and Windows NT. Communication between the server and the SNMP manager is established through one of these connection channels: IBM Tivoli Storage Manager server <--> SNMP subagent <--> SNMP agent <--> SNMP manager IBM Tivoli Storage Manager server <--> SNMP agent <--> SNMP manager To enable communication between SNMP subagent and SNMP agent, the SNMP agent must support the Distributed Protocol Interface (DPI ). 282 IBM Tivoli Storage Management Concepts

17.5 SQL queries and ODBC interface IBM Tivoli Storage Manager provides an SQL interface which supports queries to its internal database. The interface is read-only and includes a SELECT command and an open database connectivity (ODBC) driver for Windows NT/2000. 17.5.1 SELECT command The SQL interface represents IBM Tivoli Storage Manager information in the form of relational tables containing rows and columns that can be accessed by the SELECT command. The SELECT command uses standard SQL syntax compliant with the SQL92/93 standard and can be used only on the administrative command line client. Because SQL processing uses database resources, long-running or very complicated select statements can slow down server performance significantly. Therefore resource-intensive queries display a confirmation message, offering the possibility to abort the query before executing it. 17.5.2 ODBC driver ODBC is a standard interface between SQL database engines and front-end applications. It enables products such as Lotus Approach and Microsoft Access to be used to graphically construct SQL queries, which are then dispatched to the database (in this case the IBM Tivoli Storage Manager database). The select statement results are returned in tabular form and can be processed to be displayed as charts or tables. The IBM Tivoli Storage Manager ODBC driver only ships as part of the Win32 client package. The driver is compliant with the ODBC 2.5 application programming interface (API). 17.6 Operational reporting This chapter discusses operational reporting using a technical preview function of IBM Tivoli Storage Manager Operational Reporting. As this book was being written, only a pre-beta version was available. An exact date for publishing and starting the official technical preview was not known. For details and a list of features, visit the IBM Tivoli Storage Manager Web site: http://www-3.ibm.com/software/sysmgmt/products/support/ibmtivolistorage Manager.html Chapter 17. Reporting 283

17.6.1 Overview Current complementary products include several items for generating reports on IBM Tivoli Storage Manager. These reports, created for long-term analysis, provide a mechanism to make IBM Tivoli Storage Management events, performance, and fulfilment of business requirements readily visible by employing a variety of formats and reporting levels. The reports are appropriate and informative for information systems technicians, IBM Tivoli Storage Management administrators, and company executives. They usually include different views and diagrams to show how the IBM Tivoli Storage Manager environment has developed during the analysis time frame. A lot of data is required to establish such complex reports. This data usually comes from the IBM Tivoli Storage Manager database, which was not developed for data warehousing and online analytical processing, so the needed records are transferred to an external relational database management system (RDBMS), which generates the desired reports. This can be a very time-consuming process, so it usually is executed only once a day. Because of their emphasis on the long term, the reports do not include real-time information about the current state of an IBM Tivoli Storage Manager server. Operational reporting, on the other hand, is made to support IBM Tivoli Storage Manager administrators in their daily work. Normally an IBM Tivoli Storage Manager administrator executes a query or select commands to discover current issues on an IBM Tivoli Storage Manager server. These tasks can be repeated daily or hourly to display the most current data to keep IBM Tivoli Storage Manager running smoothly and resolve any issues as quickly and easily as possible when they arise. Operational reporting views an IBM Tivoli Storage Manager server as being in one of two states, Running Smoothly or Needs Attention, determined by customizable rules. This information is automatically determined and sent in the subject line of an e-mail. The e-mail provides access to a customizable status report. If a server needs attention, the e-mail also describes any issues and provides recommendations on how to get IBM Tivoli Storage Manager running smoothly again. For example, IBM Tivoli Storage Manager operational reporting can be configured to query IBM Tivoli Storage Manager servers every day at 5:00 a.m., generate a report with the designated information, and send the report as e-mail with a subject line indicating whether the server is running smoothly or needs attention. A server needs attention if it has the outstanding issues you have specified, such as if more than one client schedule has failed or if there are fewer than 10 scratch volumes. You can also provide a recommendation about what to do when there are issues. 284 IBM Tivoli Storage Management Concepts

If the report indicates that a server needs attention, it will highlight the issues and provide recommendations for resolving them. IBM Tivoli Storage Manager operational reporting also includes a special kind of report called an operational monitor, which can be configured to run hourly to check for issues. Whereas a report will be sent regardless of any issues, a monitor will only notify you if any issues arise, via e-mail or by sending a message to your Windows desktop. You can customize and share XML-based operational report and monitor templates with others. IBM Tivoli Storage Manager operational reporting features include: Reduces the amount of time needed to administer IBM Tivoli Storage Manager. Provides customizable daily operational summary reports. Provides customizable hourly monitors. Supports multiple IBM Tivoli Storage Manager servers (any version, any platform). Supports multiple reports and monitors per server. Reports can be viewed interactively. Reports can be viewed from a Web site. Color highlighting provides quick status identification. Custom report and monitor templates can be shared. Issues are identified and recommendations are provided. Administrator notification: Reports can be sent automatically via e-mail. Subject line reports whether running smoothly or needs attention. Monitor sends notification if user-defined issues arise. Client notification of failed or missed schedules: Automatically notify clients of missed or failed schedules. Easy to use: Runs as a Windows service. Integrated into IBM Tivoli Storage Manager management console (MMC snap-in). Defaults are provided out of the box. Small number of settings with a simple user interface. Chapter 17. Reporting 285

17.6.2 Examples This section shows some sample outputs from IBM Tivoli Storage Manager operational reporting. These demonstrate the described features and the way they keep your IBM Tivoli Storage Manager servers running smoothly to reduce administration time and effort. Web summary page If you enable the Web summary feature, operational reporting generates a Web page that combines references and links to all of the latest generated monitors and reports, as in Figure 17-1. By clicking the links you can reach specific reports or monitors. Figure 17-1 Operational report Web summary page 286 IBM Tivoli Storage Management Concepts

Hourly monitor You can create monitors to observe only the main, vital parameters of an IBM Tivoli Storage Manager server. This monitor is usually refreshed every hour. If an issue occurs, the monitor results are forwarded to a defined e-mail account or to the Web summary page, as shown in Figure 17-2. Figure 17-2 Operational reporting hourly monitor Chapter 17. Reporting 287

Daily report The daily report is a summary of all activities that took place during the past 24 hours. It includes useful information about client and server activities, such as execution results of schedules, client processes, missed files, throughput, bytes transferred, and server status. Furthermore, it includes summaries for specific server processes such as migration, reclamation, and tape mounts across the timeline as a bar chart, as shown in Figure 17-3 and Figure 17-4 on page 289. Figure 17-3 Operational reporting daily report summary 288 IBM Tivoli Storage Management Concepts

Figure 17-4 Operational reporting daily report load summary E-mail notifications IBM Tivoli Storage Manager operational reporting can notify the administrator via e-mail as soon as issues are detected. The defined reports and monitors can be forwarded using this feature. These e-mails can include the issue list in plain text or HTML format, or they can forward the address of the Web summary page, which can be used to access the latest monitor or report. IBM Tivoli Storage Manager operational reporting can notify the dedicated contact persons of defined client nodes via e-mail as well when an associated schedule has missed or failed. (See Example 17-1 on page 290.) This simplifies the process of informing system administrators of possibly misconfigured IBM Tivoli Storage Manager clients on their machines. Chapter 17. Reporting 289

Example 17-1 E-mail notification for missed schedule To:catfish@aquarium.com cc: Subject:Missed TSM Schedule for node JAMAICA. Hello Mr. Catfish, You are receiving this automatic notification message because you are listed as the contact for node JAMAICA on TSM server CLYDE. The node has Missed its scheduled backup. Typical reasons for missed schedules are: The computer is not on the network. The scheduler is not installed. The scheduler is not running because it is not set to start at boot time. The scheduler is not running because it had an error. The scheduler's option file is not pointing to the right server. It may help to review the *.log files in the baclient directory to identify the problem. Please reply if you: [] No longer want to be automatically notified of missed schedules. [] No longer want to be associated with this schedule. [] Need a different schedule -- specify your preferred date and times. [] Need help fixing the problem -- attach the client schedule and error logs if possible. [] Other -- provide details. Thank you. This automatic message was sent from machine CLYDE. Summary These examples describe the results IBM Tivoli Storage Manager operational reporting can provide. This useful triggering and conditioning of IBM Tivoli Storage Manager related information helps reduce the daily amount of time and effort needed to administer an IBM Tivoli Storage Manager environment. The next chapters describe in detail how IBM Tivoli Storage Manager operational reporting is installed and configured to receive results similar to those described in the examples. 290 IBM Tivoli Storage Management Concepts

18 Chapter 18. IBM Tivoli Enterprise solutions In IBM Tivoli terms, an enterprise consists of a large number of resources to manage. These resources can be network components, operating systems, databases, middleware, and off-the-shelf or custom applications. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 291

18.1 Overview The foundation of the IBM Tivoli Enterprise architecture as shown in Figure 18-1 on page 293 is a distributed object-oriented software called IBM Tivoli Systems Mangement Framework. Most of the applications of the IBM Tivoli Enterprise suite use the services included in the framework. This means that when a major function in the framework is improved, these IBM Tivoli applications can take advantage of the improvement. The IBM Tivoli Systems Management Framework also serves as a single point of integration for the IBM Tivoli and third-party applications. In addition to the framework, IBM Tivoli Enterprise provides a suite of management products in the disciplines of deployment, availability, operations, and security management. We often call these applications the fundamental IBM Tivoli management applications or the IBM Tivoli core applications. IBM Tivoli Enterprise also provides a number of modules to manage specific mission-critical applications such as: SAP R/3 and MQSeries E-mail systems, such as Domino/Notes and Microsoft Exchange Internet servers, such as Microsoft Commercial Internet System servers and Netscape Suitespot servers RDBMS (Relational Database Management System), such as Oracle, Sybase, DB/2, Informix, and SQL 292 IBM Tivoli Storage Management Concepts

The Tivoli Solution Business Systems Management Applications Management Suite Spot Tivoli Manager for.. MCIS Global Enterprise Manager Domino MQ Series SAP R/3 Database Exchange Systems and Network Management Configuration and Operation Software Distribution Inventory Management Performance and Availability Distributed NetView Monitoring Decision Enterprise Support Console Security Security Management Risk Manager Storage Storage Manager Storage Resource SAN Manager Manager Distributed Object Framework Policy Communication Tasks Scheduling Security Collections Configuration Distributions Computing Resources Systems Networks Databases Applications Internet Figure 18-1 IBM Tivoli Enterprise architecture 18.2 IBM Tivoli Enterprise modules This section provides an overview of each of the the principal IBM Tivoli Enterprise modules. 18.2.1 IBM Tivoli Systems Management Framework The IBM Tivoli Systems Management Framework provides the basic system management services, including communications, presentation, and security, that most of the IBM Tivoli management applications use, which ensures consistency and integration. At its core, the framework provides the facilities to transfer files and execute commands on remote systems with built-in security and authorization roles. The IBM Tivoli management applications can use these core facilities to implement management functions, including software distribution, resource monitoring, and system configuration. Chapter 18. IBM Tivoli Enterprise solutions 293

Most IBM Tivoli systems management tasks, regardless of the application or component that is to be managed, may be performed by using the IBM Tivoli desktop, which provides a user interface consistent throughout management applications. The upper-left corner of Figure 18-2 show the main IBM Tivoli Systems Management Framework products and their logical connections to each other. The lower part shows the IBM Tivoli Storage Manager suite with the server itself and the different clients and special modules. On the right side are some applications that can be managed by IBM Tivoli management modules and by the Data Protection components for applications. IBM Tivoli Distributed Monitoring IBM Tivoli Inventory Framework IBM Tivoli Manager for Oracle IBM Tivoli Manager for SQL Oracle SQL IBM Tivoli Software Distribution IBM Tivoli Enterprise Console IBM Tivoli RDBMS Interface Module IBM Tivoli Manager for Exchange IBM Tivoli Manager for Domino Exchange Domino RDBMS IBM Tivoli Storage Manager Server Admin Client Backup Archive Client ITSM Data Protection for Oracle ITSM Data Protection for SQL ITSM Data Protection for Exchange ITSM Data Protection for Domino Figure 18-2 IBM Tivoli Enterprise Systems Management Framework 18.2.2 IBM Tivoli Distributed Monitoring IBM Tivoli Distributed Monitoring is an application that allows monitoring of the status of a wide range of geographically-dispersed platforms from different vendors running different operating systems including resources that are not part of the IBM Tivoli environment. 294 IBM Tivoli Storage Management Concepts

A monitor is an entity that controls specific aspects of a resource (such as percentage of disk space, status of a print queue, database process status, load average of a system, and network collisions). Its definition contains threshold values and various response actions triggered upon reaching a threshold. IBM Tivoli Distributed Monitoring uses the concept of management by subscription, in common with the other IBM Tivoli core applications. Monitors are defined centrally in distributed monitoring profiles that are distributed and activated on the target systems. IBM Tivoli Distributed Monitoring provides the network computing environment with the following features: Centralized, synchronous (scheduled) monitoring of remote resources Predefined monitors for almost every resource (monitoring collections) Strong mechanism to generate events and alarms Automated decisions and actions in response to alarms or events Various responses (e-mail, triggering a program) Custom scripts for monitoring specific applications Full integration with the IBM Tivoli Enterprise Console event server Data collection for statistical analysis and capacity planning IBM Tivoli Distributed Monitoring provides a variety of predefined monitors that can be customized for a particular environment. In the IBM Tivoli Storage Manager environment, one or more profiles can be defined. These profiles contain one or more monitors that define the particular object being monitored and the actions to perform when it occurs. Monitors can be defined that, for example, will verify whether the IBM Tivoli Storage Manager server daemon is running or check for the results of a server script or SQL query execution. A monitor could also check the utilization of various resources, such as paging space or free disk space on the server. Once the profiles and its monitors are defined, one or more IBM Tivoli Storage Manager servers will be subscribed to it so that the monitors will run. 18.2.3 IBM Tivoli Software Distribution IBM Tivoli Software Distribution provides facilities for the distribution and installation of software to managed systems in an IBM Tivoli environment. IBM Tivoli Software Distribution uses the facilities provided by the IBM Tivoli Systems Management Framework to distribute file packages in an efficient manner. Administrators use the profile paradigm used by most other IBM Tivoli applications to define file packages to be distributed. These file packages can include any files (executable programs, data files) and scripts that will be executed before and after the distribution for a proper installation of the files on the target system. Chapter 18. IBM Tivoli Enterprise solutions 295

The actual distribution process can use the Multiplexed Distribution (MDist) facility of the framework to optimize the use of the network. MDist is used to define nodes as repeaters so that they become fan-out points for the distribution. By defining an appropriate repeater hierarchy for the network environment, large file packages will only be moved once across slower links, but will still reach multiple target systems. IBM Tivoli Software Distribution can be set up to distribute IBM Tivoli Storage Manager software packages, such as the backup-archive client or data protection for applications clients. The distribution can include sending the files to the client, automatically running the installation script, and performing post-installation customization. 18.2.4 IBM Tivoli Inventory One of the challenges in a network computing environment is keeping track of the hardware and software installed on each machine. IBM Tivoli Inventory addresses this problem by providing the means to gather hardware and software information related to each system then storing that information in a relational database. Queries and reports can be run to display the information in this database. IBM Tivoli Inventory has three major benefits: It is based on the IBM Tivoli Systems Management Framework, so it can be integrated tightly and automatically with other IBM Tivoli applications. It stores inventory information in an RDBMS and, therefore, allows any non-tivoli applications that can access SQL data to share the inventory information. Moreover, it benefits from the advanced features of an RDBMS system, such as scalability and performance. IBM Tivoli Inventory has close links with other applications, such as IBM Tivoli Software Distribution and IBM Tivoli Service Desk. IBM Tivoli Inventory is extremely flexible and powerful. Some of the ways it can be used to provide integration with IBM Tivoli Storage Manager include: Hardware scan so that the specific installed hardware configuration of each IBM Tivoli Storage Manager server (and clients if required) can be scanned, collected, and later queried or reported. Software scan so that the specific installed software configuration of each IBM Tivoli Storage Manager server (and clients if required) can be scanned, collected, and later queried or reported. Configuration files scan so that critical IBM Tivoli Storage Manager configuration files can be collected and saved. This provides the ability to 296 IBM Tivoli Storage Management Concepts

restore such files outside of IBM Tivoli Storage Manager, which is useful, for example, if an options file has been deleted. In this case, an IBM Tivoli Storage Manager restore could not be performed because it requires that option file to be able to start. 18.2.5 The IBM Tivoli Enterprise Console product The IBM Tivoli Enterprise Console product is a management-automation application that collects information from many sources (Tivoli applications, Tivoli partners, network management platforms, relational database systems, customer applications, and heterogeneous operating systems). The product s grouping and filtering capabilities reduce the number of events displayed to the operations staff. IBM Tivoli Enterprise Console event adapters capture and filter messages and then forward them as events to the IBM Tivoli Enterprise Console console. Events are defined by using the Basic Recorder of Objects in C (BAROC) language. For many companies, the computing enterprise is becoming more heterogeneous in nature, supporting a wider variety of operating system platforms, communications methods, applications, and databases. Many computing enterprises are also becoming more distributed both from a client/server and a geographical perspective. It follows, therefore, that the computing enterprise is becoming increasingly more demanding to manage and control, and it is getting more difficult to attain acceptable levels of availability. Availability of computing resources may be directly related to the bottom line of a company as well as to its competitiveness within the industry. The people who create and develop the variety of resources that make up a computing environment give the resources the ability to provide status information through the creation and transmission of alarms, messages, alerts, traps, and so on. These may be created in large quantities and may flow through the network expressing significant or insignificant changes in the status of those resources. It is up to the system support teams and operations staff to sort through the potentially large quantity of messages in order to respond appropriately to a given situation. To issue these problems, the IBM Tivoli Enterprise Console product provides a centralized point of integration and control for enterprise client/server environments. It enables administrators to monitor information about the environments for which they are responsible. The IBM Tivoli Enterprise Console product assists in maintaining high availability of the myriad networks, systems, applications, and databases found within an Chapter 18. IBM Tivoli Enterprise solutions 297

enterprise. It helps detect potential problems before they cause outages and may be configured to take action and intervene when problems are detected. This product can prevent administrators from being flooded with unnecessary data that masks the real problems. For instance, it can perform automatic actions or filter out duplicate messages. By maintaining a comprehensive history of reported conditions, the IBM Tivoli Enterprise Console product can note only serious problems that happen in a particular time frame or in the context of other previously received events. Though IBM Tivoli Distributed Monitoring is also capable of monitoring system resources and activities and can respond to events, the IBM Tivoli Enterprise Console product is more powerful in that it can understand that events reported from different sources are related, it can maintain an event history, and it gives administrators more power and flexibility to respond to events. The scope of events that it can monitor is also broader. However, most environments use both the IBM Tivoli Enterprise Console product and IBM Tivoli Distributed Monitoring, which is best suited for local and synchronous monitoring, while the IBM Tivoli Enterprise Console product is best for asynchronous monitoring. Complex and persistent or unresolved problems within distributed monitoring can be forwarded to the enterprise console for further analysis. For more information, refer to: http://www-3.ibm.com/software/tivoli/products/enterprise-console/ IBM Tivoli Enterprise Console event adapter Event adapters are small daemon processes that detect that something worth reporting has happened, format the information in a way that is understandable to the IBM Tivoli Enterprise Console product, and send the event to the IBM Tivoli Enterprise Console event server for processing. An event adapter usually resides on the machine where the resource it is monitoring resides. Event adapters are application programs that: Detect events of interest Format the events according to the BAROC definition Send the formatted event instances to the IBM Tivoli Enterprise Console event server An event adapter has two alternatives for sending Tivoli Enterprise Console events. A secure connection makes use of the Object Request Broker (ORB) technology within the Tivoli framework. This method requires that both the originating system and the Tivoli Enterprise Console are Tivoli-managed nodes. The second method is a direct TCP/IP socket connection. This is called an unsecure connection by Tivoli, because the originating system does not have to 298 IBM Tivoli Storage Management Concepts

be a managed node. To be a Tivoli-managed node, a system must be running additional IBM Tivoli software (the oserv daemon). IBM Tivoli Storage Manager event adapter As described in 17.4.2, Client and server event reporting on page 282, IBM Tivoli Storage Manager client and server events can be logged to a variety of internal and external interfaces, called event receivers. The IBM Tivoli Enterprise Console is one of these possible receivers. IBM Tivoli Storage Manager has included a Tivoli Enterprise Console event adapter as a standard component. This means that the server can send its messages directly to a Tivoli Enterprise Console console if one is available. The Tivoli Storage Manager event adapter uses the unsecure connection method (socket connection) as it provides greater flexibility, supports all Tivoli Storage Manager server operating system platforms, and obviates the requirement that the server must be a Tivoli-managed node. Messages originating from the Data Protection modules can also be forwarded to the Tivoli Enterprise Console server. Separate series of numbers are used to identify the messages coming from these sources. The event adapter for Tivoli Storage Manager is installed by default during server installation. It includes an event definition file called IBMTSM.BAROC that must be imported into a new or existing rulebase on the Tivoli server. The rulebase must be activated, then an event source and an event group defined. Then, the Tivoli Storage Manager server must be configured so that it knows the address and port used by the Tivoli server. Finally, logging must be set to start and events selected to send to Tivoli Enterprise Console. By default, no events will be sent, therefore the administrator can use filtering and selection commands to determine which events should go to Tivoli Enterprise Console. A detailed description of how to set up IBM Tivoli Enterprise Console event logging is found in the appropriate IBM Tivoli Storage Manager administrator s guide. 18.2.6 Data Protection applications Data Protection components enable data in certain databases or applications to be backed up directly to an IBM Tivoli Storage Manager server by using the appropriate module to interface directly with the IBM Tivoli Storage Manager API. Without Data Protection components, when data is backed up from the database, the format of this data may have to be converted into files before backup; also, the database may be have to be taken offline first to get a consistent backup. By using these Data Protection modules in conjunction with the Tivoli Storage Manager API, the underlying physical structure of the database (raw devices or files) is handled by the database or application itself. This means that the database or application controls what objects need to be backed up and how to Chapter 18. IBM Tivoli Enterprise solutions 299

extract them, so it does not matter whether raw devices or files are used. Also, the type of backup (for example, online, offline, incremental, or table space) is determined and controlled by the application. Data protection modules are available for Oracle, SAP R/3, SQL Server, Informix, Domino, and Exchange and are discussed in more detail from an IBM Tivoli Storage Manager perspective in other chapters. 300 IBM Tivoli Storage Management Concepts

Part 5 Part 5 Complementary products In this part we introduce products complementary to IBM Tivoli Storage Manager. Though not part of Tivoli Storage Manager, these IBM and non-ibm products are certified as Ready for IBM Tivoli, and they can assist with managing and controling a total storage environment. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 301

302 IBM Tivoli Storage Management Concepts

19 Chapter 19. IBM Tivoli Storage Manager for Databases This chapter discusses integrating database backup strategies with IBM Tivoli Storage Manager for Databases and the different types of database backups. An overview of relational databases also is provided, and the fundamental structure of a database, such as tables, table spaces, data files, control files, parameter files, and configuration files, is described. Specific data storage considerations for UNIX-oriented systems, such as using raw devices or file system files, are covered. Techniques for online and offline backup are discussed. Non-relational database management system products are not discussed specifically, but many of the concepts are also applicable. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 303

19.1 Relational databases The early 1980s opened the door for the relational database management system (RDBMS). Since then, these have become so popular that they are used by most line-of-business applications being implemented today. Some people predict that in the beginning of this century, object databases will supersede relational databases, but whether or not this prediction turns out to be accurate is of no immediate importance to those of us who must back up the data used by today s applications. RDBMSs share a common set of principles and, conceptually, similar logical and physical structures. Figure 19-1 shows their fundamental structure: tables, table spaces, log files, and control files. Note that although all RDBMS products are based on the same set of principles, they do not all use the same terminology or structures. For example, a table space in Informix is called a dbspace, and there is no table space concept in Sybase or Microsoft SQL Server. Log files in Oracle are called redo logs, while in Sybase they are called transaction logs. It is important to understand the basic RDBMS structures so that you can put an effective backup and recovery strategy in place. You must back up more than the database itself to ensure a successful recovery. tables tables database table spaces control files Figure 19-1 Fundamental structure of a database log files 304 IBM Tivoli Storage Management Concepts

19.1.1 Tables 19.1.2 Table spaces An RDBMS holds its data in the form of two-dimensional tables (also referred to as relations). These two-dimensional tables are easy for users to understand and manipulate. They also enable different users and applications to view and process the same data in different ways without requiring complex structures. Table spaces are logical concepts that many RDBMSs use. When a user creates tables in an RDBMS that supports table spaces, the tables are created within a table space. Table spaces provide a convenient way of separating the user s view of data from some of the practical considerations associated with storing that data on disk. In many UNIX environments, table spaces can be implemented using either files or raw devices. A table space provides the link between the logical view of a database that the user sees and the data files that the database uses to hold the data. 19.1.3 Log files Most RDBMSs maintain details of updates to databases in log files. If, for some reason, a transaction that makes a change to the database fails to complete successfully, the RDBMS recovery procedure will use the log file to detect that an update may be only partially complete and to undo any changes that the transaction made to the database. RDBMSs use log files to record the changes made to databases. Log files often can be used to maintain database consistency in the event of an error or failure. Different RDBMS suppliers use different terms for log files. Some RDBMSs support the use of log files to perform forward recovery (also called roll-forward recovery). Forward recovery takes advantage of the fact that log files hold details of all changes that have been made to the database, so you do not necessarily have to undo changes, but instead can reapply them. Log files can be used for forward recovery for both online and offline backup techniques. RDBMSs have very complex schemes to manage log files, which we have somewhat oversimplified here. RDBMSs typically have multiple sets of log files to ensure the proper recording of database transactions. Most RDBMSs have a set of online log files as well as offline (or archived) log files. Online log files are used to record the current database transaction activity, and at some point in time when the online logs become full, they become offline logs and are moved to another location. Typically, backup applications back up the offline log files. Chapter 19. IBM Tivoli Storage Manager for Databases 305

19.1.4 Control files Each RDBMS holds information about the physical structure of the database, such as which physical files are used by each table space and which is the current log file. We call this information control data. Some RDBMSs (for example, Oracle) hold this data in separate files. Others (such as Informix and Sybase) hold it within the database itself. We use the term control files to refer to files that hold control data. For those RDBMSs that hold control data in separate files, you need to define policies for backing up and restoring those files. 19.1.5 Initialization parameter and configuration files All RDBMSs provide a range of options. Some are set permanently, and others can be modified even when a database is in use (running). Some options enable you to tune the performance of the database; others enable you to specify how you want, say, logging to be implemented. It is often more convenient to specify the options that you require when you start up the database. Most RDBMSs allow you to specify (at database startup time) a file that contains a list of how you want these options set initially. We call these files initialization parameter files. Sometimes these are abbreviated as initialization files or parameter files. Installations may have multiple databases, and these databases may have multiple initialization parameter files. One reason for having multiple initialization parameter files for a single database is to optimize performance for different circumstances. For example, you may decide to allocate one set of values when the database is used for batch processing and another set when it is used for online transactions. Although some of the options are set differently for each situation, many will be the same. Some RDBMSs allow you to specify options that are common to multiple initialization parameter files in configuration files. Instead of repeating all options and their values in each of the initialization parameter files, you can select the configuration file that contains the options that you want to use. You must define policies for backing up and restoring both initialization parameter files and configuration files. 19.1.6 Backup techniques There are several techniques you can use to back up data managed by an RDBMS. These techniques are, at least at a conceptual level, common to most RDBMSs. A combination of the following techniques may be used: Disk mirroring Database export 306 IBM Tivoli Storage Management Concepts

Offline backup Online backup Full database backup Partial database backup Log file backup Incremental backup LAN-free backup Backup using split mirror features Backup of RDBMS supporting files Figure 19-2 and Figure 19-3 on page 308 describe several of the techniques; all are covered in the text that follows. Disk mirroring disk 1 RDBMS disk 2 Database export file Availability feature Useful for media failures Doubles disk space Designed for moving data Operates on logical objects Offline backup backup DB Online backup backup DB Shut down database "Almost-offline" mode Backup window critical Database is in use Log files record changes Figure 19-2 Backup techniques to be considered Chapter 19. IBM Tivoli Storage Manager for Databases 307

Full database backup Back up of entire database Some DBs provide "true" incremental backup Most DBs support online and offline DB Partial database backup table space Subset of full database Must ensure logical unit of recovery Must ensure consistent with database Log file backup Back up DB changes only Useful if large units of recovery Used with online backups "Simulated" incremental backup Figure 19-3 Other backup techniques Disk mirroring Disk mirroring is a useful technique for maximizing the availability of your database as it enables users to continue working when a media failure has occurred. Mirroring, which can be implemented in either software or hardware, is the process of writing the same data to multiple storage devices at the same time. This is done either sequentially, when data is only written to the mirror after the master write is successful, or in parallel when both master and mirror writes occur at the same time. The first method is slower but you are more likely to have at least one good copy of the data if a failure occurs. However, it does not obviate the need to back up databases. For example, disk mirroring will not enable you to restore a table that has been lost or damaged as result of user error. Also, although it dramatically reduces the impact of media failures, there is still a risk of damage to both sides of the mirror. If a database is held on one set of physical volumes, and a mirror image of the same database is maintained on a separate set of physical volumes, it is possible for both sets of physical volumes to be damaged or destroyed. This could happen as a result of a disaster or it could just be bad luck. In such instances, it will be necessary to recover the database from backup copies. Another backup technique related to disk mirroring has recently gained popularity: breaking a disk mirror. This technique breaks the synchronization of one of the disk mirrors and makes a backup copy from that broken mirror. The database is still online and available to users with the remaining mirror or mirrors. 308 IBM Tivoli Storage Management Concepts

We call this technique simulated online because the backup is not really an online backup; the backup is taken from a nonfunctional broken mirror, not a running database. There are several disadvantages to this technique. The backups and restores are being done without the database backup utilities and therefore are always full backups. Ensuring that all necessary data is included in the backups as well as figuring out what is needed for the database restore and recovery are the responsibility of the administrator; it is not an automated procedure, and therefore it is more error prone and requires a higher skill level. In addition, the database is not online to users while the mirror is being broken; a quiesce of the file system and application is required before breaking the mirror. The time to resynchronize the broken mirror with the database after the backup can also be quite extensive; some customers with large database systems have estimated that it would take more than 24 hours to resynchronize the mirrors, which would not be acceptable in a daily backup strategy. Customers considering the mirror-breaking approach for database backup typically do not have sufficient spare CPU cycles to run online database backups, so they are trying to offload some CPU cycles to the storage subsystem. Serious consideration should be given to solving the CPU constraint instead of using the mirror-breaking technique because of the disadvantages we have discussed. When reading from a mirrored logical volume, AIX will read from either the master or the mirror, whichever is the quickest at the time. If a media failure occurs, operations are automatically switched to the good copy and AIX marks the faulty copy as stale. Oracle provides multiplexing of redo logfiles and control files, and allows for multiple destinations of archive log files. It is recommended to use this feature as an alternative to mirroring these files. Database export All RDBMSs provide export and import utilities, which operate on logical objects as opposed to physical objects. For example, you can use an export command to copy an individual table to a file system file. You might want to restore the table at some later time, in which case you would use the import command. Export and import are not designed as backup and restore utilities, but instead for moving data for workload balancing or migration, for example. Export and import are often not integrated with the database s logging capability, so it is up to you to institute the proper procedures to ensure database consistency. However, because export is usually the only utility that can access individual tables, you may have to use it if you have a requirement for keeping, say, the last 30 days of each table. Most other utilities operate on the physical Chapter 19. IBM Tivoli Storage Manager for Databases 309

data files that RDBMSs use to store their databases. Therefore, other utilities cannot normally be used to back up and restore a single table because: A single physical data file may contain data belonging to several tables. The data contained in a single table may be spread across multiple data files. Thus, the only way to gain access to the set of data contained in a single table is through the RDBMS itself. Export utilities are usually slower than most other utilities and should be used only when you need access to database objects or raw devices. Offline backup Offline backup involves shutting down the database before you start the backup and restarting the database after the backup is complete. Offline backups are relatively simple to administer; however, they suffer from the obvious but significant disadvantage that neither users nor batch processes can access the database (read or write operations) while the backup is taking place. You must schedule sufficient time to perform the backup to ensure that the periods when the database will be unavailable are acceptable to your users. Most databases do not require that you perform offline backups if you perform online backups; online backups (along with the log files) are sufficient to recover the database. Some RDBMSs provide a single-user mode (or quiesced mode). You can think of this as an almost-offline mode. A database administrator can still use the database, but general users cannot. With some RDBMSs, general users can stay connected to the database but they cannot use it. (Their transactions are queued.) Backup time is reduced with almost-offline mode because a full shutdown and restart of the database is not required. Online backup Most RDBMSs enable backups to be performed while the database is started and in use. Clearly, if a database is being backed-up while users are updating it, it is likely that the backed up data will be inconsistent. The RDBMSs that support online backup use log files during the recovery process to recover the database to a fully consistent state. This approach requires that you retain the RDBMS log files and indicate to the RDBMS when you are about to start the backup and when you have completed it. Some RDBMSs enable you to quiesce activity on portions of the database (for example, a particular table space) so that a set of complete tables is temporarily frozen in a consistent state. You then can back up the set of tables that has been frozen. Once the backup is complete, you can reactivate the table space. 310 IBM Tivoli Storage Management Concepts

Full database backup Full database backups involve making copies of all of the data files used to hold user data. In some database products, full database backups also include copies of the data files that hold tables used by the RDBMS itself, RDBMS log files, and any control files and parameter files that the RDBMS uses. Many RDBMSs allow you to perform full database backups whether the database is online or offline. However, the technique for full database backup when the database is online can be quite different from offline. To perform offline backup, you can use the operating system utilities, RDBMS utilities, or IBM Tivoli Storage Manager to back up the data files that constitute the database. To perform online backup, you need to use an RDBMS utility to create data files containing a copy of the database. You can then use IBM Tivoli Storage Manager to back up these data files along with the parameter files that you use to start the RDBMS. The simplest approach to database backup is to perform only full, offline backups at regular intervals. This approach is relatively easy to administer, and recovery is relatively straightforward. However, it may not be practical to take databases offline for the period of time that is necessary to perform full backups at the frequency you need. You may have to adopt a more flexible approach. Some database products provide incremental backup, which only backs up changed database pages or blocks. This type of incremental backup is called a true incremental backup, as opposed to a simulated incremental backup (described below as log file backup). Understanding what incremental backup means for a database is critical, so we will explore that in more detail later. Partial database backup Many RDBMSs allow partial database backups when the database is online or offline. Partial database backups involve backing up a subset of the full database (such as a table space or data files that make up a table space). It is often not the best approach to back up only a subset of a database, because you must ensure that what you back up represents a complete logical unit of recovery from the point of view of the application. Otherwise, you may introduce inconsistencies into the database upon recovery. Be sure that the subset you back up (as part of a partial backup) represents a complete logical unit of recovery from the point of view of the application. You also must ensure that the unit of recovery is consistent from the point of view of the RDBMS. If you have added a new data file to a table space, you must ensure that any control file that the RDBMS uses to define the relationship between data files and table spaces is also backed up. You may need to back up data files that the RDBMS does not manage. Chapter 19. IBM Tivoli Storage Manager for Databases 311

Log file backup For some applications, the units of recovery are too large to be backed up on a daily basis (for example, performing a full daily backup). Sometimes the constraining factor is the elapsed time that is available (the backup window). Sometimes the load that the backup would place on the network would have an unacceptable impact on other processes and users. In such situations it may be possible to capture only the changes to the database by backing up the RDBMS log files. This type of backup is sometimes referred to as an incremental backup (because you are not performing a full daily backup), but it is really a simulated incremental backup, as opposed to a true incremental backup. A true incremental backup backs up changed database blocks or pages, whereas a simulated incremental backup backs up the database transactions. Recovery from a simulated incremental can be much longer than from a true incremental because you must reapply all of the transactions in the logs. This is how to recover from a log file or simulated incremental backup: 1. Restore the database from a full database backup (in some circumstances, restoring from a partial backup may be sufficient). 2. Restore the log files. 3. Apply the log files to the restored database (forward recovery). Incremental backup Some RDBMSs provide for backing up data that has changed since the last offline or online database backup. This saves tape or disk space, but might not reduce the backup duration because the RDBMS still has to read each data block to determine whether it has changed since the last backup. When recovery is needed, the database backup and incremental backups are required to fully recover the database. Incremental backups are useful for saving space or for saving bandwidth when backing up over the network. LAN-free backup Normally, a database backup has to go over the LAN to the storage destination and may affect the users or applications using the same LAN. One way to overcome this problem is to use a dedicated LAN for backup so that the data transfer will no longer interfere with the work of other users and applications. However, all of the data and metadata must still be handled by the application that will receive the backup data. This application will need resources such as CPU, memory, or disk space to buffer and manage data and metadata. To free the application from the work needed for handling the backup data itself, a LAN-free solution can be used. 312 IBM Tivoli Storage Management Concepts

LAN-free means that a group of machines can share the same storage devices over a high-performance connection. LAN-free provides an easy way to define storage devices to machines without much cabling effort, as the devices all communicate over the same connection. In our context, LAN-free can be used as follows: The clients can send their backup data files directly to the tape library (LAN-free) and only send the metadata information about where the file resides to the storage application. Backup using split mirror features A backup may potentially degrade the performance of a production system. In a 24x7 environment or with very large databases, it is particularly hard to schedule a backup that will not interfere with the normal operation. To free the production system from the overhead of backup, it is valuable to have a copy or mirror of the database for backup, reporting, or other purposes. Some intelligent storage servers, such as IBM ESS, support the split mirror feature. Split mirror means that identical and independent copies of disk volumes can be established within those storage servers. Normally these copies can be established in a very short time (five to 20 seconds, depending on the vendor). If the database resides on a storage server that supports the split mirror feature, a copy of the disk volumes can be established and assigned to another (backup) machine. On the backup machine, the (backup) database can be accessed exclusively for backup or other purposes. One important requirement is that the data on the disk volumes is consistent during the creation of the copy volumes. One way to establish this is to shut down the database and synchronize all of the data that may reside in the memory of the operating system to disk. After the split mirror is established the database can be started again. If the database cannot be stopped, then the database itself must provide features to ensure that the data on the disk will be in a consistent state when establishing the split mirror volumes. Backup of RDBMS supporting files Most RDBMSs require certain files to operate but do not back them up when using their backup utilities. These files can be initialization parameter files, password files, files that define the environment, or network configuration files. They are external files and are not part of the database because they must be accessible for reading or editing even when the database is down. For example, the password file provides authentication in order to administer a database, especially for starting up a database from a remote site. Chapter 19. IBM Tivoli Storage Manager for Databases 313

You must ensure that these files are also backed up using operating system tools or third-party tools such as IBM Tivoli Storage Manager. 19.1.7 Restore techniques As we have discussed, most RDBMSs provide full and partial online backups. Certain types of restores often can be made while the database is online, as well. Many RDBMSs allow you to restore parts of the database while the rest of the database is online and in use. Typically, these partial online restores are for user data, not system data. You cannot restore an entire database while it is online. It is important to distinguish between restoring a database and recovering a database. Restoring a database means bringing back from your backup system repository the files that make up the database. You do not necessarily have an operational database to use at this point. Recovering a database means bringing the restored database to the point of being fully operational, which may, for example, entail restoring log files and performing forward recovery. 19.1.8 Which backup and recovery technique should you use? Traditionally, customers have used a full daily backup technique for their database backups. Between the daily backups, the log files are also backed up to ensure recoverability until the most recent point in time. The advantage of full daily backups is simplicity and the possibility of a faster recovery (as compared to true incremental and simulated incremental recoveries). To recover a database (say, to the most recent point in time), you would restore the last full backup and any logs backed up since, then run forward recovery to apply those log files. The significant disadvantage of full daily backups is that they take more time. Most RDBMS data is needlessly backed-up every day even though it has not changed; in typical RDBMS environments less than 15 percent of data changes daily. Simulated incremental backups are faster than full backups because only the log files are backed up daily. Full backups are performed periodically, perhaps once per week, depending on the activity level in the database and your recovery window requirements. The significant disadvantage of this approach is slower recoveries. Performing forward recovery on the database basically means rerunning all of the transactions in the logs that is, all of your database activity since the full backup. Forward recovery is a serial process that is totally dependent on the RDBMS. There is nothing that IBM Tivoli Storage Manager can do to speed up this part of the recovery process. True incremental backup is the best approach if your database has a typical change rate. If your database changes less than 20 to 30 percent daily (remember that typical databases change less than 15 percent daily), then it is a good candidate for true incremental backups. The first time you run an 314 IBM Tivoli Storage Management Concepts

incremental backup, a full backup is performed. With subsequent backups, only changed database pages or blocks are backed up. RDBMS tools that provide true incremental backup typically offer a variety of incremental backup levels so that you can choose to perform, say, an incremental backup that captures all changes from the last full backup, or all changes from the previous lower-level backup. Keep in mind that true incremental backups for databases use the traditional incremental paradigm, full backups plus incrementals, so periodic full backups (perhaps weekly) are required. The IBM Tivoli Storage Manager paradigm of progressive incremental does not apply to database incremental backups (except for Tivoli Data Protection for Lotus Notes). You would also still back up the log files that are created between backups, but only the last log file would be required for recovery if you are recovering your database to the most recent point in time. 19.1.9 Exploiting IBM Tivoli Storage Manager for Databases Four combination techniques can be used to back up databases with IBM Tivoli Storage Manager, as shown in Figure 19-4 on page 316. These techniques involve combinations of the operating system utilities, the RDBMS utilities, and Tivoli Storage Manager. The best technique is (4), because it combines the power of database-aware utilities and the superior storage management capabilities of Tivoli Storage Manager. However, if technique (4) is not available for your database or platform, techniques (1), (2), and (3) are alternatives. Chapter 19. IBM Tivoli Storage Manager for Databases 315

Raw Devices (1) IBM Tivoli Storage Manager Image Utility Storage Pools (2) Files/Raw Devices RDMS Utility file IBM Tivoli Storage Manager Command Storage Pools Files (3) IBM Tivoli Storage Manager Command Storage Pools (4) Files/Raw Devices RDMS Utility IBM Tivoli Data Protection IBM Tivoli Storage Manager API Storage Pools Figure 19-4 Techniques for using Tivoli Storage Manager to back up databases Technique (1) applies to databases installed on raw devices. If the database or application has not been enhanced to use the IBM Tivoli Storage Manager API as in technique (4), then the image utility in IBM Tivoli Storage Manager can be used to back up the raw devices directly. This is similar to using the UNIX dump device (dd) command to back up the entire contents of the raw device, but has the advantage of having the IBM Tivoli Storage Manager to manage the backups as well as all of the storage space and devices. Technique (1) has the obvious disadvantage of requiring the database to be offline during backup for consistency. Technique (2) applies to databases installed on files as well as raw devices. You may choose to use an RDBMS utility where available to back up the data to files, and then use IBM Tivoli Storage Manager to back up those created files. By using an RDBMS utility to back up the data to files, there is no need to take the database offline. This allows the database to be available during the backup. This is a better alternative because it offers all of the RDBMS utility functionality, which can include online, incremental, and partial backups. This technique requires enough disk space to be available for the intermediate file. If the RDBMS utilities provide backup at a granular level, such as by table space, you might be able to 316 IBM Tivoli Storage Management Concepts

reduce the amount of additional disk space you would need for the files at any one time. You might also be able to send the output to a remotely mounted file system that has more space available than your local database server. Remember that when you restore the data that has been backed up by IBM Tivoli Storage Manager, you will need sufficient disk space to hold the files. Technique (3) applies to databases installed on files. With this technique, you use IBM Tivoli Storage Manager commands to directly back up the files that make up the database and logs. The advantage of this approach is that no intermediate files are created as in (2) but the database must be offline to ensure a consistent backup copy. IBM Tivoli Storage Manager has no knowledge about the type of files and the data within the files, so we cannot ensure a consistent online backup if you just use IBM Tivoli Storage Manager commands directly. One exception to this is with Oracle, which provides a special utility that allows external tools (such as IBM Tivoli Storage Manager) to perform consistent, online backups directly. Technique (4) applies to databases installed on either raw devices or files. If the application or database product has been enhanced to use Data Protection (alternatively using SQL-Backtrack utilizing IBM Tivoli Storage Manager API), the underlying physical structure of the database (raw devices or files) is handled by the application, so it does not matter whether raw devices or files are used. Also, the type of backup (online, offline, incremental, table space) is determined and controlled by the application. Technique (4) is the best approach, so it is available for all major databases. However, it may not be available for all platforms or database release levels. 19.2 Planning considerations Planning is one of the most important areas for consideration before beginning to use IBM Tivoli Storage Manager for database backups. It is important that the database administrator and the IBM Tivoli Storage Manager administrator work together to anticipate the circumstances in which recovery will be required, as well as the resource and configuration requirements. These ideas apply to all types of databases. This section includes details of some possible data recovery situations. We also cover the factors that should be weighed against one another in planning for recovery, such as type of database, backup windows, and the relative speed of the backup and recovery methods discussed in 19.1.6, Backup techniques on page 306 and 19.1.9, Exploiting IBM Tivoli Storage Manager for Databases on page 315. Chapter 19. IBM Tivoli Storage Manager for Databases 317

19.2.1 Backup requirements A backup strategy is only one part of your overall data management plan; you also must consider how important your data is to your organization. The less time that your organization can function without its data, the more crucial it is that your system is designed to keep important data available when a failure occurs. Reliance on backups may not be enough. You should also consider the following: Redundant Arrays of Inexpensive Disks (RAID) devices Dual access paths Dual I/O controllers Dual power supplies Backup or standby processors Uninterruptable power supplies None of these on their own can guarantee the availability of your data but in combination they can reduce the impact of a failure. Before you design a backup strategy, you should define the requirements that the strategy must satisfy. These are some factors to be considered: 19.2.2 Types of events Types of events (the categories of incidents that may occur) Speed of recovery (how quickly you need to be able to recover) Backup windows (the periods of time at which backups can be performed) Recovery points (to which points in time you need to be able to recover) Units of recovery (which tables and files must be recovered to the same point) We identify five categories of events that may require data recovery: User error Statement failure Transaction failure Media failure Disaster User error There is considerable opportunity for a user to make an error that causes data to be lost. For example, a user might inadvertently delete or update rows in a table or accidentally drop an entire table, or a programmer might make a logic error that results in data loss or corruption. RDBMSs provide facilities that reduce the risk or impact of user errors. For example, you can use RDBMS security to restrict the data that individual users can access or update. However, it is not possible to eliminate the risk entirely, so consider how to handle such situations. 318 IBM Tivoli Storage Management Concepts

One approach is to say that it is the user s responsibility to recover from such errors. This approach may not be acceptable to users or their management, however. Another approach is to restore the entire database to the point in time at which the last backup was taken. This may not be satisfactory to other users who will lose the updates that they have made to the database since the last backup. A third approach is to restore the table space that contains the damaged table. This approach is likely to be more acceptable than the other two because: It removes the responsibility for data recovery from the users. It may affect fewer users. The number of users it affects depends partly on the number of tables included in the affected table space. You may, however, need to be able to restore individual tables, in which case you must have backed up the tables individually. Statement failure SQL statements that are syntactically correct may fail (for example, because the database is full). RDBMSs will usually detect such problems, roll back the effects of the failing statement, and report the problem to the user. When the fundamental cause of the problem has been resolved, the user can retry the statement and continue to work. Normally, there is no need to take any special action to recover from SQL statement failures. Transaction failure Transactions may fail for a variety of reasons: Programming errors Network failures Failures of the operating system or RDBMS Power failures The actions required to recover from these situations vary according to the particular circumstances. However, the RDBMS will ensure that the integrity of the data it manages is preserved. You do not need to restore data to recover from transaction failures. Media failure RDBMSs normally use magnetic disk as the medium on which they store the data that they manage. If a disk volume is physically damaged or destroyed, at a minimum you have to restore the data files that have been lost to the state they were in when they were last backed up. Chapter 19. IBM Tivoli Storage Manager for Databases 319

Disaster recovery Many organizations have developed plans for recovery from disasters such as floods, fires, accidents, earthquakes, and terrorist attacks. Ensure that your strategy for backing up and recovering data fits in with any such plans. For example, you might arrange for backups to be made to a removable medium and stored off-site. Disaster recovery is too broad a subject to address in this book and will not be discussed in any more detail. Almost all RDBMSs provide the facilities necessary to bring databases up to date by applying log files. They also provide the facilities necessary to undo changes made by partially completed transactions. This means that designers of database backup and recovery solutions do not have to concern themselves with recovering database data after statement failures or transaction failures. For each type of event that may occur, designers of a database backup and recovery solution must: Ensure that operational procedures specify who needs to do what, in order to recover from loss or corruption of data used by the RDBMS. 19.2.3 Speed of recovery Ensure that the data files that the RDBMS recovery routines use are available when needed. Ensure that any data that the RDBMS does not manage can be recovered to a state that is consistent with the database. Ask users how quickly they would like to be able to recover lost data, and they usually answer immediately. In practice, however, recovery takes time. The actual time taken depends on a number of factors, some of which are beyond your control (for example, hardware may have to be repaired or replaced). Nevertheless, you can control certain things that will help to ensure acceptable recovery time: Develop a strategy that strikes the right balance between the cost of backup and the speed of recovery. Document the procedures necessary to recover from the loss of different groups or types of data files. Estimate the time required to execute these procedures (and do not forget the time involved in identifying the problem and the solution). Set user expectations realistically for example, by publishing service levels that you are confident you can achieve. 320 IBM Tivoli Storage Management Concepts

19.2.4 Backup windows Some RDBMSs do not allow databases to be backed up while they are in use. In such cases, you have to shut down the database before the backup starts, and you cannot restart the database until after the backup has completed. Shutting down a database often means that users cannot use applications. You must ensure that the times at which databases are shut down and unavailable are acceptable to your users. Even if you can perform backups while the database is operational, you should ensure that any load on processors or networks caused by the backup process does not result in performance or responses that are unacceptable to your users. 19.2.5 Recovery points You should define the points in time to which you will restore data. For example, you may need to recover the data to the state it was in when the last transaction was completed. Alternatively, it may be acceptable to restore the data to a consistent state that is no more than 24 hours old. In addition to either of these, you may be required to restore individual tables to the state they were in at any particular date within the past 30 days. Whatever your situation, consider recovery points and define a policy that is both achievable and acceptable to your user community. 19.2.6 Units of recovery In some circumstances, it may not be sufficient to restore individual tables (or even entire databases) to the state they were in at some point in the past. Sometimes, in order to maintain data consistency, you may have to restore data held in tables or files that have not been lost or damaged. This undamaged data must be restored to the same point in time as the damaged data. In developing your backup strategy, you should understand the relationships between the data objects on which user applications rely. Many applications rely on relationships that extend beyond the data held in a single database. For example, an engineering database application holds references to documents that exist as independent file system files. If the engineering database is lost and restored to the point in time at which the last backup was taken, references to documents may be lost. Alternatively, the medium on which some of the documents are stored may be damaged. If the data files used to hold the documents are restored to the point in time at which the last backup was taken, the engineering database may contain references to documents that do not exist. Chapter 19. IBM Tivoli Storage Manager for Databases 321

There are many other situations in which you must ensure that data consistency is preserved. The key point is that your backup and recovery strategy must take into account the needs of the applications that use the data. 19.3 DB2 data protection DB2 information management software is a high-performance, open-platform relational database product from IBM. With more than one million server licenses worldwide, DB2 software powers the world s e-business solutions by offering open, industrial-strength database management for business intelligence, transaction processing, and a broad range of applications. This section focuses mainly on DB2 running in a distributed environment; that is, UNIX, OS/2, and Windows NT. It does not include DB2 for AS/400, MVS, VM, or VSE. The IBM Tivoli Storage Manager backup-archive client is designed to back up and restore, archive and retrieve client file system data. The client therefore can back up any non-database and database files. Tivoli Storage Manager clients use standard operating system functions to access files within file systems, but they do not understand a logical structure that might exist within a file. This affects how DB2 and other database systems are backed up. Each database appears as an individual file on the server or client file systems that is backed up and restored in its entirety. A Tivoli Storage Manager backup-archive client running on a DB2 server or client can back up, restore, archive, and retrieve entire DB2 databases, but it cannot back up smaller increments. Other than the issues of size and replication, using a Tivoli Storage Manager backup-archive client to back up DB2 databases is straightforward. If a database is deleted or corrupted, it is a simple task to restore the most recent or any previous backup version of this database from the Tivoli Storage Manager server to the DB2 server or client. The Tivoli Storage Manager backup-archive client, however, does not meet all requirements for an ideal storage management solution in a DB2 environment. Some drawbacks to its use are: For a database that changes every day, the client will back up the full database even if only one document has changed. This strategy wastes a lot of time and storage space. Many databases need to operate 24x7 so a consistent backup cannot be taken because they are in use all the time. The alternative is to quiesce the DB2 database and take backups, but this would result in server unavailability, which is not good for business. 322 IBM Tivoli Storage Management Concepts

19.3.1 IBM Tivoli Storage Manager API To overcome these restrictions of the backup-archive client, DB2 uses the IBM Tivoli Storage Manager API code to facilitate database backup. DB2 provides its own backup utility that allows backup at the table space level as well as on a full database. The backup utility can be set up to use Tivoli Storage Manager as the backup media, as you will see later. Therefore, the two client types work together to provide full data protection for the DB2 environment. The API client and the Tivoli Storage Manager backup-archive client can run simultaneously on the same DB2 server; however, they are totally separate clients as far as the Tivoli Storage Manager server is concerned. 19.3.2 DB2 UDB DB2 Universal Database (UDB), also known as DB2 Version 6, provides significant enhancements over DB2 Version 2. DB2 UDB enhanced parallelism DB2 UDB provides more parallelism in the backup/restore process. Multiple processes or threads can now read data from the database in parallel. Multiple table spaces can be written in parallel during restore. DB2 UDB enhanced recovery and restart DB2 UDB also provides additional recovery options, including table space point-in-time recovery and restoration of a subset of table spaces from any backup image. A faster restart, which reduces your total down time during a full restore, is also a capability of DB2 UDB. DB2 parallel database DB2 parallel database architecture was initially implemented in DB2 Parallel Edition but is now superseded by DB2 UDB Extended Enterprise Edition. Parallel database technology has been under development at the IBM Almaden Research Center and elsewhere in IBM for several years. A parallel database must push the envelope on performance and capacity; therefore it must fully leverage the capabilities of the underlying hardware, operating system, and computing environment. DB2 Parallel Edition and DB2 UDB Extended Enterprise Edition exploit a shared-nothing architecture, as shown in Figure 25-1 on page 340: Shared-Nothing Parallel Database Architecture, where each node has its own processor, memory, and disk, and effectively nothing is shared. A shared-nothing architecture has the best scalability, because most of the processing is done independently on each node, with minimal interaction among nodes. Chapter 19. IBM Tivoli Storage Manager for Databases 323

Query Execution Query Execution Query Execution Buffer Management Buffer Management Buffer Management Lock Management Lock Management Lock Management Logging and Recovery Logging and Recovery Logging and Recovery Log Data Log Data Log Data Node 1 Node 2 Node 3 Figure 19-5 Shared-nothing parallel architecture Each node in a DB2 parallel database system supports a subset of the overall database. For a given user request, data access, buffer management, locking, logging, and other processing is done, where possible, independently on each node in parallel. The database appears to the application user as a single database on a single system. A DB2 parallel database exploits the IBM Power Parallel SP. However, it is in no way tied to or dependent on the hardware platform. A DB2 parallel database can run as multiple instances on a RISC System/6000 uniprocessor as a means of doing parallel I/O. On an SMP model of a RISC System/6000, multiple DB2 instances can be used to leverage all processors in the single machine. A DB2 parallel database can also run on separate RISC System/6000 machines that are connected on a LAN. Different RISC System/6000 models can be used, including high-availability HACMP configurations. DB2 Parallel Edition is based on DB2 Version 1 and therefore has the same level of backup/restore utilities: full online and offline backup. DB2 UDB Extended Enterprise Edition provides all of the rich DB2 UDB backup and recovery functions, including table space backups, advanced parallelism, and a fuller set of recovery options. 324 IBM Tivoli Storage Management Concepts

DB2 also provides an export/import utility to move data. This utility can be used as a supplement to your backup strategy, but it is not a replacement for the backup utility. There is a risk of introducing inconsistencies into your database because no synchronization of data with logs is performed. However, if you need to capture individual tables, export may be required because the backup utility only provides either full database or table-space-level granularity. 19.3.3 Integration with IBM Tivoli Storage Manager As shown in Figure 25-2, the DB2 backup utilities (but not export/import) are fully integrated with IBM Tivoli Storage Manager services because the DB2 utilities use the Tivoli Storage Manager API. This means that an intermediate file is not created during the backup operation before storing the database image on one or more Tivoli Storage Manager servers. Both online and offline backups can be performed with Tivoli Storage Manager, and DB2 data is automatically restored by using the DB2 restore utility. Tivoli Storage Manager can also archive DB2 log files. DB2 provides a user exit program for backing up and restoring its log files directly to Tivoli Storage Manager. Log files are moved to the DB2 user exit program when they become inactive. The logs are also automatically retrieved from Tivoli Storage Manager for roll-forward recovery. DB2 database when inactive DB2 backup User Exit IBM Tivoli Storage Manager API IBM Tivoli Storage Manager backup IBM Tivoli Storage Manager backup IBM Tivoli Storage Manager server Log files Figure 19-6 IBM Tivoli Storage Manager interface with DB2 19.4 Data Protection for Informix The Data Protection for Informix component of IBM Tivoli Storage Manager enables you to back up and restore Informix server database and logical logs to and from the Tivoli Storage Manager. Informix uses its ON-Bar utility to manage its backups. Chapter 19. IBM Tivoli Storage Manager for Databases 325

19.4.1 Informix online backup utilities Before we discuss specific backup utilities, it is important to understand a critical difference in terminology between the Informix OnLine utilities and the storage manager (Tivoli Storage Manager). When data files are sent from Informix OnLine to Tivoli Storage Manager, all data is, by default, stored in backup copy groups regardless of the utility used to initiate backup. From the perspective of a Tivoli Storage Manager administrator, this data is considered backup data, not archive data. An archive (in Informix OnLine terminology) backs up all of the data that the database server manages, which includes all dbspaces. The archive is written on a tape or to a file and includes all used disk pages. It does not include configuration files, so you have to back them up separately. Archiving is rather sophisticated in that it provides for true incremental archives so you do not have to archive the entire database each time. Three archive levels are provided: Level-0 is the baseline archive, because all used pages are archived Level-1, all changes since the last level-0 archive Level-2, all changes since the last level-1 archive You build a schedule for incremental archives that fits the needs of your environment. For example, you can perform level-0 archives monthly, level-1 archives weekly, and level-2 archives daily, or you can build a more frequent schedule. Level-1 and level-2 backups are cumulative since the previous level backup. Given how Informix OnLine handles incremental backups, we recommend that you carefully consider the Tivoli Storage Manager copygroup options, particularly those that determine the number of data versions that exist, retention periods for extra data versions, and copy mode. The main Informix OnLine Version 5.0 backup utility is tbtape. In Informix OnLine Version 6.0 tbtape is replaced by ontape, which contains enhancements over tbtape. Informix OnLine Version 6.0 also provides a new backup utility called ON-Archive which includes further enhancements over ontape. We also look at the new Informix OnLine Version 7.21, 8.0, and 9.0 utility, ON-Bar. ON-Bar replaces the functions of ON-Archive and ontape and provides an interface to a storage manager application,such as Data Protection for Informix. You can use other Informix OnLine utilities for backup purposes, but they are actually data migration utilities and not a substitute for tbtape, ontape, ON-Archive, or ON-Bar. The onunload (or tbunload in Informix OnLine Version 5.0) and dbexport utilities are not coordinated with the information stored in logical log files, and they do not save a copy of system overhead information, which is important to Informix OnLine. 326 IBM Tivoli Storage Management Concepts

19.4.2 The tbtape utility The main backup utility for Informix OnLine Version 5.0 is tbtape. It is used to back up logical logs (including continuous backups), change the database logging status, create and archive, and restore data. Continuous logical log backups automatically back up each logical log as it becomes full. Database logging is the process of writing the transactions to the log files. Different types of logging are supported, such as buffered and unbuffered. The tbtape utility is used to turn database logging on and off, and to change the type of logging used. A tbtape archive (in Informix OnLine terminology) backs up all of the data managed by the database server, which includes all dbspaces. This is called a whole system archive. This archive is written on a tape or to a file and includes all used disk pages. The archive does not include configuration files, so you must back them up separately. The tbtape archive is performed when the database is in online or quiescent mode. Quiescent mode can be thought of as an almost-offline or single-user administrative mode. The tbtape restore is performed when the database is in offline mode. 19.4.3 The ontape utility 19.4.4 ON-Archive One of the main backup utilities in Informix OnLine Version 6.0 is ontape. It is similar to tbtape, but provides some significant enhancements. With ontape you can restore specific dbspaces, and the restore can be either warm or cold. Warm restore means that Informix OnLine can be online, and cold restore means that Informix OnLine must be offline. Warm restores can be done for noncritical dbspaces, that is, any dbspace other than the root dbspace and the dbspaces that contain the physical and logical logs. Note that the backup operation is still done in online or quiescent modes and still includes all dbspaces. Only the restore has changed to allow specific dbspaces and online mode. Another difference between ontape and tbtape is that with ontape you no longer can use the Informix OnLine onmonitor utility to create the archive. You can only execute the ontape utility from the command line. ON-Archive is a powerful new utility for Informix OnLine Version 6.0. It provides the function of ontape, but adds significant enhancements including: Archive of dbspace sets (named collectives of one or more dbspaces) Archive and restore of different dbspaces in parallel It provides online and quiescent mode backup and online and offline restore for one or more dbspaces in parallel. You group one or more dbspaces into dbspace Chapter 19. IBM Tivoli Storage Manager for Databases 327

sets, and ON-Archive works against these dbspace sets. The output produced by ontape and ON-Archive is incompatible. You cannot back up data with ontape and restore it with ON-Archive (or vice versa). 19.4.5 ON-Bar ON-Bar (Backup and Restore), new to the Informix OnLine product line in Versions 7.21 and later, enhances the backup and restore facilities. ON-Bar replaces ON-Archive and ontape and provides the following enhancements: It simplifies backup and restore procedures compared to ON-Archive. Note that ON-Bar refers to a backup as a backup, not an archive, whereas ON-Archive refers to a backup as an archive. It allows for warm backup and restore of dbspaces. It enables automatic logical log backup through an ALARMPROGRAM variable that calls a custom-made script. It provides automation and management facilities to reduce operator intervention. It supports SMP, XMP, and distributed data environments. ON-Bar is designed to support the X/Open Backup Services API (XBSA). Therefore, any storage manager product that supports this standard works with ON-Bar. The term storage manager is used here to denote any type of storage management tool, for example, Tivoli Storage Manager. Therefore, ON-Bar backups can be sent directly to Tivoli Storage Manager through the API; no intermediate file is created. 19.4.6 Components The IBM Tivoli Storage Manager interface to ON-Bar consists of the following components as illustrated in Figure 27-1: the ON-Bar program, the X/OPEN Backup Services Application Programmer s Interface (XBSA), the storage manager (using Data Protection for Informix), and the ON-Bar catalog tables, message file, and emergency boot file. 328 IBM Tivoli Storage Management Concepts

Informix database ON-Bar commands ON-Bar XBSA Data Protection for Informix Db spaces And Logical Logs Catalog tables Message file Emergency boot file IBM Tivoli Storage Manager Server Figure 19-7 Data Protection for Informix integration with Informix ON-Bar program The ON-Bar program receives requests to perform backups and restores and passes them to Informix OnLine or the storage manager. Users can initiate requests either manually, by issuing a command line request to the ON-Bar program from the client machine where the Informix OnLine database is stored, or automatically, by using the IBM Tivoli Storage Manager s scheduler to invoke ON-Bar backup or restore. The ON-Bar utility itself does not provide an independent GUI. IBM Tivoli Storage Manager IBM Tivoli Storage Manager, which is used here as the storage manager, handles the actual data storage and media. It may also provide additional capabilities, such as the ability to: Schedule administrative tasks Support a distributed environment Enable data compression and decompression XBSA ON-Bar and IBM Tivoli Storage Manager communicate with each other through Data Protection for Informix. ON-Bar uses XBSA to exchange backup, restore, and control data with Tivoli Storage Manager via Data Protection for Informix. Chapter 19. IBM Tivoli Storage Manager for Databases 329

Catalog tables The ON-Bar catalog tables, stored in the sysutils database, track compatibility of component versions and contain details about dbobjects. There are five tables that contain version and backup information: The bar_server table tracks instances of the OnLine Dynamic Server. The bar_object table tracks backup objects. The bar_action table tracks all backup and restore attempts against each backup object. The bar_instance table describes each object that is backed up during a successful backup attempt. The bar_version table lists compatible versions of ON-Bar, storage managers, and XBSA. The Informix OnLine Dynamic Server Backup and Restore Guide documents the field contents for each of these tables in more detail. Message file The ON-Bar message file contains information about ON-Bar progress as it executes. The file also provides time stamps on various operations that are useful when you are trying to determine how much time the backups will require to complete so that you can develop IBM Tivoli Storage Manager schedules. Emergency boot file The ON-Bar emergency boot file contains enough information to cold-restore an online server instance. The boot file is no longer just for critical dbspaces. It is used instead of the sysutils tables during a cold restore of the database. 19.5 Data Protection for Oracle This section describes online back up of Oracle databases in two ways: using the IBM Tivoli Storage Manager backup-archive client, and via the application client Data Protection for Oracle, which can back up Oracle databases online or offline. Data Protection for Oracle from IBM Tivoli provides an integrated solution for performing full backup of Oracle online databases and full restore to the original or a different location. Data Protection for Oracle complements the Oracle backup utilities by handling all of the communications to Tivoli Storage Manager, thus letting Tivoli Storage Manager manage the backup to storage devices. 330 IBM Tivoli Storage Management Concepts

Note: Data Protection application clients are not intended as a substitute for the standard IBM Tivoli Storage Manager backup-archive client. Data Protection cannot be used to back up or restore any non-database data, such as history files or other system configuration files. Those files must be backed up by the Tivoli Storage Manager backup-archive client. The Data Protection for Oracle application client and the Tivoli Storage Manager backup-archive client work together to provide full data protection for the Oracle environment. The two client types can run simultaneously on the same Oracle server; however, they are totally separate clients as far as the Tivoli Storage Manager server is concerned. 19.5.1 IBM Tivoli Storage Manager and Oracle Customer-written scripts using Oracle alter table space begin and end backup commands together with the IBM Tivoli Storage Manager backup-archive client. Two alternatives for online backup of Oracle databases with Tivoli Storage Manager are discussed in this section: Oracle Enterprise Backup Utility (EBU) or Oracle Recovery Manager (RMAN) with Data Protection for Oracle. Customer-written scripts using Oracle alter table space begin backup and alter table space end backup commands together with the Tivoli Storage Manager backup-archive client. Each is a viable alternative, but they differ in functionality, ease of use, and platform coverage. You could also shut down the Oracle database and use the Tivoli Storage Manager backup-archive client to back up the files containing the database table spaces. However, this is not an online backup and will not be discussed further here. 19.5.2 Backup using Data Protection for Oracle Data Protection for Oracle supports Oracle Version 7 databases with EBU and Oracle Version 8 databases with RMAN. The EBU and RMAN utilities are provided by Oracle for performing online and offline backup and restore of its databases. Note that EBU is released only with Oracle7 and RMAN is released only with Oracle8. These utilities are used by interfacing them with an external media manager (such as IBM Tivoli Storage Manager) via the library provided by Oracle. After the EBU or RMAN initiates a backup or restore, Data Protection for Oracle acts as the interface to Tivoli Storage Manager. It translates Oracle API calls into Tivoli Chapter 19. IBM Tivoli Storage Manager for Databases 331

Storage Manager API calls to the Tivoli Storage Manager server for the desired functions. This causes minimal disruption, so they can be carried out while users continue working. Data Protection for Oracle (also called the Oracle Backup Agent) works in conjunction with the Tivoli Storage Manager API client and should be installed wherever the Oracle databases are located. Data Protection for Oracle output can be sent to any Tivoli Storage Manager server. Data Protection for Oracle is available for AIX, NT (Intel platform), Windows 2000, Solaris, and HP-UX. Figure 19-1 on page 304 depicts the way Oracle7 or Oracle8 works in conjunction with Data Protection for Oracle and the Tivoli Storage Manager server. Oracle backup EBU RMAN API Data Protection for Oracle IBM Tivoli Storage Manager API Tivoli Storage Manager API calls IBM Tivoli Storage Manager server Oracle database Figure 19-8 Oracle7 and Oracle8 interfacing with IBM Tivoli Storage Manager Oracle7 and Oracle8 provide backup and restore functions for Oracle databases: full or partial, offline (called cold backup in Oracle7) or online (called hot backup in Oracle7). When you have identified which database to back up, Oracle locates all of the necessary files and sends them to Tivoli Storage Manager. Recovery is managed similarly, in that Oracle issues the appropriate commands to Tivoli Storage Manager to restore the required objects (such as tables, control files, recovery logs) and then performs the recovery. When the interface to Tivoli Storage Manager is configured, all administrative commands (such as backup and restore) take place entirely within the Oracle backup utilities via EBU or RMAN scripting controls, so the Oracle DBA does not need to know Tivoli Storage Manager commands. The Oracle DBA takes control when the backups are to be removed from IBM Tivoli Storage Manager using commands or utilities (for example, ebutool with Oracle7) within Oracle. When using Data Protection for Oracle, the DBA must be familiar with the underlying utility (that is, RMAN or EBU) and be able to create and maintain the correct scripts for backup and recovery. Data Protection for Oracle exploits the full power of these Oracle-provided utilities, as well as the detailed in-depth knowledge that Oracle has about its database structure. You can back up the Oracle logical 332 IBM Tivoli Storage Management Concepts

entities themselves (for example, individual tables) rather than the file structure and incremental database backup that is also provided with RMAN. 19.5.3 Oracle alter table space utility For many years, Oracle relied on external backup tools before providing utilities such as EBU (Oracle7) and RMAN (Oracle8). However, Oracle also provided a way for external tools to perform online backups. The Oracle alter table space begin backup command puts a table space into backup mode in such a way that an external tool can back up the table space while it is changing. Changes to the table space are also recorded in the redo log files. You can think of this command as a way for Oracle to logically freeze the table space such that the database has knowledge of where the backup begins. Roll-forward recovery provides the consistency for any updates that occur after the table space is frozen. You can write scripts for each table space, as shown in Figure 19-9, that contain an alter table space begin backup command, IBM Tivoli Storage Manager client backup commands, and an alter table space end backup command. The client backup commands would back up either the files that contain the database table spaces directly if the Oracle database is installed on file systems, or else the logical volumes, using the image backup commands if the Oracle database is installed on raw devices. Besides backing up the table spaces themselves, you also back up the archived redo log files. This operation typically is performed at regular intervals throughout the day. (1) alter table space begin backup table space (2) Oracle DBMS IBM Tivoli Storage Manager backup command (if Oracle uses file systems) IBM Tivoli Storage Manager image utility (if Oracle uses raw device) IBM Tivoli Storage Manager Oracle DBMS (3) alter table space end backup Figure 19-9 Alter table space script backup option Although using the Oracle alter table space commands is a viable online backup alternative, it has the disadvantage of being limited to full, table space, data file, Chapter 19. IBM Tivoli Storage Manager for Databases 333

and log file backups. Only simulated, not true, incremental backups are possible. Much of the responsibility of managing the backup and recovery process is still left to each customer to implement. An advantage of this alternative is that it is supported on any platform on which IBM Tivoli Storage Manager provides a backup-archive client, whereas Data Protection for Oracle is limited to selected platforms. 19.6 Data Protection for Microsoft SQL Server Data Protection for Microsoft SQL Server performs online backups of Microsoft SQL Server databases to IBM Tivoli Storage Manager storage. Data Protection for SQL supports an important Tivoli Storage Management feature: automatic expiration and version control by policy. Data Protection for SQL also supports the LAN-free environment for backups across SANs. This section is for administrators of SQL Server and Tivoli Storage Manager who need to understand the issues and considerations involved with usingtivoli Storage Manager and Data Protection to back up and restore SQL Server. 19.6.1 SQL Server overview Microsoft SQL Server is a client/server relational database management system (RDBMS) that uses Transact SQL to send requests between the client and the SQL Server. Transact SQL is a programming and query language that enables data to be accessed, queried, updated, and managed. There can be no more than one instance of SQL Server 7.0 on one machine, but SQL Server 2000 can have as many as 16 instances on a machine, and any one instance may be clustered. The default instance may be SQL 7.0 (or SQL 6.5), but a default instance is not required. SQL applications Software applications for SQL Server can be divided into three logical layers, which can reside on one or more severs: Presentation: Usually, this layer is on the client computer, and it is responsible for presenting the data and application to the users. Business: Sometimes the SQL Server is involved in this layer, which is responsible for application logic and business rules. Data: Mainly, the SQL Server is responsible for this layer. 334 IBM Tivoli Storage Management Concepts

Applications may have several designs, depending on where these layers take place: Intelligent server: Only the presentation layer is on the client, and the business logic and data are on the server; in this case the server may become a bottleneck. Intelligent client: Presentation and business are on the client, and data is on the server; in this case, the network traffic is heavy. N-tier: Presentation is on the client side, business is on the application server, and data is on the database server; with this approach, more servers may be added if needed. Internet: Clients use a browser; presentation and business are on the Web server; and data is served by SQL Server. SQL Server services There are four SQL services that run as Windows services. MSSQL Server Service: Allocates resources among users, prevents using the same data at the same time, and provides data integrity and consistency. SQL Server Agent Service: Responsible for creating and managing jobs, alerts, and operators. Microsoft Distributed Transaction Coordinator Service: Verifies that in distributed transactions all updates on all servers are permanent or cancelled (if there are errors). Microsoft Search Service: A full text engine that uses indexes to alleviate queries. SQL Server database SQL Server databases can be divided into two types: system and user. System databases store information about the system about the SQL Server itself, and about all user databases. User databases store user information. Each database, including the master database, contains a database catalog: a collection of system tables that store metadata, which is information about the data. The master database contains a collection of system tables that store information about the entire system and all other databases. After installation of the SQL Server, there are four system databases: master model tempdb msdb Chapter 19. IBM Tivoli Storage Manager for Databases 335

Additionally, there are two sample user databases: pubs northwind The master database manages the SQL Server and user databases and contains information about all databases residing on the SQL Server. The master database is very important, and it must be backed up every time you perform certain statements or system stored procedures that modify it automatically. Without a current backup of the master database, in case of failure you must completely rebuild all of the system databases. The master database can be backed up only by a full backup. The model database is a template for new user databases. If the model database is modified, then back up the database. When rebuilding the master database, preceding changes to the model database will be lost and must be restored from backup. The tempdb database is used for temporary tables and other temporary working storage needs. You cannot back up this database; it is recreated each time the SQL Server is started. The msdb database is used as storage area for scheduling information and job history. If you do not have a backup of this database, you must rebuild all of the system databases and then recreate each job, alert, or operator. The pubs and northwind databases are sample databases that can be used as learning tools. User databases contain the user s data. They must be backed up regularly, especially after an index has been created, because if you back up the transaction log, the actual data page modifications are not written to the log only the fact that the index was created is backed up and in case of restore, the index must be rebuilt. The amount of time that rebuilding the index takes may be longer than the restore from a full backup. Also, it is a good practice to back up user databases after operations that are not recorded to the transaction log. Refer to the Microsoft documentation about nonlogged operations. SQL Server also includes logs that contain SQL Server activity, and logons containing user IDs and permissions. SQL Server database structure All SQL Server databases have a primary database file (*.mdf), one or more transaction log files (*.ldf), and, optionally, secondary data files (*.ndf). 336 IBM Tivoli Storage Management Concepts

Database Data File group Data file [Data file...] [File group... Data file [Data file...]] Transaction log Log file [Log file...] named PRIMARY system/user tables, indexes user tables, indexes named by user user tables, indexes user tables, indexes Figure 19-10 SQL database physical structure Database Table Column Data stored with row Data stored separately Column Data stored wit row Data stored separately Index Index... Table... Figure 19-11 SQL database logical structure A data file has a logical name and a physical name. When the data is modified, this modification is first written to the log and the disk, and the transactions from the log are committed to the database and written to the disk on a regular basis. The transaction log records all database changes except bulk inserts. One transaction file per database is always present. Multiple log files are treated as if they were concatenated into a single file. In the case of a system failure, the system tries to replay any uncommitted transactions. Chapter 19. IBM Tivoli Storage Manager for Databases 337

19.6.2 SQL important database options SQL Server 7.0 Truncate log on checkpoint cannot do log backups. Select into/bulk copy must do a full or differential backup after bulk insert before log backups can be done. SQL Server 2000 Recovery model Simple Cannot do log backups. Bulk-logged Can do logs, but cannot do restores to a point in time. Full No restrictions. SQL Server security SQL Server uses two level of security: Login authentication: The user must have an account in order to be able to connect to the SQL Server. There are two types of login authentication: SQL Server authentication and Windows authentication. SQL Server authentication requires the user to have a SQL Server login account and password. Windows authentication revalidates the Windows account and password from Windows. The SQL Server administrator specifies which kind of authentication is used, and whether users can use only Windows authentication or if both Windows and SQL authentication are allowed. Permission validation: To gain access to the database, the user must have permissions to that database that show what kind of activity the user can perform on it. SQL Server administration There are several management tools that administrators can use to minimize and automate daily tasks: Service Manager: Can be used for starting and stopping the SQL Server. Enterprise Manager: Presents a GUI for managing SQL Server. Query Analyzer: Presents a GUI to issue Transact SQL commands. Batch utilities: These include the osql utility, used to execute batch files containing one or more transact SQL statements; and the bcp utility, mainly used to import and export data to or from a data file. Client Network Utility: Used to manage the client configuration for communications components. 338 IBM Tivoli Storage Management Concepts

19.6.3 Overview of Data Protection for SQL and LAN-free As SQL databases grow and the amount of data that requires backup increases, it may become troublesome to perform Data Protection for SQL backups across the LAN connection to the IBM Tivoli Storage Manager server. One solution to overcome the problem could be to install a Tivoli Storage Manager server locally on the SQL Server itself along with a Tivoli Storage Manager storage device. This will prevent the backup data from travelling across the LAN and decrease the backup and restore times if the LAN is the bottleneck. However, this solution adds additional hardware cost to the Tivoli Storage Manager environment and makes managing the system more cumbersome and complicated. Also, it is not wise to store backups and backup equipment at the same location as the production system itself. A better solution is to set up a SAN. SANs, using Fiber Channel Protocol (FCP), are designed for large data transfers and will outperform even high-speed LANs. Data Protection for SQL supports LAN-free backup for IBM Tivoli Storage Manager. In order to shift the data movement from the LAN to the SAN, Data Protection utilizes the IBM Tivoli Storage Manager Managed System for SAN Storage Agent, which must be installed on the client machine along with Data Protection for SQL. As seen, the main purpose is to move data from the client across the SAN instead of from the LAN to the Tivoli Storage Manager storage connected to the SAN. The placement of the data is controlled by the Tivoli Storage Manager server, and only metadata, which is just a fraction of the raw backup data, is communicated across the LAN between the Tivoli Storage Manager server and the Data Protection for SQL client. The storage agent acts as an interface to the SAN for Data Protection for SQL. Chapter 19. IBM Tivoli Storage Manager for Databases 339

Data Protection for SQL Metadata TCP/IP LAN LAN SQL Databases Backup Data Fibre Fibre IBM Tivoli Storage Manager Server SAN SAN SAN Data Gateway Figure 19-12 LAN-free backup for SQL 19.6.4 Managed System for SAN Storage Agent The Managed System for SAN Storage Agent, which runs on the client machine, supports LAN-free data transfer by enabling data transfers to the SAN. To the Data Protection for SQL client it looks nearly the same as any other Tivoli Storage Manager server. From a high-level standpoint, the Storage Agent works in the following way: 1. Data Protection for SQL invokes a backup. The client contacts the Tivoli Storage Manager server and exchanges policy information over the LAN to determine the destination of the backup data. If the client is configured to use LAN-free data movement, the destination will be a storage pool that is set up to use a device on the SAN. The device must also be mapped on the client. 2. Because the backup destination is on the SAN, the client contacts the Storage Agent by opening a named pipe session. The name of the named pipe is hardcoded in Data Protection for SQL code, and the only communication protocol supported is named pipes. 340 IBM Tivoli Storage Management Concepts

3. The Storage Agent opens a server-to-server connection to the Tivoli Storage Manager server via the LAN; the only supported communication protocol at this time is TCP/IP. 4. Data Protection for SQL sends a begin-transaction verb to the Storage Agent. When the transaction is successfully committed, the Storage Agent opens a SAN data transfer to a tape storage device. Otherwise, if the first transaction fails, the communication will be switched over to the LAN, and the SAN data transfer will not be used. 5. The LAN server-to-server communication between the Storage Agent and Tivoli Storage Manager server is used by the Storage Agent for accessing the Tivoli Storage Manager server database. That is because the Storage Agent has neither its own database nor a recovery log. (You can imagine the Storage Agent as a truncated Tivoli Storage Manager server.) 6. When the Storage Agent finishes the backup, it sends file attribute data to the Tivoli Storage Manager server, which stores the data in the database. When restoring data, the restore session is always opened through a Storage Agent. If any data was backed up through the SAN, the restore will also go through the SAN. If any data was backed up through a LAN, then the LAN connection will be used during restore. If you have backed up some data using the SAN, you can still access this data through the LAN, if needed. Some limitations and requirements apply to running Data Protection for SQL across the SAN: Only IBM Tivoli Storage Manager server Version 4.1 or higher is supported. Windows NT 4.0 service pack 6, Windows 2000 build 2195 or later is required. TCP/IP is required for the LAN communication. Currently only tape storage pools are valid backup destinations. Chapter 19. IBM Tivoli Storage Manager for Databases 341

342 IBM Tivoli Storage Management Concepts

20 Chapter 20. IBM Tivoli Storage Manager for Mail IBM Tivoli Storage Manager for Mail is a software module for IBM Tivoli Storage Manager that automates the data protection of e-mail servers running either IBM Lotus Domino or Microsoft Exchange. This module utilizes the application program interfaces (APIs) provided by e-mail application vendors to perform online hot backups without shutting down the e-mail server and improve data-restore performance. As a result, it can help protect the growing amount of new and changing data that should be securely backed up to help maintain 24x7x365 application availability. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 343

20.1 Data Protection for Lotus Domino IBM Tivoli Storage Manager provides a backup solution for a heterogeneous Domino environment, which includes the backup-archive client and the Data Protection component for Domino. Together, these provide a complete backup solution to fulfill the requirements of Domino storage management. Data Protection for Domino, a successor to Data Protection for Lotus Notes, takes advantage of significant changes in the Lotus Notes R6 server architecture. These include transaction logging for interactions with Notes databases as well as a new application program interface (API) for backup and recovery of Notes databases. Data Protection for Domino helps protect and manage Lotus Domino Release 6.x server data by making it easy to: Implement centralized, online, incremental backup of Domino databases Maintain multiple versions of Domino databases Archive Domino transaction log files, when archival logging is in effect Restore backup versions of a Domino database and apply changes made since the backup from the transaction log Restore Domino databases to a specific point in time Recover to same or different Domino server Expire database backups automatically based on version limit and retention period Expire archived transaction logs when no longer needed Obtain online context-sensitive, task, and conceptual help View online documentation for Data Protection for Domino Automate scheduled backups Recover one or more archived transaction logs independent of a database recovery Recover from the loss of the transaction log Archive the currently filling transaction log file Data Protection for Domino provides two types of database backup (incremental and selective) and a log archive function. Incremental backup has a conditional backup function that creates a full online backup of Domino databases. The specific conditions that determine when a new backup is necessary vary depending on whether the database is logged. Selective backup backs up the specified databases unconditionally unless they are excluded through exclude 344 IBM Tivoli Storage Management Concepts

statements. When archival logging is in effect, changes to logged databases can be captured between full backups by archiving the transaction log. The logical components of Data Protection for Domino are shown in Figure 20-1. Transaction Logs Domino Backups Domino API Data Protection For Lotus Domino IBM Tivoli Storage Manager API IBM Tivoli Storage Manager API Calls Domino Database IBM Tivoli Storage Manager Server Figure 20-1 Logical components of Data Protection for Domino Data Protection for Domino is available on the following platforms: Microsoft Windows NT and Windows 2000 IBM AIX Sun Solaris IBM S/390 In the following sections, we give a brief introduction to Lotus Domino Release 6 (referred to as Domino), its components, and interfaces, as well as its use as a database system. We also discuss the importance of storage management and its requirements for a backup solution. 20.1.1 Lotus Domino Release 6 Lotus Domino includes the Notes client and the Domino server for messaging, collaboration, workflow automation, and Internet and intranet applications. It comprises an advanced client/server environment, a document database, and a sophisticated messaging system. With Domino, users can work together regardless of software or hardware platform and across technical, organizational, and geographical boundaries. It enables users to communicate securely over a Chapter 20. IBM Tivoli Storage Manager for Mail 345

local area network (LAN) or through telecommunication, providing users the ability to create and access documents across any distance, at any time. Lotus Domino components and platforms Lotus Domino, which runs on a variety of operating system platforms, has two product components: Domino (server). There are three types of Domino servers: Domino R6 Mail Server: Combines full support for the latest Internet mail standards with Domino s industry-leading messaging capabilities. Domino R6 Application Server: An open, secure platform optimized to deliver collaborative Web applications that integrate enterprise systems with rapidly changing business process. Domino R6 Enterprise Server: Delivers all of the functionality of the Domino Mail and Application servers reinforced with clustering for the high availability and reliability required by mission-critical applications. The Domino server provides services such as storage and replication of shared databases and mail routing to Notes users and other Domino servers. Lotus Notes (client). There are three types of Lotus Notes clients: Lotus Notes: The interface between the user and Domino server, with all features and functionality required by the end user. Users cannot perform system administration or application development using this client. Lotus Domino Administrator: Provides a complete range of tools to make Domino system administration easy with less effort. Lotus Domino Designer : Provides a wide range of development tools for Domino application developers to use in creating and modifying Domino applications. A Lotus Notes client communicates with one or more Notes servers, providing the interface that enables a Notes user to access, administer, and develop Domino application databases. Notes databases can reside on the Domino server or on the individual Notes client. Databases that reside on the client can be accessed only by that user, and administration of these database is much simpler than administering the databases on the Domino server. Lotus Notes user interface Lotus Notes provides a new GUI designed for both intranet and Internet users. The default initial screen, the Welcome Page, can be customized for user preferences. It includes the option to use the Notes 4 GUI, for Notes Release 4 users who have upgraded and would rather work with a familiar interface. The Lotus Notes 6 Welcome Page is shown in Figure 20-2 on page 347. 346 IBM Tivoli Storage Management Concepts

Notes databases and Notes applications are synonymous terms. The Notes 6 GUI has a set of pull-down menus for working with databases and SmartIcons that provide a fast path to many everyday functions. The GUI has the same look and feel across all of the supported client platforms. Figure 20-2 Lotus Notes 6 Welcome Page Lotus Domino Administrator As with any other system, Domino requires administration, so it provides two main interfaces for administration: the Domino server console and the Lotus Domino Administrator client. When a Domino server is started, a full-screen command line console is presented in a window on its screen. The console displays the server activities, such as scheduled macros and replication. It is also the interface for administrators to perform tasks such as loading additional Notes programs, querying server statistics, and setting certain server options. A remote console function is also provided through the Domino Administrator that enables remote server administration by suitably authorized users. Lotus Domino 6 provides a special client for Domino System Administration called the Lotus Domino Administrator. This client is used for remote system administration, so all administrative operations can be performed remotely without going to the physical server. Chapter 20. IBM Tivoli Storage Manager for Mail 347

Figure 20-3 shows the Domino Administrator with the Configuration view open. Figure 20-3 Lotus Domino Administrator Although Lotus Domino Administrator on the server console is the interface for basic administration, most Domino administration is performed by using a special Notes database called the Domino Directory (which in Notes 4 was called the Name & Address database) from the Lotus Notes client. The Domino Directory database, with a file name of names.nsf, is created on every Domino server and client when the servers and clients are installed. On a Notes server, the Domino Directory is public, and it contains information about all servers and users within the network. On a Notes client, the Domino Directory database is private and contains information pertinent only to that client. A Notes domain is defined as a collection of users, servers, and groups that share a common Domino Directory within a Notes environment. On a Domino server, the Domino Directory database is probably the most powerful directory services tool and server management tool for an administrator. As a directory service tool, the Domino Directory database provides a directory 348 IBM Tivoli Storage Management Concepts

of all Notes users, servers in a domain, group names for mailing lists, and foreign domains. Servers within a domain have a common Domino Directory database that is replicated across all servers in the domain. As a server management tool, the Domino Directory database is used to control server operations. It contains instructions about how servers can communicate with other servers, and which tools or programs are run. It is the main Notes scheduling tool for operations such as establishing server-to-server connections for replication. 20.1.2 Lotus Notes data Notes data consists of both database and non-database files. A Notes database is the basic component of a Notes application. It is the repository where users create, update, store, and track documents in various formats. The document-oriented information within the files is unstructured and can contain many types of data: text, image, audio, and video. Shared databases reside on one or more Domino servers and can be accessed by multiple users. A local database is resident on a user's client and is accessible only at that client. A Notes database created on a Windows client, for example, has the same format as a database created on an OS/2 or UNIX Domino server. Therefore, Notes databases are portable among various Domino servers and clients throughout an enterprise. A Notes database is stored on a server or client as a single notes structured file with a.nsf file extension. A Notes database is a single, self-contained entity as far as the client operating system is concerned. Notes databases can become very large files, often growing to hundreds of megabytes in size. A client operating system such as AIX has no knowledge of the internal structure or contents of a Notes database. This lack of knowledge is beneficial in terms of portability but presents an interesting storage management challenge. Beside databases, Domino includes a number of other non-database files. These are normal operating system files, not Notes databases. They include initialization files, ID files, configuration files, and more. To sum up, a Domino environment is more than just the databases, and these non-database files must also be considered in the backup strategy. 20.1.3 Storage management for Lotus Notes Providing effective storage management services for a Domino system can be a demanding task. All non-database Domino data comes under your general storage management policy: regular backups need to be run against frequently updated data. The challenge with Domino, however, is the storage management of the Notes databases. Chapter 20. IBM Tivoli Storage Manager for Mail 349

Notes databases are complex logical structures, often very large, that appear to traditional storage management tools as single client files. A backup tool that operates only at operating system level will always back up the entire database. Whenever a single document is updated within a database, an incremental backup would catch the entire database, because the one document has changed the modification time stamp of the database. This could lead to an enormous amount of data and backup copies on the storage location. Notes itself provides a replication function for database backups. Replication is the process of updating databases that simultaneously reside on different servers and clients within a Domino environment. Updates to a database can be reflected on all database copies wherever they physically reside. This update works on a document level: If a database or a document within a database is accidentally deleted, it can be recovered as long as a replication database copy is available elsewhere in the Domino environment. However, replication is not a substitute for an effective backup solution. Replication will duplicate user errors throughout a Domino network. If a critical document or database is erased by accident, replication will, in time, erase that information wherever it is replicated. Another problem with most backup products is that they do not allow backup of open files. There are several files that cannot be backed up while the Domino server is running, one of which is the most crucial file, the Domino Directory database. These files will not be backed up unless you stop the Domino server first, or make periodic replica copies that can be backed up. 20.1.4 Tivoli Storage Manager backup-archive client and Domino The backup-archive client is designed to back up and restore, archive and retrieve client file system data. The client therefore can back up any non-database Notes data on both Domino server and client. Backup-archive clients use standard operating system functions to access files within file systems, but they do not understand any logical structure that might exist within a file. This limitation affects how Domino and other database systems are backed up. Each database appears as an individual NSF file in the server or client file systems. A backup-archive client running on a Domino server or client can only back up and restore entire Notes databases. It cannot back up smaller increments. Backup-archive clients can be installed wherever there are Notes databases that require backing up. However, that approach could potentially lead to large numbers of duplicate database backup copies if Notes replication is also being used. A more sensible approach is to implement backup-archive clients on Notes servers only. If possible, identify those databases on the servers that are replicas from other servers and exclude them from backup. This approach assumes that 350 IBM Tivoli Storage Management Concepts

backups of those databases have already been performed at the originating database server. Other than the issues of size and replication, using the backup-archive client to back up Notes databases is straightforward. Each database is a self-contained NSF file that is backed up and restored without any problem. The backup-archive client restores a database in its entirety because it is just a file for Tivoli Storage Manager. If a database is deleted or corrupted, it is a simple task for Tivoli Storage Manager to restore any previous backup version of this database from the Tivoli Storage Manager server to the Domino server or client. The backup-archive client, however, does not meet all requirements for an ideal storage management solution in a Notes environment, hence the need for the application agent, Data Protection for Domino. 20.1.5 The Data Protection for Lotus Domino component When archival logging is used on the Domino server, it archives the transaction log files and retrieves them as required for a database recovery. Database backups and archived transaction log files are stored on Tivoli Storage Manager storage. The Data Protection for Domino component communicates with a Tivoli Storage Manager server using the Tivoli Storage Manager application program interface (API). Data Protection for Domino communicates with a Domino server using the Domino API. The backup and recovery API in Domino 6 provides the capability to perform online full backups of individual databases and archives of the transaction log when archival logging is in effect. A transaction log captures database changes for logged databases, so full database backups are not required as frequently. Updates to a logged database are recorded in the Domino server transaction log. Changes to a database since the last full backup can be applied from the transaction log after the backup is restored from the last full backup. Data Protection for Domino cannot be used to back up or restore any other type of data, such as operating system or Domino non-database files. Those files are backed up by the Tivoli Storage Manager backup-archive client. Data Protection for Domino provides a command line interface on all platforms and a GUI on Windows NT/2000 only for performing backups and restores. Figure 20-4 on page 352 shows the Data Protection for Domino GUI interface on a Windows NT system. Chapter 20. IBM Tivoli Storage Manager for Mail 351

Figure 20-4 Data Protection for Domino GUI 20.2 Data Protection for Microsoft Exchange Server This chapter provides introductory information for the IBM Tivoli Storage Manager component Data Protection for Microsoft Exchange Server, which provides online backups of Microsoft Exchange Server databases to a Tivoli Storage Manager server. Data Protection for Exchange provides complete integration with Microsoft Exchange APIs by offering: Centralized online backups (full, copy, incremental, and differential) of Exchange Directory and Information Stores to Tivoli Storage Manager server storage Automatic expiration and version control by policy Fail-over for Microsoft Cluster Server (MSCS) Parallel backup sessions for high performance Automated transaction log file management LAN-free backup Windows GUI Data Protection for Exchange supports Microsoft Exchange Individual Mailbox Restore in combination with Tivoli Storage Manager backup-archive client and the Microsoft Exchange Mailbox Merge Program (ExMerge). 352 IBM Tivoli Storage Management Concepts

Data Protection for Exchange helps protect and manage Exchange Server data by facilitating the following: Perform full, copy, differential, and incremental backups of the Microsoft Exchange Directory and Information Store databases. Restore a full Directory or Information Store database and any number of associated transaction logs. Delete a Directory or Information Store database backup from Tivoli Storage Manager storage. Back up the Exchange Server databases to any Tivoli Storage Manager server with drag-and-drop ease. Set Tivoli Storage Manager options regarding connection information to Tivoli Storage Manager servers. Launch other Tivoli Storage Manager (and related) system applications. Automate scheduled backups. Automate deletion of old backups. Data Protection for Exchange communicates with Tivoli Storage Manager using its API, and with an Exchange Server using the Exchange API, as shown in Figure 20-5. Exchange Database Exchange Backups Exchange API Data Protection For Exchange IBM Tivoli Storage Manager API IBM Tivoli Storage Manager API Calls IBM Tivoli Storage Manager Server Figure 20-5 Overview of Data Protection for Exchange operating environment Data Protection for Exchange must be installed on the same machine as the Exchange Server. This does not have to be the same system that is running the Tivoli Storage Manager server. Data Protection for Exchange can compress Exchange data before sending it to the Tivoli Storage Manager server (which can be running on any operating system platform). Data Protection for Exchange also runs in an MSCS environment. Chapter 20. IBM Tivoli Storage Manager for Mail 353

20.2.1 Exchange Application Client functions This section gives an overview of functions the Exchange Application Client can perform, including: Backup Restore Backup delete In addition, this section identifies security requirements, performance, and backup strategy, and Microsoft Cluster Server considerations. Exchange Server database backup A backup creates a copy of an Exchange database with any associated transaction logs on Tivoli Storage Manager storage media. Data Protection for Exchange provides selection mechanisms and the logic that is required to back up and restore Exchange data. Four types of backup are provided by Data Protection for Exchange: Full backup: A full backup backs up the specified database as well as its associated transaction logs. After the database and logs are backed up, the log files are deleted. Copy backup: A copy backup is similar to a full backup except that transaction log files are not deleted after the backup. A copy backup can be used to make a full backup of the Exchange Server database without disrupting any backup procedures that use incremental or differential backups. Incremental backup: An incremental backup only backs up the transaction logs and then deletes them. Restoration of an Exchange Server database from an incremental backup requires: Restore of the last full backup Restore of any other incremental backups performed between the full backup and this incremental backup Restore of this incremental backup Differential backup: A differential backup only backs up transaction logs but does not delete them. If you perform a full backup and then perform only differential backups, the last full backup plus the latest differential backup has all data needed to bring the database back to the most recent state. This type of backup is also called a cumulative incremental backup. Restoring an Exchange Server database from a differential backup requires: Restore of the last full backup Restore of this differential backup, but no other differential backups 354 IBM Tivoli Storage Management Concepts

Note: When the Exchange Server is installed, circular logging is set as the default and is enabled for both the Directory and Information Store databases. When circular logging is enabled, you cannot use differential or incremental backups. This is because data loss could occur if the log wrapped before an incremental or differential backup is done. If you choose a backup strategy that involves incremental or differential backups, you must disable circular logging for the Exchange databases from the Exchange Administrator program. For more information about circular logging, see your Microsoft Exchange Server documentation. Exchange Server database restore A restore obtains backup copies of Exchange databases and transaction logs and returns them to the Exchange Server. To do a restore, the Exchange service and its corresponding database that is being restored must be stopped. Depending on the backup strategy, restoring an Exchange database might involve restoring multiple backup objects from the Tivoli Storage Manager server. Upon restarting the Exchange service for the restored database, the Exchange service applies the transactions in the restored transaction logs to the restored database. Exchange Server database backup delete This function enables Exchange database backup objects to be deleted from Tivoli Storage Manager storage space when they are no longer needed. This is done by selecting specific Tivoli Storage Manager stored objects to be deleted, or by specifying to delete all inactive objects older than a stated number of days. 20.2.2 Exchange Server security Standard IBM Tivoli Storage Manager security requirements apply to Data Protection for Exchange. That is, it must be registered to the Tivoli Storage Manager server and use the appropriate node name and password when connecting to the Tivoli Storage Manager server. To access the Exchange Server APIs, Data Protection for Exchange must run under the Exchange Site Services Account. The Site Services Account, the account under which the Exchange services are running, has read/write access to the local registry with backup and restore authority to the Exchange server. For more information about the Site Services Account, see your Microsoft Exchange Server documentation. Chapter 20. IBM Tivoli Storage Manager for Mail 355

20.2.3 Exchange Server backup strategy considerations Depending on your specific requirements regarding network traffic, backup window and acceptable restore times, you might choose to follow different backup strategies. Some commonly used strategies are described below: Full backups only: This approach is best for Exchange Servers that are relatively small, because it implies that the entire database is backed up each time. Each backup takes longer to perform, but the restore process is most efficient because only the most recent (or other appropriate) full backup needs to be restored. Full backup plus incremental backups: This strategy is commonly used when the normal backup window or network capacity cannot support a full backup each time. In such cases, a periodic full backup followed by a series of incremental backups enables the backup window and network traffic to be minimized during peak usage times. An example of this is a weekly full backup, done on the weekend, that is followed by daily incremental backups. The full backups can be done during low usage times when a larger backup window and increased network traffic can be tolerated. The restore process becomes more complex, however, because a full backup, as well as subsequent incremental backups, must be restored. You should also consider setting the Tivoli Storage Manager policies to ensure that all of the incremental backups are stored together (collocated). This helps improve restore performance and can reduce the number of media mounts necessary for restoring a series of incremental backups, which should result in faster restores. Full backup plus differentials: This process provides an easier restore than the full plus incremental backup. This approach might be useful if your backup window and network capacity are sufficient to handle the backup of all transaction logs that accumulates between full backups. This requires the transfer of only one differential plus the last full backup to accomplish a restore. However, the same amount of data needs to be transferred in the one differential image as in the series of incremental backups. Therefore, a full backup plus differential backup policy results in more network traffic and more Tivoli Storage Manager storage usage. This assumes that the differential backups are done with the same frequency as the incremental backups. You should carefully consider whether there is sufficient advantage to justify the additional resource necessary to resend all prior transaction logs with each subsequent differential backup. 356 IBM Tivoli Storage Management Concepts

21 Chapter 21. IBM Tivoli Storage Manager for Enterprise Resource Planning This chapter describes IBM Tivoli Storage Manager for Enterprise Resource Planning (Tivoli Storage Manager for ERP), a software module that works with IBM Tivoli Storage Manager to better protect the infrastructure and application data and improve the availability of SAP R/3 Servers. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 357

21.1 Overview Specifically designed and optimized for the SAP R/3 environment, Tivoli Storage Manager for ERP provides automated data protection, reduces the CPU performance impact of data backups and restores on the R/3 server, and greatly reduces the administrator workload necessary to meet data protection requirements. It builds on the SAP database, a set of database administration functions integrated with R/3 for database control and administration. The Tivoli Storage Manager for ERP software module enables multiple R/3 servers to utilize a single Tivoli Storage Manager server to automatically manage the backup of R/3 data. As the intelligent interface to the R/3 database, Tivoli Storage Manager for ERP is SAP certified in heterogeneous environments, supporting large-volume data backups, data recovery, data cloning, and disaster recovery of multiple SAP R/3 servers. IBM Tivoli Storage Manager for Enterprise Resource Planning offers the following features: The Data Protection for R/3 component can handle large amounts of data reliably to minimize downtimes and operational cost and flexibly adapt to changing requirements in a dynamic system infrastructure. Unlike other offerings that merely provide an interface to a generic storage management tool, Data Protection for R/3 is specifically designed and optimized for the R/3 environment, delivering business value by focusing on automated operation, built-in productivity aids, optimum performance, and investment protection. Multiple management classes provide a library structure for sets of device parameters. Multiple path/session support provides one path or session per tape device, thus maximizing backup and restore performance. Multiple server operations enable multiple Tivoli Storage Manager servers to be used in parallel for backup and restore, eliminating capacity bottlenecks. Multiplexing merges multiple data streams into one data stream, thereby exploiting the full write bandwidth of storage devices and minimizing backup window times. Multiple log files store log files in two management classes, providing additional security through redundancy of log files. SAN support and integration enables the use of SAN fiber channels with high bandwidth, freeing up the LAN. Centralized management with administration assistant enables policies and processes to be managed from a central point, thus achieving consistent backup and recovery of critical data, even in lights out operations. 358 IBM Tivoli Storage Management Concepts

Policy controlled file migration across storage hierarchies uses the most cost-effective storage media based on retention periods and resource usage, thus decreasing the cost of ownership. Support for Flash Copy and split mirror technology creates an additional disk for backup purposes, leaving R/3 applications and performance unaffected during the backup. Standby servers can be switched to within seconds during a failure, thus achieving 100 percent availability of R/3 applications. Adaptive file sequencing sorts and sequences files to be backed up according to the overall situation of the path and session load, thereby optimizing resource usage and decreasing total backup and restore times. SNMP traps enable communication with other applications, making control of the data management system available for other applications. 21.2 SAP SAP (Systeme, Applikationen und Produkte in der Informationsverarbeitung), founded in 1972 by five former IBM employees in Germany, is one of the world s largest software companies providing packaged commercial applications. It now has 28 subsidiaries and affiliates in all of the major industrialized countries of Europe, North America, Asia, and Africa, and it supports more than 3500 customers in 36 countries worldwide. IBM and SAP formed an alliance in July 1983 by signing an international agreement that covers mutual cooperation in development, marketing, sales, and support of customer business solutions. SAP R/3 is an integrated client/server package covering accounting, human resources, logistics, and production planning. R/3 also provides an application development environment. As shown in Figure 21-1 on page 360, a typical SAP R/3 system consists of three tiers: database servers, applications servers, and presentation clients. Chapter 21. IBM Tivoli Storage Manager for Enterprise Resource Planning 359

Database Servers Application Servers Presentation Clients Fast Backbone Connection LAN/WAN Connection Figure 21-1 SAP R/3 components 21.2.1 Online backup for all major databases In a SAP R/3 configuration a single application server can reside on the same machine as the database server, or a dedicated database server and one or more application servers can run on separate machines. In the second case, the servers are connected through a fast LAN or a high-performance switch. The end user is connected to SAP R/3 through a presentation front-end with a GUI, the presentation client, typically a PC or X-terminal. The presentation client uses SAP R/3 transactions to send requests to the application server. The application server reads data from local memory (buffered data) or initiates database requests to the database server, which represents the highest level in the server hierarchy. Typically an application server is dedicated to a group of users, such as a department. The SAP R/3 software, certain application development programs, and user data are stored on the database server. SAP has chosen a centralized database concept because it is easier to maintain. SAP R/3 runs on platforms such as AIX, HP TRU64, HP-UX, SNI, Solaris, OS/390, Windows NT, and AS/400 systems. The following database products are supported in an SAP R/3 environment, although not all databases are available for all platforms: DB2 Oracle Informix ADABAS-D Microsoft SQL Server DB2/400 Consult SAP marketing for more information about specific availability. 360 IBM Tivoli Storage Management Concepts

21.2.2 Methods of backing up R/3 databases There are several methods of backing up databases in an SAP R/3 environment, but SAP typically supports and certifies only specific methods, which are a subset of all possible methods: For DB2, the database utilities (which use the Tivoli Storage Manager API) are supported. For Informix, the ONTape, ON-Archive, and ON-Bar utilities are supported. The ON-Bar utility uses an X/OPEN API. Data Protection for Informix provides an X/OPEN API to the Tivoli Storage Manager server via the ON-Bar utility. For ADABAS-D, the ADABAS-D backup utilities are supported. An external interface to storage management products is provided through ADINT, which interfaces directly with the Tivoli Storage Manager API. It is available as a service offering. For Microsoft SQL Server, the Microsoft backup/restore functions are supported. IBM Tivoli Storage Manager provides an interface to these functions with the Data Protection for Microsoft SQL Server component. For Oracle, SAP provides their own Oracle backup utilities, BRBACKUP and BRARCHIVE through the SAP DBA interface. They also provide an interface. BACKINT to external storage manager products. The application client Data Protection for R/3 uses the BACKINT interface to connect the R/3 backup utilities to Tivoli Storage Manager. Figure 21-2 on page 362 shows the flow that BACKINT uses for backing up Oracle databases when integrated with Tivoli Storage Manager. IBM offers another SAP-related product, ARCHINT/TSM, that interfaces to SAP archiving functions (for any SAP R/3 database). ARCHINT/TSM is available as a service offering. ARCHINT/TSM allows data from a SAP archive function to be stored and managed by one or more Tivoli Storage Manager servers. Chapter 21. IBM Tivoli Storage Manager for Enterprise Resource Planning 361

Oracle Database Messages BRBackup SAP/R3 API Data Protection For ERP PRO Data Protection For ERP Agent IBM Tivoli Storage Manager API IBM Tivoli Storage Manager Server Object List Figure 21-2 SAP logical flow of BACKINT operation Table 21-1 summarizes the backup alternatives for all supported databases in an SAP R/3 environment. Table 21-1 SAP R/3 backup alternatives with IBM Tivoli Storage Manager Database Database implementation Database mode Intermediate file created Supported backup alternative Platforms supported Oracle OPS File system Raw device Offline Online No BACKINT using TDP for R/3/ AIX, HP-UX, Tru64, RedHat Linux, NT, Solaris, Windows 2000 Informix - Online Raw device Offline Online No Ontape, ON-Archive ON-Bar using DP for Informix AIX, Solaris DB2 File system Raw device Offline Online No DB2 backup using Tivoli Storage Manager API AIX, HP, NT, SINIX, Solaris 362 IBM Tivoli Storage Management Concepts

Database Database implementation Database mode Intermediate file created Supported backup alternative Platforms supported MS SQL Server File system Offline Online No DP for SQL Server NT ADABAS-D Raw device Offline Online No ADINT/Tivoli Storage Manager AIX, NT, Solaris 21.2.3 Data Protection for SAP R/3 Data Protection for R/3 lets you manage backup storage and processing independently from normal SAP R/3 operations. It uses the SAP BACKINT interface to back up and restore an SAP R/3 Oracle database. It enables system administrators to follow SAP procedures and use the integrated SAP utilities for backup and restore. These utilities are SAPDBA, BRBACKUP, BRARCHIVE, and BRRESTORE. Other SAP files can be backed up using standard Tivoli Storage Manager techniques for file backup and restore. Data Protection for R/3 uses the Tivoli Storage Manager API client to communicate between SAP R/3 and the Tivoli Storage Manager server. It has two main modules: Data Protection for SAP R/3 PRO: This module deals with the BACKINT interface. It: Receives and sends commands and messages with lists of database objects over the BACKINT interface. Reads and interprets the parameters that are specified in the profile. Sets up the proper environment and controls the AGENTs. Data Protection for SAP R/3 AGENT: This module deals with (and contains calls to) the Tivoli Storage Manager API client. It : Reads and writes database objects from and to disk (backup/restore). Transfers data to and from the Tivoli Storage Manager API client, which in turn connects with the Tivoli Storage Manager servers. These components communicate with an internal protocol and can execute on different CPUs, allowing parallel backup of multiple nodes of a parallel database. Alternate IBM Tivoli Storage Manager servers For disaster recovery or performance reasons, backup/restore can be routed to more than one Tivoli Storage Manager server. For example, you could store a Chapter 21. IBM Tivoli Storage Manager for Enterprise Resource Planning 363

disaster recovery backup on a remote Tivoli Storage Manager server system at specified intervals. You can increase throughput by defining multiple backup servers. When you define multiple backup servers, Data Protection for R/3 transfers database objects among several Tivoli Storage Manager servers simultaneously. Performance enhancements Data Protection for R/3 has these performance enhancements: Multithreading code using large internal buffers. This allows SMP exploitation. Fast null block compression: designed and typically used for database files because they usually contain large portions of null blocks. Multiplexing: multiplexes several files into a joint data stream allowing for performance optimization depending on the hardware environment and compressibility of the data files. User-adjustable block size for reading from disk. User-adjustable block size for sending data to Tivoli Storage Manager. 21.2.4 BACKINT File Manager BACKINT File Manager is an add-on utility of Data Protection for R/3. It simplifies the Data Protection for R/3 inquire, restore, and delete operations. The BACKINT File Manager user interface consists of a text window that displays all backup IDs found on all Tivoli Storage Manager servers along with all files that belong to a particular backup ID. You can select individual backup IDs or multiple files to restore or delete. 21.2.5 Administration tools The Administration Tools for Data Protection for R/3 are an extra-charge optional product. They provide a browser interface to three main tools: System Configuration Tool lets you customize the SAP backup profile, the Data Protection for SAP R/3 profile, and all necessary IBM Tivoli Storage Manager files. The Performance Monitor displays Data Protection for R/3 performance information while Data Protection for R/3 is performing a backup or restore operation. You can also display saved performance statistics even when Data Protection for R/3 is not active. The Operations Monitor provides a centralized overview of backup status information for all SAP R/3 systems registered with the central Administration 364 IBM Tivoli Storage Management Concepts

Tools server. The overview panel shows summaries of the backup status of an SAP R/3 system and the state of each current backup. Chapter 21. IBM Tivoli Storage Manager for Enterprise Resource Planning 365

366 IBM Tivoli Storage Management Concepts

22 Chapter 22. IBM Tivoli Storage Manager for Applications This section describes IBM Tivoli Storage Manager for Application Servers (formerly Tivoli Data Protection for WebSphere Application Server), a software module that works with IBM Tivoli Storage Manager to better protect the infrastructure and application data and improve the availability of WebSphere Application Servers. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 367

22.1 Overview of WebSphere Application Server A base WebSphere Application Server Version 5 configuration includes only the application server process. There is no node agent or Deployment Manager involved in this configuration. No coordination between application server processes is supported in the base configuration, with each application server instance having to be separately administered. Figure 22-1 shows an overview of the runtime architecture in a base installation. Node Application Server Web browser client HTTP server WebSphere plug-in Web container Embedded HTTP server Web Services engine Config repository (XML files) Admin UI Client container Java client EJB container Admin application application (EAR) Admin service Application Database JCA container Scripting client Name Server (JNDI) Security server Integral JMS Server Figure 22-1 IBM WebSphere Application Server components Node A node is a logical grouping of WebSphere managed server processes that share common configuration and operational control. In the base configuration, each application server is responsible for its own configuration in the configuration repository. 368 IBM Tivoli Storage Management Concepts

Configuration repository The configuration repository holds copies of all of the individual component configuration documents. Unlike previous versions of WebSphere Application Server, which used a relational database to hold configuration information, in Version 5 all configuration information is stored in XML files. The application server's admin service takes care of the configuration and makes sure it is consistent during the runtime. Application server The application server is the primary component of WebSphere. It runs in a Java virtual machine (JVM), providing the runtime environment for the application's code. The application server provides containers that specialize in enabling the execution of specific Java application components. There are three containers in the application servers: Web container EJB container J2C container Web browser clients connect to the Web container through the HTTP server and Web server plug-in to access the dynamic content. Stand-alone Java applications, either J2EE application clients or thin Java clients, connect to the EJB container to access EJBs and invoke methods through RMI/IIOP. Web container components can use EJB resources within the application logic. Application servers can access a shared database for storing data. The Application Server provides other services besides the containers: Object Request Broker (ORB) Name service (JNDI) Security service (JAAS and Java 2 security) Admin service (JMX) Trace service Performance Monitoring Interface (PMI) Transaction management Messaging interfaces (JMS) E-mail interfaces (JavaMail) Database connection (JDBC) and connection pooling Web server and Web server plug-in The WebSphere Application Server works with a Web server to handle requests for dynamic content from Web applications. The Web server and application server communicate using the Web server plug-in. Chapter 22. IBM Tivoli Storage Manager for Applications 369

The Web server plug-in uses an easy-to-read XML configuration file to determine whether a request should be handled by the Web server or the application server. It uses the standard HTTP protocol to communicate with the application server, but can also be configured to use secure HTTPS, if required. Embedded HTTP server A key feature of IBM WebSphere Application Server is the embedded HTTP server within the application server. This Web server is very useful for testing or development purposes but should not be used in production environments. For performance and security reasons, use a Web server and Web server plug-in for the Web server in a production environment. Virtual hosts A virtual host is a configuration enabling a single host machine to resemble multiple host machines. It enables a single physical machine to support several independently configured and administered applications. It is not associated with a particular node. It is a configuration, rather than a live object, which is why it can be created, but not started or stopped. Each virtual host has a logical name and a list of one or more DNS aliases by which it is known. A DNS alias is the TCP/IP host name and port number used to request the servlet, for example yourhostname:80. Common aliases are the machine s IP address, short host name, and fully qualified host name. The alias comprises the first part of the path for accessing a resource such as a servlet. When a servlet request is made, the server name and port number entered into the browser are compared to a list of all known aliases in an effort to locate the correct virtual host and serve the servlet. If no match is found, an HTTP 404 error is returned to the browser. Virtual hosts allow the administrator to isolate, and independently manage, multiple sets of resources on the same physical machine. Web container The Web container processes servlets, JSP files, and other types of server-side includes. Each Web container automatically contains a single session manager. When handling servlets, the Web container creates a request object and a response object, then invokes the servlet service method. The Web container invokes the servlet s destroy method when appropriate and unloads the servlet, after which the JVM performs garbage collection. The Web container runs an embedded HTTP server for handling HTTP(S) requests from external Web server plug-ins or Web browsers. 370 IBM Tivoli Storage Management Concepts

A Web container configuration provides information about the application server component that handles servlet requests forwarded by the Web server. Each application server runtime has one logical Web container, which can be modified but not created or removed. The administrator specifies Web container properties including: Default virtual host Session management properties Number and type of connections between the Web server and the Web container Port(s) on which the Web container listens for incoming HTTP(S) requests EJB container The EJB container provides all of the runtime services needed to deploy and manage Enterprise Java Beans (EJBs). It is a server process that handles requests for both session and entity beans. The enterprise beans (inside EJB modules) installed in an application server do not communicate directly with the server; instead, the EJB container provides an interface between the EJBs and the server. Together, the container and the server provide the bean runtime environment. The container provides many low-level services, including threading and transaction support. From an administrative viewpoint, the container manages data storage and retrieval for the contained beans. A single container can host more than one EJB JAR file. JCA container The Java Connector Architecture (JCA) container is a component provided by WebSphere Application Server that can be plugged into, configured, and used by JCA Resource Adapters from EIS vendors. Client application container The client application container is a separately installed component on the client s machine. It enables the client to run applications in an EJB-compatible J2EE environment. A command-line executable (launchclient) is used to launch the client application along with its client container runtime. Web administrative console and application The Web-based administration interface is installed as a standard J2EE 1.3 compliant Web application called adminconsole. The administrator connects to the application using a Web browser client. Users assigned to different Chapter 22. IBM Tivoli Storage Manager for Applications 371

administration roles can manage the application server and certain components and services using this interface. In the base configuration, the adminconsole application runs on the application server and can manage only that application server. In the Network Deployment configuration, it is installed and run on the Deployment Manager only (by default). Admin service The Admin service runs within each server JVM. In the base configuration, the Admin service runs in the application server. In the Network Deployment configuration, each of the following servers hosts an Admin service: Deployment Manager Node agent Application server JMS server The Admin service provides the necessary functions to manipulate configuration data for the server and its components. The configuration is stored in a repository; a set of XML files is stored in the server s file system. Note: Application servers are attached to nodes, and nodes belong to a cell in the Network Deployment environment. In this environment the Deployment Manager is responsible for managing all of the application servers in the cell, which means that the administrator has access to multiple application servers under one user interface through the Deployment Manager. The Admin service running in a particular server is only responsible for that server. Admin services has a course-grained security control and filtering functionality, providing different levels of administration to certain users or groups using the following admin roles: Administrator Monitor Configurator Operator Scripting client The scripting client wsadmin provides extra flexibility over the Web-based administration application, enabling administration using the command-line interface. Using the scripting client not only makes administration quicker, but 372 IBM Tivoli Storage Management Concepts

helps automate the administration of multiple application servers and nodes using scripts. The scripting client uses the Bean Scripting Framework (BSF), which enables a variety of scripting languages to be used for configuration and control. JMS server The embedded WebSphere JMS provider uses a JMS server to implement the integrated messaging functions. It supports point-to-point and publish/subscribe styles of messaging and is integrated with the transaction management service. The JMS server is used for: Support of message-driven beans Messaging within a WebSphere cell In the base configuration, the JMS server runs in the same JVM as the application server. In the Network Deployment configuration, the JMS server is separated from the application server and runs in a separate, dedicated JVM. Applications Applications are custom designed and developed programs that are hosted and run by the application server. An application is packaged into an Enterprise Application Archive that is deployed to one or more application servers. Application database Data storage is an essential part of many applications. The application database runs on a database server in an enterprise system where multiple application servers can share the same database. Session database In a multi-server environment, session information can be stored in a central session database for session persistence. The multiple application servers hosting a particular application need to share this database information in order to maintain session states for the stateful components. An alternative approach is to use the memory-to-memory session replication functionality in the Network Deployment environment. Name server Each application server JVM hosts a name service that provides a Java Naming and Directory Interface (JNDI) name space. The service is used to register all EJBs and J2EE resources (JMS, J2C, JDBC, URL, JavaMail) hosted by the application server. Chapter 22. IBM Tivoli Storage Manager for Applications 373

Security server Each application server JVM hosts a security service that uses the security settings held in the configuration repository to provide authentication and authorization functionality. Web services engine The Web services engine does not really stand as a separate component. The application server implements numerous APIs for additional services. Web services is provided as a set of APIs in cooperation with the J2EE applications. WebSphere s Web services engine is based on AXIS, and it implements the following specifications: SOAP (Simple Object Access Protocol) A protocol that defines the messaging between objects. It is based on the XML and XML schema specification. WSDL (Web Services Description Language) Describes the services that can be located and used by applications. UDDI (Universal Description, Discovery, and Integration) Enables an application to find services on the network published by service brokers. WSIF (Web Services Invocation Framework) A tool that provides a standard API for invoking services described in WSDL, no matter how or where the services are provided. The architecture enables new bindings to be added at runtime. For more information regarding the WebSphere software platfrom visit the following Web site: http://www-3.ibm.com/software/info1/websphere/index.jsp?tab=products/appserv You also may refer to the redbook IBM WebSphere Application Server V5.0 System Management and Configuration: WebSphere Handbook Series, SG24-6195. 22.2 Overview of IBM Tivoli Storage Manager for Application Servers This section describes the IBM Tivoli Storage Manager for Application Servers module and its features. 374 IBM Tivoli Storage Management Concepts

22.2.1 Architecture IBM Tivoli Storage Manager for Application Servers works with the WebSphere Application Server software to provide an applet GUI to do reproducible, automated online backup of a WebSphere Application Server environment, including the WebSphere administration database (DB2 Universal Database), configuration data, and deployed application program files. Changes to the WebSphere environment, such as the addition of applications, are automatically detected and included in the data backup schedule to help keep backed-up data current. If data loss or data corruption occurs, Storage Manager for Application Servers can automatically restore the necessary data from offline storage to the WebSphere Application Server environment s online storage. IBM WebSphere Application Server File Systems Beans HTML Pages Servlets IBM WebSphere Database Server Administrative Database IBM WebSphere Application Server File Systems Beans HTML Pages Servlets Client Module Control (Master) Module Client Module Client Module Control Module IBM Tivoli Storage Manager Server Figure 22-2 IBM Tivoli Storage Manager for Application Servers architecture Tivoli Storage Manager for Application Servers provides the following features: Data Integrity: The dynamic extraction of WebSphere Application Server configuration information ensures that all critical data is backed up. The dynamically generated XML file contains all required information to detect all Chapter 22. IBM Tivoli Storage Manager for Applications 375

WebSphere Application Servers in the backed-up domain. The administration database and all WebSphere application data are included. WebSphere Application Server Online Backup/Restore: Provides the ability to back up all WebSphere Application Servers online (hot backup). This means that the WebSphere administration database and all of the WebSphere Application Servers are backed up during normal operation. No server shutdown is required. Therefore, this product supports 24x7 availability of the complete WebSphere environment. Furthermore, high backup/restore performance helps to minimize availability impacts, even in disaster recovery scenarios. Fully Automated Backup Process: Ensures a fully automated backup process. The ability to configure scheduled backups together with the automatic detection of all linked WebSphere Application Servers eliminates the need to provide customer-maintained scripts. Manual interventions are no longer required because all actions are triggered from a central point of control. LAN-free Support: Can perform the backup and restore directly through the SAN, instead of going through the LAN. In a SAN environment, this product s data movers can be directly connected over the SAN to the respective storage devices. In this scenario, the data are transferred over the SAN, whereas the metadata flow over the LAN to the Tivoli Storage Manager server. The major benefits of this option include: Offloading the LAN from network traffic by sending the data directly through the SAN Using a centralized IBM Tivoli Storage Manager server, while keeping the read/write load on WebSphere Application Servers Table 22-1 IBM Tivoli Storage Manager for Application Servers features Features Advantages Benefits Online backups Avoids downtime Improves application availablity Consistent backups Complete protection Protects vital e-business infrastructure Policy driven Reduces manual operations Efficiency and automation Centralized backups Minimizes operational costs Data and application backups done on an enterprise level to a centralized server 22.2.2 Functions Tivoli Storage Manager for Application Servers enables you to back up, query, and restore WebSphere Application Server V5 components with the Tivoli Storage Manager backup-archive client command line interface and Web client. 376 IBM Tivoli Storage Management Concepts

WebSphere Application Server backup The product enables back up of stand-alone Application Servers and Network Deployment configurations of WebSphere Application Servers. A Network Deployment configuration is backed up from the node that contains the Network Deployment Manager. Tivoli Storage Manager for Application Servers can also back up multiple instances of the Network Deployment Manager and Application Server concurrently. However, multiple concurrent back up sessions of the same node or cell are not supported. Tivoli Storage Manager for Application Servers backs up the following Network Deployment Manager and Application Server data: The properties directory WebSphere Application Server Version 5.0 Web applications: Java archive files (JAR) Class files Configuration information from the configuration repository The following types of backup are available: Full: A complete backup of the following configuration files of the selected Application Server or Network Deployment Manager node: Configuration information from the WebSphere Application Server Configuration Repository All files in the properties directory WebSphere Application Server V5 installed Web applications Differential (the default backup): A backup of files that have changed on the WebSphere Application Server node since the last full backup. A differential backup backs up a subset of files that are otherwise included in a full backup. Files that have not changed are not re-sent. WebSphere Application Server query Tivoli Storage Manager for Application Servers enables you to query the Tivoli Storage Manager server to display WebSphere Application Server backups and WebSphere Application Server instances. You can query both active and inactive backups. The query function is available via the query was command. The Web client automatically queries the Tivoli Storage Manager server when the Restore window is refreshed. WebSphere Application Server restore Tivoli Storage Manager for Application Servers enables restoration of full or differential WebSphere Application Server backups that match the specified node Chapter 22. IBM Tivoli Storage Manager for Applications 377

name and type of WebSphere Application Server backup. You can also restore backups that were backed up at a particular date and time by using the Tivoli Storage Manager backup-archive client pittime and pitdate options, which enable you to specify the date and time at which to restore the latest version of the backup. Groups backed up on or before the specified date and time, and which were not deleted before the specified date and time, are processed. When using the Web client, restoring data other than at the Network Deployment Manager or Application Server group level can corrupt your WebSphere Application Server installation. It is strongly recommended to restore only the entire Network Deployment Manager or Application Server group. 22.3 Backup strategies Tivoli Storage Manager for Application Servers provides various strategies to employ in a backup solution. This chapter provides information about developing a backup strategy appropriate for the WebSphere Application Server environment. 22.3.1 Full backups only This strategy backs up all files that comprise a WebSphere Application Server backup group regardless of whether existing files have changed or new files have been added. If backing up to tape, full backups also keep all files of a backup set together on the same storage volume to optimize restore processing. However, this strategy requires the most network and storage resources because files that have not changed are processed with each backup. 22.3.2 Differential backups only This strategy backs up files that have changed since the last full backup or new files that have been added since the last full backup. A differential-only strategy requires the fewest network and storage resources as it processes only those files that have changed since the last backup. As such, the differential backup group contains all files needed for a full restore because the unchanged files are dynamically linked to the group from the prior full backup. As with a full-backup strategy, you select only the backup version you want to restore. However, files that compose your backup versions in a differential-only strategy may be distributed over more storage volumes. Even with Tivoli Storage Manager collocation enabled, files backed up together are more likely to reside on fewer sequential volumes than files backed up over a long period of time. If the backups reside in a random access disk pool, then restoring files distributed over more storage volumes is not a concern. In that case, a differential only strategy is the most efficient. 378 IBM Tivoli Storage Management Concepts

22.3.3 Differential plus periodic full backups This strategy requires fewer network resources and avoids distributing files excessively over multiple storage volumes (if stored on sequential media). The frequency of a full backup depends on: The number and size of files within the full backup Storage volume capacity Tivoli Storage Manager collocation Full and differential backups contain different backup types (active, inactive, expired) determined by Tivoli Storage Manager policy settings. As a result, a full backup cannot be expired by a differential backup. Chapter 22. IBM Tivoli Storage Manager for Applications 379

380 IBM Tivoli Storage Management Concepts

23 Chapter 23. IBM Tivoli complementary products IBM Tivoli Storage Manager has two types of complementary products: IBM Tivoli products that add to the Total Storage solution and third-party software products that complete and enhance the storage management solution. This chapter discusses additional IBM Tivoli storage management solution software and one third-party application. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 381

23.1 IBM Tivoli Storage Area Network Manager Tivoli Storage Area Network Manager is a comprehensive solution that discovers, monitors, and manages SAN fabric components. Tivoli SAN Manager is architected to ANSI SAN standards, enabling you to choose best-of-breed products for your storage infrastructure. Tivoli SAN Manager can help: Reduce storage administration costs Reduce administrative workloads Maintain high availability Minimize downtime For companies seeking SAN management support of 64 ports or less, IBM Tivoli Bonus Pack for SAN Management is also available. Table 23-1 IBM Tivoli SAN Manager Features Advances Benefits SAN fabric management Predictive error detection/fault isolation Open industry standards for SAN Topology views Brocade zoning API support Integration with IBM Tivoli NetView Automatically discovers SAN components and devices. Detects potential problem situations. Utilizes ANSI standards in the discovery of the SAN topology. Enables views at either the physical or logical level. Provides a view of the Brocade zones. Manages LANs, WANs, and SANs from a single console. Enableseasy SAN management and monitoring from a single console; ensures continuous data access on the SAN. Ensures high SAN availability by intelligently predicting a SAN link level failure before it actually occurs. Allows for inter-operability and choice of the best technologies for the SAN infrastructure. Enables easy problem identification and resolution. Enables leveraging of existing investments. Simplifies training and administration while lowering operational costs. Tivoli SAN Manager: Monitors and manages the switches and hubs, storage and servers in a SAN. Can be used for both online monitoring and historical reporting. Manages fabric devices (switches) through outband management 382 IBM Tivoli Storage Management Concepts

Discovers many details about a monitored server and its local storage through an IBM Tivoli SAN Manager agent loaded onto a SAN-attached host (managed host). Monitors the network and collects events and traps. Launches vendor-provided specific SAN element management applications from the IBM Tivoli SAN Manager console. Tivoli SAN Manager is compliant with the standards relevant to SAN storage and management. 23.1.1 Business purpose of IBM Tivoli SAN Manager The primary business purpose of Tivoli SAN Manager is to help storage administrators: Display and monitor storage network resources to increase data availability for applications so the company can be more efficient and maximize the opportunity to produce revenue. Prevent faults in the SAN infrastructure through reporting and proactive maintenance. Identify and resolve problems in the storage infrastructure quickly, when a problem occurs. In the next several sections of this chapter we identify Tivoli SAN Manager components and discuss some of their uses. We discuss prevention of problems through predictive reporting and proactive maintenance and show how to identify a fault quickly. 23.1.2 Components of IBM Tivoli SAN Manager These are the major components of IBM Tivoli SAN Manager: A manager or server, running on a SAN managing server Agents, running on one or more managed hosts Management console, which is by default on the Manager system, plus optional additional remote consoles Outband agents consisting of vendor-supplied MIBs for SNMP An optional additional component (which is provided by the customer) is an IBM Tivoli Enterprise Console or other SNMP manager which is used to receive events generated by Tivoli SAN Manager. These can be consolidated with events Chapter 23. IBM Tivoli complementary products 383

from other applications and acted on according to enterprise policy. The components are: IBM Tivoli SAN Manager server IBM Tivoli SAN Manager agent The most up-to-date list of supported operating systems and Host Bus Adapters (HBAs) is available at: http://www-3.ibm.com/software/sysmgmt/products/support/ Select IBM Tivoli Storage Area Network Manager from the pull-down list. 23.1.3 IBM Tivoli SAN Manager server The manager system must be a Windows 2000 system, with the following components: IBM Tivoli SAN Manager code: Controls the SAN management function. DB2: Used as a repository for topology and event records. IBM Tivoli NetView: Presents the topology and event information graphically. WebSphere: Manages the servlets used by Tivoli SAN Manager for various functions. Java Virtual Machine: Use of JVM supports portability and completeness. SNMP Manager: Communicates with SNMP Agents on outband-monitored devices. Remote Console One or more Remote Consoles can be installed to provide a GUI for Tivoli SAN Manager. The Server system automatically includes a console display. Remote Consoles must be Windows 2000 systems with the following components: NetView: Presents the information graphically Remote Console code: Enables an administrator to monitor Tivoli SAN Manager from a remote location or locations Agents or Managed Hosts Agents provide inband management capability and consist of the following components: The Agent itself: Collects information from various sources and forwards it to the Manager. JVM: Supports portability and completeness. 384 IBM Tivoli Storage Management Concepts

SNMP Agent for managed switches SAN switches can use SNMP to act as outband Agents. IBM Tivoli SAN Manager can use SNMP Management Information Base (MIB) queries to discover information about these switches. 23.1.4 Supported devices for IBM Tivoli SAN Manager The list of supported devices, including HBAs, disk systems, tape systems, SAN switches, and gateways is provided at: http://www-3.ibm.com/software/sysmgmt/products/support/ibm_tsanm_device _Compatibility.html When planning, you should check this site first for any special considerations for your environment.. 23.1.5 Important functions of IBM Tivoli SAN Manager The IBM Tivoli SAN Manager performs the following functions: Discovers SAN components and devices. Displays a topology map of the SAN in physical and logical views. Highlights faults and reports errors. Provides real-time and historical reports (through NetView). Launches vendor-provided applications to manage components. These functions are distributed across the Manager and the Agent, as listed in the following sections: IBM Tivoli SAN Manager server functions Performs initial discovery of environment Gathers and correlates data from agents on managed hosts Gathers data from SNMP (outband) agents Graphically displays SAN topology and attributes Provides customized monitoring and reporting through NetView Reacts to operational events by changing its display (Optionally) Forwards events to Tivoli Enterprise Console or SNMP managers IBM Tivoli SAN Manager Agent functions Gathers information about: SANs by querying switches and devices for attribute and topology information host-level storage, such as filesystems and LUNs event and other information detected by HBAs Chapter 23. IBM Tivoli complementary products 385

Forwards topology & event information to the Manager For more information about IBM Tivoli Storage Area Network Manager, refer to the redbook IBM Tivoli Storage Area Network Manager: A Practical Introduction, SG24-6848. 23.2 IBM Tivoli Storage Resource Manager This chapter introduces and positions IBM Tivoli Storage Resource Manager and its architecture, components, and functionality. IBM Tivoli Storage Resource Manager monitors storage assets, capacity, and usage across an enterprise. IBM Tivoli Storage Resource Manager can look at: Storage from a host perspective by managing all of the host-attached storage, capacity, and consumption attributed to file systems, users, directories, and files Storage from an application perspective by monitoring and managing the storage activity inside different database entities including instance, table space, and table Storage utilization and provide chargeback information. IBM Tivoli Storage Resource Manager provides more than 300 standardized reports (and the ability to customize your own reports) about filesystems, databases, and storage infrastructure. These reports provide storage administrators information about: Assets Availability Capacity Usage Usage violation Backup With this information, the storage administrator can: Discover and monitor storage assets enterprise-wide. Report on enterprise-wide assets, files and filesystems, databases, users, and applications. Provide alerts (set by the user) on issues such as capacity problems and policy violations. Support chargebacks by usage or capacity. 386 IBM Tivoli Storage Management Concepts

23.2.1 Business purpose of IBM Tivoli Storage Resource Manager The primary business purpose of Tivoli Storage Resource Manager is to help the storage administrator keep data available to applications. Through monitoring and reporting, Tivoli Storage Resource Manager helps the storage administrator prevent outages in the storage infrastructure. Armed with timely information, the storage administrator can take action to keep storage and data available to the application. Tivoli Storage Resource Manager also helps to make the most efficient use of storage budgets by allowing administrators to use their existing storage more efficiently and more accurately predict future storage growth. 23.2.2 Architecture of IBM Tivoli Storage Resource Manager Tivoli Storage Resource Manager architecture is shown in Figure 23-1. Tivoli Storage Resource Manager Server HP/ UX Web Server Managed Storage Browser Repository Figure 23-1 IBM Tivoli Storage Resource Manager Architecture The Server system manages a number of Agents, which can be servers with storage attached, NAS systems, or database application servers. Information is collected from the Agents and stored in a database repository. The stored information can then be displayed from a native GUI client or browser interface anywhere in the network. The GUI or browser interface gives access to the other Chapter 23. IBM Tivoli complementary products 387

Tivoli Storage Resource Manager functions, including creating and customizing of a large number of different types of reports and setting up Alerts. With IBM Tivoli Storage Resource Manager you can monitor virtually any host or local, SAN-attached, and Network Attached Storage from a browser anywhere on the network. 23.2.3 IBM Tivoli Storage Resource Manager products The IBM Tivoli Storage Resource Manager package contains these products: IBM Tivoli Storage Resource Manager: Monitoring and reporting for servers and their storage Wide OS support for Agents Includes NAS monitoring and reporting Prerequisite for the other products IBM Tivoli Storage Resource Manager for Databases: Monitoring and reporting for application databases Supports Oracle, Sybase, and MS SQL Server IBM Tivoli Storage Resource Manager for Chargeback: Collects storage usage information Generates reports and invoices for chargeback IBM Tivoli Storage Resource Manager This is the basic product for the set. It is needed as a prerequisite for the other two products. The Tivoli Storage Resource Manager provides monitoring, reporting, and alerting for storage on a wide variety of popular operating systems, including UNIX variants, Windows, and NetWare. See Section 2.1.5 of IBM Tivoli Storage Resource Manager: A Practical Introduction, SG24-6886 for the complete list of currently supported platforms. IBM Tivoli Storage Resource Manager also includes monitoring and reporting for NAS devices. IBM Tivoli Storage Resource Manager for Databases IBM Tivoli Storage Resource Manager for Databases is an additionally priced and orderable product. It requires IBM Tivoli Storage Resource Manager as a prerequisite. It provides monitoring and reporting for application databases: showing storage utilization by these applications, finding unused space, identifying the fastest growing databases, and many other functions. 388 IBM Tivoli Storage Management Concepts

IDC IBM Tivoli Storage Resource Manager for Chargeback IBM Tivoli Storage Resource Manager for Chargeback is an additionally priced and orderable product that requires Tivoli Storage Resource Manager as a prerequisite. It uses the storage usage information gathered by IBM Tivoli Storage Resource Manager and IBM Tivoli Storage Resource Manager for Databases to generate invoices that charge back for storage usage. 23.2.4 Components of IBM Tivoli Storage Resource Manager All three Tivoli Storage Resource Manager products use the same components; different functions are enabled by licensing them individually. At a high level, the major components of Tivoli Storage Resource Manager are: Server, running on a managing server, with access to a database repository Agents, running on one or more Managed Devices Clients (using either a locally installed GUI, or a browser-based Web GUI), which users and administrators use to perform storage monitoring tasks Figure 23-2 shows these components and their relationship. Direct-connect Clients SRM Server WWW Server Web-connect Clients Managed Servers (Agents) SRM Database Repository Figure 23-2 IBM Tivoli Storage Resource Manager components Chapter 23. IBM Tivoli complementary products 389

IBM Tivoli Storage Resource Manager server The IBM Tivoli Storage Resource Manager server: Controls the discovery, reporting, and alert functions Stores all data in the central repository Issues commands to Agents for jobs (either scheduled or ad hoc) Receives requests from the user interface clients for information and retrieves the requested information from the central data repository An RDBMS (either locally or remote) manages the repository of data collected from the Agents, as well as the reporting and monitoring capabilities defined by the users. WWW Server The Web Server is optional. It handles communications to enable remote Web access to the Server. The WWW Server can run on the same physical server as the SRM Server. Storage Resource Manager Agent (on a Managed System) The Agent runs probes and scans, collects storage-related information from the managed system, and forwards it to the Manager to be stored in the database repository and acted on if so defined. Every host system except NetWare and NAS devices requires an Agent in order to be monitored. Novell NetWare and NAS devices do not currently support locally installed Agents; they are managed via an Agent installed on a machine that accesses the NetWare or NAS device. The Agent will discover information about the volumes or filesystems that are accessible to the Agent s host. The Agents are quite lightweight. Agents listen for commands from the host, then perform a probe (against the operating system), and/or a scan (against selected filesystems). Normal operations might see one scheduled scan per day or week, plus various ad hoc scans. Clients (direct-connected and Web-connected) Direct-connect clients have a locally installed GUI to the server. They communicate directly to the Manager to perform administration, monitoring, and reporting. The Manager retrieves information requested by the clients from the database repository. Web-connect clients use the WWW Server to access the UI interface via a Web browser. The Java administrative applet is downloaded to the Web Client machine and presents the same user interface that direct-connect clients see. 390 IBM Tivoli Storage Management Concepts

Security considerations Tivoli Storage Resource Manager has two security levels, non-administrative users and administrators: Non-administrator users can: View the data collected by Tivoli Storage Resource Manager. Create, generate, and save reports. Administrators can: Create, modify, and schedule pings, probes, and scans Create, generate, and save reports. Perform administrative tasks and customize the Tivoli Storage Resource Manager environment. Create groups, profiles, quotas, and constraints. Set alerts. For more information about Tivoli Storage Resource Manager, refer to IBM Tivoli Storage Resource Manager: A Practical Introduction, SG24-6886. 23.3 IBM Tivoli SANergy IBM Tivoli SANergy is a unique application that enables you to realize the cost savings, performance benefits, and new capabilities provided by SANs. IBM Tivoli SANergy enables storage volumes to be shared to multiple hosts running various operating systems. This does not require implementation of a new operating system or new file system, and existing applications will run under their current design. The skills for administrating LAN-based shared storage are similar to those needed to manage IBM Tivoli SANergy shared storage. Tivoli SANergy is a very mature product (relative to this area of technology) that runs on more than 5000 hosts and 1000 customer environments. Tivoli SANergy accomplishes SAN storage sharing by integrating with traditional LAN-based file-sharing applications NFS and CIFS. Through this integration, Tivoli SANergy hosts access the shared data over the SAN instead of the LAN. This redirection of the data I/O is transparent to the hosts operating system and applications. The applications see the disk volumes as if they were accessing them using a traditional LAN-based configuration. NFS (Network File System) is a file-level protocol for sharing file systems across the network. It originated on UNIX platforms and was developed by Sun Microsystems. CIFS (Common Internet File System) is also a file-level protocol Chapter 23. IBM Tivoli complementary products 391

for sharing disk storage. It originated in the Microsoft operating system world. It was formally known as SMB (System Message Block). CIFS, like NFS, is available on both UNIX and Microsoft platforms. By utilizing this unique and deceptively simple technique, Tivoli SANergy enables full use of the SAN without re-engineering the entire infrastructure (other than implementing the SAN itself). Tivoli SANergy enables an organization to exploit their SAN in a wide variety of ways. It is also important to note that SANergy is truly set and forget software; that is, after setting up the initial configuration, little ongoing maintenance is required to keep the configuration performing effectively (apart from adding new file systems or hosts to be managed by Tivoli SANergy). Tivoli SANergy simply does its job quietly in the background. 23.3.1 What are the benefits of IBM Tivoli SANergy? Here we discuss the main benefits you can expect to receive from implementing Tivoli SANergy, including sharing disk volumes, backup and recovery, and file sharing. 23.3.2 Sharing disk volumes One of the most beneficial Tivoli SANergy features is the sharing of disk volumes between hosts of multiple operating systems: heterogeneous disk sharing, shown in Figure 23-3. This not only reduces the total number of logical volumes to be administered within an enterprise, it also solves several technical and business problems as well. SAN Exploitation: Heterogeneous Disk Sharing Shared SANergy volume Host A Host B SAN Host C Hosts of different operating systems A, B & C Storage subsystem Figure 23-3 Sharing volumes from heterogeneous hosts with SANergy When considering whether a configuration will benefit from disk volume sharing using Tivoli SANergy, we first look at the benefits of using NAS devices or normal 392 IBM Tivoli Storage Management Concepts

LAN-based file sharing. The attraction of NAS is that an organization can invest much less effort in administering its storage. For example, it is not uncommon for an NT server to use two or three disk volumes to store its data. Each of these must be installed, administered, and monitored. If an organization utilizes an NAS device for 10 of these NT servers, the number of disk volumes could be reduced from 20-30 to one or two. (See Figure 23-4.) Traditional storage NAS-based storage LAN Host A A Host B B Host C C Host A Host B Host C A A B B C C NAS Shared storage Figure 23-4 Locally attached storage compared to exploiting a NAS appliance Tivoli SANergy provides a configuration the manageability of NAS or file servers and offers additional benefits. A possible NAS solution is to utilize the NAS appliance as a storage for databases such as IBM DB2 UDB. This provides ease of administration and storage consolidation. However, if you choose such a solution, be sure that your network infrastructure, including LAN and SAN, can handle the traffic. The CPU workload of large data transfers using TCP/IP can quickly overwhelm a host, but SAN I/O has negligible impact. When using Tivoli SANergy for volume sharing instead of NAS, you can gain the advantages of easier administration and storage consolidation, but the performance will be at SAN speeds and the CPU resources of the hosts will not be overtaxed. Other advantages include a lower utilization of the existing LAN as well as more-consistent data writes. NAS and LAN-based file serving solutions may signal that a write I/O is complete before it is written to disk. This problem, referred to as unsettled writes, has previously prevented critical applications, such as databases, from being implemented in a LAN-based file sharing environment. Volume sharing has other advantages apart from ease of administration and storage consolidation, including functional advantages. Consider the sharing of Chapter 23. IBM Tivoli complementary products 393

volumes needed by Web servers or file servers. Although they both benefit from sharing their disk volumes, they do so for slightly different reasons. When an organization designs a Web-serving infrastructure, it often requires more horsepower than is available in a single machine. Without Tivoli SANergy, there are a couple of options, each with significant drawbacks. The first option is to increase the horsepower of the existing machines, which may be expensive and not provide sufficient redundancy. The other option is to add more Web servers. While this may enable you to use less-expensive servers and does provide redundancy, there are some drawbacks. When using multiple servers, either there will be duplication of the data being served or you have to administer a Web site that is stored in many locations. Also, there must be a process to ensure that all copies of the data are kept synchronized and organized. By using Tivoli SANergy, you can implement a configuration that takes advantage of multiple, cheaper Web servers without the disadvantages of each server having its own storage. Each of the Web servers simply shares a copy of the entire Web site, which is stored on shared volumes. File servers also benefit from the sharing of disk volumes. Many organizations require multiple file servers to adequately support their user community. Each of these file servers typically has its own storage that must be monitored and administered. By consolidating this to fewer, larger volumes, the administrative overhead is reduced, along with the frequency of maintenance required to increase storage or relocate data. A new file server may be needed because there is no available disk space on existing servers. By consolidating storage, the number of file servers required is dictated by the actual number of machines needed to adequately serve the workload. It is more desirable to have each tier in a multiple-tier architecture scaled by the function it performs, rather than by another tier s requirements. There are other advantages to using Tivoli SANergy in these two scenarios: for example, a Tivoli SANergy implementation could also include space management software to perform automatic migration and expiration based on the age and size of files. This means that all of the hosts sharing the volumes have access to an almost unlimited amount of virtual storage. Another significant advantage to utilizing Tivoli SANergy in these configurations is that less-expensive hosts can be used for different functions in the configuration. For example, a Windows NT server can be used in a file serving infrastructure to provide authentication as well as space management. The remaining hosts can then be Linux machines built on less-expensive hardware that performs the actual serving of the files via Samba. 394 IBM Tivoli Storage Management Concepts

23.3.3 Backup and recovery 23.3.4 File sharing When most organizations choose to implement a SAN, they also should enhance their data protection infrastructure so that backups and restores will take place over the SAN with maximum performance and minimal impact to the hosts. Tivoli SANergy enables SAN-based, server-less backups of shared storage. Backups and restores in such a configuration take place with no impact to the hosts sharing the storage and exploit the enhanced throughput of the SAN. One of the most common uses of Tivoli SANergy is to enable file sharing by multiple users or applications. For example, filmmakers use computer-generated special effects to replace what once required the use of expensive, dangerous stunts and model-based special effects. The data files that contain these movies are very large, and a post-processing company may need to have multiple personnel working on different parts of the same file. Tivoli SANergy, in conjunction with traditional LAN-based file sharing, enables these huge files to be edited by multiple SAN-attached hosts. Data reads and writes are redirected to utilize the SAN for much greater performance. The application must include a mechanism to safely handle concurrent file access, so the Tivoli SANergy role in this implementation is to enable SAN-based data I/O. It does not alter the capabilitiesor design of the application in any other way. (See Figure 23-5.) Another key application of this type is the processing of large data files by high-performance computing systems. For example, raw geophysical or medical imaging data may have to be accessed simultaneously by several processes, which may be on multiple nodes in a high-performance cluster. Whenever a configuration calls for the simultaneous access of large files at high speeds, SANergy is an ideal solution. SAN Exploitation: Heterogeneous File Sharing Shared file on SANergy volume Host A Host B SAN Host C Hosts of different operating systems Shared file Figure 23-5 Sharing files with SANergy and storage area networks Chapter 23. IBM Tivoli complementary products 395

23.3.5 IBM Tivoli SANergy requirements Tivoli SANergy has the following requirements: At least one machine on the SAN must be identified as a Meta Data Controller (MDC). The MDC owns the volume being shared and formats it using its file system. There can be as many MDCs as there are volumes being shared on the SAN, or a single MDC may share a large number of volumes. The number of MDCs depends on a given configuration and workload. All of the machines sharing storage must share a common LAN protocol and be able to communicate with one another across it. All machines sharing storage must share a common SAN with at least one storage device. The hosts HBA cards must support multi-initiator environments and be compatible with other SAN components. All of the machines must have an NFS or CIFS client capable of sharing files from the MDC. If a UNIX MDC is sharing files to Windows hosts, it must have a CIFS server, such as Samba, configured. If a Windows MDC is sharing files to UNIX hosts, it must be running an NFS server. Macintosh hosts use an SMB client that ships with SANergy and have the same requirements as Windows hosts. With Tivoli SANergy 2.2, MDCs running Windows NT 4.0, Windows 2000, Red Hat Linux, or Solaris are supported. The disk partitions owned by those MDCs must be formatted with either NTFS, UFS, EXT2FS, or any other Tivoli SANergy API-compliant file system such as LSCi's QFS and SAMFS. An IBM Tivoli SANergy license is required for all of the hosts participating in file sharing, either as an MDC or a SANergy host (client). 23.3.6 IBM Tivoli SANergy limitations IBM Tivoli SANergy enables many powerful features, but there are some scenarios where you may choose not to deploy it. As with most distributed file-sharing solutions, Tivoli SANergy has a small amount of overhead associated with accessing each file on a shared volume. If a file is very small, it may actually be more efficient to just send it over the LAN rather than redirecting to the SAN. This cut-over point is normally reached with files 100 KB in size or smaller. Therefore, if an entire workload is made up of files this small, Tivoli SANergy may not add any performance benefit. Because typical workloads and environments are made up of a variety of file sizes, Tivoli SANergy can bypass tiny files while still being available for files it should handle. However, even in situations in which it may offer minimal speed increases, you may still find significant advantages by using its volume-sharing capabilities. 396 IBM Tivoli Storage Management Concepts

While it is not a limitation of Tivoli SANergy, care must be taken when utilizing it with other products that may intercept and/or redirect I/O. While Tivoli SANergy has been shown to coexist with other applications that intercept I/O, it is important that these combinations be validated. An example of such an application may be space management or anti-virus software. In general, to understand the capabilities or limitations of Tivoli SANergy, you must understand the limitations of the LAN-based file sharing infrastructure itself. For example, neither NFS or CIFS can share a raw partition; therefore, neither can Tivoli SANergy. However, it is critical to understand that many of the limitations of LAN-based file sharing, such as poor performance, the heavy load on a host's CPU, and unsettled writes, are eliminated when using Tivoli SANergy. For more information regarding IBM Tivoli SANergy refer to A Practical Guide to Tivoli SANergy, SG24-6146, and Implementing the IBM TotalStorage NAS 300G: High Speed Cross Platform Storage and Tivoli SANergy!, SG24-6278. 23.3.7 Summary IBM Tivoli SANergy enables sharing of SAN-attached disk volumes (such as performance, sharing, cost-cutting, new capabilities) without redesigning all aspects of an infrastructure. Tivoli SANergy does not attempt to re-implement core features such as security authentication or the advertisement of shares, but rather integrates with standard LAN-based file-sharing systems (NFS and CIFS). A Tivoli SANergy configuration provides many advantages over simple NAS or LAN-based file sharing, including better performance and data consistency, and it enables customers to truly exploit their SAN s potential. 23.4 Cristie Bare Machine Recovery Cristie Bare Machine Recovery (CBMR) is a software package that works in conjunction with IBM Tivoli Storage Manager to provide a fully automated method of recovering a Windows operating system to a new hard disk drive or RAID system. There are three components to the software: the backup of the operating system, the configuration files and the boot files. The backup of the operating system comprises the files contained in the Windows operating system folder together with the IBM Tivoli Storage Manager client files and the CBMR files. These are backed up as a few files to the IBM Tivoli Storage Manager filespace and kept up to date either on an ad hoc basis or by using the scheduler incorporated within CBMR. Chapter 23. IBM Tivoli complementary products 397

The configuration files contain key static information about the hard disk drive, boot sectors, and partitions, and this is stored on a network share and/or on a floppy disk (one for each computer). The boot and system files are contained on the supplied bootable CD-ROM or can be created on two floppies by running a utility in CBMR. A machine recovery is performed by booting from the supplied CD-ROM or created floppy disk, and running the CBMR recovery program. This program loads a Linux shell operating system, the drivers required to access the network, and the IBM Tivoli Storage Manager client. The Windows operating system is then recovered from the files stored on the IBM Tivoli Storage Manager server to the most recent point-in-time backup, and the system is rebooted in Windows mode. The rest of the data files can then be restored from the IBM Tivoli Storage Manager client. 23.4.1 Overview Cristie Bare Machine Recovery (CBMR) backup and disaster recovery software readily integrates with the IBM Tivoli Storage Manager to provide bare Machine Recovery capability to an IBM Tivoli Storage Manager client computer. IBM Tivoli Storage Manager Server V 5.2 Network Connection Server or Workstation Running IBM Tivoli Storage Manager Client and Cristie BMR Laptop computer running IBM Tivoli Storage Manager client and Cristie BMR Figure 23-6 Cristie Bare Machine Recovery with IBM Tivoli Storage Manager 398 IBM Tivoli Storage Management Concepts

CMBR consists of several components that are included within the package, and it has a single installation process. These components do not have to be purchased separately. CBMR consists of the following components: 1. Backup and restore software Cristie s backup and restore software (PC-BaX) is trusted and used in thousands of servers worldwide. This is used to back up and restore files in Windows mode. 2. Open File Module (OFM) OFM enables backup of files that are in use by other applications at the time of backup. 3. Customized version of Linux operating system A failed computer needs to be booted from the CBMR CD-ROM or floppies created from the CD-ROM with the supplied tools. This boots a version of Linux in which the partitioning and formatting of the hard disks will be done. 4. Linux mode restore software Restores the essential operating system files from the IBM Tivoli Storage Manager server. It is possible to replace the original hard disk with a larger or smaller one, and CBMR automatically scales the partitions to fit in the new hard disk. In doing so all partitioning rules are obeyed. There is also the capability to manually size the partitions. 23.4.2 How does it work? CBMR stores the computer s vital configuration information on a floppy disk and/or on a network share. This information includes the number and types of hard disks and their layout; Windows, CBMR, and IBM Tivoli Storage Manager installation folders; and the SCSI, RAID, and network adapters installed. The files necessary to bring the Windows system back are stored on the Tivoli Storage Manager server. In a disaster situation, the computer must be booted with the Linux operating system provided. The hard disks will be partitioned and formatted, and the operating system files will be restored from the Tivoli Storage Manager. Necessary hard disk preparation will be done so that Windows system boots from the hard disk. At this point, you could use the native IBM Tivoli Storage Manager client to restore the user s data. Chapter 23. IBM Tivoli complementary products 399

23.4.3 The deployment steps The steps involved in deploying CBMR in a Tivoli Storage Manager environment are listed below. For a detailed procedure refer to http://www.cristie.com: How to configure Cristie BMR 4.01 with IBM Tivoli Storage Manager 5.1.5. One time only 1. Create a dedicated client node on the IBM Tivoli Storage Manager server for CBMR usage. 2. Install CBMR on the user s machine. 3. Create a CBMR storage device to represent the IBM Tivoli Storage Manager client node 4. Use the CBMR CD to create a system and a boot floppy. 5. Use the CBMR CD to create a generic configuration floppy. 6. Save the user s specific system configurations to the configuration floppy. When hardware or software configurations change 1. Store the configuration information for the computer on a floppy or network share. 2. Back up the important system files to the IBM Tivoli Storage Manager server through the device created in the previous step 3. When you need to recover a system 1. Boot from either the CBMR CD-ROM or boot and system floppies created using the utilities provided on the CD-ROM. 2. Supply the configuration information from a floppy or a network share. 3. Respond to the prompts and, when asked, reboot the machine after removing the floppy and CD-ROM from the drives. 4. Windows will boot now from the hard disk. Log on using a user ID that has administrative privileges to the computer. 5. DR-Wizard pops up and responds to the prompts. When prompted, reboot the computer. 6. Restore all of the data from the IBM Tivoli Storage Manager native client, which is now functional. You have successfully recovered your computer. 400 IBM Tivoli Storage Management Concepts

23.4.4 More information For more information about this or about Cristie Bare Machine Recovery contact your closest IBM Tivoli Storage Manager reseller or Cristie Data Products on the Web at: http://www.cristie.com 23.5 Ready for IBM Tivoli products and solutions Ready for IBM Tivoli is the official program through which selected Business Partner products are designed, tested, and certified for seamless integration with Tivoli technology management solutions. When you buy products that are validated as Ready for IBM Tivoli, you know they will work together with your Tivoli solutions to provide true end-to-end technology management functionality. All of the integration and testing have been done before you even purchase the product. Selecting Ready for IBM Tivoli products along with your Tivoli solutions simplifies and streamlines technology management. Ready for IBM Tivoli products encompass a wide variety of hardware, software, management tools, and business applications from leading technology companies. Each Business Partner product is validated to meet Ready for IBM Tivoli integration standards with a corresponding IBM Tivoli solution. Benefits include: Faster and easier initial deployment with out-of-the-box integration Increased value from all your products, including the ability to manage your Ready for IBM Tivoli products with your Tivoli solutions More options for future enhancements to your technology management system For more information about Ready for IBM Tivoli, visit these IBM Tivoli Web sites: IBM Global Solutions Directory: http://www.developer.ibm.com/solutions/isv/igssg.nsf/tivolisolutionweb?openview IBM Tivoli: http://www-3.ibm.com/software/tivoli/ Chapter 23. IBM Tivoli complementary products 401

402 IBM Tivoli Storage Management Concepts

24 Chapter 24. iseries storage management solutions For some years an IBM Tivoli Storage Manager server has been available for IBM ^ iseries systems, where it has mainly been used as a repository for end-user workstation and client data. Since the introduction of the BRMS/400 application client for Tivoli Storage Manager, iseries data can also be stored and managed using a Tivoli Storage Manager server. This chapter includes a high-level discussion of the different aspects of using Tivoli Storage Manager in an iseries-centric network environment, covering both the application of an iseries system as a Tivoli Storage Manager server and the integration of an iseries system in an existing Tivoli Storage Manager environment. It also gives an overview of different solutions when using Tivoli Storage Manager in an iseries environment, such as managing data in a partitioned Portable Application Solutions Environment (PASE) environment and the application of Tivoli Storage Manager with the iseries Integrated Netfinity server. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 403

24.1 Why choose an iseries system? The IBM ^ iseries system is a secure, proven, and reliable machine with at least 99.9 percent uptime (according to reported IBM figures) provided by a single iseries system with no special high-availability add-on products. This compares favorably with other operating systems that rely on additional high-availability products and may not have as much established time in the marketplace. For current information about iseries, refer to: http://www-132.ibm.com/content/home/store_ibmpublicusa/en_us/eserver/iseries/ This high reliability makes an iseries system the ideal platform for running mission-critical systems, including IBM Tivoli Storage Manager. 24.2 iseries with IBM Tivoli Storage Manager An iseries system can be integrated easily into a Tivoli Storage Manager data management solution as either client or server. To act as a Tivoli Storage Manager client, the iseries system must be running Backup, Recovery, and Media Services for iseries (BRMS). 24.3 Portable Application Solutions Environment OS/400 Portable Application Solutions Environment (OS/400 PASE): An integrated OS/400 runtime for porting selected UNIX applications Provides a broad subset of AIX libraries and adds more shells and utilities in V5R2 (in which it is a no-charge option) Uses the hardware directly; is not an operating system or emulated environment OS/400 PASE applications can use iseries file systems, and call DB2 UDB for iseries, or Java and ILE programs. They can exploit all aspects of iseries server operations environment. IBM ^ iseries and IBM ^ pseries share a common PowerPC chip. Using the ability of this hardware base to switch between 64- and 32-bit applications, OS/400 PASE can execute AIX applications on iseries within OS/400 jobs. Since its applications execute directly on the hardware in PowerPC mode, computational intensive applications use the processor without any additional layers overhead. 404 IBM Tivoli Storage Management Concepts

OS/400 PASE uses the SLIC kernel for system services. A OS/400 PASE application is fully integrated with work management, security, backup, file systems, and database. OS/400 PASE provides a very large subset of 32-bit and 64-bit AIX syscalls and APIs, plus nearly 200 common utilities along with the Korn, Bourne, and C shells. 24.3.1 Advantages of OS/400 PASE porting iseries customers running applications ported using OS/400 PASE do not use UNIX system operations. OS/400 PASE applications run in jobs using standard work management (subsystems), the integrated file system with standard save/restore operations, and standard security. No special system operations are introduced by PASE, only new applications. 24.3.2 Important PASE features DB2 UDB iseries is the database available on the iseries. All applications using database in ILE or PASE are ported to DB2 UDB iseries. PASE contains the same Call Level Interface (CLI) set of APIs for DB2 UDB iseries that is supported for ILE. Data returned from DB2 UDB iseries can be presented in ASCII format, as expected by the majority of UNIX applications. Embedded SQL is not available for PASE, because PASE executables are built on AIX, and no iseries preprocessor runs there. PASE applications can be fully integrated with other iseries applications, such as an ERP application implemented in ILE or a Websphere application written in Java. A suite of applications can run together in a job mix or be separated into their own logical partitions, depending on performance and customer scheduling requirements. Solution developers porting to iseries using PASE and supporting their applications will require a combination of AIX and OS/400 programming and support skills. PASE applications are built and compiled on an AIX workstation. As of V5R2, an application can also be compiled within OS/400 PASE itself using either the IBM VisualAge C++ Professional for AIX or IBM C for AIX Version 6.0 compiler products. Primary application development continues to use existing UNIX skills where they add their greatest application value. iseries skills will be required for converting database calls, providing integration with iseries security, and application operational interfaces (installation, start-up, shut-down). Solution developers also require iseries skills in their support teams as customers using iseries instead of UNIX terminology will call. Chapter 24. iseries storage management solutions 405

24.3.3 Reducing time to market Bringing an application to the iseries market requires three phases of effort: market development, solution enablement (including porting the application) and market introduction. Market development and introduction are efforts common to all techniques of moving Solution Developer applications to iseries. PASE can improve several aspects of the solutions enablement phase. A faster port can mean a shorter time to market. When using PASE for enablement, our automated application assessments can be more complete as character set and pointer size assumptions do not change from what they are for AIX code. (An ILE port requires use of longer ILE pointers and often EBCDIC character set.) Also, PASE runtime includes more flexibility in its C language support compared to the full ANSI compliant support provided in ILE C. A significant time savings may be achieved in the porting phase by not having to recreate the application s build environment. The testing cycle for a PASE application also may be more similar to a UNIX test environment. There is a second part to enablement after the application is running. All applications, whether ported in ILE or PASE, require a similar amount of customizing to create a product that meets iseries customers expectations of full integration with database, save/restore, security, ease of installation, licensing, and robust support services. A product integration and test cycle is required for PASE applications to fully exploit the environment on iseries. The Application Factory was created to assist solution developers in identifying items that should be examined for a new application to appeal to the iseries customer base. Performance For the latest information about PASE performance see visit: http://www-1.ibm.com/servers/enable/site/porting/iseries/pase/ 24.4 Who would use Tivoli Storage Manager on iseries? The criteria for determining whether you should use the iseries for Tivoli Storage Manager backups depends on several factors relevent to your specific IT environment. Refer to Chapter 4, Planning concepts on page 55 for more details. 406 IBM Tivoli Storage Management Concepts

When considering IBM Tivoli Storage Manager on iseries you should review the following points to determine whether they match your business environment: You have medium to large iseries servers (measured by CPW). You have iseries CPU cycles to spare. (IBM Tivoli Storage Manager must share resources with other jobs.) You want to leverage the stability of iseries and the OS/400 environment. You have iseries tape libraries with multiple tape drives. For customers looking to leverage large existing tape resources, IBM Tivoli Storage Manager may be used to help justify library hardware investment for iseries. Autoloader or standalone drivers are not recommended. You want to centralize tape operations. You want to centralize backup of small to medium workstations or servers (Windows, Linux, UNIX, NetWare, and associated applications and databases). You have adequate network bandwith into iseries systems. (Gigabit Ethernet or multiple 100MB Ethernet adapters are recommended.) You have inadequate data protection for your open-systems environment. You have outgrown your old product. You want to centralize myriad departmental products. You have best systems administration expertise on iseries. 24.5 Hardware and software requirements The following hardware and software requirements are necessary: Either OS/400 V5R1 with PASE (option 33 of OS/400) or OS/400 V5R2 (PASE is standard) Any iseries hardware that supports V5R1 or V5R2 of OS/400 Medium to high CPW systems Minimum of 128 MB memory (256 MB recommended Minimum of 110 MB of disk space Additional space for Tivoli Storage Manager database and recovery log Additional space for Tivoli Storage Manager diskpool (actual disk requirements determined via standard IBM Tivoli Storage Manager sizing) TCP/IP enabled on iseries Chapter 24. iseries storage management solutions 407

PASE interface has AIX look and feel Knowledge of some AIX commands and general concepts (recommended) 24.6 Considerations for iseries (PASE) IBM Tivoli Storage Manager 5.2 Server for iseries (PASE) does not support: Server-free LAN-free (storage agent) IBM Tivoli Storage Manager tape library sharing Raw logical volumes for Tivoli Storage Manager database, log, or diskpools Optical devices NAS (NDMP) SNMP Subagent IPX or APPC protocols PASE on OS/400 does not support: SMIT ODM (object data manager) AIX device drivers Migration from IBM Tivoli Storage Manager for AS/400 to IBM Tivoli Storage Manager for iseries (PASE): Tivoli Storage Manager PASE does not automatically upgrade any existing Tivoli Storage Manager product for the iseries. Tivoli Storage Manager PASE server may be installed on the same machine as Tivoli Storage Manager iseries server. Data from existing Tivoli Storage Manager iseries server must be migrated to new Tivoli Storage Manager PASE server. Customer may use traditional export/import using tape devices. This approach requires tape media type supported on both versions of IBM Tivoli Storage Manager. Tivoli Storage Manager PASE includes support for export/import between Tivoli Storage Manager servers over a network. This approach requires that customers upgrade their existingtivoli Storage Manager for AS/400 server to the most recent maintenance level prior to performing export/import. This maintenance level is included on CD-ROM for IBM Tivoli Storage Manager OS/400 PASE server. 408 IBM Tivoli Storage Management Concepts

24.7 BRMS/400 Backup Recovery Media Services (BRMS) is the primary IBM product for backup and recovery of the iseries and iseries data. Tivoli Storage Manager and BRMS can coexist on same iseries server. iseries data is not read directly by Tivoli Storage Manager because there is no Tivoli Storage Manager client for iseries. BRMS backs up iseries data. Tivoli Storage Manager backs up other network-attached, non-iseries servers and workstations such as Windows, NetWare, UNIX, and Linux, and associated applications and databases. BRMS supports SAN-attached tape in OS/400 V5R2; IBM Tivoli Storage Manager for iseries does not. iseries can participate as a client to a Tivoli Storage Manager server on a different platform (such as Windows 2000, UNIX, or z-os) via BRMS Application Client to IBM Tivoli Storage Manager. Tivoli Storage Manager is not a replacement for BRMS, but they are complimentary products. While BRMS/400 is the strategic data management solution for the iseries world, there is also a specific terminology established when talking about managing data in the context. Unfortunately this terminology uses the some of the same terms that IBM Tivoli Storage Manager does, but with different meanings. Table 24-1 gives a comparison of terms used in both worlds for the same data management concept. It will be particularly useful for people with iseries system and BRMS experience who want to become familiar with Tivoli Storage Manager, or for administrators who have to integrate an iseries system into a Tivoli Storage Manager environment. Table 24-1 BRMS and IBM Tivoli Storage Manager terminology Concept BRMS IBM Tivoli Storage Manager Save only changed objects, keep a set number of versions of each object Save all objects, keep a set number of versions of each object Save all objects, keep each object for a set number of days Free space by moving files off disk, while keeping stub file on disk Incremental Backup with version expiry Full backup with version expiry Full backup with days expiry Archive, with storage freed Normal incremental backup Selective backup Archive Space Management Chapter 24. iseries storage management solutions 409

Concept BRMS IBM Tivoli Storage Manager Save objects while they are in use Save while active Copy serialization BRMS is an IBM product for the iseries system that uses a set of rules to fully automate the backup, recovery, and tape management of an iseries system. BRMS will work with a single tape drive or a multitude of different tape libraries. BRMS can be used in a network of iseries systems to share a pool of scratch tapes, although it cannot back up data across a network to another iseries system. Figure 24-1 shows the different elements of BRMS. Retention Savefiles Quarterly Daily Defaults Media Policies Lib1 Lib3 Lib2 Lib4 Control Groups System Policy Backup Recovery Archive Policy Move Polices Media Devices Tape Devices Storage Locations Figure 24-1 Basic components of BRMS Many iseries systems already use BRMS. The Tivoli Storage Manager server for the iseries system can be integrated with BRMS to share tape resources with it if that is required. More common is to use the BRMS Application Client to enable the iseries system to be a client to a Tivoli Storage Manager server. With BRMS, a recovery plan can be produced that details exactly what must be done, step-by-step, to recover an iseries system after a disaster. 410 IBM Tivoli Storage Management Concepts

24.8 iseries system as Tivoli Storage Manager API client A set of application program interfaces (APIs) can be obtained for BRMS. These form the BRMS Application Client to an IBM Tivoli Storage Manager server. This enables BRMS to save and restore data on any Tivoli Storage Manager server. See Figure 24-2. iseries Data BRMS Connection Code BRMS ITSM API Attached Tape IBM Tivoli Storage Manager API IBM Tivoli Storage Manager API Calls IBM Tivoli Storage Manager Storagepools IBM Tivoli Storage Manager Figure 24-2 BRMS Application Client The BRMS Application Client was initially developed to cater to remote iseries sites that had little or no iseries knowledge. The idea was that once a system administrator had performed a complete backup of the system using BRMS or the native save commands, the user data could then be transferred across a network to a Tivoli Storage Manager server at a remote site. This ensures that the user data is backed up on a regular basis, rather than having to rely on possibly unskilled staff to change tapes and perform backups. A typical iseries system will already be running BRMS to automate the backup and restore of that iseries system and user data. With the addition of the BRMS Application Client software, BRMS can be used to save user data to a Tivoli Storage Manager server across the network. System data must still be saved to a local tape device using BRMS or OS/400 commands. Chapter 24. iseries storage management solutions 411

Note it is not recommended to use the IBM Tivoli Storage Manager/400 server and BRMS together to back up a stand-alone iseries system. Using Tivoli Storage Manager in this manner is more costly, unnecessarily complicates the backup plan, and can degrade backup performance. Best results can be achieved by using BRMS to back up the system directly to local media. The BRMS Application Client is not intended for use where large amounts of data are to be backed up in short periods of time. If this is the requirement then BRMS should be used to save the data directly to tape. Requirements OS/400 V4R3 or higher is required to use the BRMS Application Client to save and restore objects from a Tivoli Storage Manager server. Also, the Media Storage Extensions option and BRMS for iseries V4R3 or higher are required. The BRMS Application Client API itself is included on the CD that accompanies the BRMS product, and it can be downloaded from the Internet. How does it work? Backups are defined using BRMS control groups. These are a grouping of objects from the iseries system that are to be saved to a specific media and kept for a specific period. A control group can be set up that saves this data to a Tivoli Storage Manager server rather than to a local tape device. When objects are saved to a Tivoli Storage Manager server they are saved in the form of an iseries savefile, which is like an archive that contains one or more other files. The BRMS interface itself is used to control the backup and restore operations. This is unlike the native IBM Tivoli Storage Manager clients, which all use the same command sets. With the BRMS Application client to Tivoli Storage Manager, backup and recovery commands are issued using either the BRMS menus or native commands. Tivoli Storage Manager appears in these as another possible storage location, along with any local tape devices. Virtually anything can be restored through this interface, from a single iseries object to all of the user data contained in many libraries and IFS directories. Unlike data saved from a conventional IBM Storage Manager backup-archive client, the Tivoli Storage Manager server does not know exactly what has been saved to it from the iseries client as the inventory of saved data is kept within BRMS on the client system. All that the server sees is one or more save files. Because of this it is important to set up a special Tivoli Storage Manager policy domain to cope with the specific needs of iseries clients and to ensure that the best use is made of Tivoli Storage Manager server storage space. 412 IBM Tivoli Storage Management Concepts

24.9 iseries system as a Tivoli Storage Manager server IBM Tivoli Storage Manager for iseries integrates unattended network backup and archive with disaster recovery planning functions in a single software solution. Tivoli Storage Manager for iseries backs up and archives data from more than 30 multi-vendor platforms. In addition to the multiple client platforms, it supports leading devices and communication protocols. This broad range of support makes iseries server a comprehensive storage management solution. A typical example of how a Tivoli Storage Manager server can fit in with iseries systems is a distributed computing environment in which there may be an application that is divided into three parts. The data for the application is kept on an iseries system, the logic for the application may be kept on a Windows NT server, and the user interface for the application is stored locally on desktop PCs. If a disaster occurs on the logic or data machines then the whole application is unavailable. If a disaster occurs on a desktop PC then just that PC is affected. Tivoli Storage Manager can be used to back up all of the desktop PCs and the Windows NT server to the iseries system, creating a complete storage management solution. How does it work? IBM Tivoli Storage Manager for iseries works in the same basic way as any other Tivoli Storage Manager server. Tivoli Storage Manager for iseries supports all OS/400-supported disk drives, a wide range of OS/400-supported tape devices and library, both manual and automatic, and optical jukeboxes. The Tivoli Storage Manager for iseries support for automated libraries is slightly different to other platforms in that drives are not defined in Tivoli Storage Manager. Drive parameters are sorted out by OS/400 instead. It is also possible to utilize an external tape management system, such as BRMS, to handle tape libraries as well. When these libraries are defined to Tivoli Storage Manager, they are given a media library device parameter, which is used to point to the BRMS device name used for the tape drive or library. Exit programs are created (the samples supplied work with BRMS without any modifications) that take Tivoli Storage Manager commands and pass them onto the tape management system (such as BRMS) for processing. These commands enable BRMS to handle tape mount, dismount, expiration, and deletion processes. This enables BRMS and Tivoli Storage Manager to share a pool of scratch tapes if required. Chapter 24. iseries storage management solutions 413

24.10 Disaster recovery for the iseries The iseries client does not support bare machine recovery. Recovery of an iseries system relies on the recovery plan available through BRMS. This uses a step-by-step approach that explains exactly what must be done to recover the entire machine. It automatically uses Tivoli Storage Manager to recover objects wherever necessary. Recovery of a Tivoli Storage Manager server on an iseries system depends on how the iseries system has been backed up. Recovering a server running on an iseries system is a relatively straightforward process. BRMS (if installed) can be used to aid in the recovery of the server so as to make it a simple step-by-step procedure. 24.11 HSM on an iseries system There is no iseries (HSM) Tivoli Storage Manager for Space Management client. However, this capability does exist in BRMS as dynamic archival and retrieval. This enables certain types of iseries objects, such as files, to be archived to storage locations while leaving the object description on disk. The object is saved with storage freed, as shown in Figure 24-3 on page 415. The storage location can be any BRMS defined location, such as a BRMS tape or Tivoli Storage Manager server. When the file is accessed, BRMS is invoked to retrieve the data part of the file (the storage freed part), and if the object was last saved to a Tivoli Storage Manager server, then it will be retrieved using the BRMS Application Client. 414 IBM Tivoli Storage Management Concepts

Object Description Object Description Data Objects before saving with storage freed Objects after saving with storage freed Figure 24-3 iseries data before and after storage is freed 24.12 Large database and application support The backing up of very large databases can take a long time. That is why IBM and other vendors have created various agents that integrate with different database applications. These enable individual records to be backed up instead of the whole database file, saving a lot of time and storage pool space. Online backup is also supported to reduce or eliminate application downtime. At the time of writing, all application agents (Data Protection for applications) are supported by all Tivoli Storage Manager servers, including iseries systems. However, at this time no agents run as a client on the iseries system. The BRMS Application Client has not been designed with large database support in mind. If a single byte of information has changed in a database file, then the whole database file has to be backed up. The recommended method for backing up database files on the iseries system is to ensure that they are not in use. With applications such as Lotus Domino, it is preferable that the Domino server is temporarily shut down while the backup occurs to ensure that there are no mail file locks in place and to allow correct backup. Using a function of BRMS, it is possible to write into the backup control group that the Domino server should be shut down before invoking the backup. After the backup has completed another function can be called that restarts the server. Chapter 24. iseries storage management solutions 415

24.13 Logical partitions OS/400 V4R4 enables the 7xx, 6xx, and Sxx machines to support logical partitions (LPARS). With LPARS is possible to divide a single physical iseries system into smaller logical partitions (LPARS). Figure 24-4 shows a single iseries system on the left (SYS Lyon) and an example LPAR configuration on the right (SYS Lyon1, SYS Lyon2, SYS Lyon3). Each LPAR contains a proportion of the total available resource that is available to the single partition iseries system on the left (SYS Lyon). SYS Lyon OS/400 PPPP MMMM MMMM Logical Partitioning SYS Lyon1 OS/400 P MM SYS Lyon2 OS/400 P MM Secondary Partition 1 SYS Lyon3 OS/400 P MMMM Secondary Partition 2 Primary Partition Primary Partition P = Processor M = Memory Figure 24-4 Logical partition overview Using software called Virtual OptiConnect/400, it is possible to achieve very high data transfer rates between the different LPARs. With a Tivoli Storage Manager server on one partition and BRMS Application client on another, rates of 26GB/hour have been achieved. This would lend itself very well to installing a Tivoli Storage Manager server on one partition and backing up all of the user data from the other partitions to the Tivoli Storage Manager server at high speed. For more details about Logical Partitioning on iseries, see the redbook Slicing the AS/400 with Logical Partitioning: A How-to Guide, SG24-5439. 416 IBM Tivoli Storage Management Concepts

24.14 Integrated Netfinity Server Many iseries systems have an Integrated PC Server (IPCS), or the newer Integrated Netfinity Server installed. These hardware products (shown in Figure 24-5) enable a Microsoft Windows NT partition to run in the same footprint as the iseries system, using different Intel Pentium processors depending on the model. There are integration features that enable sharing of data and resources (such as tape and optical devices) between Windows NT and an iseries system. Figure 24-5 Windows NT server running on IPCS Careful thought has to be put into the backup and recovery strategy employed when protecting these Windows NT installations. Without Tivoli Storage Manager, BRMS (or native OS/400 save and restore commands) can be used to back up the whole server storage spaces at once. However, individual objects within the storage areas cannot be backed up and restored without using built-in Windows NT commands. Also, the Windows NT server must be shut down to back up the server storage areas, which of course means that users will not be able to access the Windows NT server during the backup operation. On some smaller Windows NT installations, it would be feasible for the network card to be shared between the iseries and Windows NT. When the Windows NT server is shut down it also means that the network card becomes unavailable for use by the iseries system, rendering LAN access to the iseries system impossible. The Tivoli Storage Manager backup-archive client code can be installed on the Windows NT server, just as on a conventional Windows NT machine. This allows individual files and programs to be backed up. The target Tivoli Storage Manager server can be the iseries system that has the IPCS installed, or it can be any Chapter 24. iseries storage management solutions 417

Tivoli Storage Manager server on the network. It is also possible to run an Tivoli Storage Manager server for Windows NT on the IPCS card. 418 IBM Tivoli Storage Management Concepts

Part 6 Part 6 Appendixes Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 419

420 IBM Tivoli Storage Management Concepts

A Appendix A. Planning and sizing worksheets This collection of worksheets was introduced in Chapter 4, Planning concepts on page 55. The redbook support material is available in softcopy from the redbooks Web server at: ftp://www.redbooks.ibm.com/redbooks/sg245416 Alternatively, you can get to the same Web page at: http://www.redbooks.ibm.com Select Additional Materials and click the suggested link (or follow the instructions given, as Web pages can change), then select SG245416. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 421

Table 24-2 Client requirements worksheet Client name Contact information Operating system Total storage available (GB) Total storage used (GB) GB changed per backup Number of files backed up Data compression Backup window times Backup number of hours Required recovery time IBM Tivoli Storage Manager recovery time GB copied per archive Number of files archived Number of archives kept Archive frequency Archive window times Archive number of hours Number of image backups Image backup frequency Number of backup sets Backupset frequency Policy domain Client option set Client 1 Client 2 Client 3 Client 4 422 IBM Tivoli Storage Management Concepts

Table 24-3 Storage policy requirements worksheet Group name Number of backup versions Backup file retention period Number of deleted versions Last deleted file version retention period Archive retention period off-site copies on-site collocation off-site collocation Image backup retention Backupset retention Example 1 Example 2 Example 3 Table 24-4 Database worksheet Database volume Filename (Primary) Size (MB Filename (Copy) Size (MB) Table 24-5 Recovery log worksheet Log Volume Filename (Primary) Size (MB) Filename (Copy) Size (MB) Total Total Appendix A. Planning and sizing worksheets 423

Table 24-6 Device configuration and volume history worksheet Name Size (MB) Total Table 24-7 Total IBM Tivoli Storage Manager disk required worksheet Size (MB) IBM Tivoli Storage Manager software (dependant on platform) IBM Tivoli Storage Manager database IBM Tivoli Storage Manager recovery log IBM Tivoli Storage Manager primary storage pools Device configuration table and volume history table Other (RAID, Operating system) Total 424 IBM Tivoli Storage Management Concepts

Table 24-8 Tape drive configuration worksheet Option Library model Number of drives Drive model Number of on-site tape volumes Number of off-site tape volumes Number of database volumes Number of scratch tapes Number of backupset tape volumes Total tape volumes required Table 24-9 Administrator IDs worksheet Functions IBM Tivoli Storage Manager ID Authority Appendix A. Planning and sizing worksheets 425

Table 24-10 License requirements worksheet Required Server type Client connections Network connections Open systems environment clients Space management 426 IBM Tivoli Storage Management Concepts

Glossary A Agent A software entity that runs on endpoints and provides management capability for other hardware or software. An example is an SNMP agent. An agent has the ability to spawn other processes. AL See arbitrated loop. Allocated storage The space that is allocated to volumes, but not assigned. Allocation The entire process of obtaining a volume and unit of external storage, and setting aside space on that storage for a data set. Arbitrated loop A Fibre Channel interconnection technology that allows up to 126 participating node ports and one participating fabric port to communicate. See also Fibre Channel Arbitrated Loop and loop topology. Array An arrangement of related disk drive modules that have been assigned to a group. B Bandwidth A measure of the data transfer rate of a transmission channel. Bridge Facilitates communication with LANs, SANs, and networks with dissimilar protocols. C Client A function that requests services from a server, and makes them available to the user. A term used in an environment to identify a machine that uses the resources of the network. Client authentication The verification of a client in secure communications where the identity of a server or browser (client) with whom you wish to communicate is discovered. A sender's authenticity is demonstrated by the digital certificate issued to the sender. Client-server relationship Any process that provides resources to other processes on a network is a server. Any process that employs these resources is a client. A machine can run client and server processes at the same time. Console D A user interface to a server. DATABASE 2 (DB2) A relational database management system. DB2 Universal Database is the relational database management system that is Web-enabled with Java support. Device driver A program that enables a computer to communicate with a specific device, for example, a disk drive. Disk group A set of disk drives that have been configured into one or more logical unit numbers. This term is used with RAID devices. Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 427

E Enterprise network A geographically dispersed network under the backing of one organization. Enterprise Storage Server (ESS) Provides an intelligent disk storage subsystem for systems across the enterprise. Event In the Tivoli environment, any significant change in the state of a system resource, network resource, or network application. An event can be generated for a problem, for the resolution of a problem, or for the successful completion of a task. Examples of events are: the normal starting and s ping of a process, the abnormal termination of a process, and the malfunctioning of a server. F Fabric The Fibre Channel employs a fabric to connect devices. A fabric can be as simple as a single cable connecting two devices. The term is often used to describe a more complex network utilizing hubs, switches, and gateways. FC FCS See Fibre Channel. See Fibre Channel standard. Fiber optic The medium and the technology associated with the transmission of information along a glass or plastic wire or fiber. Fibre Channel Arbitrated Loop A reference to the FC-AL standard, a shared gigabit media for up to 127 nodes, one of which can be attached to a switch fabric. See also arbitrated loop and loop topology. Refer to American National Standards Institute (ANSI) X3T11/93-275. Fibre Channel standard An ANSI standard for a computer peripheral interface. The I/O interface defines a protocol for communication over a serial interface that configures attached units to a communication fabric. Refer to ANSI X3.230-199x. File system An individual file system on a host. This is the smallest unit that can monitor and extend. Policy values defined at this level override those that might be defined at higher levels. G Gateway In the SAN environment, a gateway connects two or more different remote SANs with each other. A gateway can also be a server on which a gateway component runs. H Hardware zoning Hardware zoning is based on physical ports. The members of a zone are physical ports on the fabric switch. It can be implemented in the following configurations: one to one, one to many, and many to many. Fibre Channel A technology for transmitting data between computer devices at a data rate of up to 1 Gb. It is especially suited for connecting computer servers to shared storage devices and for interconnecting storage controllers and drives. HBA See host bus adapter. 428 IBM Tivoli Storage Management Concepts

Host Any system that has at least one internet address associated with it. A host with multiple network interfaces can have multiple internet addresses associated with it. This is also referred to as a server. Host bus adapter (HBA) A Fibre Channel HBA connection that allows a workstation to attach to the SAN network. Hub A Fibre Channel device that connects up to 126 nodes into a logical loop. All connected nodes share the bandwidth of this one logical loop. Hubs automatically recognize an active node and insert the node into the loop. A node that fails or is powered off is automatically removed from the loop. IP J Internet protocol. Java A programming language that enables application developers to create object-oriented programs that are very secure, portable across different machine and operating system platforms, and dynamic enough to allow expandability. Java runtime environment (JRE) The underlying, invisible system on your computer that runs applets the browser passes to it. Java Virtual Machine (JVM) The execution environment within which Java programs run. The Java virtual machine is described by the Java Machine Specification which is published by Sun Microsystems. Because the Tivoli Kernel Services is based on Java, nearly all ORB and component functions execute in a Java virtual machine. JBOD Just a Bunch Of Disks. JVM L See Java Virtual Machine. Logical unit number (LUN) The LUNs are provided by the storage devices attached to the SAN. This number provides you with a volume identifier that is unique among all storage servers. The LUN is synonymous with a physical disk drive or a SCSI device. For disk subsystems such as the IBM Enterprise Storage Server, a LUN is a logical disk drive. This is a unit of storage on the SAN which is available for assignment or unassignment to a host server. Loop topology In a loop topology, the available bandwidth is shared with all the nodes connected to the loop. If a node fails or is not powered on, the loop is out of operation. This can be corrected using a hub. A hub opens the loop when a new node is connected and closes it when a node disconnects. See also Fibre Channel Arbitrated Loop and arbitrated loop. LUN See logical unit number. LUN assignment criteria The combination of a set of LUN types, a minimum size, and a maximum size used for selecting a LUN for automatic assignment. LUN masking This allows or blocks access to the storage devices on the SAN. Intelligent disk subsystems such as the IBM Enterprise Storage Server provide this kind of masking. M Managed object A managed resource. JRE See Java runtime environment. Glossary 429

Managed resource managed. A physical element to be O Management Information Base (MIB) A logical database residing in the managed system which defines a set of MIB objects. A MIB is considered a logical database because actual data is not stored in it, but rather provides a view of the data that can be accessed on a managed system. MIB See Management Information Base. MIB object A MIB object is a unit of managed information that specifically describes an aspect of a system. Examples are CPU utilization, software name, hardware type, and so on. A collection of related MIB objects is defined as a MIB. N Network topology A physical arrangement of nodes and interconnecting communications links in networks based on application requirements and geographical distribution of users. N_Port node port A Fibre Channel-defined hardware entity at the end of a link which provides the mechanisms necessary to transport information units to or from another node. NL_Port node loop port A node port that supports arbitrated loop devices. Open system A system whose characteristics comply with standards made available throughout the industry, and therefore can be connected to other systems that comply with the same standards. P Point-to-point topology It consists of a single connection between two nodes. All the bandwidth is dedicated for these two nodes. Port An end point for communication between applications, generally referring to a logical connection. A port provides queues for sending and receiving data. Each port has a port number for identification. When the port number is combined with an Internet address, it is called a socket address. Port zoning In Fibre Channel environments, port zoning is the grouping together of multiple ports to form a virtual private storage network. Ports that are members of a group or zone can communicate with each other but are isolated from ports in other zones. See also LUN masking and subsystem masking. Protocol The set of rules governing the operation of functional units of a communication system if communication is to take place. Protocols can determine low-level details of machine-to-machine interfaces, such as the order in which bits from a byte are sent. They can also determine high-level exchanges between application programs, such as file transfer. 430 IBM Tivoli Storage Management Concepts

R RAID Redundant array of inexpensive or independent disks. A method of configuring multiple disk drives in a storage subsystem for high availability and high performance. S SAN See storage area network. SAN agent A software program that communicates with the manager and controls the subagents. This component is largely platform independent. See also subagent. SCSI Small Computer System Interface. An ANSI standard for a logical interface to computer peripherals and for a computer peripheral interface. The interface utilizes a SCSI logical protocol over an I/O interface that configures attached targets and initiators in a multi-drop bus topology. Server A program running on a mainframe, workstation, or file server that provides shared services. This is also referred to as a host. Shared storage Storage within a storage facility that is configured such that multiple homogeneous or divergent hosts can concurrently access the storage. The storage has a uniform appearance to all hosts. The host programs that access the storage must have a common model for the information on a storage device. You need to design the programs to handle the effects of concurrent access. Simple Network Management Protocol (SNMP) A protocol designed to give a user the capability to remotely manage a computer network by polling and setting terminal values and monitoring network events. SNMP See Simple Network Management Protocol. SNMP agent An implementation of a network management application which is resident on a managed system. Each node that is to be monitored or managed by an SNMP manager in a TCP/IP network, must have an SNMP agent resident. The agent receives requests to either retrieve or modify management information by referencing MIB objects. MIB objects are referenced by the agent whenever a valid request from an SNMP manager is received. SNMP manager A managing system that executes a managing application or suite of applications. These applications depend on MIB objects for information that resides on the managed system. SNMP trap A message that is originated by an agent application to alert a managing application of the occurrence of an event. Software zoning Is implemented within the Simple Name Server (SNS) running inside the fabric switch. When using software zoning, the members of the zone can be defined with: node WWN, port WWN, or physical port number. Usually the zoning software also allows you to create symbolic names for the zone members and for the zones themselves. SQL Structured Query Language. Storage administrator A person in the data processing center who is responsible for defining, implementing, and maintaining storage management policies. Storage area network (SAN) A managed, high-speed network that enables any-to-any interconnection of heterogeneous servers and storage systems. Glossary 431

Subagent A software component of SAN products which provides the actual remote query and control function, such as gathering host information and communicating with other components. This component is platform dependent. See also SAN agent. Subsystem masking The support provided by intelligent disk storage subsystems such as the Enterprise Storage Server. See also LUN masking and port zoning. Switch A component with multiple entry and exit points or ports that provide dynamic connection between any two of these points. Switch topology A switch allows multiple concurrent connections between nodes. There can be two types of switches, circuit switches and frame switches. Circuit switches establish a dedicated connection between two nodes. Frame switches route frames between nodes and establish the connection only when needed. A switch can handle all protocols. System Management Interface Tool (SMIT) An interactive interface application. T W WAN Wide Area Network. Z Zoning In Fibre Channel environments, zoning allows for finer segmentation of the switched fabric. Zoning can be used to instigate a barrier between different environments. Ports that are members of a zone can communicate with each other but are isolated from ports in other zones. Zoning can be implemented in two ways: hardware zoning and software zoning. Other glossaries: For more information about IBM terminology, see the IBM Storage Glossary of Terms at: http://www.storage.ibm.com/glossary.htm For more information about IBM Tivoli terminology, see the IBM Tivoli Glossary at: http://publib.boulder.ibm.com/tividd/glo ssary/termsmst04.htm TCP See Transmission Control Protocol. TCP/IP Transmission Control Protocol/Internet Protocol. Topology An interconnection scheme that allows multiple Fibre Channel ports to communicate. For example, point-to-point, arbitrated loop, and switched fabric are all Fibre Channel topologies. Transmission Control Protocol (TCP) A reliable, full duplex, connection-oriented, end-to-end transport protocol running on of IP. 432 IBM Tivoli Storage Management Concepts

Abbreviations and acronyms ACL AD ADSM AIX ANSI API APPC ASCII ASR BAROC BSF CA CIDR CIFS CPU DES Access Control List Microsoft Active Directory ADSTAR Distributed Storage Manager Advanced Interactive Executive American National Standards Institute Application Programming Interface Advanced Program-to-Program Communication American National Standard Code for Information Interchange Automated System Recovery Basic Recorder of Objects in C Bean Scripting Framework Certification Authorities Classless InterDomain Routing Common Internet File System Central Processing Unit Data Encryption Standard EBU EFS EISA EJB ERP ESS FAT FC FIFO GUI HACMP HBA HSM HTTP IBM ICCM I/O IP IPX Enterprise Backup Utility Encrypting File Systems Extended Industry Standard Architecture Enterprise Java Bean Enterprise Resources Planning Enterprise Storage Server File Allocation Table Fibre Channel First In/First Out Graphical User Interface High Availability Cluster Multiprocessing Host Bus Adapter Hierarchical Storage Management Hypertext Transfer Protocol International Business Machines Corporation Inter-Client Conventions Manual Input/Output Internet Protocol Internetwork Packet Exchange DNS Domain Name System Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 433

ISV Independent Software Vendor PDF Portable Document Format ITSO International Technical Support Organization PMI Performance Monitoring Interface JAR JCA JNDI LAN LP LPARS LUN MDC MMC MSCS MSSQL NAS NDMP NFS NIM NTFS ODBC ODM ORB OS PASE Java Archive Java Connector Architecture Java Naming and Directory Interface Local Area Network Logical Partition Logical Partitions Logical Unit Number Meta Data Controller Microsoft Management Console Microsoft Cluster Server Microsoft SQL Network Attached Storage Network Data Management Protocol Network File System Network Installation Management NT File System Open Database Connectivity Object Data Manager Object Request Broker Operating System Portable Application Solutions Environment PSM RACF RAID RDBMS RGID RISC RMAN RSM SAN SAP SCSI SDK SMB SMIT SMP SNMP SOAP SP Persistent Storage Manager Resource Access Control Facility Redundant Array of Independent Disks Relational Database Management System Real Group Identifier Reduced Instruction Set Computer Oracle Recovery Manager Removable Storage Management Storage Area Network Systeme, Applikationen und Produkte Small Computer System Interface Software Developer's Kit Server Message Block System Management Interface Tool Symmetric Multiprocessor Simple Network Management Protocol Simple Object Access Protocol System Parallel 434 IBM Tivoli Storage Management Concepts

SQL SRM SSA SSL TCP/IP TSM UDB UDDI UFS UID URL WAN WSDL WSIF WWW XBSA XML Structured Query Language Security Reference Monitor Serial Storage Architecture Secure Sockets Layer Transmission Control Protocol/Internet Protocol IBM Tivoli Storage Manager Universal Database Universal Description, Discovery, and Integration UNIX File System User Identifier Universal Resource Locator Wide Area Network Web Services Description Language Web Services Invocation Framework World Wide Web X/OPEN Backup Services Application Programmer s Interface Extensible Markup Language Abbreviations and acronyms 435

436 IBM Tivoli Storage Management Concepts

Related publications The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook. IBM Redbooks For information about ordering these publications, see How to get IBM Redbooks on page 442. Note that some of the documents referenced here may be available in softcopy only. A Practical Guide to Tivoli SANergy, SG24-6146 Backing Up DB2 Using Tivoli Storage Manager, SG24-6247 Backing Up Lotus Domino R5 Using Tivoli Storage Management, SG24-5247 Backing Up Oracle Using Tivoli Storage Management, SG24-6249 Backing up WebSphere Application Server with Tivoli Storage Management, REDP0149 Deploying the Tivoli Storage Manager Client in a Windows 2000 Environment, SG24-6141 Disaster Recovery Strategies with Tivoli Storage Management, SG24-6844 Getting Started with Tivoli Storage Manager: Implementation Guide, SG24-5416 IBM TotalStorage NAS Backup and Recovery Solutions, SG24-6831 IBM TotalStorage Solutions for Disaster Recovery, SG24-6547 The IBM TotalStorage Solutions Handbook, SG24-5250 Implementing IBM LTO in Linux and Windows, SG24-6268 Implementing the IBM TotalStorage NAS 300G: High Speed Cross Platform Storage and Tivoli SANergy!, SG24-6278 Introduction to SAN Distance Solutions, SG24-6408 Managing device addressing of SAN attached tape for use with Tivoli Storage Manager, REDP0150 R/3 Data Management Techniques Using Tivoli Storage Manager, SG24-5743 Tivoli Storage Manager Version 4.2 Technical Guide, SG24-6277 Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 437

Tivoli Storage Manager Version 5.1 Technical Guide, SG24-6554 Using IBM LTO Ultrium with Open Systems, SG24-6502 Using Tivoli Data Protection for Microsoft Exchange Server, SG24-6147 Using Tivoli Data Protection for Microsoft SQL Server, SG24-6148 Using Tivoli Storage Manager to Back Up Lotus Notes, SG24-4534 Using Tivoli Storage Manager in a SAN Environment, SG24-6132 Using TSM in a Clustered Windows NT Environment, SG24-5742 Other publications These publications are also relevant as further information sources: IBM Tivoli Storage Manager for AIX Quick Start V5.2, GC32-0770 IBM Tivoli Storage Manager for AIX Administrator's Guide V5.2, GC32-0768 IBM Tivoli Storage Manager for AIX Administrator's Reference V5.2, GC32-0769 IBM Tivoli Storage Manager for HP-UX Quick Start V5.2, GC32-0774 IBM Tivoli Storage Manager for HP-UX Administrator's Guide V5.2, GC32-0772 IBM Tivoli Storage Manager for HP-UX Administrator's Reference V5.2, GC32-0773 IBM Tivoli Storage Manager for Linux Quick Start V5.2, GC32-4692 IBM Tivoli Storage Manager for Linux Administrator's Guide V5.2, GC32-4690 IBM Tivoli Storage Manager for Linux Administrator's Reference V5.2, GC32-4691 IBM Tivoli Storage Manager for Sun Solaris Quick Start V5.2, GC32-0780 IBM Tivoli Storage Manager for Sun Solaris Administrator's Guide V5.2, GC32-0778 IBM Tivoli Storage Manager for Sun Solaris Administrator's Reference V5.2, GC32-0779 IBM Tivoli Storage Manager for Windows Quick Start V5.2, GC32-0784 IBM Tivoli Storage Manager for Windows Administrator's Guide V5.2, GC32-0782 IBM Tivoli Storage Manager for Windows Administrator's Reference V5.2, GC32-0783 438 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Manager for AIX Storage Agent User s Guide, GC32-0771 IBM Tivoli Storage Manager for HP-UX Storage Agent User s Guide, GC32-0727 IBM Tivoli Storage Manager for Linux Storage Agent User s Guide, GC32-4693 IBM Tivoli Storage Manager for Sun Solaris Storage Agent User s Guide, GC32-0781 IBM Tivoli Storage Manager for Windows Storage Agent User s Guide, GC32-0785 IBM Tivoli Storage Manager for UNIX Backup-Archive Clients Installation and User s Guide V5.2, GC32-0789 IBM Tivoli Storage Manager for Windows Backup-Archive Clients Installation and User s Guide V5.2, GC32-0788 IBM Tivoli Storage Manager for Space Management for UNIX: User s Guide, GC32-0794 IBM Tivoli Storage Manager for System Backup and Recovery V5R6 - Installation and User's Guide, GC32-9076 Tivoli Storage Manager SANergy Administrator's Guide, GC32-0740 IBM Tivoli Storage Manager for Application Servers: Data Protection for WebSphere Application Server Installation and User s Guide, SC32-9075 IBM Tivoli Storage Manager for Databases: Data Protection for Microsoft SQL Server Installation and User s Guide, SC32-9059 IBM Tivoli Storage Manager for Databases: Data Protection for Oracle for UNIX Installation and User s Guide, SC32-9064 IBM Tivoli Storage Manager for Databases: Data Protection for Oracle for Windows Installation and User s Guide, SC32-9065 IBM Tivoli Storage Manager for Databases: Data Protection for Informix Installation and User s Guide, SH26-4095 IBM Tivoli Storage Manager for Enterprise Resource Planning: Data Protection for R/3 Installation and User s Guide for DB2 UDB, SC33-6341 IBM Tivoli Storage Manager for Enterprise Resource Planning: Data Protection for R/3 Installation and User s Guide for Oracle, SC33-6340 IBM Tivoli Storage Manager for Hardware: Data Protection for EMC Symmetrix for R/3 Installation and User s Guide, SC33-6386 IBM Tivoli Storage Manager for Hardware: Data Protection for Enterprise Storage Server Databases (DB2 UDB) Installation and User s Guide, SC32-9060 Related publications 439

IBM Tivoli Storage Manager for Hardware: Data Protection for Enterprise Storage Server Databases (Oracle) Installation and User s Guide, SC32-9061 IBM Tivoli Storage Manager for Hardware: Data Protection for IBM ESS for R/3 Installation and User s Guide for DB2 UDB, SC33-8204 IBM Tivoli Storage Manager for Hardware: Data Protection for IBM ESS for R/3 Installation and User s Guide for Oracle, SC33-8205 IBM Tivoli Storage Manager for Mail: Data Protection for Lotus Domino for UNIX and OS/400 Installation and User s Guide, SC32-9056 IBM Tivoli Storage Manager for Mail: Data Protection for Lotus Domino for Windows Installation, SC32-9057 IBM Tivoli Storage Manager for Mail: Data Protection for Lotus Domino, S/390 Edition Licensed Program Specifications, GC26-7305 IBM Tivoli Storage Manager for Mail: Data Protection for Microsoft Exchange Server Installation and User s Guide, SC32-9058 IBM Tivoli Storage Manager Using the Application Program Interface V5.2, GC32-0793 Online resources These Web sites are also relevant as further information sources: IBM Software: Storage Management http://www-3.ibm.com/software/tivoli/solutions/storage/products.html IBM Tivoli Software support site http://www-3.ibm.com/software/sysmgmt/products/support/ IBM Tivoli Storage Area Network Manager http://www-3.ibm.com/software/tivoli/products/storage-san-mgr/ IBM Tivoli Storage Manager http://www-3.ibm.com/software/tivoli/products/storage-mgr/ IBM Tivoli Storage Manager Extended Edition http://www-3.ibm.com/software/tivoli/products/storage-mgr-extended/ IBM Tivoli Storage Manager for Application Servers http://www-3.ibm.com/software/tivoli/products/storage-mgr-app-servers/ IBM Tivoli Storage Manager for Databases http://www-3.ibm.com/software/tivoli/products/storage-mgr-db/ 440 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Manager for Enterprise Resource Planning http://www-3.ibm.com/software/tivoli/products/storage-mgr-erp/ IBM Tivoli Storage Manager for Hardware http://www-3.ibm.com/software/tivoli/products/storage-mgr-hardware IBM Tivoli Storage Manager for Mail http://www-3.ibm.com/software/tivoli/products/storage-mgr-mail/ IBM Tivoli Storage Manager for Space Management http://www-3.ibm.com/software/tivoli/products/storage-mgr-space/ IBM Tivoli Storage Manager for Storage Area Networks http://www-3.ibm.com/software/tivoli/products/storage-mgr-san/ IBM Tivoli Storage Manager for System Backup and Recovery http://www-3.ibm.com/software/tivoli/products/storage-mgr-sysback/ IBM Tivoli Storage Resource Manager http://www-3.ibm.com/software/tivoli/products/storage-resource-mgr/ IBM.com ftp Software Server ftp://ftp.software.ibm.com/storage/tivoli-storage-management/ Tivoli SANergy http://www-3.ibm.com/software/tivoli/products/sanergy/ Tivoli Software Information Center http://publib.boulder.ibm.com/tividd/td/tdprodlist.html IBM Content Manager CommonStore Web site http://www-3.ibm.com/software/data/commonstore/ IBM Performance Management Guide http://publibn.boulder.ibm.com/doc_link/en_us/a_doc_lib/aixbman/prftungd/pr ftungd.htm iseries Information Center http://publib.boulder.ibm.com/pubs/html/as400 White Papers for AS/400 and iseries http://www.ibm.com/servers/eserver/iseries/whpapr/ifs.html IBM Storage Media Product Selector http://www.storage.ibm.com/media/products.html IBM Tape and Optical Storage http://www.storage.ibm.com/hardsoft/tape/index.html Related publications 441

Kernel Extensions and Device Support Programming Concepts http://publibn.boulder.ibm.com/doc_link/en_us/a_doc_lib/aixprggd/kernextc/l s_devconfig_subr.htm IBM HP-UX Tape and Medium Changer Device Driver (ATDD) Readme file ftp://ftp.software.ibm.com/storage/devdrvr/hpux/readme IBM Developer Kit for AIX, Java Technology Edition http://www-106.ibm.com/developerworks/java/jdk/aix/index.html American National Standards Organization http://www.ansi.org Cristie Data Products http://www.cristie.com The Source for Java Technology http://java.sun.com/ Redhat Linux http://www.redhat.com/ SuSE Linux http://www.suse.com/index_us.html The Linux Documentation Project http://www.tldp.org/ Open Source software development website http://sourceforge.net/ Linux RPM search engine http://www.rpmfind.net/ How to get IBM Redbooks You can search for, view, or download Redbooks, Redpapers, Hints and Tips, draft publications, and additional materials, as well as order hardcopy Redbooks or CD-ROMs, at this Web site: ibm.com/redbooks 442 IBM Tivoli Storage Management Concepts

Help from IBM IBM Support and downloads ibm.com/support IBM Global Services ibm.com/services Related publications 443

444 IBM Tivoli Storage Management Concepts

Index A accounting log 280 ACL 109 activation process, policy set 170 active file versions 115 activity log 280 Adaptive Differencing technology 5 Adaptive sub-file backup adding components 110 considerations 110 non-file data 111 restore limitations 111 scheduling of mobile backup 110 versioning and expiration 110 adaptive subfile backup 71, 107 administration 34 interfaces 35 administrative command routing 35 administrative control 171 administrative schedules 174 administrator 214 change authority 218 create 214 locking and unlocking 218 remove 218 rename 218 request information 219 administrator-defined objects 183 advanced settings for clients 137 AIX 20, 247 AIX-based clustering 247 analyst 216 ANS1312E 190 any-to-any access 24 API 21, 36, 145, 299 API client 145 environment 148 multithreaded mode 150 options files 147 overview 146 package 146 passwordaccess 149 shared library 146 usage 146 with LAN-free 146 application management 24 application protection 28 Application Servers 13 Architectural concepts 27 architecture 30, 67, 159, 231 architecture overview 30 archival concepts 37 archive 72, 121 instant 72 package description 121 packages 121 retention period 123 archive copy group 167, 238 archive objects 146 ASR 142 asset utilization 24 assign management classes 146 auditing 219 authentication 45 client 139 authority levels 214 autodetection 211 Automated System Recovery 142 automation 173 available on-demand 24 B BACKINT File Manager 364 BACKINT Operation 362 backup 98, 120 binding 118 copy group 165 extra version retention 117 incremental 100 journal-based 111 logical volume 104 mode and frequency 166 open file 107 progress 99 selective 101 using hardware snapshot 72 Copyright IBM Corp. 1997, 2000, 2003. All rights reserved. 445

backup concepts 37 backup operations 69 Backup Recovery Media Services see BRMS. backup schemes 38 backup set 38, 124 planning 125 portable 125 restore 132 backup strategies 378 backup techniques 315 backup topology 8 backup versus archive 136 backup-archive client 83, 350 batch mode 88 support with MSCS 252 user interfaces 32 backup-restore operation types 70 base file component 109 basic concepts 37 better planning 59 binding concepts 119 BRMS application client 411 components 410 terminology 409 BRMS/400 409 Business Continuity Plan 256 Business Impact Analysis 256 business needs 24 Business Recovery Plan 256 business requirements 23 business value 24 C CBMR backup and restore software 399 components 399 customized Linux version 399 deployment steps 400 function 399 Open File Module 399 overview 398 with IBM Tivoli Storage Manager 398 central event logging functions 35 central scheduling 174 centralized administration 3 centralized data 24 centralized management 28 centralizing storage 24 change authority 218 CIFS 75, 391 CLI 87 IBM Tivoli Storage Manager 87 client CLI 87 command line 88 configuration and options files 90 configuration information 6 GUI 85 minimum configuration parameters 91 session information 89 web interface 89 Windows interface 86 client access authority 217 client application container 371 client architecture 67 client authentication 139 client components 84 client compression 138 client definition 84 client error log 281 client events central logging 281 client GUI interface 33 client interfaces 85 client node information 281 client option sets 223 client owner authority 217 client platforms 20 client polling 177 client schedule 137 examples of 176 one-time 179 server prompted 176 client security 220 client space reduction 122 client threads multiple 93 client transaction 97 cluster node 249 clustered servers 25 clustering 245 CLUSTERNODE 253 cold site 267 collocation 41, 183, 198 command line 33 command line interface 446 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Manager 87 command routing 236 COMMRESTARTDURATION 248 COMMRESTARTINTERVAL 248 complementary products 301, 381 comprehensive management 28 compression 138 concepts 37, 39, 55 concepts, storage solutions, solutions 1 concurrent file access 75 Consumer thread 93 94 control data 109 copy group 162 163 archive 167 backup 165 copy groups 163 164 copy pool duplexing 189 copy storage pool 188 cost 24 Courier state 261 Cristie Bare Machine Recovery see CBMR. cross-platform restore 133 customized backup solutions 3 D DACL 109 daily incremental backup 100 data retention rules 163 data flow 164 data integrity 25 data movement 200 type 69 data movement between servers 239 data mover 187 data objects 39 Data ONTAP 8 data protection 23, 25 Data Protection components 12, 36, 299 Data Protection for applications 299 Data Protection for Informix 14, 325 backup utilities 326 catalog tables 330 components 328 ON-Archive 327 ON-Bar 328 329 ontape utility 327 tbtape utility 327 XBSA 329 Data Protection for Lotus Domino 17, 344, 351 Data Protection for Microsoft Exchange backup strategy 356 security 355 Data Protection for Microsoft Exchange Server 18, 352 Data Protection for Microsoft SQL Server 15, 334 LAN-free 339 overview 339 SQL server services 335 Data Protection for Oracle 15, 330 alter table space utility 333 Backup 331 EBU 331 RMAN 331 Data Protection for SAP R/3 363 administration tools 364 performance enhancements 364 data restoration 140 data sharing 23 24 data storage 183 database 14, 280, 315 backup techniques 306 configuration files 306 control files 306 database export 309 disk mirroring 308 full backup 311 fundamental structure 304 IBM Tivoli Storage Manager for Databases 315 initialization parameter 306 log file backup 312 log files 305 offline backup 310 online backup 310, 360 partial backup 311 recovery technique 314 restore techniques 314 table spaces 305 tables 305 DB2 322 data protection 322 DB2 data protection DB2 UDB 323 IBM Tivoli Storage Manager API 323 integration 325 ON-Bar emergency boot file 330 ON-Bar message file 330 Index 447

default policy 171 define backupset 125 delta file component 109 Demilitarized Zones 221 device class 185 device concepts 39 device management 184 device mapping 211 devices 21 differential backup 114 dirty backup inconsistent state 164 disaster 266 disaster recovery 23, 25, 256 issues 273 disaster recovery for AS/400 414 disaster recovery plan 256 disaster recovery plan file 6 disaster recovery techniques 267 disk caching 200 disk mirroring 202, 308 breaking the mirror 308 simulated online 309 with striping 202 disk storage protection 201 disk storage, RAID 201 DMZ 221 domain policy 162 domain privilege 174 drive 186 DRM PREPARE 263 dsmc 88 DSMC program 87 dynamic 165 dynamic multithreaded transfer 4 E EBU 331 efficient management 3 electronic vaulting with virtual volumes 238 element number autodetection 212 encrypted password 233 Encryption considerations 140 encryption 139 end-to-end software management 28 enterpise solutions 291 enterprise administration 5, 232 Enterprise Administration features 235 enterprise command routing 235 enterprise configuration 35 enterprise configuration and policy management 235 Enterprise Console 233 enterprise logging 236 enterprise management features 232 enterprise monitoring 234 enterprise protection 28 29 enterprise reporting 234 Enterprise Resource Planning see ERP. Enterprise Solution 28 entities 98 ERP 3, 357 error logging central 281 ESS 72, 78 essential applications backup 78 event log 181 event reporting 282 Exchange Application Client functions 354 Exchange Server 352 backup strategy 356 database backup 354 database backup delete 355 database restore 355 ExMerge 352 expiration 129 explicit binding 167 to management class 168 export 240 export directly to server 241 export server 240 export to sequential media 240 export/import admin 241 node 241 policy 242 server 242 externalized interfaces 36 F fabric failover 209 fault tolerance 26 448 IBM Tivoli Storage Management Concepts

features 4 FILE deviceclass 75 file level 38 file sharing 395 firewall 221 FlashCopy 72, 78 fragmentation, tape volumes 193 fragmented volumes reclamation 194 frequency 166 frequency, scheduling 180 G generate backupset 124 group backup 115 GUI 85 H HACMP 246 configuration with TSM 247 hardware 16 hardware support 28 heartbeat monitoring 282 heterogeneous file sharing 392 Hierarchical Storage Management see HSM. Hierarchical Storage Manager 151 hierarchical structures 40 high availability 245 High Availability Cluster Multi-Processing see HAC- MP. highly scalable 28 high-speed automated server recovery 3 hot site 268 HP-UX 20 HSM 414 HSM client 151, 248 HSM migration 153 HSM support 250 HTTP port 222 httpport 222 I IBM 299 IBM Global Solutions Directory 401 IBM Storage Network Solutions 24 IBM Tivoli Disaster Recovery Manager 6 IBM Tivoli Distributed Monitoring 294 IBM Tivoli Enterprise architecture 292 IBM Tivoli Enterprise Console 236, 297 event adapter 298 IBM Tivoli Inventory 296 IBM Tivoli SANergy 24, 75, 391 backup and recovery 395 benefits 392 file sharing 395 limitations 396 requirements 396 sharing disk volumes 392 volume sharing 393 IBM Tivoli Software Distribution 295 IBM Tivoli Storage Area Network Manager 382 Agent 385 components 383 functions 385 Server 384 SNMP 385 supported devices 385 IBM Tivoli Storage Management Enterprise Solution 28 IBM Tivoli Storage Management Solution 27 IBM Tivoli Storage Manager Adaptive Differencing technology 51 additional products 10 administration 34, 52 architecture 30 backup set 72 backup-archive client 350 collocation 48 command line interface 87 copy group 162 database 47 device mapping 211 disaster recovery plans 53 element autodetection 211 Enterprise administration 49 export 240 externalized interfaces 36 instant archive 50, 72 introduction 3 iseries Server 413 key areas 51 LAN-free data transfer 51 managing multiple servers 232 managing off-site tape volumes 52 media 52 media management 49 media rotation/migration 52 Index 449

mixed-media libraries 185 Mobile backup 51 on-site and offsite storage 52 operator time 52 optional products 10 planning 62 product highlights 47 progressive backup methodology 48 rapid recovery 50 reclamation 48 SAN device mapping 211 SAN tape resource sharing 51 split-mirror backup 72 tape library slots usage 51 versions 70 IBM Tivoli Storage Manager Extended Edition 5 6 IBM Tivoli Storage Manager for Application Servers 13 architecture 375 backup strategies 378 differential backup 378 features 376 full backups 378 functions 376 overview 374 periodic full backups 379 WebSphere Application Server backup 377 WebSphere Application Server query 377 WebSphere Application Server restore 377 IBM Tivoli Storage Manager for Applications 367 IBM Tivoli Storage Manager for AS/400 Disaster Recovery Manager 414 IBM Tivoli Storage Manager for Databases 14, 303, 315 backup requirements 318 backup windows 321 event types 318 LAN-free backup 312 planning 317 recovery points 321 recovery speed 320 techniques 315 units of recovery 321 IBM Tivoli Storage Manager for Enterprise Resource Planning 18, 357 overview 358 IBM Tivoli Storage Manager for Hardware 16 IBM Tivoli Storage Manager for Mail 16, 343 IBM Tivoli Storage Manager for Space Management 10, 151 advanced transparent recall 156 archive and retrieve 158 automatic migration 154 backup and restore 157 HSM migration 153 introduction 152 options 157 pre-migration 154 recall 155 selective migration 154 IBM Tivoli Storage Manager for Storage Area Networks 11 IBM Tivoli Storage Manager for System Backup and Recovery 11 IBM Tivoli Storage Manager server 31 features 31 IBM Tivoli Storage Manager servers management of multiple 232 IBM Tivoli Storage Manager Storage Agent 340 IBM Tivoli Storage Manager supported devices 21 IBM Tivoli Storage Manager supported platforms 20 IBM Tivoli Storage Manager Version 5.2 API 21 IBM Tivoli Storage Manager Version 5.2 clients 20 IBM Tivoli Storage Manager Version 5.2 servers 20 IBM Tivoli Storage Resource Manager 386 architecture 387 Clients 390 components 389 products in package 388 security 391 Server 390 SRM Agent 390 WWW Server 390 IBM Tivoli Systems Management Framework 292 293 IBM Tivoli Web site 401 identifying offsite volume 259 image backup 71, 81, 104 options 106 with differential backups 71 import 240 importance of data 56 improve hardware utilization 24 improve software utilization 24 INACTIVE 116 inactive file versions 115 include-exclude lists 102, 120 450 IBM Tivoli Storage Management Concepts

incrbydate 114 increase network response time 24 incremental 113 incremental backup 100 incremental-by-date 113 copy group frequency 114 rebind 114 INCRThreshold 114 Information Technology Recovery Plan 256 Informix 14 Informix Dynamic server 14 instant archive 39, 72 integrating tape management systems 260 integration with applications 10 intelligent data movement 28 intelligent data storage 28 interactive mode 87 introduction 3 IPCS 417 iscsi 24 iseries 403 API client 411 application support 415 disaster recovery 414 HSM 414 IBM Tivoli Storage Manager Server 413 IPCS 417 large database 415 Netfinity server 417 requirements 407 with IBM Tivoli Storage Manager 404 J journal-based backup 71, 111, 113 advantages 113 overview 112 K Kerberos 45 key management 140 L LAN 186 LAN and WAN backup 73 LAN environment 73 LAN-free backup 74 LAN-free backup/restore 11 LAN-free client data transfer 207 LAN-free data transfer 4 LAN-free path 77 LAN-free recovery 39 libraries 185 library 186 improve efficiency 210 partitioning 210 sharing 210 library client 242 library sharing 242 license compliance 226 complimentary products 227 features 226 licensing 225 Linux 20, 399 load balancing 24 logical entities 40 logical volume 82 restore 131 logical volume backup 82, 104 logical volume restore 131 Logical Volume Snapshot Agent 107 Logical Volume Storage Agent 82 loop mode 87 Lotus Domino R6 17, 345 backup-archive client 350 components 346 data 349 platforms 346 storage management 349 user interface 346 LTO 186 mixed media with TSM 185 LVSA 107 M Macintosh 20 Mail 16 Main thread 94 manage file spaces 146 Managed Storage Services 26 Managed System for SAN Storage Agent 340 management class 81, 119, 167, 238 explicit binding 168 structure 168 maximum file size Index 451

storage pool 193 MAXNUMMP 96, 190 MAXSESSIONS 96 maxsize 193 MAXSIZE parameter 193 media management 271 media support 126 Microsoft Cluster Server see MSCS. Microsoft Exchange Server 18, 352 Microsoft SQL Server 14, 334 Microsoft Volume Shadow-Copy Service 107 migration delay, storage pool 192 Mirror 268 mirror 268 mirrored disk 25 mission-critical 25 mixed generation device 185 mixed media 185 Mountable state 260 movement of data 191 MSCS 246, 250, 353 with backup-archive client 252 msdb database 336 multi-session clients 93 multi-session function 94 multi-session restore 131 multithreaded backup 96 N NAS 8, 24, 79, 392 appliance 8 NAS Gateway 24 NDMP 79, 187 backup 80 enhancements 10 topology 9 with IBM Tivoli Storage Manager 81 NDMP backup 8, 71 Netfinity server 417 Network Attached Storage see NAS. network-free rapid recovery 4 NFS 75, 391 node 216 nojournal 114 NOLIMIT 128 NotMountable state 260 Novell NetWare 21 O objects 184 ODBC driver 283 ODBC interface 283 offsite 260, 262 offsite data copy 6 offsite storage 6 offsite volumes reclamation 194, 196 online backup 360 onsite 260, 262 open file backup 107 operating costs 24 operational reporting 284 operations 69, 217 operator 216 Oracle 14, 331 organize resources 162 Original Block File 82 OS/390 20 OS/400 20 P Packages 121 packages 121, 135 packaging features 122 PASE 404 advantages 405 considerations 408 features 405 password expiry 220 password length 220 passwordaccess 149 path 186 performance 62, 64, 209 performance impact 78 Performance Monitor thread 94 Persistent Storage Manager see PSM. physical structure 337 planning 55 planning worksheets 421 platforms 20 point-in-time backup 78, 115 point-in-time recovery 81 point-in-time restore 61, 128 point-in-time rules 130 policy 161 active set 170 452 IBM Tivoli Storage Management Concepts

archive copy group 167 backup copy group 165 backup mode 166 components 162 copy groups 163 data flow 164 domain 170 domain structure 171 dynamic 165 introduction 162 management 172 relationships 162 retention periods 165 set 169 shrdynamic 164 shrstatic 164 static 164 policy and configuration, propagation 235 policy concepts 43 policy domain 44, 170 policy management 161, 172 policy privilege 216 policy relationships and resources 44 policy set 169 activation 170 validation 170 policy-based automation 28 pool of storage resources 24 Portable Application Solutions Environment see PASE. primary storage pool 188 privilege classes administrator 215 proactive monitoring 25 Producer thread 93 94 products 10 progressive backup methodology 4, 38 progressive incremental backup 60, 70, 100 propagating commands 236 protection 201 PSM 79 Q query for information 146 R RAID 183, 201 RAID 1 202 RAID 1+0 202 RAID 5 204 Rapid Recovery 39 raw logical volumes 98 raw volumes 76 RDBMS 284, 304 Ready for IBM Tivoli 401 reallocate storage resources 24 rebinding 119 recall 155 advanced transparent 156 reclamation 43, 183, 193 reclamation, storage pool 193 reconstruction 267 recovery 265 focus on 264 recovery plan 270 recovery testing 274 recycling partially filled volumes 260 Red Hat Linux 20 Redbooks Web site 442 Contact us xxiv reduce data duplication 24 relational databases 304 reliability 24 remote help desk support 232 report load summary 289 reporting 277 daily report 288 daily summary 278 detail reports 279 e-mail notifications 289 event 282 examples 286 hourly monitor 287 needed reports 278 operational 283 report load summary 289 Web summary page 286 why 278 resource types 43 RESOURCEUTILIZATION 96 restartable restore 127 restore 126 backup set 132 cross-platform 133 logical volume 131 multi-session 131 point-in-time 128 Index 453

progress 127 restore objects 146 restore operations 69 restore times reduce 197 restore window 86 restores matter 57 retention 117, 123 retention periods 165 RETEXTRA 116, 128 retextra 166 RETONLY 116, 128 retonly 166 retrieve 134 retrieve objects 146 retry and randomization, scheduling retry and randomization 181 reuse delay, storage pools 197 RMAN 331 rules 103 S SAN 30, 74, 80, 186, 206, 242, 384, 391 architectures 206 device mapping 211 discovery 212 efficiency 210 exploitation 206 how to use 207 management 28, 30 overview 206 TSM device mapping 211 SAN attached tape device 76 SAN backup 74 SAN infrastructures 3 SAN performance 209 SAN products 24 SAN topology 76 SAN-connected tape library 11 SANergy 391 SANergy see IBM Tivoli SANergy SAP 359 SAP database 18 SAP R/3 18, 357 database backup methods 361 schedule frequency 180 scheduler log 281 scheduling 173 administrative 174 associating clients 176 central 174 client operations 137 client polling 177 client schedules 176 communication method 176 concepts 175 event log 181 execution location 174 frequency 180 introduction 174 one-time 179 server prompted 178 SCSI commands inquiry 212 SCSI-3 extended copy command 77 security 213 client 220 maximum logon attempts 219 password 220 server 219 Web 220 security concepts 44 SELECT command 283 selective backup 70, 101 sequential access volumes 41 serial number autodetection 211 server 187 server activity log 219 server architecture 159 server information 280 server network 231 server platforms 20 server prompted 178 server recovery 6 server recovery strategy 270 server scripts 234 server security 219 server-free backup 76 server-free path 77 server-to-server communication 187 server-to-server data movement 239 session and transaction concepts 93 SGI IRIX 21 Shared-nothing parallel architecture 324 shrdynamic 164 shrstatic 164 Signal Waiting thread 94 454 IBM Tivoli Storage Management Concepts

simplified volume formatting 235 simultaneous writes 189 single drive reclamation 195 sizing worksheets 421 SMB 392 snapshot image backup 82 SNMP 282, 385 server monitoring 282 solution components 28 solutions 291, 401 source server, virtual volumes 237 Space Management 10, 151 space reclamation 43 special considerations 120 speed 265 split-mirror backup 72, 78 SQL 334 SQL applications 334 SQL database 337 important options 338 logical structure 337 SQL queries 283 SQL server administration 338 SQL server database 335 SQL Server database structure 336 SQL server security 338 start or end a session 146 static 164 STGPOOL 189 Storage Area Networks see SAN. storage concepts 39 storage consolidation 23 24 storage device management 184 Storage hierarchy 39 storage management 45 best practices 45 concepts 1, 40 strategic approach 46 storage objects 184 storage pool collocation 41 storage pools 40, 75, 183 184, 188 collocation 198 copy 188 data movement 191 hierarchy 190 maximum file size 193 maxsize 193 migration delay 192 primary 188 reclamation 193 relation to copy groups 163 reuse delay 197 simultaneous writes 189 storage privilege 216 strategic outsourcing 26 sub-file backup and restore 109 Sun Solaris 20 supported devices 21 supported platforms 20 SuSE Linux 20 SysBack 11 System Backup and Recovery 11 system privilege 216 systems management 275 T tape library sharing 207, 242 243 tape reclamation 42 tape resource sharing 4 tape usage, optimising 193 target server 237 TCA 149 TCP/IP port 222 TCP/IP port for administrative sessions 223 TCP/IP ports for remote workstation 222 tcpport 222 tempdb database 336 time is a critical factor 114 TimeFinder 72 Tivoli Enterprise Console see IBM Tivoli Enterprise Console TOCLOADRETENTION 81 total cost of ownership 25 tracking offsite volumes 260 traditional environment 73 transaction client 97 transaction log files 336 transparent sharing 75 transparent to the client 40 Tru64 UNIX 21 Trusted Communication Agent 149 U unified login 233 UNIX platforms 391 unnecessary files 123 Index 455

user interfaces 32 user management 213 V V5.1 clients not migrated 21 validation process policy set 170 Vault state 261 vaulting 268 VERDELETED 116, 128 verdeleted 166 VEREXIST 116 VEREXISTS 128 version control 117 version rules existing and deleted 166 virtualnode 133 volume tracking 259 VSS 107 virtual hosts 370 Web container 370 Web server 369 Web services engine 374 Windows 250 Windows 2000 20 Logical Volume Storage Agent 82 snapshot image backup 82 Windows NT 4.0 21 Windows Server 2003 20 Windows specialities 141 Windows System Object 141 Windows XP 21 Z z/os 20 W WAN environment 73 warehouse of capacity 24 Web authentication timeout 220 Web backup-archive clients 233 Web browser client interface 33 Web client 89 WebSphere Application Server 13, 368 Admin service 372 administrative console 371 application database 373 application server 369 Applications 373 backup 377 components 368 configuration repository 369 EJB container 371 HTTP server 370 JCA container 371 JMS server 373 name server 373 node 368 overview 368 query 377 restore 377 scripting client 372 security server 374 session database 373 456 IBM Tivoli Storage Management Concepts

IBM Tivoli Storage Management Concepts (1.0 spine) 0.875 <->1.498 460 <-> 788 pages

Back cover IBM Tivoli Storage Management Concepts See how IBM Tivoli Storage Manager can improve your IT operations Learn how to protect your vital applications and data Understand all aspects of storage management This IBM Redbook describes the features and functions of IBM Tivoli Storage Manager. It introduces Tivoli Storage Management concepts for those new to storage management, in general, and to IBM Tivoli Storage Manager, in particular. This easy-to-follow guide gives a broad understanding of IBM Tivoli Storage Manager software, the key technologies to know, and the solutions available to protect your business. It offers a broad understanding of how IBM Tivoli Storage Manager will work in heterogeneous environments including Windows, UNIX/Linux, OS/400, and z/os platforms, and with such mission-critcal applications as DB/2, Oracle, Lotus Domino, Exchange, SAP, and many more. The book introduces storage management software by explaining the concepts, architecture, and systems management features of IBM Tivoli Storage Manager and showing available complementary products. It will help you design solutions to protect data holdings from losses ranging from those caused by user error to complete site disasters. INTERNATIONAL TECHNICAL SUPPORT ORGANIZATION BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment. For more information: ibm.com/redbooks SG24-4877-03 ISBN 0738499617