Using Tivoli Data Protection for Microsoft Exchange Server

(1)

ibm.com/redbooks

Using Tivoli

Data Protection for

Microsoft Exchange Server

Pat Randall

Ivanka Kabranova

Jan Sternberg

Marcus Thordal

Strategic planning and implementation

considerations for effective backup

Backup over the LAN and

Storage Area Network

(2)

(3)

Using Tivoli Data Protection for

Microsoft Exchange Server

May 2001

SG24-6147-00

(4)

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 2000.

Comments may be addressed to:

IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2

650 Harry Road

San Jose, California 95120-6099

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.

Before using this information and the product it supports, be sure to read the general information in Appendix H, “Special notices” on page 151.

(5)

Figures

1. TDP for Exchange, TSM APIs, and Exchange APIs: online backup . . . 8

2. Circular logging and location of transaction log files . . . 10

3. Setting Item Recovery settings for an Exchange 5.5 Information Store . . 15

4. Setting Deletion settings for an Exchange 2000 database . . . 16

5. Specifying an installation path . . . 27

6. TDP for Exchange registration . . . 28

7. Properties for the shortcut for GUI . . . 31

8. TDP for Microsoft Exchange 5.5 Server GUI . . . 36

9. Backup of Exchange 5.5 Directory and Information Store . . . 37

10. Configuring settings — general tab . . . 38

11. Configuration settings — performance tab . . . 39

12. Configuration settings — logging tab . . . 39

13. Configuration settings — regional tab . . . 40

14. TDP for Microsoft Exchange 2000 GUI . . . 45

15. Configuration settings for Exchange 2000 . . . 46

16. Example of using Include/Exclude statement . . . 53

17. Result of the backup . . . 54

18. Backing up Exchange on a cluster. . . 56

19. Defining schedule — TSM administrative client Web interface . . . 59

20. Associate client nodes with the schedule . . . 60

21. Registry Replication . . . 63

22. LAN-free backup . . . 68

23. SAN devices seen by Windows 2000 after installing Host Bus Adapter . . 73

24. Version of the API-dll . . . 74

25. AdsmScsi device management . . . 76

26. TSM server monitoring. . . 85

27. TSM activity log . . . 86

28. Monitoring Windows event log . . . 90

29. Verifying success using the GUI . . . 94

30. Restoring the ITSO 6147 Mailbox Store . . . 108

31. Recovering deleted items . . . 118

32. DS/IS Consistency Adjustment . . . 122

33. Using ADSI Edit to get the legacyExchangeDN. . . 124

34. Reconnecting mailboxes . . . 127

35. Exchange lab environment . . . 133

36. No Exchange organization available for NTBackup. . . 141

(10)

(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 2000. However, we do not cover backing up the operating system itself.

Version 2.2 provides new functionality as well as support for Exchange 2000. 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, SG24-6141.

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

(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

(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

(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.

1.2.1 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 e-mail addresses, logging message tracking information, and assisting in generation of the offline address book. All the other services are dependent on the system attendant.

(15)

Chapter 1. Exchange overview for TSM administrators 3

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.

1.2.2 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.

(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.

1.3.1 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.

(17)

Chapter 1. Exchange overview for TSM administrators 5

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.

1.3.3 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.

1.3.4 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.

1.3.5 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.

(18)

(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, SG24-6141.

2.1.1 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

(20)

Figure 1. TDP for Exchange, TSM APIs, and Exchange APIs: online backup

2.1.2 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 5.5.

2.1.2.1 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.

Exchange Server TDP for Exchange v.2 TSM API Transaction logs Tivoli Storage Manager server Exchange API Exchange databases

Exchange storage group

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.

(21)

Chapter 2. Planning considerations 9

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 number1 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.

(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

---Server Name: ELBRUS Domain Name: k2.uphi.sky Exchange Server Version: 6.0.4417.0 Storage Groups with Databases and Status ---First Storage Group

Circular Logging - Disabled

Mailbox Store (ELBRUS) Online Public Folder Store (ELBRUS) Online ITSO SG

Circular Logging - Disabled

(23)

Chapter 2. Planning considerations 11 2.1.2.2 Exchange 5.5 Directory Store and Information Store

On Exchange 5.5 installations, the following storage groups2 (databases) must be backed up:

• Directory Store • Information Store:

- Private Information Store - Public Information Store

2.1.2.3 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.

2.1.2.4 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 environment3. 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.} 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.

(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.

2.1.2.5 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 objects4 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, SG24-6141, 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.

2.1.3 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.

(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.

(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.

2.1.3.1 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.

(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.

(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.

2.1.3.2 Files maintained by Outlook5

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.

(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.

(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)

2.3.1 Policies and management classes

Tivoli Storage Manager policies are used to specify how objects are backed up and migrated.

(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:

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.

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.

(32)

The value for Retain Only Version for incremental backups must be, at minimum, as long as the value for the associated full backup. On the other hand, it does not make much sense to keep transaction logs if the associated full backup has expired and has been removed from TSM storage.

We ended up specifying equal limits for Retain Only Version and Retain Extra Versions: 30 days.

The destination for our backups is disk (API_DISK). If using removable media, it is recommended to use collocation if a restore potentially involves more than just a full backup — for instance, a differential or multiple

incremental backups.

The following parameters are not applicable for TDP for Exchange, and default values must be accepted:

• Copy mode • Copy serialization • Copy frequency

Here is an example of setting up management classes on the TSM server:

tsm: BRAZIL>define domain TDPEXCH2_DOMAIN ANR1500I Policy domain TDPEXCH2_DOMAIN defined. tsm: BRAZIL>define policyset TDPEXCH2_DOMAIN standard

ANR1510I Policy set STANDARD defined in policy domain TDPEXCH2_DOMAIN. tsm: BRAZIL>define mgmtclass TDPEXCH2_DOMAIN standard API_DISK_30DAYS

ANR1520I Management class API_DISK_30DAYS defined in policy domain TDPEXCH2_DOMAIN, set STANDARD.

tsm: BRAZIL>define copygroup tdpexch2_domain standard api_disk_30days type=backu p dest=api_disk verexists=nolimit retextra=30 verdeleted=nolimit retonly=30 ANR1530I Backup copy group STANDARD defined in policy domain TDPEXCH2_DOMAIN, set STANDARD, management class API_DISK_30DAYS.

tsm: BRAZIL>define copygroup tdpexch2_domain standard api_disk_30days type=archi ve dest=api_disk retver=30

ANR1535I Archive copy group STANDARD defined in policy domain TDPEXCH2_DOMAIN, set STANDARD, management class API_DISK_30DAYS.

tsm: BRAZIL>assign defmgmtclass TDPEXCH2_DOMAIN standard API_DISK_30DAYS ANR1538I Default management class set to API_DISK_30DAYS for policy domain TDPEXCH2_DOMAIN, set STANDARD.

(33)

2.3.2 Node registration

When policy sets and management classes have been configured, it is time to register the node.

We decided to use nodenames indicating the particular node as being a TSM Exchange API node. We used the naming template

ExchangeServerName_EXCH2.

In this manner we left the server name itself to be used as a nodename for any TSM Backup Archive installation.

2.4 TDP for Exchange v.1 and v.2: differences and coexistence

The TDP for Exchange version 2 conventions for backup objects and file space naming are different from version 16. This means that the versions are completely incompatible, and it is not possible to query or restore backups made by the earlier version.

It is therefore necessary to keep your installation of TDP for Exchange v.1 as long as you are storing backup objects created by this version and you want to be able to restore these. You can still install version 2 and start using it at the same time. The new version will not overwrite the old one.

TDP for Exchange version 2 supports Exchange 5.5 and Exchange 2000. If support for Exchange 5.0 is needed, TDP for Exchange version 1 must be used.

We did not install version 1, but it is recommended by the installation guide for version 2 that you set up different node names for version 1 and version 2. If using the same nodename, the INCLUDE option in the dsm.opt file must be used to bind TDP for Exchange version 1 objects and TDP for Exchange version 2 objects to different management classes. Otherwise, a

malconfigured setup may result in unforeseen removals of backups from TSM or leaving backups forever without any expiration.

6 _{TDP for Exchange v.1 was initially named ADSMConnect Agent for Microsoft Exchange server}

tsm: BRAZIL>register node ELBRUS_EXCH2 uphi domain=TDPEXCH2_DOMAIN backdelete =yes maxnummp=2

ANR2060I Node ELBRUS_EXCH2 registered in policy domain TDPEXCH2_DOMAIN. ANR2099I Administrative userid ELBRUS_EXCH2 defined for OWNER access to node ELBRUS_EXCH2.

(34)

Start using the new version, and leave only the old version, in order to support any possible restores of old backups.

2.5 How TDP for Exchange stores objects on the TSM server

As mentioned, TDP for Exchange version 2 stores backup objects on the TSM server differently from the previous version.

Objects are stored using the following pattern:

Filespace name: ExchangeServerName\StorageGroupName

High-level qualifier: \ObjectKeyword[\ObjectIndex][\DatabaseName] where ObjectKeyword is: meta, data, or logs and ObjectIndex is: xxxx (xxxx’th file within database – data object only. For instance, there will be ObjectIndex 0000 and 0001 for every mailbox store reflecting the existence of the .edb and .stm file) or yyyymmddhhmmss (timestamp) for incremental backups. Metadata is data containing information about a particular backup. The data keyword specifies the database files themselves and the logs keyword specifies backup of transaction log files.

Low-level qualifier: \Type where Type is: full, copy, diff, incr, or dbcopy depending on what kind of backup is performed.

Knowledge about object names is valuable when querying the TSM server for information about backups. Below we show some examples on viewing objects in TSM database.

Do not use TDP for Exchange v.1 and TDP for Exchange v.2 to back up the same database. Doing so may mess up the transaction log backups.

(35)

Query the backups table using the TSM administrator client:

Notice that there are two data objects for this backup: one object for the .edb file and one for the .stm file.

Another option is to use the show versions command through the administrative client. The format is:

show versions <node_name> <file_spacename>

tsm: BRAZIL>select * from backups where node_name='ELBRUS_EXCH2' and state='ACTI VE_VERSION' and filespace_name='ELBRUS\ITSO SG' and hl_name like '%ITSO 6148%' ANR2963W This SQL query may produce a very large result table, or may require a significant amount of time to compute.

Do you wish to proceed? (Yes (Y)/No (N)) y NODE_NAME: ELBRUS_EXCH2

FILESPACE_NAME: ELBRUS\ITSO SG STATE: ACTIVE_VERSION

TYPE: FILE

HL_NAME: \data\0000\ITSO 6148 Mailbox Store\ LL_NAME: full OBJECT_ID: 107084 BACKUP_DATE: 2001-04-06 13:43:26.000000 DEACTIVATE_DATE: OWNER: CLASS_NAME: DEFAULT NODE_NAME: ELBRUS_EXCH2 FILESPACE_NAME: ELBRUS\ITSO SG STATE: ACTIVE_VERSION TYPE: FILE

HL_NAME: \data\0001\ITSO 6148 Mailbox Store\ LL_NAME: full OBJECT_ID: 107085 BACKUP_DATE: 2001-04-06 13:43:26.000000 DEACTIVATE_DATE: OWNER: CLASS_NAME: DEFAULT

tsm: BRAZIL>show versions ELBRUS_EXCH2 "ELBRUS\ITSO SG" .

ELBRUS\ITSO SG : \data\0000\ITSO 6147 Mailbox Store\ full (MC: DEFAULT) Inactive, Inserted 04/05/01 22:44:59, Deactivated 04/06/01 09:53:18 ObjId: 0.106345

ELBRUS\ITSO SG : \data\0000\ITSO 6147 Mailbox Store\ full (MC: DEFAULT) Inactive, Inserted 04/06/01 09:53:18, Deactivated 04/06/01 13:43:26 ObjId: 0.106826

(36)

(37)

Chapter 3. Installation of TDP for MS Exchange servers

Tivoli Data Protection for Microsoft Exchange (TDP) performs online backups of Microsoft Exchange server databases to Tivoli Storage Manager (TSM) storage. TDP for Exchange must be installed on the same machine as the Microsoft Exchange server. TDP for Exchange Version 2 supports Microsoft Exchange Server 5.5 and Microsoft Exchange 2000 Server.

3.1 TDP for Exchange requirements

Before installing Tivoli Data Protection for Microsoft Exchange server, you must be sure that your system meets the following requirements:

• Hardware requirements: - 8 MB of free disk space

- 48 MB of RAM (96 MB or more is highly recommended) - Intel Pentium or equivalent 166 (or higher) processor

- Cluster requirements — see Microsoft requirements for installing Exchange in Cluster environment

• Operating system requirements:

Microsoft Windows NT Server (Server or Enterprise Edition) Version 4 with Service Pack 4 (SP4) or Microsoft Windows 2000 Server (Server,

Advanced Server, Datacenter Server) with Service Pack 1 (SP1) or later. It is recommended that you install the latest Windows service packs available from Microsoft.

In our test environment we installed both Exchange 5.5 (SP4) and Exchange 2000 over Windows 2000 with Service Pack 1.

TDP for Exchange supports the following communication protocols: TCP/IP, IPX/SPX, NetBIOS, Named Pipes (only for connection from TDP for Exchange to TSM), LU 6.2(CPIC), Lan free.

We set up our environment to run on TCP/IP. If you are planning to use it LAN-free, you must use TCP/IP.

• Systems supported by TDP for Exchange version 2:

- Exchange Server 5.5 (Windows NT 4.0 with SP4 or later and Windows 2000 with SP1 or later).

(38)

- MSCS Active/Passive Configuration — Exchange server 5.5 with SP3 (Windows NT 4.0 Enterprise Edition with SP4 or later or Windows 2000 Advanced Server with SP1 or later).

- MSCS Active/Active Configuration — Exchange 2000 Server (Windows 2000 Advanced Server with SP1 or later).

In our test environment we installed Microsoft Exchange 2000 in a MSCS cluster.

Also, consider the following issues:

• The TSM server can reside on a different machine than TDP for Exchange and can be on any platform supported by TSM.

In our lab environment we used a TSM server running AIX on RS/6000. • If you want to use TSM Scheduling you must install the TSM

Backup/Archive Client for Windows. The TSM Backup/Archive Client must reside on the same machine as TDP for Microsoft Exchange server. • Microsoft Internet Explorer V4.01 or later for the access to the online

information.

You can obtain the latest requirements for TDP for Exchange from the following URL:

http://www.tivoli.com/products/solutions/storage

There are a number of hotfixes to Exchange 2000 that are important. You should check the hotfix list for Exchange 2000. Active/Passive is also supported for Exchange 2000.

3.2 How to Install the TDP Agent

This section gives you information how to install TDP for Exchange in a non-clustered environment, how to install TDP Agent in a clustered environment, how to perform silent installation, and how to install the Backup/Archive Client in order to take advantage of the TSM Scheduler.

3.2.1 Installing TDP for Exchange

Follow the Microsoft requirements and instructions for installing Microsoft Exchange, and be sure that you use the latest service packs available. In our lab environment, we set up two Exchange servers — Exchange 5.5 with SP4 and Exchange 2000, both of them on Windows 2000 with SP1.

(39)

Chapter 3. Installation of TDP for MS Exchange servers 27

Before performing the installation, see the readme1st.txt file which includes useful information about installing and configuring TDP for Exchange.

Make sure you are logged to the system with an account having administrator privileges to the local system.

Follow these steps to install TDP for Exchange:

1. Insert the TDP for Exchange CD ROM into the CD-ROM drive. If you have the autorun feature enabled, the setup will start as soon as you insert the CD into the drive. If autostart is not enabled:

a. Select Run from the Start menu.

b. Enter x:\setup where x is your CD-ROM drive letter. c. Click OK to start the installation program.

2. Follow the installation instructions contained in the prompt windows. If no previous version of TDP for Exchange exists on the system, the default installation directory is ProgramFiles\Tivoli\TSM\TDPExchange. You may override it and specify a different installation directory (Figure 5).

(40)

However, installing all TSM products into the same base directory is recommended. If the Tivoli Storage Manager product is detected, the path to that product becomes the default installation directory.

3. If you would like to register the TDP for Exchange, check the box provided for registration, and then fill in the form represented in Figure 6.

Figure 6. TDP for Exchange registration 4. Click Finish to complete the setup.

If TDP for Exchange Version 2 already exists on the system, you can Repair or Remove the previously installed TDP for Exchange Version 2. By choosing

Repair you will fix missing or corrupt files, but your configuration will remain

intact. By choosing Remove you will have the option to remove the current installation. The other way to remove TDP for Exchange installation is to point to Control Panel -> Add/Remove Programs and then choose Tivoli Data

Protection for Microsoft Exchange Server - V2 and click Remove.

(41)

3.2.2 Registering TDP for Exchange with a TSM server

Before you can perform backup and restore with TDP for Exchange, your TSM administrator must register TDP for Exchange as a client node with the server. The administrator will provide the node name, the initial password, the communication method to connect to the TSM server, the policy domain to which TDP for Exchange belongs, TSM schedules and whether you are allowed to use compression before sending files to server. (Note that the TSM administrator can override your preferences about compression specified in your options file). See 2.3, “TSM: Preparation for TDP for Exchange” on page 18 regarding node registration on the TSM server.

3.2.3 The TDP for Exchange options file

After registering TDP for Exchange to the TSM server, you must configure several parameters in the options file. The default options file name is dsm.opt and it is stored in the TDP for Exchange directory. You can edit this file using a text editor. You will have to specify the following parameters: • NODename xxx — The unique name which the TSM administrator has

registered.

• The TSM server name — The name of the TSM server.

(TCPserveraddress or IPXServeraddress or NETBIOSServername; if you use TCPserveraddress specify IP address or Host name.)

• Communication Options — TDP supports the following communication protocols — TCP/IP, IPX/SPX, NetBIOS, Named Pipes.

You may specify the following additional options:

• PASSWORD Access — If this option is set to generate the TSM API stores the password (encrypted) in the Windows registry and automatically generates the new password when the current one expires. Be aware that if this option is set to prompt your backup may fail because of an expired password.

• COMPRESSion — You may use this option to compress data before sending it to the TSM server. However, this will lead to higher CPU utilization on the machine where TDP for Exchange is installed. On the other hand, this will cause less network traffic and less storage space on the TSM server. The TSM administrator’s settings on the TSM server takes precedence over your settings in the options file and he or she may enforce you to always use compression, never use compression or leave this decision up to you.

• enablelanfree — If yes you may run TDP for Exchange in a LAN free environment.

(42)

3.3 Installing TDP for Exchange in an MSCS environment

The procedure for installing TDP for Exchange in a clustered environment is the same as installing it in a non-clustered environment. Install TDP for Exchange on both nodes of the cluster. Make sure that the option files on both nodes of the cluster are identical. You must specify the CLUSTERnode parameter in the options file to be yes for TDP for Exchange to function on the cluster.

Also create the new Start menu shortcut so that the GUI is invoked by specifying the /exchserver parameter. To do that, either point to Start ->

Settings -> Taskbar and Start Menu Properties, click the Advanced tab

and then the Advanced command or browse to \Documents and

settings\All users\Start Menu\Programs\Tivoli Storage Manager\TDP for MS Exchange.

Then choose New Shortcut by right-clicking with the mouse. In the field Type

the location of the item specify the location of the tdpexc.exe with the

parameter /excserver=your_server or click Browse to find this file and then add the /excserver=your_server parameter. The location of the file is Program files\Tivoli\TSM\TDPExchange. If you right-click the created shortcut, you will see the screen shown in Figure 7.

(43)

Figure 7. Properties for the shortcut for GUI The option name is "/EXCSERVER".

3.4 Silent installation

Silent installation is extremely useful when you want to perform installation of TDP for Exchange on several of identical machines because administrators do not have to provide input to dialog boxes and specify TDP for Exchange parameters.

(44)

If you want to perform the silent installation, you have the following options: • Use the command line setup program with s (silent) and v switches:

- Use setup /s /v/qn from the command line to install in the default directory. Issue this command from the “TDPExchange” subdirectory. - Use setup /s /v”INSTALDIR=\”X:\Desired Install Path\” /qn” to install

to the specified directory. Make sure you use quotes if your installation path includes spaces and place a backslash (\) in front of each quote mark that is within an outer set of quotes. Also, there cannot be a space between the command-line option (/v) and the arguments that you are passing.

• Create a batch file with desired parameters (Create this file with Notepad and save it as setup.bat file). The following example shows the sample script:

rem=================================================== rem silent install script

rem

cd .\TDPExchange

.\setup /s /v”INSTALDIR=\”X:\Desired Install Path\” /qn” rem

rem replace the option file

copy dsm.opt X:\Desired Install Path

rem===================================================

The silent installation package may reside on a file server, or you may choose to burn a special CD and distribute it for this purpose. This package contains the TDP for Exchange code distribution files and usually a batch file for silent installation.

If you use a silent install package on a CD and autostart is enabled, the installation will begin after inserting the CD into the drive (do not forget to let the autorun.inf file point to your setup.bat file). If autostart is not enabled, you may run the silent installation by activating the setup.bat file from the root of the CD.

If the package is placed on the file server and you want to perform the silent installation from another machine, you must execute the command: net use x:\\machine1\Silent_installation where machine1 is the file server and Silent_installation is the shared directory containing the silent installation package. No visual cues exist to inform you about the end of the installation. If the silent installation fails, you can create a detailed log file of installation by typing: setup /v”/l*v setup.log”.

(45)

3.5 Installing the Backup/Archive client

If you want to take advantage of TSM Scheduler, you must install the

Backup/Archive Client on the same machine on which you have installed TDP for Exchange. Make sure you are logged on using a Windows account with administrative privileges.

To install the Backup/Archive Client:

1. Insert the CD-ROM containing the TSM Windows Client into your CD-ROM drive.

2. Start the setup program by selecting Run from the Start menu. 3. Click OK.

4. Follow the instructions displayed on the screen. You can choose between two setup types:

- Complete — This setup gives you the Backup/Archive Client, the API, and the Web Client. Use the custom option if you want to install the Administrative client.

- Custom — This setup allows you to select the desired options. You must use this option if you want to install the Administrative client — the program which lets administrators monitor and control TSM servers using TSM administrator commands. If you select to install the

Backup/Archive client and the administrative client, they must reside in a single directory and will share the same options file. Make sure there is enough disk space for the TSM Client files on the destination drive. 5. Click on Finish once the installation process completes.

For current installation and configuration information, refer to the README file that is shipped on the product installation media.

For current information concerning TSM, see:

(46)

(47)

Chapter 4. Backing up Exchange databases

TDP for Exchange performs backups of Exchange storage groups on TSM server — a storage group being an Exchange 5.5 Directory, an Exchange 5.5 Information store or an Exchange 2000 Storage group. The backup includes databases and associated transactions logs. TDP for Exchange

communicates with the TSM server using the TSM application programming interface (API) and with the Exchange server using the Exchange API — see Figure 1 on page 8. TDP for Exchange must be able to connect to a TSM server. The TSM server can run on the same machine as TDP for Exchange or on a different machine on any supported operating platform.

In our lab environment we set up two Exchange servers — Exchange 5.5 and Exchange 2000 both of them running on the Windows 2000 platform. First we installed Exchange 5.5. After that we installed Exchange 2000 joining the Exchange 5.5 site, and we set up a Site Replication Service between them. We set up our environment in this way in order to be close to a common scenario of migrating from Exchange 5.5 to Exchange 2000. We also installed Exchange 2000 in a cluster environment. We used a different machine for the Domain controller. (See Figure 35 on page 133.)

4.1 Exchange 5.5 DIR and IS backup general procedures

You can perform backup of the Exchange 5.5 Directory and Information store by using the Graphical User Interface (GUI) or using the Command Line Interface (CLI).

4.1.1 Backing up Exchange 5.5 using the GUI

To start the TDP for Exchange GUI point to Start -> Programs, then Tivoli

Storage manager -> TDP for MS Exchange Server - v2 and click Exchange Client GUI. You will see the window represented in Figure 8.

Using Tivoli Data Protection for Microsoft Exchange Server

ibm.com/redbooks

Using Tivoli

Data Protection for

Microsoft Exchange Server

Pat Randall

Ivanka Kabranova

Jan Sternberg

Marcus Thordal

Strategic planning and implementation

considerations for effective backup

Backup over the LAN and

Storage Area Network

Using Tivoli Data Protection for

Microsoft Exchange Server

May 2001

Contents

Figures

Preface

The team that wrote this redbook

Comments welcome

Chapter 1. Exchange overview for TSM administrators

1.1 General overview

1.2 Exchange core components and backup

1.2.1 Exchange 5.5 database technology and backup

1.2.2 Exchange 2000 database technology and backup

1.3 Files maintained by Outlook

1.3.1 Offline folders

1.3.2 Personal folders

1.3.3 Personal address book

1.3.4 Archive folders

1.3.5 Outlook favorites bar file

Chapter 2. Planning considerations

2.1 Backup strategies

2.1.1 Online versus offline backup

2.1.2 Backing up Exchange databases

2.1.3 Backup strategies for Exchange 2000 and 5.5

2.2 Sizing

2.3 TSM: Preparation for TDP for Exchange

2.3.1 Policies and management classes

2.3.2 Node registration

2.4 TDP for Exchange v.1 and v.2: differences and coexistence

2.5 How TDP for Exchange stores objects on the TSM server

Chapter 3. Installation of TDP for MS Exchange servers

3.1 TDP for Exchange requirements

3.2 How to Install the TDP Agent

3.2.1 Installing TDP for Exchange

3.2.2 Registering TDP for Exchange with a TSM server

3.2.3 The TDP for Exchange options file

3.3 Installing TDP for Exchange in an MSCS environment

3.4 Silent installation

3.5 Installing the Backup/Archive client

Chapter 4. Backing up Exchange databases

4.1 Exchange 5.5 DIR and IS backup general procedures

4.1.1 Backing up Exchange 5.5 using the GUI