Using Tivoli Data Protection for Microsoft Exchange Server

Transcription

1 Using Tivoli Data Protection for Microsoft Exchange Server Strategic planning and implementation considerations for effective backup Backup over the LAN and Storage Area Network Successful recoveries Pat Randall Ivanka Kabranova Jan Sternberg Marcus Thordal ibm.com/redbooks

2

3 SG International Technical Support Organization Using Tivoli Data Protection for Microsoft Exchange Server May 2001

4 Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix H, Special notices on page 151. First Edition (May 2001) This edition applies to Version 2, Release 2 of Tivoli Data Protection for Microsoft Exchange Server, Program Number 5698-PDX for use with Exchange 2000 and Exchange 5.5 running on the Windows 2000 and NT 4.0 Operating Systems. Exchange 2000 requires Windows Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation All rights reserved. Note to U.S Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

5 Contents Figures vii Preface ix The team that wrote this redbook ix Comments welcome x Chapter 1. Exchange overview for TSM administrators General overview Exchange core components and backup Exchange 5.5 database technology and backup Exchange 2000 database technology and backup Files maintained by Outlook Offline folders Personal folders Personal address book Archive folders Outlook favorites bar file Chapter 2. Planning considerations Backup strategies Online versus offline backup Backing up Exchange databases Backup strategies for Exchange 2000 and Sizing TSM: Preparation for TDP for Exchange Policies and management classes Node registration TDP for Exchange v.1 and v.2: differences and coexistence How TDP for Exchange stores objects on the TSM server Chapter 3. Installation of TDP for MS Exchange servers TDP for Exchange requirements How to Install the TDP Agent Installing TDP for Exchange Registering TDP for Exchange with a TSM server The TDP for Exchange options file Installing TDP for Exchange in an MSCS environment Silent installation Installing the Backup/Archive client Copyright IBM Corp iii

6 Chapter 4. Backing up Exchange databases Exchange 5.5 DIR and IS backup general procedures Backing up Exchange 5.5 using the GUI Backing up Exchange 5.5 using the Command Line Interface General procedures for backing up Exchange Backing up Exchange 2000 using the GUI Backing up Exchange 2000 using the CLI Backing up Site Replication Service Backing up Key Management Service Backing up Active Directory Recommended practices Include/Exclude statement Different node names Clustering Automating backups Scheduling backups on a single node Scheduling backups on a cluster Performance Integration with other products Chapter 5. SAN usage Overview of LAN-free SAN and TDP for Exchange The TSM Storage Agent Setting up LAN-free SAN support Preparing TSM server for LAN-free configuration Setting up the client node to support LAN-free Chapter 6. Day-to-day monitoring DB log management TSM activity log TDP for Exchange log TSM API log Windows event logs TSM scheduler logs Day-to-day verifications TSM server monitoring TDP for Exchange log TSM API log Windows event log TSM Scheduler logs Test restores Auto deletion of old backups Verifying the success of the backup using the GUI iv Using Tivoli Data Protection for Microsoft Exchange Server

7 6.5.1 Query commands Chapter 7. Restoring Exchange databases Basic Information Store recovery from online backups General restore procedures for Exchange General restore procedures for Exchange Using the TDP for Exchange GUI for restoring Exchange Using the TDP for Exchange CLI for restoring Exchange Restoring Exchange in a cluster environment Single item and mailbox recovery Deleted Item Retention feature Alternate server restore Disaster recovery Disaster recovery for Exchange Disaster recovery for Exchange Restoring Site Replication Service (SRS) database Restoring Key Management Service (KMS) database Appendix A. Lab environment Appendix B. Best practices Appendix C. Quick start / checklist C.1 Checklist C.2 Installation C.3 Performing backups C.4 Performing restore C.5 Solving problems Appendix D. Gotchas D.1 Exchange 5.5 backups invoked from Terminal Service client hangs D.2 Using NTBackup in Window 2000 to Backup Exchange D.3 Perform a full backup after restoring Appendix E. Troubleshooting Appendix F. Limitations of the GUI F.1 Backing up the SRS database F.2 Backing up the KMS database F.3 Viewing the TSM object name v

8 Appendix G. TSM object names Appendix H. Special notices Appendix I. Related publications I.1 IBM Redbooks I.2 IBM Redbooks collections I.3 Tivoli publications I.4 Other resources I.5 Referenced Web sites and newsgroups I.5.1 Web sites I.5.2 Newsgroups How to get IBM Redbooks IBM Redbooks fax order form Glossary Index IBM Redbooks review vi Using Tivoli Data Protection for Microsoft Exchange Server

9 Figures 1. TDP for Exchange, TSM APIs, and Exchange APIs: online backup Circular logging and location of transaction log files Setting Item Recovery settings for an Exchange 5.5 Information Store Setting Deletion settings for an Exchange 2000 database Specifying an installation path TDP for Exchange registration Properties for the shortcut for GUI TDP for Microsoft Exchange 5.5 Server GUI Backup of Exchange 5.5 Directory and Information Store Configuring settings general tab Configuration settings performance tab Configuration settings logging tab Configuration settings regional tab TDP for Microsoft Exchange 2000 GUI Configuration settings for Exchange Example of using Include/Exclude statement Result of the backup Backing up Exchange on a cluster Defining schedule TSM administrative client Web interface Associate client nodes with the schedule Registry Replication LAN-free backup SAN devices seen by Windows 2000 after installing Host Bus Adapter Version of the API-dll AdsmScsi device management TSM server monitoring TSM activity log Monitoring Windows event log Verifying success using the GUI Restoring the ITSO 6147 Mailbox Store Recovering deleted items DS/IS Consistency Adjustment Using ADSI Edit to get the legacyexchangedn Reconnecting mailboxes Exchange lab environment No Exchange organization available for NTBackup Modifying the GUI shortcut Copyright IBM Corp vii

10 viii Using Tivoli Data Protection for Microsoft Exchange Server

11 Preface This IBM Redbook is an experience-based description of how to use Tivoli Data Protection (TDP) for Microsoft Exchange v.2.2 to perform backups and restores in your Exchange environment. Tivoli Data Protection for Microsoft Exchange server performs online backups of Microsoft Exchange server databases to Tivoli Storage Manager (TSM) storage. We demonstrate how to back up and recover data on Exchange 5.5 as well as Exchange 2000 on a single server installation and a clustered environment. We decided to use Windows 2000 (Service Pack 1) as the operating system and Exchange 5.5 and Exchange However, we do not cover backing up the operating system itself. Version 2.2 provides new functionality as well as support for Exchange Most significantly, the new version of Tivoli Data Protection for Exchange supports one of the important features of Tivoli Storage Management: automatic expiration and version control by policy. We demonstrate how this frees users from having to explicitly delete backup objects in the Tivoli Storage Manager server. TDP for Exchange supports LAN-free data movement. We show how to use TDP for Exchange to perform backups across a traditional LAN as well as utilizing TSM LAN-free to support backups across Storage Area Networks (SANs). Focus is placed on protection of Exchange data, and thorough performance tests are not included. For a description of backing up the Windows 2000 operating system and Active Directory consult Deploying the Tivoli Storage Manager Client for Windows 2000, SG This document is written for Exchange administrators as well as TSM administrators with a need to understand the issues and considerations pertinent to utilizing TSM and TDP to back up and restore Microsoft Exchange. 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. Pat Randall is a Distributed Storage Software Specialist at the International Technical Support Organization, San Jose, California. He has written 12 Copyright IBM Corp ix

12 Redbooks on ADSM and Tivoli Storage Manager, teaches IBM classes worldwide on all areas of distributed storage, and is a consultant in disaster and business recovery. Before joining the ITSO in July 1996, Patrick worked in IBM UK's Business Recovery Services as a Solutions Architect. Ivanka Kabranova is an IT Expert in Bulgaria. She has 5 years of experience in the IT field, as an administrator of messaging and information systems based on Lotus Notes and MS Exchange server. She holds a degree from Technical University, Sofia. Jan Sternberg is an Advisory IT Specialist at IBM Global Services, Denmark. He has worked at IBM for 7 years. His areas of expertise include Geographical Information Systems, AIX, and Microsoft BackOffice products, in particular, Microsoft Exchange. Jan is a Microsoft Certified Systems Engineer (MCSE) and he holds an MSc. degree in Electronic Engineering from The Technical University of Denmark. Marcus Thordal is an IT Analyst at IBM Global Services, Denmark. He has been with IBM for 3 years. He is MCSE certified, and his areas of expertise include MS cluster, SQL server, and Windows 2000 systems. He holds a BSc. Eng. degree from The Technical University of Denmark. Thanks to the following people for their invaluable contributions to this project: Del Hoobler IBM Global Services, Endicott Jon Tate, SAN Specialist International Technical Support Organization, San Jose Center Yvonne Lyon, editor International Technical Support Organization, San Jose Center Comments welcome Your comments are important to us! We want our Redbooks to be as helpful as possible. Please send us your comments about this or other Redbooks in one of the following ways: Fax the evaluation form found in IBM Redbooks review on page 173 to the fax number shown on the form. Use the online evaluation form found at ibm.com/redbooks Send your comments in an Internet note to redbook@us.ibm.com x Using Tivoli Data Protection for Microsoft Exchange

13 Chapter 1. Exchange overview for TSM administrators This chapter provides a general overview of Exchange aimed at TSM administrators. 1.1 General overview Exchange server is a contemporary messaging system which enables users to exchange information and messages within an organization and with users on the Internet. It also allows users to view items that are in Public Folders, as well as posting items in these folders so that the other users can see them. Exchange server is a Client/Server Messaging System, meaning that the messaging process is divided between the client and the server. The client composes the messages and sends them to the server, then the server places messages in the appropriate place and communicates with the other servers. If there are new messages for the user, the server dispatches them. Exchange server has a hierarchical organization. In Exchange 5.5, the main container is your organization. The next level is a site or sites. You may have more than one site in your organization. Think of a site as a logical group of servers (for instance, according to geographical location). Servers within a site can replicate directory information and route mail directly to each other, but the administrator must explicitly set replication between sites. Servers are the third level. They contain local user s mailboxes (recipients) and Public Folders for the server. In addition, they may be used for tasks such as connecting to the other Exchange sites or to foreign systems; or for special needs, like replication between sites. In Exchange 2000, servers are organized in administrative groups (instead of sites) for easy administration and in routing groups to control the message flow. Administrative groups do not necessarily coincide with routing groups if you have only Exchange 2000 in your organization and the Exchange server is switched to native mode (the default is mixed). But as long as you have coexistence with Exchange 5.5, you must run Exchange 2000 server in mixed mode, and the content of administrative groups must not deviate from the content of routing groups. Exchange 5.5 keeps its own directory information in the Exchange directory database. Exchange 2000 relies on directory information provided by the Active Directory and the operating system. Because Active Directory Copyright IBM Corp

14 supports attribute-level security permissions, administrators have more precise control over the Exchange security configuration. 1.2 Exchange core components and backup Awareness of the underlying database technology that Exchange uses can help you to better understand the backup and restore processes Exchange 5.5 database technology and backup Exchange 5.5 uses a transaction-based logging system to ensure that users never lose information. All transactions are written first to the transaction log (*.log), then committed to the corresponding database file (*.edb). In the event of a failure, all transactions can be replayed. Exchange also uses check point files which indicate when a transaction is successfully committed to the database file. Using check point files preserves the server from replaying every transaction. Instead, only uncommitted data is replayed. Microsoft Exchange 5.5 has four core components which are implemented as Windows services: Directory service The directory service manages information about addresses, mailbox information, distribution lists, public folder hierarchy, and other servers. The directory information is stored in the dir.edb database file. Information store The Information Store service maintains the server-based private (user mailboxes) and public folder information. The private and public store Information Stores are in two separate databases: priv.edb and pub.edb. The Information Store is responsible for replicating public folders, enforcing storage limits, and delivering messages to users on the same server. Message transfer agent (MTA) The MTA manages submitting, routing, and delivering messages to other servers, other sites, or foreign systems. System attendant The system attendant service is responsible for a number of actions such as server monitoring, checking messaging connectors, checking directory replication, building routing tables, generating addresses, logging message tracking information, and assisting in generation of the offline address book. All the other services are dependent on the system attendant. 2 Using Tivoli Data Protection for Microsoft Exchange Server

15 For the Exchange server 5.5 to be backed up, you must perform backup of: The directory service, ExchInstalDir\dsadata\dir.edb The transaction logs for the directory service, ExchInstalDir\dsadata\*.log The private Information Store, ExchInstalDir\mdbdata\priv.edb The public Information Store, ExchInstalDir\mdbdata\pub.edb The transaction logs for the Information Store, ExchInstalDir\mdbdata\*.log The key management server, ExchInstalDir\mdbdata\kmsdata You must keep in mind that Exchange 5.5 uses Windows account information, so you must have access to the account information in order to perform a successful restore Exchange 2000 database technology and backup Exchange 2000 database technology is based on the Extensible Storage Engine (ESE) which is part of the Microsoft Web Storage System process. Exchange 2000 uses Microsoft Windows 2000 Active Directory. In earlier versions of Exchange, the directory was an ESE database that was backed up with other Exchange databases. Because the Exchange 2000 directory information is stored in Active Directory, backing up Windows 2000 Active Directory is as important as backing up Exchange 2000 databases. Exchange 2000 provides support for multiple databases and storage groups on the same server. Exchange 2000 allows up to five multiple databases per storage group, with four storage groups possible per server. One database within a storage group is composed of the following files: The *.edb file, which contains folders, tables, and indexes for messaging data, MAPI messages and attachments. The *.stm file, which is a new format in Exchange 2000 for storing native Internet content. The *.edb and *.stm files function as a pair. Also, if you have a Site Replication Service (if you have both Exchange 5.5 and Exchange 2000) and Key Management server, you will have the following files: Site Replication Service files, located in the ExchInstalDir\srsdata directory, which permit compatibility with Exchange 5.5 by emulating an Exchange 5.5 directory service. Key Management server files, which provide security encryption services. Chapter 1. Exchange overview for TSM administrators 3

16 Exchange 2000 also uses transaction log files. All transactions are written first to the transaction log (*.log), then committed to the correspoding database file (*.edb) and/or streaming database (*.stm). In the event of a failure, all transactions can be replayed using the transaction log. Exchange 2000 also uses check point files which indicates when a transaction is successfully committed to the database file. Using check point files preserves server from replaying every transaction instead of only uncommitted in case of disaster. So, for the Exchange server 2000 to be backed up, you must include the following types of data: Exchange Web Storage Systems databases and supporting files. Message tracking log files - if you are running message tracking. Use for instance Backup/Archive Client to back them up. Active Directory - plan backing up of Active Directory with regular Backup/Archive Client. Key Management Service databases. Site Replication Service (SRS) databases. 1.3 Files maintained by Outlook The Outlook client stores configuration and messaging data in files that are not part of the Microsoft Exchange server. These files may be included in the backup. For this purpose it is a good idea to place them on a file share and use Backup/Archive client for performing backups from central place. Otherwise the client itself must perform backup of these files Offline folders Offline folders are files that are replicated copies of the Microsoft Exchange server based mailbox. They are commonly referred to as ost-files because of their default extension. Ost-files are used by mobile users who are not permanently connected to the Microsoft Exchange server. They enable a mobile user to work offline and periodically synchronize local data with the server-based mailbox. The first time you configure and use an offline folder, an ost-file is created on the local file system, and the server-based mailbox is replicated. When working offline, you work in your offline mailbox exactly as you do with your mailbox on the server. When you connect to the Microsoft Exchange server, changes are sent to the server-based mailbox, and any new messages on the server are replicated to the ost-file. 4 Using Tivoli Data Protection for Microsoft Exchange Server

17 1.3.2 Personal folders Personal folders are files you can create to store messaging data on a file system outside the server-based mailbox. They are commonly referred to as pst-files because of their default extension. You can define as many pst-files as you like. You can copy, delete, rename, and move a pst-file just like any other file Personal address book The personal address book is the place where you store the personal address entries in Microsoft Outlook versions which do not support contacts. In later versions of Outlook you should use Contacts instead, because the contacts folder is stored on the server. The personal address book files have the extension pab Archive folders Archive folders are files created by the archive process on the Outlook client. They are pst-files. An identical folder structure is created between the archive file and the server-based mailbox. It is important to remember that when you archive items they are moved from the server-based mailbox to the client s file system and are no longer accessible on the server Outlook favorites bar file The Outlook favorites bar file contains configuration settings. When you customize the Outlook bar within the Outlook client, the changes are automatically saved to a file called <profile name>.fav. This file is unique for each user and cannot be copied to another user. Chapter 1. Exchange overview for TSM administrators 5

18 6 Using Tivoli Data Protection for Microsoft Exchange Server

19 Chapter 2. Planning considerations In this chapter we describe some strategies for backing up Exchange 5.5 and Exchange 2000 using TDP for Exchange. 2.1 Backup strategies Our considerations regarding backup are server-centric, and the scope does not include any discussion on backup and restore of the operation system itself. Backup strategies for data controlled by Exchange clients (see 1.3, Files maintained by Outlook on page 4) are not discussed in any greater detail either. For strategies on backing up Windows 2000 and client controlled files, we encourage you to consult the redbook Deploying the Tivoli Storage Manager Client in a Windows 2000 Environment, SG Online versus offline backup Offline database backups are defined as file level backups of database files while they are not in use. Thus the Exchange system (or at least parts of it) must be shut down in order to perform an offline backup. Online backups, on the other hand, leave the system running and will allow clients to continue working on the system. Users may experience some performance impact while the backup takes place. Besides the obvious benefit of being able to leave the system running and accessible, online backups do also ensure more reliable backups. When doing online backups, the database is automatically tested for any corruption. This is not the case for offline backups. In some cases a service level agreement will dictate online backups, but even though there may be a choice from the two methods, we strongly recommend online backups. TDP for Exchange supports online backups of Exchange 5.5 and 2000 utilizing the Exchange API and TSM API to communicate with Exchange and the TSM server respectively (see Figure 1). Use the TSM Backup/Archive client for offline backups. This book does not include strategies for offline backups. Note: The term backup (if not specified specifically as being offline) is generally used for online backups in the rest of this book. Copyright IBM Corp

20 Exchange Server Exchange storage group Transaction logs Tivoli Storage Manager server Exchange API TDP for Exchange v.2 TSM API Exchange databases Figure 1. TDP for Exchange, TSM APIs, and Exchange APIs: online backup Backing up Exchange databases The concepts and functionalities of the Exchange 5.5 and Exchange 2000 databases are very much alike. Although Exchange 2000 has introduced the new core database file for Internet content data, the stm-file, and added more flexibility with respect to the number and naming of databases, the basic concepts for backing up the databases are very similar to the ones for Exchange Transaction logging As described in Chapter 1 Exchange databases are transactional databases. Data is written to the log files before it is committed to the database. Besides some performance benefits, transaction logging may enable you to restore data newer than the oldest backup by replaying the transaction logs. As a consequence of the nature of transaction logging, the placement of transaction log files is important. You should plan to place transaction logs on a physical disk separate from the disk holding the database itself. Thus you will have a possibility of replaying the latest transaction logs in case the disk(s) holding the database files should crash. Recommendation We strongly recommend placing transaction log files on disk separate from the databases themselves. The paths are set on the Server object properties Database Paths tab (Exchange 5.5) and the storage group properties General tab (Exchange 2000). See Figure 2. 8 Using Tivoli Data Protection for Microsoft Exchange Server

21 Transaction log files are always 5 MB in size, no matter if the file holds any data or not. The files are numbered sequentially, and when one log file is full, Exchange will start using the next one. The number of log files may be limited to a fixed number 1 or simply by the amount of disk space on the system. Microsoft Exchange server operates with the concept of circular logging. When using circular logging, transaction logs are reused in a round-robin fashion. In this way, old transaction logs that contain data which is not yet backed up may be overwritten. If circular logging is disabled, Exchange will simply create new log files on the fly as they are needed. Old log files are then purged from the system at the completion of the next successful full or incremental online backup. On Exchange 5.5 there are two sets of transaction logs: One set for the Directory Store and one set for the Information Store. If the server has got a public Information Store, it will be sharing the transaction logs with the private Information Store. On Exchange 2000 there is one set of transaction logs for every storage group. There may be as many as 4 storage groups per server and up to 5 databases in each storage group. The storage group feature and ability to have more databases in one storage group is new in Exchange 2000, and so is the concept of mounting and unmounting databases. On Exchange 2000, the Information Store service will independently mount and unmount databases within the individual storage groups as the administrator may wish. Since transaction logs are shared among the databases within a particular storage group, it is a very good idea to backup entire storage groups with all databases mounted in one attempt. TDP for Exchange performs backups at a storage group level. If a database is not mounted while the storage group is being backed up, the old transaction log files will not be purged. This may become an issue for the size of incremental backups if the database stays offline for an extended period. The size of the incremental backups will keep on increasing until the transaction log files can be purged. Thus the benefit of using the incremental backup type is slowly being reduced. Exchange 5.5 enables circular logging by default. Exchange 2000 disables it by default. The setting is configured from the server or storage group properties respectively. See Figure 2. 1 Even though Exchange is configured for circular logging the number may be temporarily increased if the server is stressed and new data arrives faster than data is committed to the database. Exchange will initially attempt to maintain a window of four log files when using circular logging. Chapter 2. Planning considerations 9

22 Figure 2. Circular logging and location of transaction log files You may also use the TDP tool tdpexcc to query the Exchange server for information about circular logging settings: E:\Program Files\Tivoli\TSM\TDPExchange>tdpexcc query exchange Tivoli Storage Manager Tivoli Data Protection for Microsoft Exchange Server Version 2, Release 2, Level 0.0 (C) Copyright IBM Corporation 1998, All rights reserved. Microsoft Exchange Server Information Server Name: ELBRUS Domain Name: k2.uphi.sky Exchange Server Version: Storage Groups with Databases and Status First Storage Group Circular Logging - Disabled Mailbox Store (ELBRUS) Public Folder Store (ELBRUS) ITSO SG Circular Logging - Disabled ITSO 6147 Online Online Online 10 Using Tivoli Data Protection for Microsoft Exchange Server

23 Recommendation We strongly recommend a strategy with regular full backups and disabling circular logging. Note that changing the circular logging settings will require a restart of the Information Store Exchange 5.5 Directory Store and Information Store On Exchange 5.5 installations, the following storage groups 2 (databases) must be backed up: Directory Store Information Store: - Private Information Store - Public Information Store Exchange 2000 storage groups Exchange 2000 does not have its own Directory Store. Exchange 2000 allows more storage groups and databases per server than does Exchange 5.5. Up to 4 storage groups are supported per server and as many as 5 databases per storage group are supported. All in all, there may be as many as 20 databases to back up on one server. Transaction logs are shared among databases within the same storage group, and backups should be performed at a storage group level, which is the way TDP for Exchange operates Site Replication Service and Key Management Service Depending on the setup of your Exchange organization, you may need to backup the auxiliary databases for Key Management Services (KMS) and Site Replication Services (SRS). If Key Management Service is part of your Exchange installation the associated KMS databases are subject to backup too. TDP for Exchange supports backup of Exchange 2000 KMS databases through the Command Line Interface. The Site Replication Service (SRS) is responsible for interfacing Exchange 5.5 with Active Directory and assuring replication of configuration in between Exchange servers in a mixed Exchange environment 3. The SRS database is 2 We use the term storage group not only for Exchange 2000 storage groups, but also for the Exchange 5.5 Information Store and directory. 3 Mixed Exchange environment: Exchange organization containing both Exchange 5.5 and Exchange 2000 servers. Chapter 2. Planning considerations 11

24 a directory database and to Exchange 5.5 servers it looks as any other Exchange 5.5 directory service though it is an Exchange 2000 database. Because SRS is a directory database, you may choose to back it up on a less regular basis if you have more servers in your Exchange organization. In case you need to restore an SRS database that is not completely up-to-date, other servers will simply backfill the database with the missing updates and make it current. TDP for Exchange supports online backup of the Site Replication Service database Active Directory and IIS metabase Since Exchange 2000 does not have its own directory but relies entirely on Active Directory (AD) for directory information, a backup plan for Exchange 2000 also includes backup of AD. Backing up Active Directory is part of backing up system objects 4 on Windows 2000 domain controllers. It is not discussed any further in this book. Instead, we recommend that you consult Deploying the Tivoli Storage Manager Client in a Windows 2000 Environment, SG , for information about backing up AD in a TSM environment. Exchange 2000 also takes advantage of services provided by Internet Information Server (IIS). Though a lot of information about IIS setup is duplicated in AD, it is still important to back up IIS as well. TDP for Exchange does not back up IIS Backup strategies for Exchange 2000 and 5.5 An Exchange backup generally consists of the database file itself (*.edb and for Exchange 2000 *.stm) and a set of transaction log files (*.log). Some products may allow backups of individual databases within a storage group. TDP for Exchange operates on a storage group level and will only allow backups of the type database copy of individual databases. Since transaction logs are used on a storage group level, we would recommend deploying a strategy involving backups at storage group level, anyway. Backing up databases individually would have a great potential for confusing things, due to the fact that transaction logs work on a storage group level. 4 TSM uses the term system objects. The Microsoft equivalent is system state. 12 Using Tivoli Data Protection for Microsoft Exchange Server

25 TDP for Exchange supports various types of backups: Full Incremental Differential Copy Database copy (Exchange 2000 only) Your backup strategy, however, will include more than one type of backup in many cases. For instance, it does not make much sense to make incremental or differential backups without any full backups. The chosen strategy will depend on such factors as service level agreements, available storage, and ease of use. The following are various backup strategies: Full backups: A full backup will back up the entire database. If circular logging is disabled the old transaction logs will be deleted upon completion of a successful backup (For Exchange 2000 this is only true if all databases within the same storage group are backed up. TDP for Exchange backs Exchange 2000 databases up on a storage group level.). Scheduling daily full backups is the easiest manageable backup strategy to deploy. It greatly reduces the complexity for doing restores, and it is probably the best solution for many smaller organizations. However, when databases grow too large, or backup hardware is only available for a limited time, it may not be feasible to do full backups every day. To restore from a full backup, only one backup set is needed. Incremental and full backups: An incremental backup will back up transaction logs and purge old transaction log files if all databases sharing the log files are backed up. An incremental backup must be used in conjunction with a full database backup in order to be able to restore the database. Using daily incremental backups along with for instance one weekly full backup is a common scenario if the daily backup window is too short to support full backups or the network capacity is too low. Scheduling the full backup to week-ends or other non-peak hours will in most cases make the increased impact on network bandwidth less critical. For a restore the last full backup as well as all incremental backups since the full backup are needed for a complete database restore. This will, of course, increase the complexity of the restore procedure and make it more time consuming and tedious. This is the main drawback of this strategy. Chapter 2. Planning considerations 13

26 Differential and full backups: A differential backup will back up transaction logs without purging anything. Thus the differential backup can to some degree logically be understood as a cumulative incremental backup. If differential backups are performed without any full backups in between, the last differential backup will also include the transaction logs already backed up the previous differential backups. In this manner differential backups will require more bandwidth and storage compared to incremental backups performed on the same schedule. A differential backup must be used in conjunction with a full database backup in order to be able to restore the database. For a restore, the last full backup as well as the last differential backup (if newer than the full backup) are needed for a complete database restore. Compared to using a full plus incremental backup strategy, this setup will make any restores faster and less tedious. Copy: A copy backup is a full backup without deletion of any transaction logs. It backs up the entire storage group including transaction logs. A copy backup is used to make a full backup of a storage group without interfering with any deployed strategy involving differential or incremental backups. Database copy: The database copy type backup is available for Exchange 2000 only. It works in the same way as the copy backup, but it operates on individual databases within a storage group. It includes the database files along with the associated transaction logs. Transaction logs are not purged using this type of backup Deleted item and mailbox retention Exchange has some built-in features that will help in recovering data that has been mistakenly deleted by users or administrators. Deleted items retention can be set up on Information Stores and storage groups in order to keep items in the database for a period after the time that a user requested them deleted. Items will then simply be marked for deletion and hidden to users. The items are recoverable from the client as long as a configurable grace period has not expired. Deleted items retention is available for Exchange 5.5 as well as Exchange 2000, but is disabled by default. 14 Using Tivoli Data Protection for Microsoft Exchange Server

27 See Figure 3 and Figure 4 for configuration retention settings. Retention settings are normally set on a database level, but it is possible to specify individual settings. Individual settings are specified through the limits tab of the mailbox object on Exchange 5.5. Individual Exchange 2000 settings are specified through the Properties -> Exchange Features -> Storage Limits interface of Active Directory Users and Computers MCC. Exchange 2000 also includes a similar feature for retention of deleted mailboxes.the setting is specified as Keep deleted mailboxes. Like the deleted item retention this feature will keep a mailbox in the database for a period after the owner of the mailbox may have been deleted from Active Directory. Administrators will be able to reconnect an AD user object to the mailbox. The default setting for this feature is to keep mailboxes for 30 days. Figure 3. Setting Item Recovery settings for an Exchange 5.5 Information Store Chapter 2. Planning considerations 15

28 Figure 4. Setting Deletion settings for an Exchange 2000 database It is important to remember that deleted items retention or deleted mailboxes retention are only remedies for recovering data that actually still exist in the database. There is no way that these features will help if the database crashes or for some reason is not startable. Therefore, these features cannot be used for protection against disasters. See 7.2, Single item and mailbox recovery on page 117 for restore procedures utilizing the deleted item retention feature Files maintained by Outlook 5 Files maintained by Outlook are not backed up by TDP for Exchange. Backups of these files must be accomplished by using file level backups. Use the TSM Backup Archive Client for backing up these files if it is part of your strategy. 5 We generally consider Outlook as the client for Exchange server. Many other clients do exist, and Outlook is now available in many different versions. 16 Using Tivoli Data Protection for Microsoft Exchange Server

29 We do not discuss backup of Outlook files in any greater detail, but the following considerations may be helpful: Store pst-files (Personal Folders) and pab-files (Personal Address Book) on file shares, for instance users home drives. Backup the file shares. There is generally no particular need to restore ost-files (Offline Folder Storage). They are easily regenerated from the client. For clients supporting Outlook Address Book (Contacts) instead for Personal Address Books, consider using it. Besides being more elaborate, the Contacts folder is server based and is thus backed up by Exchange server backups. Be aware that backups of the Outlook files may fail due to file locking if a client is connected. Connected clients are not an issue in that respect, when performing online Exchange backups. 2.2 Sizing Typical user question: What is the optimal sizing of my Exchange system? Many factors will influence your decisions on how to configure and set up an Exchange environment. However, the effects of backup and restore time will most likely have great influence on the strategies for the sizes of your Exchange databases. Since the size of Exchange 5.5 and 2000 databases theoretically is limited by hardware only, backup and restore times will probably become bottlenecks before anything else when considering database sizes. As databases grow too large, there will simply not be a service window wide enough to support the required backup times. On Exchange 2000, it may be a very good idea to utilize the possibilities for having more storage groups and more databases. Split data between storage groups and back these up separately. Also, there may be different service level agreements applicable to different users. For instance, there may exist requirements for fast restores for a group of VIPs. Here are our recommendations: Create smaller databases for VIPs in order to support quicker restores and leave standard users on larger databases. However, do not overuse the possibility for creating multiple databases. As the number of databases and storage groups grow, so does administration. Exchange and the Extensible Storage Engine are not built for the purpose of single user databases, so avoid setting these up. Chapter 2. Planning considerations 17

30 When creating multiple storage groups on a cluster, remember that a single cluster node will only support 4 storage groups in total. Thus creating 3 storage groups on both nodes in a two-node cluster will leave 2 storage groups unmounted if one node fails. On Exchange 5.5, it is not possible to create additional storage groups. If a prolonged backup/restore time is forcing a split of the database, it must be done by setting up a new server. Another option for limiting the growth of the database sizes is to enforce quotas on the individual mailboxes. Limits for mailboxes sizes are set on the database properties page (see Figure 3 on page 15 and Figure 4 on page 16). Unless the TSM server is installed on the same server as TDP for Exchange, network bandwidth constraints may become critical factors to backing up and restoring Exchange. A typical 100-Mbs network equals about 42 GB an hour. That is not considering any overhead and collisions. Expect far less available bandwidth for your backups, and schedule backups for quiet hours. If bandwidth is an issue, running backups across a SAN may be the solution. TDP for Exchange supports the TSM LAN-free environment. In Chapter 5, we illustrate how to get your TDP for Exchange installation to transfer data across a SAN. 2.3 TSM: Preparation for TDP for Exchange The TSM administrator must prepare the TSM server for TDP for Exchange nodes. The preparation involves a number steps: Define and configure policy domain Define and configure a policy set Define and configure a management class Define and configure copy groups Assign the default management class to the domain Activate the policy Register TDP for Exchange node(s) Policies and management classes Tivoli Storage Manager policies are used to specify how objects are backed up and migrated. 18 Using Tivoli Data Protection for Microsoft Exchange Server

31 The TDP for Exchange version 2.2 conventions for backup objects and file space naming (see Appendix G) differ from version 1. Version 2.2 supports the automatic policy based expiration capabilities provided by the TSM server, and there is no need to request expiration of backup objects from the client anymore. All backup objects are stored in backup storage pools by TDP for Exchange. It is therefore not necessary to setup an archive copy group. An archive copy group can exist, and we did define one, even though was is not being used. We did so just to avoid some warning messages appearing in case the archive copy group did not exist. For instance, an activation of a policy would provoke a warning like this: tsm: BRAZIL>activate policyset TDPEXCH2_DOMAIN standard ANR1554W DEFAULT Management class API_DISK_30DAYS in policy set TDPEXCH2_DOMAIN STANDARD does not have an ARCHIVE copygroup: files will not be archived by default if this set is activated. For our TDP for Exchange installation, we defined the policy domain TDPEXCH2_DOMAIN and the management class API_DISK_30DAYS for the STANDARD policy set. For the API_DISK_30DAYS management class, we defined the copy groups of type backup and archive. As mentioned, only the first one is actually used. We decided using the following parameters for our copy group in our default management class: Versions Data Exists: No limit Versions Data Deleted: No limit Retain Extra Versions: 30 days Retain Only Version: 30 days The rationale was to keep old backups for 30 days before they were expired and removed from TSM storage. Specifying no limit for the Version Data Exists and Version Data Deleted parameters assured that repeated backups in our test environment would not flush relatively new backups just because of exceeding a version limit. Incremental backups are always named uniquely. Therefore, they will only expire due to Retain Only Version limits. When performing a full backup, all objects for the Exchange storage group are inactivated and after that subject to expiration. Whereas a full backup normally will expire due to limitations set by Retain Extra Versions (assuming an unlimited number of versions), the incremental backups will expire from limits set by Retain Only Version. Chapter 2. Planning considerations 19