New EMC TimeFinder /Integration Modules (TF/EIM, TF/SIM, SIU) · 2020. 3. 6. · 14 EMC TimeFinder/Integration Modules Version 4.1 Product Guide Preface EMC Solutions Enabler Symmetrix

EMC CorporationCorporate Headquarters:

EMC® TimeFinder®/Integration Modules(TF/EIM, TF/SIM, SIU)

Version 4.1

Product GuideP/N 300-001-457

REV A06

Hopkinton, MA 01748-9103

1-508-435-1000www.EMC.com

2

Copyright © 2000 — 2007 EMC Corporation. All rights reserved.

Published June, 2007

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All other trademarks used herein are the property of their respective owners.

EMC TimeFinder/Integration Modules Version 4.1 Product Guide

Contents

Preface............................................................................................................................ 13

Chapter 1 Product OverviewSYMCLI and TimeFinder/Integration Modules .......................... 18

Enterprise storage for Windows...............................................18EMC TimeFinder/IMs .............................................................. 19

EMC and third-party requirements ............................................... 21EMC software requirements .....................................................21Windows Server support...........................................................22Exchange Server support...........................................................23SQL Server support ....................................................................24VSS support ................................................................................ 25Veritas support............................................................................25

Business continuance storage environment.................................. 26TimeFinder/Mirror ................................................................... 26TimeFinder/Snap ...................................................................... 28TimeFinder/Clone..................................................................... 29SRDF ............................................................................................ 30Open Replicator ..........................................................................34

Chapter 2 InstallationBefore you begin ............................................................................... 38Installing the TimeFinder/Integration Modules.......................... 39Enabling your software.................................................................... 40

EMC TimeFinder/Integration Modules Version 4.1 Product Guide 3

Contents

Chapter 3 Disk Management with Symmetrix Integration UtilitiesIntroduction....................................................................................... 42

SIU capabilities .......................................................................... 42Privilege requirements............................................................... 43SIU commands........................................................................... 43Volume management software ................................................ 44SFW dynamic disk groups with TimeFinder ......................... 44

Making disks visible to the system ................................................ 45Viewing detailed information about disks.................................... 46Defining volume sets and disk groups.......................................... 47

Deporting disk groups.............................................................. 47Importing disk groups.............................................................. 47

Manipulating disk signatures ......................................................... 49Flushing cache buffers to disk ........................................................ 50Mounting disks ................................................................................. 51

Disk unmount operations.......................................................... 52Open handles on drives............................................................. 53Exclusive locks on drives .......................................................... 54Device masking operations....................................................... 54

Creating a backup for dynamic disks ............................................ 56Performing typical storage operations .......................................... 57

Synchronizing the BCV............................................................. 57Restoring Veritas dynamic disks with TimeFinder............... 60Creating a backup using TimeFinder/Snap........................... 62Creating a backup using TimeFinder/Snap and rescan....... 63

Chapter 4 TF/EIM Overview and SetupOverview............................................................................................ 68

Setting up an Exchange business continuance system ......... 69Setting up a production server for TF/EIM.................................. 70

Windows installation requirements ........................................ 70Configuring volumes for the server database........................ 70Server database application install strategy ........................... 72EMC Solutions Enabler installation......................................... 73EMC VSS Provider installation ................................................ 74

Setting up a backup/recovery server environment .................... 75Server database application install strategy ........................... 75EMC Solutions Enabler installation......................................... 75EMC TimeFinder/IMs installation .......................................... 75Exchange Recovery Storage Groups........................................ 76

Configuring the TimeFinder/Mirror environment ..................... 77Configuring the TimeFinder/Snap environment ........................ 79

EMC TimeFinder/Integration Modules Version 4.1 Product Guide4

Contents

Volume Shadow Copy Service (VSS).......................................79Configuring the TimeFinder/Clone environment ....................... 81Configuring the SRDF enviornment .............................................. 83

BCV remote mirroring................................................................83Standard remote mirroring .......................................................85

Configuring the Open Replicator environment............................ 87

Chapter 5 Backup and Restore Operations with TF/EIMBackup execution environments..................................................... 90

Command line startup ...............................................................90Backing up Exchange 2003 and 2007 servers with VSS ............... 91Backing up Exchange 2003 and 2007 servers (non-VSS) ............. 93Backing up multiple Exchange Server instances .......................... 97Creating a backup command initialization file............................. 98Restore procedures.......................................................................... 103

Exchange 2003/2007 VSS restores ..........................................103Restoring a database using Open Replicator ........................104Exchange Server Hot Split database restore with transaction log replay....................................................................................104Single mailbox recovery using a Hot Split database ...........112Exchange database restore from a remote site .....................113Cluster restores with and without maintenance mode .......116TF/EIM restore with VSS and Extended Maintenance mode ...........................................................................................117TF/EIM Restore with VSS without Extended Maintenance mode ...........................................................................................121

Troubleshooting Exchange Server ................................................ 124

Chapter 6 TF/SIM Overview and SetupOverview .......................................................................................... 128

TF/SIM with VSS..................................................................... 129SQL Server snapshots ..................................................................... 131

Concurrent BCVs ..................................................................... 132Remote backup......................................................................... 132SQL Server 2005 ....................................................................... 133

Setting up an SQL Server storage environment ......................... 135Solutions Enabler ..................................................................... 136

Configuring the TimeFinder/Mirror environment.................... 139Configuring the TimeFinder/Snap environment....................... 141Configuring the TimeFinder/Clone environment ..................... 142Configuring the SRDF environment ............................................ 144

5EMC TimeFinder/Integration Modules Version 4.1 Product Guide

Contents

Standard SRDF......................................................................... 144Remote TimeFinder/Mirror (RBCV)..................................... 145Remote mirroring of local TimeFinder/Mirror (BRBCV) .. 146Remote TimeFinder/Clone (RClone) .................................... 147

Configuring the Open Replicator environment ......................... 148Configuring Windows server disks ............................................. 149Creating a backup for dynamic disks with TimeFinder ........... 150

Chapter 7 SQL Server Backup and Restore Operations with TF/SIMTF/SIM execution environments ................................................. 154

Considerations and guidelines ............................................... 154Event logging and error files for Windows .......................... 156tsimsnap/tsimsnap2 execution sequence ............................. 156tsimvss execution sequence .................................................... 158Open Replicator execution sequence..................................... 158Command line start up............................................................ 159

Backing up a database or filegroup locally (tsimsnap) ............. 160Running TF/SIM backup locally ........................................... 161

Concurrently backing up a database (tsimsnap) ....................... 162Running TF/SIM backup locally ........................................... 163

Restoring a database or filegroup locally (tsimsnap) ................ 164Running TF/SIM restore ......................................................... 164Example .................................................................................... 166Restoring a database using Open Replicator........................ 168

Backing up a database or filegroup remotely (tsimsnap) ......... 169Running TF/SIM backup using SRDF .................................. 170

Backing up multiple databases locally (tsimsnap2) .................. 172Running TF/SIM backup locally ........................................... 173

Concurrently backing up multiple databases (tsimsnap2)....... 174Running TF/SIM backup locally ........................................... 175

Restoring multiple databases locally (tsimsnap2) ..................... 176Running TF/SIM restore ......................................................... 176Initializing multiple databases on the standby host ........... 177Initializing multiple databases on the BCV host.................. 177Restoring a database on a production clustered host ......... 179Restoring a database on a production clustered host with extended maintenance mode.................................................. 180Disaster recovery strategy for multiple databases .............. 182

Backing up multiple databases remotely (tsimsnap2) .............. 185Running a TF/SIM backup using SRDF ............................... 186

Backing up SQL Server instance remotely (tsimsnap2) ............ 188Running a TF/SIM instance backup using SRDF................ 189


Contents

SQL backup and restore methods (tsimsnap/tsimsnap2) ........ 191Initializing and updating the standby database...................191Initialize/recovery of backup database on local BCV.........195Initialize/recovery of backup database on virtual snap .....197Database filegroup backup and recovery..............................199

Restoring a database with VSS (tsimvss)..................................... 209

Appendix A TimeFinder/IMs Command ReferenceSYMCLI conventions ...................................................................... 212symntctl ............................................................................................ 213ExBackup2003/2007 ....................................................................... 220tsimsnap............................................................................................ 228tsimsnap2.......................................................................................... 238tsimvss .............................................................................................. 248

Appendix B TimeFinder/IMs Support MatrixExBackup2003/ExBackup2007 support....................................... 254tsimsnap support............................................................................. 256

tsimsnap backup from the production host ......................... 256tsimsnap backup from the backup host................................ 256tsimsnap restore from the production host .......................... 257

tsimsnap2 support........................................................................... 258tsimsnap2 backup from production host.............................. 258tsimsnap2 backup from the backup host.............................. 259tsimsnap2 restore from the production host ........................ 260

Open Replicator support................................................................ 261Open Replicator database backup......................................... 261Open Replicator restore from production host.................... 262

tsimvss support ............................................................................... 264tsimvss backup database......................................................... 264tsimvss backup using Open Replicator ................................ 265tsimvss restore database.......................................................... 266tsimvss restore using Open Replicator ................................. 267

Index .............................................................................................................................. 269


Contents


Title Page

Figures

1 Windows server enterprise storage system ................................................ 182 Exchange enterprise storage business continuance system ..................... 273 SQL enterprise storage business continuance system .............................. 274 Copy of a standard device to a virtual device (VDEV) ............................. 285 TimeFinder/Clone copy of a standard device ........................................... 306 SRDF — BCV mirroring ................................................................................ 317 SRDF — standard mirroring ......................................................................... 328 SRDF — mixed mirroring ............................................................................. 339 Symmetrix DMX device cold push operation ............................................ 3510 Parallel backups on multiple Exchange production servers .................... 6811 SE_ESM Properties - Identity tab settings .................................................. 7412 File dump sample for log required ............................................................ 10913 Transaction log listing ................................................................................. 11014 Restoring data from the R2 ......................................................................... 11315 Restoring data from the remote BCV ........................................................ 11516 SQL Server business continuance environment ...................................... 13517 SQL Component in the Custom Setup window ...................................... 13618 EMC storsqld service setting ...................................................................... 13719 Database query: Logical and physical filename pairs ............................ 16720 Relocation file with old logical and new physical filenames ................. 16721 Updating standby database using BCV transaction backup ................. 19322 Filegroup backup example environment .................................................. 20123 Database backup schedule for example scenario 1 ................................. 20324 Database backup schedule for example scenario 2 ................................. 206


Figures


Title Page

Tables

1 Requirements for EMC TimeFinder/IMs ....................................................212 License key reference numbers .....................................................................223 Exchange Server requirements ......................................................................234 SQL Server requirements ...............................................................................245 SIU command summary ................................................................................436 Troubleshooting Exchange Server operations ..........................................1247 TF/SIM commands .......................................................................................1548 Filegroup backup example environment ...................................................2029 ExBackup2003/ExBackup2007 supported options ..................................25410 VSS supported configurations .....................................................................25511 tsimsnap backup support from the production host ...............................25612 tsimsnap backup support from the backup host ......................................25613 tsimsnap restore support from the production host ................................25714 tsimsnap2 backup support from the production host .............................25815 tsimsnap2 backup support from the backup host ....................................25916 tsimsnap2 restore support from the production host ..............................26017 Open Replicator backup database support ...............................................26118 Open Replicator restore support using tsimsnap .....................................26219 Open Replicator restore support using tsimsnap2 ...................................26320 tsimvss TimeFinder/SRDF backup database support .............................26421 tsimvss Open Replicator backup database support .................................26522 tsimvss TimeFinder/SRDF database restore support .............................26623 tsimvss Open Replicator database restore support ..................................267


Tables


Preface

As part of its effort to continuously improve and enhance the performance and capabilities of the EMC product line, EMC periodically releases new versions of both the EMC Enginuity Operating Environment and EMC Solutions Enabler software. Therefore, some functions described in this guide may not be supported by all versions of Enginuity or Solutions Enabler software currently in use. For the most up-to-date information on product features, see your product release notes.

If a Solutions Enabler feature does not function properly or does not function as described in this guide, please contact the EMC Customer Support Center for assistance.

Audience This manual provides both guide and reference information for command-line users and script programmers. The manual describes how to manage Symmetrix arrays that contain Microsoft Exchange databases and SQL Server databases using SYMCLI commands of the Solutions Enabler software. EMC disk management CLI commands integrate the Windows operating system (Disk Manager) with the SYMCLI features to collectively automate various storage enterprise management operations.

Relateddocumentation

Related documents include:

◆ EMC TimeFinder/Integration Modules Release Notes

◆ EMC VSS Provider Release Notes

◆ EMC Solutions Enabler Symmetrix Base Management CLI Product Guide

◆ EMC Solutions Enabler Symmetrix TimeFinder Family CLI Product Guide


14

Preface

◆ EMC Solutions Enabler Symmetrix SRDF Family CLI Product Guide

◆ EMC Solutions Enabler Symmetrix Open Replicator CLI Product Guide

◆ EMC Host Connectivity Guides

Conventions used inthis manual

The following conventions are used in this manual:

In this manual, every use of the word Solutions Enabler or SYMCLI means Symmetrix CLI.

In this manual, every occurrence of the words volume, disk, or drive, also means device.

Note: A note calls attention to any item of information that may be of special importance to the reader.

CAUTION!A caution contains information essential to avoid damage or degraded integrity to storage of your data. The caution might also apply to protection of your software or hardware.

Typographical conventionsEMC uses the following type style conventions in this document:

Normal Used in running (nonprocedural) text for:• Names of interface elements (such as names of windows,

dialog boxes, buttons, fields, and menus)• Names of resources, attributes, pools, Boolean expressions,

buttons, DQL statements, keywords, clauses, environment variables, filenames, functions, utilities

• URLs, pathnames, filenames, directory names, computer names, links, groups, service keys, file systems, notifications

Bold: Used in running (nonprocedural) text for:• Names of commands, daemons, options, programs,

processes, services, applications, utilities, kernels, notifications, system call, man pages

Used in procedures for:• Names of interface elements (such as names of windows,

dialog boxes, buttons, fields, and menus)• What user specifically selects, clicks, presses, or types


Preface

Where to get help EMC support, product, and licensing information can be obtained as follows.

Product information — For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to the EMC Powerlink website (registration required) at:

http://Powerlink.EMC.com

Technical support — For technical support, go to EMC Customer Service on Powerlink. To open a service request through Powerlink, you must have a valid support agreement. Please contact your EMC sales representative for details about obtaining a valid support agreement or to answer any questions about your account.

Italic: Used in all text (including procedures) for:• Full titles of publications referenced in text• Emphasis (for example a new term)• Variables

Courier: Used for:• System output, such as an error message or script • URLs, complete paths, filenames, prompts, and syntax when

shown outside of running text

Courier bold: Used for:• Specific user input (such as commands)

Courier italic: Used in procedures for:• Variables on command line• User input variables

< > Angle brackets enclose parameter or variable values supplied by the user

[ ] Square brackets enclose optional values

| Vertical bar indicates alternate selections - the bar means “or”

{ } Braces indicate content that you must specify (that is, x or y or z)

... Ellipses indicate nonessential information omitted from the example


http://powerlink.emc.com

16

Preface


1

This chapter provides an overview of the SYMCLI and the TimeFinder/Integration Modules.

◆ SYMCLI and TimeFinder/Integration Modules ........................... 18◆ EMC and third-party requirements................................................. 21◆ Business continuance storage environment ................................... 26

Product Overview

Product Overview 17

18

Product Overview

SYMCLI and TimeFinder/Integration ModulesThe Symmetrix® Command Line Interface (SYMCLI) is a specialized library or set of UNIX-formatted commands that can be invoked one at a time. The SYMCLI is used in single command line entries and scripts to map and perform control operations on devices and data objects toward the management of your storage complex. The TimeFinder®/Integration Modules (TimeFinder/IMs) extend the basic SYMCLI command set to include the commands that allow you to integrate the SYMCLI offerings with various Windows server database applications and streamline the management of their associated database objects.

Enterprise storage for WindowsFigure 1 illustrates the major elements of a Symmetrix enterprise storage system for Windows Server applications. Symmetrix is an integrated cached disk array (ICDA) designed for online data storage. Host servers and Symmetrix arrays communicate through SCSI, iSCSI, or Fibre Channel interfaces.

Figure 1 Windows server enterprise storage system

The EMC Solutions Enabler Symmetrix Array Management CLI Product Guide provides more information on the major Symmetrix components.

Symmetrix

SYMCLI,SIU, TF/EIM,TF/SIM

WindowsServerhosts

Exchangedatabases

SQL Serverdatabases

Enginuity


Product Overview

EMC TimeFinder/IMs EMC® TimeFinder®/IMs includes the following software modules:

◆ Symmetrix Integration Utilities (SIU)◆ TimeFinder/Exchange Integration Module (TF/EIM)◆ TimeFinder/SQL Server Integration Module (TF/SIM)

SIU The Symmetrix Integration Utilities (SIU) are disk management utilities for setting up and controlling a TimeFinder, SRDF®, or Open Replicator business continuance configuration involving a Windows 2000 or Windows 2003 host. The SIU provides the disk management functions missing from the Windows operating system when working with TimeFinder, SRDF, and Open Replicator.

Note: For more information on SIU, refer to “Disk Management with Symmetrix Integration Utilities” on page 41.

TF/EIM The TimeFinder Exchange Integration Module (TF/EIM) streamlines the collective TimeFinder actions required in backup operations of the storage enterprise for Exchange servers. TF/EIM leverages EMC Solutions Enabler software (SYMCLI) and the Microsoft Win32 and Exchange backup application program interface (API) to coordinate the integration of EMC TimeFinder software and Microsoft Exchange Server.

Using the TimeFinder software, TF/EIM produces exact copies of the production volumes that hold the Exchange Server information stores and logs. This enables Exchange administrators to perform both full and single-mailbox restores in a fraction of the usual time.

Note: For more information on TF/EIM, refer to “TF/EIM Overview and Setup” on page 67.

TF/SIM The TimeFinder SQL Server Integration Module (TF/SIM) integrates and automates the features of EMC TimeFinder, the EMC Solutions Enabler (SYMCLI), and tools supplied with Microsoft SQL Server products.

TF/SIM with SYMCLI provides a user interface to back up and restore databases, using both the Microsoft Virtual Device Interface (VDI) and the database snapshot functionality. TF/SIM provides an integrated method for quickly creating point-in-time database copies that can be used for decision-support systems or database

SYMCLI and TimeFinder/Integration Modules 19

20

Product Overview

maintenance. TF/SIM also provides a database backup that can be quickly restored in disaster scenarios.

TF/SIM further enhances the availability of the database to mission-critical applications. It can greatly reduce backup and restore times and, in conjunction with typical database administration tasks, provide a more stable and available production platform.

Note: For more information on TF/SIM, refer to “TF/SIM Overview and Setup” on page 127.


Product Overview

EMC and third-party requirementsThis section lists the EMC and third-party software requirements for TF/EIM, TF/SIM and SIU.

For detailed interoperability information, refer to the EMC E-Lab Interoperability Navigator at http://elabnavigator.EMC.com

EMC software requirementsTable 1 lists the EMC software dependencies, their minimum requirements, and the license keys needed to run each of the TimeFinder/IMs. Table 2 lists the license key reference numbers shown in Table 1.

Table 1 Requirements for EMC TimeFinder/IMs

Module

Solutions Enablerversion

EMClicense keys

Enginuityminimumversion

Executionhost Comments

SIU V6.4.1 minimum

1 5x68 and later

Production or Backup host

TF/EIM V6.4.1 minimum

1, 2, 3, 4, 5, 7, 8

5x68 and latera

Backup host Solutions Enabler must be installed on the production host and the backup host. If you plan on using TF/EIM with VSS, you must also install the EMC VSS Provider on the production and backup host.

TF/SIM V6.4.1 minimum

1, 2, 3, 4, 6, 7, 8

5x68 and latera

Production or Backup host

Solutions Enabler must be installed on the production host and/or the backup host, depending on from where TF/SIM will be running.The Solutions Enabler installation must include the SRM SQL Database Components option.If you plan on using TF/SIM with VSS, you must also install the EMC VSS Provider on the backup host.

a. For Enginuity™ version 5x68 and later the instant split behavior is the default mode.

EMC and third-party requirements 21

22

Product Overview

EMC license keys The EMC Solutions Enabler license key numbers referenced in Table 2 are only required if that functionality is used. For example, if you are performing clone operations, you require the TimeFinder/Clone license key.

Gatekeeperrecommendation

EMC recommends that backup and production hosts being used with TF/EIM and TF/SIM be configured with 4 gatekeepers.

Windows Server supportSIU, TF/EIM, and TF/SIM only support Windows 2000 Server and Windows 2003 Server environments.

TimeFinder/IMs on IA64 requires EMC Solution Enabler version 6.4.1 for IA64 or later.

TimeFinder/IMs on x64 requires EMC Solutions Enabler version 6.4.1 for x64 or later.

The Windows host connection to the Symmetrix array can use a SCSI, iSCSI, or Fibre Channel interface.

Table 2 License key reference numbers

1 Base 4 TimeFinder/Mirror 7 TimeFinder/Clone

2 TimeFinder/Snap 5 TF/EIM 8 Open Replicator

3 SRDF/S 6 TF/SIM


Product Overview

Exchange Server support

Note: As of this version, 4.1, the Exchange Server 2000 support has been dropped from TF/EIM. If you require the use of Exchange Server 2000, download and install a previous version of the TimeFinder/Integration Modules software from http://Powerlink.EMC.com

The TF/EIM backup interface targets different combinations and versions of Windows and Exchange Server releases. The TF/EIM interface supports the following environments.

Note: A user must have both local administrative rights for the server as well as Exchange administrative rights for the domain.

Table 3 Exchange Server requirements

Exchange Windows

Exchange 2003 Windows 2000 Server (SP4)

Windows 2000 Advanced Server (SP4)

Windows Server 2003 Standard Edition (SP1/SP2)

Windows Server 2003 Enterprise Edition (SP1/SP2)

Windows Server 2003 R2 Edition (SP1/SP2)

Exchange 2007 Windows Server 2003 Standard Editiona (SP1/SP2)

Windows Server 2003 Enterprise Editiona (SP1/SP2)

Windows Server 2003 R2 Editiona (SP1/SP2)

Windows Server 2003 Standard Edition x64 (SP1/SP2)

Windows Server 2003 Enterprise Edition x64 (SP1/SP2)

Windows Server 2003 R2 Edition x64 (SP1/SP2)

a. Only supported as an Exchange Server 2007 backup host.



24

Product Overview

SQL Server supportThe various TF/SIM backup and restore commands target different combinations and versions of the Microsoft Windows operating system and the SQL Server versions. The TF/SIM commands integrate with and support the following environments:

◆ The following SQL Server and Windows combinations.

◆ Stand-alone or clustered servers using Microsoft Cluster Services (MSCS)

Note: A user must have both local administrative rights for the server as well as SYSADMIN rights for the SQL Server instance.

Table 4 SQL Server requirements

SQL Server Windows

SQL Server 2000 Server Edition Windows 2000 Server (SP4)

Windows 2000 Advanced Server (SP4)

Windows Server 2003 Standard Edition (SP1/SP2)



Windows Server 2003 R2 for x64 and R2 for x86 (SP1/SP2)


Window Server 2003 Enterprise Edition Itanium (SP1/SP2)

SQL Server 2005 Server Edition Windows Server 2003 Standard Edition (SP1/SP2)


Windows Server 2003 R2 for x64 and R2 for x86 (SP1/SP2)



Window Server 2003 Enterprise Edition Itanium (SP1/SP2)


Product Overview

VSS support Microsoft SQL Server 2005 provides support for creating snapshots from SQL Server databases using Volume Shadow Copy Service (VSS). This is accomplished using the SQL writer service.

The SQL writer service is installed in the system as part of the SQL Server 2005 installation, but is not started by default. Open the Services Control Manager to set this service to automatic.

Veritas supportVeritas Storage Foundation for Windows (SFW) version 4.1 or 4.2 is required for dynamic disks in a Windows 2000 environment.

Veritas Storage Foundation for Windows (SFW) version 4.1, 4.2, 4.3, or 5.0 is required for dynamic disks in a Windows 2003 environment.


26

Product Overview

Business continuance storage environmentThe Symmetrix business continuance storage environment for Exchange and SQL databases is based on the integration of TimeFinder/IMs with TimeFinder, SRDF, and Open Replicator technologies.

TimeFinder/Mirror EMC TimeFinder/Mirror works by creating multiple, independently addressable online business continuance volumes (BCVs) for information storage. Each BCV is a Symmetrix device and is configured as a single mirror, which independently supports host applications.

BCVs, created as mirror images of active production volumes, give you another source of data with which to work. This is ideal for backup and recovery, as well as off-line operations such as defragmentation. The principal device, known as the standard device, remains online for regular Symmetrix operation so there is no interruption of service with the original production server.

Each BCV contains a unique host address making it accessible to a separate backup/recovery server.

A business continuance sequence first involves setting, or establishing, the BCV device as a mirror of a standard Symmetrix device, making the BCV device available for backup. The BCV device may later be separated, or split, from the standard Symmetrix device with which it was previously established. The split BCV device still has valid data, and is available for backup or other host processes through its original device address.

For illustrations of TimeFinder/IMs in Exchange and SQL environments, refer to Figure 2 and Figure 3 on page 27.


Product Overview

Figure 2 Exchange enterprise storage business continuance system

Figure 3 SQL enterprise storage business continuance system

ExchangeServer A

production

ExchangeServer Bbackup

STD BCV

BCV

Symmetrix

Databasefiles

STD

Log files

Databasefiles

Log files

STDproductiondatabases

BCVread-onlystandby

BCV

Transactionbackupdevices

BCV

Userdatabase

log

BCV

Userdatabase

STD

Transactionbackupdevices

STD

Userdatabase

Log

STD

Userdatabase

ProductionSQL server Standby SQL server

Symmetrix

Business continuance storage environment 27

28

Product Overview

TimeFinder/Snap EMC TimeFinder/Snap allows you to create virtual copy sessions between a source device and multiple virtual (VDEV) target devices. The source device can be either a standard device or a BCV device. The target device(s) must be virtual device(s).

EMC TimeFinder/Snap is useful in situations where multiple copies of production data are needed for testing, backups, or report generation. It can also be used to reduce disk contention and improve data access speed, by assigning users to copies of data rather than accessing the one production copy.

EMC TimeFinder/Snap functionality is controlled using copy sessions, which pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of the devices. A copy session must first be created and then activated for the target virtual devices to become accessible to its host. When the information is no longer needed, the session can be terminated.

Figure 4 illustrates a virtual copy session where the controlling host creates a copy of standard device DEV001 on target device VDEV005.

Figure 4 Copy of a standard device to a virtual device (VDEV)

Symmetrix

Controlling host

StandardDEV001

symsnap create

VirtualVDEV005

Target host

Createsessionsymsnap activate

Savedevices

Device pointers from virtual device to original data

Original data copiedto save devices onfirst CopyOnWrite

Device pointers toSave devices

Source

Target

I/O

I/O


Product Overview

As illustrated in Figure 4 on page 28, a virtual device is a host-accessible device that contains a collection of pointers to unchanged data and to save data. When you activate a snap pair, disk space is consumed (on SAVE devices) only when data is written to the source device, and then only the space required to accommodate pre-update data from the source tracks that changed.

Pointers on the virtual device are initialized to point to tracks on the source device. The first time new data is written to a track on the source device, the original track data is copied to a SAVE device, and the pointer on the virtual device is changed to point to that original data.

TimeFinder/Clone EMC TimeFinder/Clone allows you to create clone copies of a source device on multiple target devices. The source and target devices can be either standard devices or BCV devices, as long as they are all the same size and emulation type (FBA or CKD).

TimeFinder/Clone copies are appropriate in situations where multiple copies of production data are needed for testing, backups, or report generation. Clone copies can also be used to reduce disk contention and improve data access speed by assigning users to copies of data rather than accessing the one production copy. Depending on whether a device has associated BCVs, a single source device may have as many as 16 clone copies.

TimeFinder/Clone functionality is controlled using copy sessions, which pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of the device pairs. A copy session must first be created to define and set up the clone devices. The session is then activated, enabling the target device to be accessed by its host. When the information is no longer needed, the session can be terminated.


30

Product Overview

Figure 5 illustrates a clone session where the controlling host creates a clone copy of standard device DEV001 on target device DEV005.

Figure 5 TimeFinder/Clone copy of a standard device

SRDF Symmetrix Remote Data Facility (SRDF) provides a disaster tolerant business continuance environment. SRDF with TimeFinder/IMs allows for the recovery from local database corruption and local site disasters, as well as restart capabilities from the remote site.

With TimeFinder/IMs integrating your Exchange/SQL server with both TimeFinder and SRDF, you can recover from any disaster. You can also restart Exchange/SQL at the remote location in the event something happened to the production site.

TimeFinder/IMs supports two types of SRDF configurations: BCV mirroring and standard mirroring.

Symmetrix

Controlling host

SourceDEV001

TargetDEV005

Target host

symclone create

symclone activate

followed by


Product Overview

SRDF BCV mirroring The BCV mirroring configuration shown in Figure 6 consists of a standard volume and a local BCV-R1 volume. The remote R2 mirror mirrors the local BCV, and it also has a remote BCV (BRBCV) mirror. This configuration allows for local database recovery as well as remote disaster recovery. When the BCV-R1 and R2 are synchronized, the remote BCV exists to ensure that a valid, remote copy of your Exchange data is always available.

Figure 6 SRDF — BCV mirroring

With this BCV mirroring configuration, each mirror is incrementally established independently in sequence:

1. The BCV-R1 is established and split from the standard volume.

2. The R2 is established and split from the BCV-R1.

3. The remote BCV (BRBCV) is established and split from the primary R2 device (if desired).

Note: TF/EIM will checksum (using ESEUTIL) the R1-BCV copy of the data.

R2

LocalSymmetrix

RemoteSymmetrix

Remote disasterrecovery server

(optional)

BRBCVR1BCV

Productionserver

Backupserver

Standard


32

Product Overview

SRDF standard mirroringThe standard mirroring configuration, shown in Figure 7, consists of a production R1 standard device that is mirrored by a remote R2 device. Also, the remote R2 device has a remote BCV (RBCV). This configuration provides remote database and site disaster recoverability, but does not provide any local recoverability. This configuration is ideal for environments that require the remote site disaster recoverability, but do not have enough storage available to implement the previous example. The obvious disadvantage to this configuration is that database restores, necessitated by corruption or other failures, must be performed over the SRDF link, which will be slower than the local database restores using EMC TimeFinder/Mirror.

Figure 7 SRDF — standard mirroring

With this standard mirroring configuration, there are two possible modes of operation:

◆ Keep the SRDF link synchronously established R2 with R1. In this case, the RBCV is established and split from the standard volume.

Note: TF/EIM will checksum the RBCV copy of the data.

R2

LocalSymmetrix

RemoteSymmetrix

Backup server

RBCV

Productionserver Standard

R1


Product Overview

◆ Keep the SRDF link split. In this case, the TimeFinder/IM (TF/EIM or TF/SIM) will first establish and split the SRDF link, transferring data from R1 to R2. Then, the TimeFinder/IM will establish and split the RBCV (if desired).

Note: TF/EIM will checksum the R2 copy of the data. A Hot Split is not possible in this scenario because SRDF does not offer an instant split.

Figure 8 shows an example of mixed mirroring with SRDF.

Figure 8 SRDF — mixed mirroring

R2

LocalSymmetrix

RemoteSymmetrix

Backup Server

RBCV

ProductionServer

STD

R1BCV

BRBCV

R1

R2Local VSS path

Remote VSS path-brbcv


34

Product Overview

Open ReplicatorThe EMC Open Replicator for Symmetrix (ORS), Enginuity version 5671 and later, provides a method for copying device data from various types of arrays within a Storage Area Network (SAN) infrastructure to or from a Symmetrix DMX™ array. For example, Open Replicator for Symemtrix provides a tool that can be used to migrate data from older Symmetrix arrays and CLARiiON® arrays to a Symmetrix DMX array. Alternatively, the Open Replicator command can also be used to migrate data from a Symmetrix DMX array to other types of storage arrays within the SAN infrastructure. Copying data from a Symmetrix DMX to devices on remote storage arrays allows for data to be copied fully or incrementally.

Open Replicator session (ORS) operations are controlled from a local host attached to the Symmetrix DMX. Data copying is accomplished as part of the storage system process and does not require host resources. Optionally, the data can be copied online between the Symmetrix DMX and remote devices, allowing host applications, such as a database or file server, to remain operational (function normally) during the copy process. Data is copied in sessions with up to 512 sessions allowed per Symmetrix DMX array.

There can only be one control device per active session.

In Figure 9 on page 35, the BCV or clone will be the source device in the Open Replicator session copy. The production SQL


Product Overview

Server/Exchange database is running on the STD devices, the BCV or clone devices are presented to the backup host.

Figure 9 Symmetrix DMX device cold push operation

Note: For TxIM device files, the source Symmetrix device can be specified as either the production STD volume or it can be the BCV or clone associated with the production STD volume. TxIM automatically determines the STD to BCV/clone relationship.

If the source symid in the device file refers to the STD devices used by the production SQL Server databases or Exchange databases, and BCVs are used, then TxIM uses preferred BCV pairs to migrate the data to the remote Symmetrix array. For clone devices, the user needs to manually create a clone session, adding the -copy or -precopy option. TxIM then picks up the clone devices that are in the created or recreated state. Once the relationships are established, and the BCV or clone copies are completed, TxIM uses the offline cold push operation for Open Replicator session (ORS).

ORS cold push

ORS TargetSymmetrix or CLARiiON

No connection to backup host required

Backup hostProduction host

STD

STD

BCV

Clone

ORSTGT

ORSTGT


36

Product Overview

If the source symid in the device file refers to the BCV or clone devices then TxIM still requires the BCV or clone relationships to exist before executing the TF/EIM or TF/SIM command using the -orf option.

Another command line option for TF/EIM and TF/SIM, associated with ORS, is -orsdiff. This option performs an ORS differential data copy operation. By default, a full data copy operation would be performed. The -orsdiff option can only be used when a previous full copy operation has completed. To support differential ORS operations, when TxIM creates an ORS, the session will not be automatically terminated when the TxIM ORS operation has completed. Users must manually terminate TxIM created ORS sessions. The ORS name created by TxIM will be tsim_ors_session or teim_ors_session. You need to use the device file specified with -orf and the ORS session name with the symrcopy terminate command to terminate the session.


2

This chapter describes how to install the TimeFinder/Integration Modules.

◆ Before you begin................................................................................. 38◆ Installing the TimeFinder/Integration Modules ........................... 39◆ Enabling your software ..................................................................... 40

Installation

Installation 37

38

Installation

Before you beginBefore you run the installation program, be sure to do the following:

❑ Review the requirements listed in “EMC and third-party requirements” on page 21 and refer to the EMC E-Lab Interoperability Navigator at http://elabnavigator.EMC.com

❑ Ensure that the Solutions Enabler V6.4.1 installation includes the SRM SQL Database option as this does not install by default.

❑ If you are installing TimeFinder/Integration Modules on IA64, uninstall the previous version of TimeFinder/IMs (if applicable).

❑ Stop the SIU service and all running TimeFinder/Integration Modules (if applicable).


Installation

Installing the TimeFinder/Integration ModulesThe TimeFinder/IMs are packaged on a single CD-ROM that contains executable files for the following modules:

◆ Symmetrix Integration Utilities (SIU)

◆ TimeFinder/Exchange Integration Module (TF/EIM)

◆ TimeFinder/SQL Integration Module (TF/SIM)

You can install each module separately or choose to install any or all of the modules in a multiple install session.

Note: You must perform the installation as a Windows administrator so that the folders and files created by the installation have the correct permissions.

To install the TimeFinder/IMs:

1. Log on as host system administrator.

2. Insert the TimeFinder/IMs CD in the CD-ROM drive.

If autorun is enabled, the installation script starts automatically.

If autorun is not enabled, or if the installation does not start automatically, do the following to run the setup manually:

• For 32-bit x86 hosts, run setup.exe from the WIN32 folder.

• For IA64 hosts, run setup.exe from the IA64 folder.

• For x64 hosts, run setup.exe from the x64 folder.

3. In the Welcome dialog box, click Next.

4. In the Destination Location dialog box, select an installation directory, and click Next.

5. In the Select Features dialog box, select the modules to install, and click Next.

6. In the Installation Summary dialog box, verify your installation directory and features, and click Next.

The setup program installs the requested features.

7. To complete the installation, you must enable your software according to the procedure in “Enabling your software” on page 40.

Installing the TimeFinder/Integration Modules 39

40

Installation

Enabling your softwareBefore you can use TF/EIM and TF/SIM, you must first enable each module’s functionality by entering the appropriate license keys.

To enable the modules:

1. Ensure you are still at the install path by entering the following:

C:\Program Files\EMC\SYMCLI\bin

2. Invoke the License Management Facility (LMF) by entering the following:

symlmf

The LMF displays the following:

E M C S O L U T I O N S E N A B L E R

SOLUTIONS ENABLER LICENSE MANAGEMENT FACILITY

3. At the following prompt, enter y to continue the registration:

Register LICENSE Key (y/[n]) ? y

4. At the following prompt, enter the license key of the module you want to enable:

Enter License Key:

LMF displays a message indicating success.

5. At the following prompt, enter y to register another component, or n to quit:

Register License Key (y/[n]) ? y

6. Verify that the registered module(s) are in the license file (C:\Program Files\EMC\Symapi\config\symapi_licenses.dat).


3Invisible Body Tag

This chapter describes the Symmetrix Integration Utilities (SIU) disk management operations for your storage system in a Windows Server environment.

◆ Introduction ........................................................................................ 42◆ Making disks visible to the system.................................................. 45◆ Viewing detailed information about disks..................................... 46◆ Defining volume sets and disk groups ........................................... 47◆ Manipulating disk signatures .......................................................... 49◆ Flushing cache buffers to disk.......................................................... 50◆ Mounting disks................................................................................... 51◆ Creating a backup for dynamic disks ............................................. 56◆ Performing typical storage operations............................................ 57

Disk Management withSymmetrix Integration

Utilities

Disk Management with Symmetrix Integration Utilities 41

42

Disk Management with Symmetrix Integration Utilities

IntroductionThe Symmetrix Integration Utilities (SIU) integrates and extends the Windows 2000 and Windows 2003 disk management functionality to better operate with and on the EMC Symmetrix business continuance storage devices. TimeFinder and Symmetrix Remote Data Facilities (SRDF) are two main management components of the EMC business continuance offering. SIU operations integrate with the management functionality of TimeFinder and SRDF with support specifically for Windows servers by extending their ability to:

◆ Mount and unmount hard disks and their associated file systems.

◆ Flush file system cache buffers to disk.

◆ Write or erase signatures to a disk or group of disks.

SIU is not a replacement for the Windows Logical Disk Manager (LDM), but bridges these lacking functionalities necessary for Windows users to optimally work with EMC business continuance storage devices.

Note: In this chapter, every occurrence of the word volume also means device or disk.

SIU capabilities SIU enables you to perform the following actions:

◆ Mount and unmount hard disks and their associated file systems.

◆ Manipulate drive letter assignments.

◆ View the actual physical configuration and the volume configuration data in the Windows operating system.

◆ Erase or write signatures (labels) to a disk or group of disks.

◆ Flush any pending cached file system data to disk.

◆ Show any applications using a specified volume.

◆ Rescan and discover the disk configuration in view by the Windows host.

◆ Mask and unmask devices from and to the Windows host.



Privilege requirementsSIU is based on the functionality and features of associated hardware and software in an EMC Enterprise Storage environment managed and used on Windows 2000 and Windows 2003 platforms. Most command actions require administrative privileges.

SIU commands The SIU CLI commands are a syntactical set and form of one command (symntctl), which has various arguments to support each of the main functional operations or actions. A summary of the SIU command set that operate in a Windows operating system environment is listed in Table 5.

These commands can be used in scripts when working on Windows 2000 or Windows 2003 platforms.

For command syntax information, refer to Appendix A and the remainder of this chapter.

Table 5 SIU command summary

Command Argument Action

symntctl Performs disk management operations for Windows platforms to properly work with Business Continuance devices. Possible operations are:

mount Mounts the specified disk to the specified mount point or drive letter.

umount Unmounts the specified disk from the specified mount point or drive letter.

list Views the actual physical disk configuration and the volume configuration data in the Windows operating system.

openhandle Displays any open sessions (applications/processes) working with a specified disk.

signature Manipulates the disk signature.

flush Flushes all pending unwritten file system cache entries to disk.

rescan Rescans and discover the disk configuration in view by the Windows host.

locks Controls the file system locks held on devices.

mask Uses device masking to remove the device from the host.

unmask Uses device masking to present the device to the host.

Introduction 43

44


Volume management softwareWindows 2000/Windows Server 2003 have two types of disks: basic and dynamic. Basic disks support primary partitions only. Dynamic disks support FT-Volumes only. The Windows Logical Disk Manager (LDM) provides basic volume management and enables you to logically group disks under disk groups.

Most of the advanced capabilities of dynamic disks are only available with SFW. SFW is a storage management subsystem that enables you to manage physical disks as logical devices or volumes. A volume is a logical device that appears to data management systems as a physical disk partition device.

SFW dynamic disk groups with TimeFinderFor Windows advanced server systems with dynamic disks, SIU functionality works with Veritas Storage Foundation for Windows.

If you are going to set up and use Veritas dynamic disk groups (VDGs) on a production server, you must comply with the following requirements when configuring VDGs for use with Solutions Enabler TimeFinder/Mirror software:◆ Create a TimeFinder/Mirror device group for every dynamic disk

group, maintaining the one-to-one basis. To keep this relationship clear, name the dynamic disk groups the same as the TimeFinder/Mirror device groups.

◆ It is not necessary to create the disk group on the backup server, since the Logical Disk Manager (LDM) database is resident on every dynamic disk, as it is copied over to the backup server on each of the BCVs. All disk group definitions are stored in this database and will immediately appear on the backup server (in an offline state). You can create the TimeFinder/Mirror device groups on either the production server or the backup server.

Be aware of the following when creating TimeFinder/Mirror device groups:

• Do not mix STD and BCV devices in the same VDG.

• Do not have Symmetrix and non-Symmetrix storage type devices in the same VDG.

• Do not mix R1 and R2 devices in the same VDG.• Do not add gatekeeper devices to any VDG.



Making disks visible to the system

After any dynamic disks are added to the Windows system, the new disks are initially not accessible. The SIU rescan action scans the drive connections and discovers any new disks available to the system, using the following form:

symntctl rescan

The rescan command is useful after you perform a TimeFinder/Mirror establish or split operation because when you do an establish or split, your devices become inaccessible. So, after you perform the establish or split operations, you can rescan the buses to discover all the devices to make them visible to the system again.

After you perform the rescan action, you can examine the results of the discovered disks, to ensure these disks are available to the system:

symntctl list -physical

Making disks visible to the system 45

46


Viewing detailed information about disks In the Windows operating system, the SIU list action provides a consolidated view for displaying and managing the actual physical disk configuration and the volume configuration data.

To view disk numbers in your storage configuration, enter:

symntctl list -physical [-brief]

To view the volume configuration, enter:

symntctl list -volume [-brief]

In situations when you want a collapsed or an abbreviated output display for quick overall viewing, use the -brief option.

Also, you can target a specific disk by entering:

symntctl list -pd diskN [-brief]

where N is the disk number.

Or, you can target a specific volume by entering:

symntctl list -vol VolName [-dg DgName][-brief]

and optionally confining the volume list within a device group (DgName).



Defining volume sets and disk groupsThe term volume set is used to describe multidisk volumes on Windows 2000/2003 systems. In the context of SIU, a volume set is referred to as a Veritas disk group (VDG) when using dynamic disks. A VDG is made up of disk space that is linked together from multiple disks. You can dynamically extend the size of a spanned volume.

You can extend a simple or spanned volume only if the volume was created on a dynamic disk. You cannot extend a simple or spanned volume that was upgraded from basic to dynamic.

When using dynamic disks in the Windows system, all the information about the volumes is stored on the disk, including the system ID, device group ID, and so on. After the split, the BCVs have all the information from the standard Symmetrix volume (STD). It is therefore necessary to make the IDs local to the system to make them accessible.

Deporting disk groups

Deporting with symntctl is no longer supported as of SIU 4.0. It is recommended to use Veritas commands to deport Veritas dynamic disk groups (VDGs).

A disk group consists of volumes and disks that are logically grouped together in the Veritas database.

To deport a certain disk group, use the following form:

vxdg deport -g DgName

Deporting a disk group disables access to a disk group that is currently enabled (imported) by the system. You should deport a disk group if you want to move the disk members of a disk group to another system or if you want to use all of the disks remaining in a disk group for a new purpose.

Importing disk groups

Importing with symntctl is no longer supported as of SIU 4.0. It is recommended to use Veritas commands to import Veritas dynamic disk groups (VDGs).

Importing a disk group enables host system access to members of a disk group. If you want to move a disk group from one system to another, first disable (deport) the disk group on the original system, and then move the disk members between systems and enable (import) the disk group.

Defining volume sets and disk groups 47

48


To import a certain disk group, use the following form:

vxdg import -g DgName [-C]

This command will not function when the disk group is part of a cluster.

The option to clear the host ID [-C] should be used with SFW Version 3.0 or later, when the disk group originates on a host other than where it is being imported. This is a common occurrence with TimeFinder/Mirror when the standard volumes and BCVs are presented to two different hosts. The import command will fail in this scenario if the clear host ID is not used.



Manipulating disk signaturesIn the Windows operating system, basic disks are identified by disk signatures (also known as labels).

Note: In Windows Server 2003, GPT (GUID Partitioned) disks are identified by disk ID. The disk signature operation is not applicable to GPT disks.

Using a signature action, you can erase a signature from disk, write or edit a signature to disk, or initialize a signature.

You specify the physical disk for a signature operation using the -pd option:

symntctl signature -pd diskN ...

where N is the physical disk number.

To view disk numbers in your storage configuration, enter:


Using the -sig option, the signature of a disk is assigned/changed to any desired label specified in this command option.

Using the -initialize option, the SIU service assigns signatures to any disks discovered without signatures.

Using the -erase option, the signature of the specified disk is erased. This option is only used when setting up shared disks and TimeFinder configurations.

Note: With Windows 2003, this option will erase the signature, only to have Windows immediately re-generate a new signature. Therefore, the volume will appear with a different signature, instead of an empty signature.

Manipulating disk signatures 49

50


Flushing cache buffers to diskTimeFinder/Mirror operations such as an on-the-fly BCV split require that the Windows file system cache buffers be flushed to disk. For this case, all pending unwritten file system data must be flushed to disk for a clean and complete split. The SIU flush action does this without removing the drive letter or volume association. This flush action is needed where the standard/BCV or SRDF R1/R2 pair is split without taking down an application.

You can target the standard or R1 device to flush with a drive letter or mount point:

symntctl flush -drive DriveLettersymntctl flush -path MountPnt

Or, you can target the standard device to flush with a volume name or global ID (GUID):

symntctl flush -vol VolName [-dg DgName]symntctl flush -guid VolGuid

Because this command only flushes the Windows file system, applications that handle their own cache management (such as SQL Server or Exchange) are not affected. Flush or checkpoint mechanisms embedded in the application must flush its own application data. The application data must be flushed first, followed by a file system flush.

For example, to flush a volume with the volume GUID of Volume{ecba40b5-d522-11d5-98cb-00b0d0b03303}, enter:

symntctl flush -guid Volume{ecba40b5-d522-11d5-98cb-00b0d0b03303}



Mounting disksAfter splitting BCV or SRDF volumes, you can reassign the drive letters for those volumes using the SIU mount action. The SIU mount action lets you mount hard disks and their associated file systems in your storage environment.

The mount action mounts the specified volume name, GUID, or Symmetrix device to the specified drive letter or mount point:

symntctl mount -drive DriveLetter | -path MountPnt<-vol VolName [-dg DgName]> | -guid VolGuid | –sid SymId | –symdev SymDev | -part PartNum

SIU provides a Windows service that performs the mount, unmount, and flush operations. This is done so that an exclusive lock can be acquired and set on a volume when it is dismounted. This lock is cached so that no other applications can access the volume while it is being unmounted, thus ensuring data integrity during TimeFinder/Mirror establish and split operations.

If multiple, simultaneous symntcl mount or umount commands are issued, the SIU Service allows one command to continue while the next command waits. Once the first command completes, the next command continues and will also complete.

When a symntctl mount command is performed, the SIU service:

1. Locates the cached handle and lock to the volume being mounted.

2. Adds the drive letter or mount point assignment to that volume.

3. Releases the cached operating system lock if one is currently held.

4. Closes the handle to the volume.

SIU and SYMAPI databaseWhen performing mount operations on the Symmetrix device number (-symdev option), SIU relies on the SYMAPI database to obtain physical drive information. The physical drive information within the SYMAPI database is created and updated following a Symmetrix discover command symcfg discover. Therefore, if any device changes are made to the mount host, it is recommended to run the symcfg discover command in order to update the SYMAPI database to reflect those changes. If device changes are made

Mounting disks 51

52


frequently to the mount host, then the discover should be scripted as a part of the mount process.

When symntctl mount or umount commands are called, SIU takes an exclusive lock against the SYMAPI database. If other Solutions Enabler commands occur in parallel to the SIU operations, SIU waits on any locks against the SYMAPI database and continues after the locks are released.

Because SIU mount and unmount operations can interact with the SYMAPI database, it is recommended that at least 2 gatekeeper devices are presented to the SIU mount host.

Disk unmount operationsOn the BCV or SRDF target (R2) side, establishing a BCV with its standard volume makes the BCV unavailable to the Windows system. Windows systems generate error messages if a mounted volume is referenced while unavailable.

The SIU unmount action provides the ability to unmount hard disks and their associated file systems, and also removes the drive letter from the specified disk volume.

You can target a drive letter or mount point:

symntctl umount -drive DriveLetter [-nolock] [-force]symntctl umount -path MountPnt [-nolock] [-force]

Or, you can target a volume or global ID:

symntctl umount -vol VolName [-nolock] [-force]symntctl umount -guid VolGuid [-nolock] [-force]

This affects the current drive letter mapping. The command performs a file system flush as part of the dismount process, and the drive is locked with an exclusive lock until a subsequent mount (or forced release). This lock is set so that no other applications can access the volume while it is being unmounted, thus ensuring data integrity during TimeFinder/Mirror establish and split operations.

If you want to leave the drive unlocked after the dismount (umount) action, you can specify the -nolock option.

Note: Issuing an umount with the -nolock option does not check for openhandles and unmounts volumes even if applications are accessing the volumes.



When an unmount operation is performed, the SIU service does the following:

1. Gets a handle to the volume being unmounted from the operating system.

2. Obtains an exclusive lock on that volume from the operating system (unless -nolock is specified).

3. Flushes all pending file system cached data to disk for that volume.

4. Dismounts the volume by calling DeviceIoControl() with the FSCTL_DISMOUNT_VOLUME control code.

5. Deletes the specified drive letter or mount point. If the umount command was executed with the volume name or GUID, then all drive letter and mount point assignments are deleted.

Open handles on drivesBefore performing an unmount or split action, you should determine if any other applications or processes are using, or have, an open handle on the target drive. The SIU openhandle action enables you to determine whether there are processes accessing a volume you intend to unmount. This command should only be used for diagnostic and informational purposes to list processes using a drive.

You can target a drive letter or mount point:

symntctl openhandle -drive DriveLettersymntctl openhandle -path MountPnt

Or you can target a volume or volume GUID:

symntctl openhandle -vol VolName [-dg DgName]symntctl openhandle -guid VolGuid

Mounting disks 53

54


Exclusive locks on drivesSIU takes exclusive locks on devices during an unmount operation. SIU retains these locks until SIU services is stopped, the host is rebooted, or the file system is mounted.

In troubleshooting situations, or when a third-party application fails, you can release these locks by entering:

symntctl locks -releaseall

This command releases all locks currently cached by SIU.

To release only a single exclusive lock being held for a particular volume, specify the volume’s GUID in the following command:

symntctl locks -release VolGuid

To view all of the exclusive locks currently held by SIU, enter:

symntctl locks -listall

Note: For details on the SIU command syntax, refer to Appendix A.

Device masking operationsIt is often necessary to add and remove access to a given Symmetrix device for the current host. This is known as device masking. Device masking typically requires several steps to make the device visible or hidden to the host, especially if multiple HBAs and PowerPath are being used. SIU provides the ability to perform device masking operations with a single command by leveraging some of its internal functionality, like system rescan. When using SIU to mask or unmask a device, SIU does the following:

1. Obtains a list of all of the HBAs connected to the specified Symmetrix array on the current host.

2. Determines the current state of the specified device on each of the HBAs (whether it is currently masked or unmasked).

3. Either adds or removes access to the specified device (depends on whether it is a mask or unmask operation) for each of the HBAs.

4. Performs a system rescan of the host so that the newly masked devices will be removed from the host, and the newly unmasked devices will appear on the host.



Note: There is currently no way to control which HBAs should be involved in the mask/unmask operation. For PowerPath, SIU will perform the mask/unmask on all HBAs where the specified device is accessible.

For SIU device masking to work correctly, the Symmetrix array must be configured for device masking. The following requirements exist:

◆ There must be a valid VCMDB created on the Symmetrix array.

◆ The VCMDB must be mapped to all of the Fiber Adapters (FA) where the device masking is to take place.

◆ The VCM flag must be set on all of the FAs where the device masking is to take place.

◆ The Symmetrix device that is to be masked or unmasked must be mapped to all of the FAs where the device masking is to take place.

Note: SIU device masking does not perform any checking to determine if the Symmetrix device is currently accessible to other hosts on the SAN. It is the user’s responsibility to prevent multiple hosts from using the same device.

Device masking is very useful when attempting to break open handles to a current volume. Currently, the SIU umount command will fail if there are processes with open handles to that volume. In order to ensure the integrity of the data on the volume, these open handles need to be removed. By masking the device from the host, Windows will be forced to completely unload the I/O stack for that device, thus removing all open handles. The device can then be unmasked and it will appear on the host without any open handles.

Using device masking to break the open handles to a volume may be necessary when using TimeFinder/Mirror in particular environments. Currently, it is recommended that the BCV be unmounted, and subsequently locked by SIU before establishing it. In most cases, this is sufficient to prevent the volume’s cache from getting corrupted during the TimeFinder/Mirror establish. However, if the host is running monitoring agents or anti-virus software that maintains open handles to the BCV, then the unmount and lock will not be enough. Instead, you must mask the BCV prior to the TimeFinder/Mirror establish in order to remove the open handles. After the split operation, the BCV can be unmasked so that it is accessible to the host. This procedure is explained in “For basic disks with open handles:” on page 59.

Mounting disks 55

56


Creating a backup for dynamic disksThe following procedure describes the process for using both SIU and TimeFinder/Mirror to create a BCV of a dynamic disk. If the disk group on the backup server containing the BCVs is not online, skip steps 1 and 2.

1. Unmount any drive letters or reparse points currently assigned to the BCVs in the dynamic disk group on the backup server.

Note: Do not use mountvol to perform this dismount.

2. Deport the dynamic disk group on the backup server. This step is only for precaution. In test, the dynamic disk groups are deported automatically once the TimeFinder/Mirror establish is performed and the BCVs become Not Ready to the server.

3. Establish the TimeFinder/Mirror device group.

4. Rescan the storage bus on the backup server. The dynamic disk group and all of its dynamic disks are listed as unreadable, and are therefore, offline.

5. Split the TimeFinder/Mirror device group.

6. Rescan the storage bus on the backup server. The dynamic disk group and all of its dynamic disks are readable, but are still offline and foreign.

7. Import the dynamic disk group. Accept the default to keep the dynamic disk group name the same. The final result is that the dynamic disk group and all of its dynamic disks are online and usable.



Performing typical storage operationsThe following are typical storage operations that use both SIU and TimeFinder/Mirror commands to manage the storage environment.

Synchronizing the BCV

Using the symntctl and the symmir commands, the following procedures for basic and dynamic disks work with devgroup1 to synchronize the BCV device (drive x) with the standard on primary and secondary servers. For more information on the symmir command, refer to EMC Solutions Enabler Symmetrix TimeFinder Family CLI Product Guide.

For Windows Basic or Dynamic Disks:1. Unmount the volume on the secondary system with the following

command:

symntctl umount -drive x:

2. Establish the standard and BCV pair on the primary system with the following command:

symmir -g devgroup1 est

3. Verify that the device is synchronized on the primary system with the following command:

symmir -g devgroup1 verify -synched

4. Perform a flush on the primary system with the following command:

symntctl flush -drive x:

5. Split the device on the primary system with the following command:

symmir -g devgroup1 split

6. Perform a rescan on the secondary system with the following command:

symntctl rescan

7. Mount the volume on the secondary system with the following command:

symntctl mount -drive x: -vol volumex

Performing typical storage operations 57

58


For Veritas Dynamic Disks:1. Unmount the volume on the secondary system with the following

command:


2. Deport the dynamic disk group on the secondary system and rescan with the following commands:

vxdg deport -g devgroup1 symntctl rescan

3. Perform an establish on the primary system with the following command:


4. Rescan the storage bus on the backup server to assure that the disk has been dropped and will not be accessed by Windows Plug and Play with the following command:

symntctl rescan



6. Perform a flush on the primary system with this command:





symntctl rescan

9. Perform an import of the disk group on the secondary system and rescan with the following commands:

vxdg import -g devgroup1 -Csymntctl rescan





For basic disks with open handles:To ensure that cache corruption does not occur when a BCV has open handles:

Note: This procedure should be used for all TimeFinder operations if the BCV volume has open handles (usually due to a monitoring agent or anti-virus software). To determine if a BCV has open handles, use the symntctl openhandle command.

1. Unmount the volume on the secondary system with the following command:

symntctl umount –drive x:

2. Mask the volume on the secondary system with the following command:

symntctl mask –sid SymmId –symdev SymDev

3. Establish the standard and BCV pair on the primary system with the following command:




5. Perform a flush on the primary system with the following command:




7. Unmask the volume on the secondary system with the following command:

symntctl unmask –sid SymmId –symdev SymDev


symntctl rescan


60



symntctl mount –drive x: -vol volumex

Note: The above SIU mask and unmask commands (steps 2 and 7) can also be applied to the Dynamic disk procedure (“For Veritas Dynamic Disks:” on page 58) to perform TimeFinder/Mirror operations on Dynamic Disks with openhandles.

Restoring Veritas dynamic disks with TimeFinderThe following procedure restores a BCV of a dynamic disk that uses both SIU and TimeFinder/Mirror commands.

1. Unmount any drive letters or reparse points currently assigned to the BCVs in the dynamic disk group on the backup server with the following command:


2. Deport the dynamic disk group on the backup server and rescan with the following commands:

vxdg deport -g DgNamesymntctl rescan

3. Unmount any drive letters or reparse points currently assigned to the standard devices in the dynamic disk group on the production server with the following command. This step is necessary to ensure that the standard device is not written to during the restore (since all writes are committed to the BCV). Do not use mountvol to perform this dismount.


4. Deport the dynamic disk group on the production server and rescan with the following commands. Failure to perform this step may leave the dynamic disk group in an unrecoverable state on the production server.

vxdg deport -g DgNamesymntctl rescan



5. Restore the TimeFinder/Mirror device group with the following command:

symmir -g DgName restore

6. Rescan the storage bus on the backup server with the following command. The dynamic disk group and all of its dynamic disks are listed as unreadable, and are therefore, offline.

symntctl rescan

7. Split the TimeFinder/Mirror device group with the following commands:

symmir -g DgName verify -synchedsymmir -g DgName split

8. Rescan the storage bus on the backup server with the following command. The dynamic disk group and all of its dynamic disks are readable, but are still offline and foreign.

symntctl rescan

9. Rescan the storage bus on the production server with the following command. The dynamic disk group and all of its dynamic disks are present, but offline and foreign on the production server.

symntctl rescan

10. Import the dynamic disk group on the backup server with the following command:

vxdg import -g DgName -C

11. Rescan the storage bus on the backup server with the following command:

symntctl rescan

12. Import the dynamic disk group on the production server with the following command. The dynamic disk group and all of its dynamic disks are online and healthy.



62


13. Rescan the storage bus on the production server with the following command. The dynamic disk group and all of its dynamic disks are present, but offline and foreign on the production server.

symntctl rescan

14. Remount each of the volumes in the disk group on the production server with the following command. Use the LDM snap-in, SIU CLI, for this mount.


Creating a backup using TimeFinder/SnapThis example starts with the VDEVS masked (unavailable) from the backup/reporting host. Automount should be disabled. Disabled is the default and can be checked through the "diskpart" CLI.

1. Create the snap devices:

symsnap -g test create DEV001 sym ld VDEV001 DEV002 sym ld VDEV002 -nop

2. Activate the snap devices:

symsnap -g test activate DEV001 sym ld VDEV001 DEV002 sym ld VDEV002 -consistent -nop

3. Unmask the snap devices for backup host access:

symntctl unmask -sid 754 -symdev 01e1symntctl unmask -sid 754 -symdev 01e2

4. Plug and Play rescan to enumerate new devices:

symntctl rescan

5. Arbitrarily set a wait time to allow Plug and Play to enumerate new devices:

sleep 30

6. Perform an LDM rescan to find unmasked snap devices:

diskpart /s c:\rescan.txt

7. Arbitrarily set a wait time to allow LDM to enumerate new devices:

sleep 30



8. Update the SYMAPI database for SIU mount operations:

symcfg dis

9. Mount snap devices to desired mount points:

symntctl mount -drive e: -symdev 01e1 -sid 754symntctl mount -drive f: -symdev 01e2 -sid 754

10. When the backup or reporting is finished, unmount the snap devices (using -nolock because the VDEV will be masked):

symntctl unmount -drive e: -nolocksymntctl unmount -drive f: -nolock

11. Mask the snap devices:

symntctl mask -sid 754 -symdev 01e1symntctl mask -sid 754 -symdev 01e2

12. Perform a Plug and Play rescan to ensure that the devices are removed:

symntctl rescansleep 10

13. Perform an LDM rescan to ensure that the devices have been removed:

diskpart /s c:\rescan.txtsleep 10

14. Terminate the snap devices:

symsnap -g test terminate DEV001 sym ld VDEV001 DEV002 sym ld VDEV002 -nop

15. Optionally, if Powerpath is installed:

Remove dead pathspowermt check force

Creating a backup using TimeFinder/Snap and rescanThis example starts with the VDEVS unmasked (available) to the backup/reporting host. Automount should be disabled. Disabled is the default and can be checked through the "diskpart" CLI.

1. Create the snap devices

symsnap -g test create -nop


64


2. Plug and Play rescan to discover the VDEVs in their Not Ready state:

symntctl rescantimeout 30

3. Disk manager rescan to ensure that the VDEVS are discovered in their Not Ready state:

diskpart /s c:\rescan.txttimeout 30

4. Activate the snap devices:

symsnap -g test activate -nop

5. Plug and Play rescan to discover the VDEVs in their Ready state:


6. Disk manager rescan to ensure that the VDEVS are discovered in their Ready state:


7. Update the SYMAPI database for SIU mount operations:

symcfg dis

8. Mount the snap devices to desired mount points:

symntctl mount -drive w: -symdev 3C0 -sid 54

9. When the backup or reporting is finished, unmount the snap devices:

symntctl umount -drive w:

10. Terminate the snap devices:

symsnap -g test terminate -nop

11. Plug and Play rescan to discover the VDEVs in their un-initialized (terminated) state:




12. Disk manager rescan to ensure that the VDEVS are discovered in their terminated state:



66



4Invisible Body Tag

This chapter describes the TimeFinder Exchange Integration Module (TF/EIM) and the related software that manage Exchange production and backup servers. This chapter also describes the complete setup of an Exchange enterprise business continuance environment.

◆ Overview............................................................................................. 68◆ Setting up an Exchange business continuance system................. 69◆ Setting up a production server for TF/EIM................................... 70◆ Setting up a backup/recovery server environment...................... 75◆ Configuring the TimeFinder/Mirror environment....................... 77◆ Configuring the TimeFinder/Snap environment.......................... 79◆ Configuring the TimeFinder/Clone environment ........................ 81◆ Configuring the SRDF enviornment ............................................... 83◆ Configuring the Open Replicator environment ............................ 87

TF/EIM Overview andSetup

TF/EIM Overview and Setup 67

68

TF/EIM Overview and Setup

OverviewThe TimeFinder Exchange Integration Module (TF/EIM) provides a comprehensive backup management interface specifically for Windows servers that support Microsoft Exchange databases residing in Symmetrix storage.

Note: Unless otherwise noted, all references to Exchange Server refer to Exchange Server 2003 and Exchange Server 2007.

Using EMC storage technologies, TF/EIM leverages EMC Solutions Enabler software and Microsoft Windows and Exchange backup application program interfaces (APIs) to coordinate the integration of EMC’s Business Continuance and Microsoft’s Exchange Server software.

Using the business continuance software, TF/EIM produces exact copies of the production volumes that hold the Exchange server information stores and logs. This enables Exchange administrators to perform both full- and single-mailbox restores in a fraction of the usual time. EMC’s TimeFinder and SRDF are the two basic interface elements of the business continuance technology. In an SRDF configuration, TF/EIM can create remote copies of the Exchange data to be used in case of site disasters. TF/EIM can be used in an enterprise environment where there are multiple production Exchange servers for one backup server (Figure 10).

Figure 10 Parallel backups on multiple Exchange production servers

T L U



In this type of environment, TF/EIM is able to perform backups of all production servers in parallel. This greatly reduces the nightly backup window.

Aligning Exchange I/O on storage track boundariesFor information about aligning Exchange Server I/O on storage track boundaries, refer to the Microsoft Windows File-System Alignment: An EMC Best Practice for Microsoft Windows Servers on Symmetrix and CLARiiON white paper on EMC’s Powerlink® at http://Powerlink.EMC.com

Setting up an Exchange business continuance systemThe remainder of this chapter describes how to setup an Exchange enterprise storage business continuance system, involving the various production and backup servers. The environment setup includes certain setup requirements for the volume configurations, plus the Windows operating systems, Exchange Server software, and the EMC Solutions Enabler software in the server system. The proper operation of the TF/EIM backup interface is dependent on the resulting configuration.

The setup process is presented in the following sections:

◆ “Setting up a production server for TF/EIM” on page 70◆ “Setting up a backup/recovery server environment” on page 75◆ “Configuring the TimeFinder/Mirror environment” on page 77◆ “Configuring the TimeFinder/Snap environment” on page 79◆ “Configuring the TimeFinder/Clone environment” on page 81◆ “Configuring the SRDF enviornment” on page 83◆ “Configuring the Open Replicator environment” on page 87

Overview 69


70


Setting up a production server for TF/EIMThis section outlines the setup procedure for the production server environment to properly integrate with TF/EIM and the Solutions Enabler. The production server environment for TF/EIM is for Exchange servers that require Windows 2000 or Windows 2003 software and the EMC Solutions Enabler.

Windows installation requirementsFor a proper Windows setup, the network environment must be in place on the network prior to the installation of the operating system on this server. Specifically, a forest, domain, and DNS server must exist (it can be on the same host as the domain controller). Additional information about creating a Windows forest and active directory can be found on the Microsoft Website.

For clustered systems on Windows 2000, the Microsoft Cluster Service (MSCS) must be installed as an additional Windows component.

Configuring volumes for the server databaseIf the Windows environment is correct, the host should be able to see Symmetrix devices. At this point, the logical volume layout should be considered. When creating the partitions on these volumes, it is recommended to assign appropriate volume labels to ease your future management tasks. Primarily, this will help to distinguish log volumes from Information Store volumes.

Dynamic disks The initial setup of the dynamic disks on a server determines the outcome of using EMC TimeFinder/Mirror for backup and recovery of dynamic disks. It is important to keep dynamic disk groups and TimeFinder/Mirror device groups on a one-to-one basis. For every dynamic disk group, create a TimeFinder/Mirror device group, and vice versa. It may also be helpful to name the dynamic disk groups the same as the TimeFinder/Mirror device groups. This helps keep the one-to-one relationship clear.

It is not necessary to create the disk group on the backup server. Because the LDM database is resident on every dynamic disk, it is copied to the backup server on each of the BCVs. All disk group definitions are stored in this database and immediately appear on the



backup server (in an offline state). You can create the TimeFinder device groups on either the production server or the backup server.

Before you begin volume configuration, you should establish a plan for the layout of the database volumes. It is recommended to refer to the EMC white paper, EMC Symmetrix Storage Solutions Microsoft Exchange 2000 and 2003 Best Practices Storage Configuration Guidelines, when designing this plan. You can download this white paper from the EMC Powerlink Website at: http://powerlink.EMC.com

Follow these requirements for laying out volumes with TF/EIM:

◆ All Exchange data must be located on Symmetrix disks. This includes all mailbox and public databases, as well as their respective transaction logs. In the case of TF/EIM Hot Splits, the checkpoint files must be located on Symmetrix disks as well.

◆ No two NTFS volumes, being used for Exchange data, can be located on the same LUN. Failure to follow this rule will result in TF/EIM failures.

◆ Exchange Information Store databases and transaction logs should be located on separate physical disks. This way, no single disk failure will result in a loss of both the databases and transaction logs.

◆ It is recommended that all Information Store databases be located on separate physical disks. This allows for flexible restore and recovery of single Information Store databases. To share disks between storage groups, use VSS with the sequential consistency check (-scc) option.

◆ If transaction logs from different storage groups are located on the same physical disk, the only supported solution is to use VSS with the sequential consistency check (-scc) option.

◆ All volumes must be formatted with NTFS file system. FAT and FAT32 are not supported.

Disk alignment You should always create your volumes with partitions that are aligned along the track boundaries of the underlying Symmetrix disk. This improves the performance for any application using those volumes.

Hot Split When using the Hot Split feature of TF/EIM, all Exchange volumes must have partitions that are aligned with the underlying disk's track boundaries. This insures that the Hot Split does not cause a torn page on the BCV.

Setting up a production server for TF/EIM 71

72


Server database application install strategyThis section highlights the installation strategies for Exchange Server software.

Exchange Server 2003 Upon initial start of the install program, the default items are already selected. This guide assumes a basic Exchange Server installation. Other technologies, such as Conference Server and instant messaging, are out-of-scope.

Continue with the default selections and choose where to place the Exchange Server binaries (a local disk is acceptable). If this server is the first Exchange server in the forest, then the administrator is asked to specify an organization name.

Note: For more information on the Exchange server installation process, refer to the Microsoft website.

Exchange server starts with a single storage group containing both a private and public Information Store. At this point, the administrator must implement the Exchange Server framework that has already been designed. When creating the storage groups and Information Stores, be sure to locate the necessary files (edb.log, priv1.edb, priv1.stm, and so on) on the appropriate volumes. This is where the volume labels help. All private and public Information Stores, as well as transaction logs, must be located in Symmetrix storage.

When using the Exchange Server Hot Split feature of TF/EIM, it is required that the checkpoint file (E00.chk, E01.chk, and so on.) for each storage group be located on the same volume as one of the databases in that storage group.

Microsoft Exchange Server has built-in functionality to retain deleted items for a specified period. You have the option to restrict the purging of these deleted items until after a full backup. If you select this option when using TF/EIM, deleted items will never be purged because TF/EIM does not perform an online backup using the API. Selecting this option causes your Exchange database to grow consistently but never shrink. Eventually, your database will run out of free disk space. For this reason, it is required that the default values be kept for this setting.



All Exchange 2003 data and log files (including the .chk files) must be located on the Symmetrix array. Otherwise, the Exchange 2003 install strategy is the same, even if Volume Shadow Copy Service (VSS) is being used.

Exchange 2007 Exchange Server 2007 has expanded the number of Exchange Storage Groups supported, now allowing up to 50 storage groups per Exchange Server. The maximum number of databases is still 50 per Exchange Server.

Exchange Server 2007 supports only Windows 2003 x64 for the production environment. Exchange Server 2007 supports a Management Tools installation on x86 hosts. TF/EIM 4.0 supports both x86 and x64 hosts as TF/EIM backup hosts.

EMC Solutions Enabler installationAfter you have installed and configured the Microsoft software, you must install EMC Solutions Enabler.

EMC Solutions Enabler, which can provide the TimeFinder, Open Replicator, and SRDF components, is required. Refer to the EMC Solutions Enabler Installation Guide, and verify that the software with the required licenses are enabled. If not, enable the licenses using symlmf.

When prompted by the Solutions Enabler install program, select Yes to install and start the storsrvd service. This service is necessary for TF/EIM to connect and interface to the SYMAPI server from the backup recovery server.

The SE_ESM Serviced Component must be set with the Exchange Admin on the Identity tab, as shown in Figure 11 on page 74.

Setting up a production server for TF/EIM 73

74


.

Figure 11 SE_ESM Properties - Identity tab settings

After changing the user on the Identity tab, shut down and restart the SE_ESM Serviced Component, restart the storsrvd, and the EMC VSS provider (if started).

After Solutions Enabler is installed, run symcfg discover to populate the host's SYMAPI database with the appropriate disk information.

EMC VSS Provider installationIf you plan on using the TF/EIM with VSS, you must install the EMC VSS Provider after you have finished installing Solutions Enabler.

Note: The EMC VSS Provider is no longer released as part of the EMC Solutions Enabler installation kit. The VSS Provider is now released in a standalone installation kit, specifically designed for Microsoft VSS.

Note: After installing the EMC VSS Provider it may be necessary to manually start the storsrvd service.

For installation instructions, refer to the EMC VSS Provider Version 3.2.1 Release Notes.



Setting up a backup/recovery server environmentThis section describes the setup of a TF/EIM backup/recovery server environment to support the Exchange Server databases. This setup involves certain install strategies and requirements for the following software: Windows operating system, either Exchange 2003 Server or Exchange 2007 Server, and the EMC Solutions Enabler.

Server database application install strategyWhen configuring an Exchange Server 2003 or Exchange Server 2007 backup server, the only required Exchange components are the Exchange Management Components/Tools. This also applies when VSS is being used.

EMC Solutions Enabler installationThe EMC Solutions Enabler installation on the backup/recovery server is similar to that of the production server, except it is not necessary to install and run the storsrvd service on the backup/recovery server.

The Base and TimeFinder licenses must be installed. If you have an SRDF or Open Replicator environment, the SRDF and Open Replicator licenses are also required. These licenses should be purchased from EMC prior to starting this setup.

The SE_ESM Serviced Component must be set with the Exchange Admin on the Identity tab. Refer to “EMC Solutions Enabler installation” on page 73 for instructions.

After Solutions Enabler is installed and the licenses have been established using symlmf, run a symcfg discover SYMCLI command to populate the host's SYMAPI database with the appropriate disk information.

EMC TimeFinder/IMs installationThe EMC TimeFinder/IMs CD contains the installation programs for all the integration modules. TF/EIM does not have any dependencies on other integration modules/commands, so it can be installed alone. However, the Symmetrix Integration Utility command (symntctl)

Setting up a backup/recovery server environment 75

76


can often be very useful when diagnosing disk/volume issues on a host.

Exchange Recovery Storage GroupsTo use the Recovery Storage Groups feature of Exchange Server, refer to the document Using Microsoft Exchange Server 2003 Recovery Storage Groups on the Microsoft website.



Configuring the TimeFinder/Mirror environment

Note: When using the Symmetrix Remote Data Facility, refer to “Configuring the SRDF enviornment” on page 83 for set up instructions.

With the proper Symmetrix configuration in place for your TimeFinder Exchange environment, you should now have a BCV on the backup/recovery server for every standard device being used for Exchange Server. If this is not the case, then revise the Symmetrix configuration.

To provide the initial BCV to standard device association, you must create device groups on the backup/recovery server. The actual device group arrangement is completely up to you, as long as each standard device and BCV being used by Exchange is included. Although TF/EIM does not use these device groups directly, they can be very helpful to you during restore scenarios. Therefore, use care when designing the device groups.

To configure your TimeFinder environment, do the following:

1. Create a device group with the following command:

symdg create DgName

2. After you have created all of the device groups, add the standard devices to the appropriate device groups with the following command:

symld -g DgName add dev SymDevName

3. Associate all of the BCVs to the device groups with the following command:

symbcv -g DgName associate dev SymDevName

4. Verify the device group contains all of the devices that it should with the following command:

symdg show DgName

5. All of the standard devices and BCVs should be listed in the order they were added. To establish the devices in this order, the first standard device with the first BCV, use the following command:

symmir -g DgName establish -full -exact

Configuring the TimeFinder/Mirror environment 77

78


This performs a full establish on the devices, which can take a long time depending on the size of the devices. Make sure you remove any mount points from the BCVs on the backup/recovery server before attempting the establish. To determine the current state of the establish, enter the following command:

symmir -g DgName query

6. Once this command shows that all of the device pairs are synchronized, run the following command to split all of the devices in the device group:

symmir -g DgName split

At this point, the BCVs connected to the backup/recovery server should have the identical volume label as its paired standard device.

Any BCVs that are dynamic disks are most likely offline after the split. Use the SFW to bring these disks back online.

Multiple BCVs TF/EIM supports the use of multiple BCVs in a rotating fashion (using the -multi option). To configure this, associate and establish each BCV with its particular standard volume by repeating steps 3 through 6, as described above. TF/EIM will only use multiple BCVs if each BCV has been fully established with the standard volume.

If you want to choose a specific BCV pair, establish the pair, then run the TF/EIM backup command with the -preestablish option.

Note: Because of a restriction imposed by the Windows operating system, you cannot use multiple BCVs with dynamic disks.

Furthermore, verify that all BCVs currently paired to a given standard device are visible on the backup server. If this is not the case, and -multi is used, TF/EIM will fail at some point because it will try to use that BCV, but it will not find it on the backup server.

To remove an unused BCV pairing, use either of the following commands:

symmir -g DgName cancel LdevName BCV dev SymDevNameor

symmir -g DgName cancel LdevName BCV ld LdevName



Configuring the TimeFinder/Snap environmentTo use TF/EIM and EMC TimeFinder/Snap to snapshot your Exchange data, it is necessary to have a separate VDEV for every standard device that is currently storing Exchange data. This data includes all databases and logs.

The configuration of EMC TimeFinder/Snap for TF/EIM is very similar to that for EMC TimeFinder/Mirror. The biggest difference, however, is that TimeFinder/Snap does not maintain a record of existing pairing relationships between the source and target devices. The result is that any virtual device (VDEV) can be paired with any standard device of the same size, provided the VDEV does not already have a TimeFinder/Snap session. Without an existing pairing, the selection of VDEVs for the standard devices is left to TF/EIM. TF/EIM will choose any VDEV that is presented to the host and is the same size as the standard device. This means that in order to use the -snap option, the user must present to the backup TF/EIM host, at least one VDEV of the correct size for each of the standard devices in the backup.

To use the -multi option in conjunction with -snap, at least two VDEVs must be presented to the backup TF/EIM host for every standard device in the backup. The number of VDEVs presented for each standard device will determine how many backups can be performed before the existing TimeFinder/Snap sessions will need to be terminated.

To present a VDEV to the backup TF/EIM device, use the symmask command. To view existing TimeFinder/Snap sessions, use the symsnap command.

Volume Shadow Copy Service (VSS)When VSS is being used with Exchange 2003 or Exchange 2007 and EMC TimeFinder/Snap, these device groups must be created on both the production and backup servers. This is required because the Symmetrix VSS provider on the production server will be choosing the VDEVs and performing the EMC TimeFinder/Snap operations. In this case, the symdg import and export commands can be used to simplify the device group creation.

During the backup with EMC TimeFinder/Snap, TF/EIM will use the next available VDEV in the device group. It will not always use

Configuring the TimeFinder/Snap environment 79

80


the same VDEV. Furthermore, TF/EIM will allow multiple snap sessions per standard device if a multitude of VDEVs exist in the device group. This means that it is possible to run TF/EIM with EMC TimeFinder/Snap and then run it again without terminating the first snap sessions. This is TF/EIM default behavior with TimeFinder/Snap, so the –multi option is not needed in this case.



Configuring the TimeFinder/Clone environmentTimeFinder/Clone functionality is controlled by copy sessions, which pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of the device pairs.

A copy session must first be created to define and set up the clone devices. The session is then activated, enabling the target device to be accessed by its host. When the information is no longer needed, the session can be terminated.

To provide the initial clone to standard device association, you must create device groups on the backup/recovery server. The actual device group arrangement is completely up to you, as long as each standard device and clone being used by Exchange is included.

Although TF/EIM does not use these device groups directly, they can be very helpful to you during restore scenarios. Therefore, use care when designing the device groups.

To configure your TimeFinder/Clone environment, do the following:


symdg create DgName



3. If the clone devices are BCV devices, add the BCV devices to the device group with the following command:


4. Verify the device group contains all of the devices that it shouldwith the following command:

symdg show DgName

5. Create the clone session with the following command:

symclone -g DgName create SymDevName SYM ld SymDevName

Configuring the TimeFinder/Clone environment 81

82


This creates a clone copy session on the devices, which can take a long time depending on the size of the devices. Make sure you remove any mount points from the clone devices on the backup/recovery server before creating the clone session. To determine the current state of the clone session, enter the following command:

symclone -g DgName query

6. Once this command shows that all of the clone sessions are created, run the following command to activate the clone sessions for all the devices in the device group:

symmir -g DgName activate

At this point, the clone devices connected to the backup/recovery server should have the identical volume labels as their paired standard devices.

Any clone devices that are dynamic disks are most likely offline after the split. Use the SFW to bring these disks back online.



Configuring the SRDF enviornment The following procedures describe how to configure the TF/EIM SRDF environment on the backup Exchange Server. There are two possible configurations:

◆ BCV remote mirroring

◆ Standard remote mirroring

BCV remote mirroringThe BCV remote mirroring configuration (Figure 6 on page 31) involves a standard device and its local BCV (R1). The local BCV-R1 is remotely-mirrored by a remote R2 device which also has a remote BCV (BRBCV).

Note: This is the only SRDF configuration supported with VSS.

To provide this initial BCV remote mirroring association, you must create a device group on the backup server.

To create a device group, enter the following command:

symdg create DgName

To configure the TF/EIM SRDF environment, do the following:

1. Add the standard devices to the appropriate device groups with the following command:


2. Associate all of the local BCVs (R1BCV) to the device groups with the following command:


Note: Make sure to add the devices in the order in which they are paired with their standard devices.

3. Associate all of the remote BCVs (BRBCV) to the device groups with the following command:

symbcv -g DgName associate dev SymDevName -rdf -bcv

Configuring the SRDF enviornment 83

84


Note: Make sure to add the remote BCV devices in the order in which they are to be paired with their R2 devices.

4. Verify that the device group contains all of the devices that it needs with the following command:

symdg show DgName

5. All of the standard devices, local BCVs and remote BCVs should now be listed in the order that they were added. To establish the standard and local BCV devices in this order, use the following command:


This performs a full establish on the devices. To determine the current state of the establish command, use the following command:


6. Once this command shows that standard and local BCV device pairs are synchronized, split all the devices in the device group with the following command:


7. Establish the R2 and remote BCV device pairs in the order in which they were added to the device group with the following command:

symmir -g DgName establish -rdf -bcv -full -exact

This performs a full establish of the R2 and remote BCV device pairs. To determine the current state of the establish, use the following command:

symmir -g DgName query -rdf -bcv

8. Once this command shows that device pairs are synchronized, split all of the remote devices in the device group with the following command:

symmir -g DgName split -rdf -bcv

At this point the BCVs connected to the backup server should have the same volume labels as the paired R2 devices.

The SRDF environment is now configured and ready for TF/EIM.



Note: Before running ExBackup2003 or ExBackup2007 with the -srdf option, it is important to ensure that the R1BCV/R2 and the R2/BRBCV device pairs are in a split state. To verify that the R1BCV and R2 are split, enter:symrdf -g DgName query -bcv

To verify that the R2 and BRBCV pair is split, enter:symmir -g DgName query -rdf -bcv

Note: In addition to verifying that the remote devices are in a split state, it is important to ensure that these devices are not mounted by any host. TF/EIM will still operate with the remote devices mounted but there is a potential for corruption of data on those devices.

Standard remote mirroringThe standard remote mirroring configuration (Figure 7 on page 32) involves a standard device (R1), which is remotely mirrored by a remote R2 device and the remote R2 device is mirrored by a BCV (RBCV). This configuration requires a RDF2 type device group.

Note: This SRDF configuration is not supported with VSS.

To create a device group, use the following command:

symdg create DgName -type rdf2

1. After creating all of the device groups, add the R2 devices to the appropriate device group with the following command:


2. Associate all of the remote BCVs to the device group with the following command:


To verify that the device group contains all of the devices, use the following command:

symdg show DgName

Configuring the SRDF enviornment 85

86


3. To establish the R2 devices and the remote BCVs (RBCVs) in the order that they were added to the group, use the following command:


This performs a full establish on the devices, which can take a long time depending on the size of the devices. Make sure to remove any mount points from the BCVs on the backup/Exchange server before attempting the establish.

To determine the current state of the establish command, use the following command:


4. Once this command shows that all of the device pairs are synchronized, run the following command to split all of the devices in the device group:


At this point, the BCVs connected to the Backup TF/EIM server should have the same volume label as its paired R2 device. This environment is now ready for TF/EIM.

Note: Prior to running ExBackup2003 or ExBackup2007 with the -srdf option, it is important to ensure that the R2 and remote BCVs are in a split state.



Configuring the Open Replicator environmentOpen Replicator operations use a device file as described in the following section.

Open Replicator device fileTo specify ORS operations a new optional filename -orf FileName is used. This specifies the device paring relation between the local Symmetrix and remote Symmetrix or CLARiiON devices. It uses the following formats to be consistent with SYMCLI command for Open Replicator:

Symdev = src symid:symdevname symdev = tgt symid:symdevnameSymdev = src symid:symdevname clardev = tgt clarid:clardevnameSymdev = src symid:symdevname wwn=tgt device wwn

Target devices that are only accessible through the SAN cannot be specified with Symmetrix device names. Any World Wide Name (WWN) of a remote system must be obtained using platform-native tools.

Example device file entries:

# dev_file_1# control and remote device pairs# Symmetrix and StorageID:device always listed first

symdev=0000187900041:0102 wwn=123456781234567820000000c920b484symdev=041:0103 wwn=123456781234567820000000c9274156symdev=58:1C5 clardev=APM00034801589:39symdev=58:1C5 symdev=000184500160:19C

# End

Configuring the Open Replicator environment 87

88



5nvisible Body Tag

This chapter describes how to perform backup and restore operations to a Windows Exchange server database using the TimeFinder Exchange Integration Module (TF/EIM) command line interface.

◆ Backup execution environments...................................................... 90◆ Backing up Exchange 2003 and 2007 servers with VSS................ 91◆ Backing up Exchange 2003 and 2007 servers (non-VSS) .............. 93◆ Backing up multiple Exchange Server instances........................... 97◆ Creating a backup command initialization file ............................. 98◆ Restore procedures........................................................................... 103◆ Troubleshooting Exchange Server ................................................. 124

Backup and RestoreOperations with TF/EIM

Backup and Restore Operations with TF/EIM 89

90

Backup and Restore Operations with TF/EIM

Backup execution environmentsFor a complete list of supported options for ExBackup2003 and ExBackup2007, refer to “TimeFinder/IMs Support Matrix” on page 253.

Command line startupTo use TF/EIM CLI for command line entries:

1. From the Start menu, select Programs > EMC > TimeFinder Integration Modules > TimeFinder Exchange Integration Module > TEIM > TEIM CLI.

TF/EIM CLI (MS-DOS command prompt window) opens to the \Program Files\EMC\TimeFinder Integration Modules\TEIM directory.

2. Enter TF/EIM commands at the prompt.

3. Type exit to close the console window.



Backing up Exchange 2003 and 2007 servers with VSS

Local replication The following summarizes the TF/EIM tasks to back up a Windows server with an Exchange database using ExBackup2003 or ExBackup2007 and VSS:

1. Check the database files and resolve the Symmetrix devices used by the database files.

2. Validate that the devices are in the correct state:

• BCV devices should be in a split state, or in a synchronized state if the -preestablish option is used.

• Clone devices should be in the created or recreated state.

• Virtual devices (VDEVs) should either have no snap sessions, or be in the created state.

3. Remove drive letters and access paths from all replica devices (BCV, clone, or VDEV) and prepare the devices for removal from the system.

4. Create the Shadow Copy of the Exchange database.

5. Import the Shadow Copy to the backup host and verify the database consistency.

6. For clone devices, wait until the clone devices are in the copied state.

Remote replication In TFIM 4.1, the options -rbcv and -rclone are added to support a remote BCV and remote clone with VSS. The following are the prerequisites for this support:

◆ The production Exchange database runs on R1 devices.

◆ R1 and R2 devices must be synchronized before backup time. Only the synchronous RDF mode is supported.

◆ RBCV/RClone devices are present to the backup host. RBCV devices can be split or synchronized, however, if they are synchronized the -preestablish option must be used. For RClone devices, they are required to be in a created state.

The following are the operations performed by TF/EIM to backup an Exchange database with VSS and RBCV/Rclone devices.

1. Check the database files and resolve the Symmetrix devices used by the Exchange database files.

Backing up Exchange 2003 and 2007 servers with VSS 91

92


2. Validate that the devices are in the correct state:

• RBCV devices should be in a split state, or in a synchronized state if the -preestablish option is used.

• Remote clone devices should be in the created or recreated state.

3. For RBCV devices, establish the RBCV devices with R2 devices. Check the devices state and wait until the devices are synchronized.

4. Remove the RBCV/RClone device access from the backup host.

5. Create the VSS Shadow Copy for the Exchange Storage Group.

6. Import the Shadow Copy to the backup host and verify the database consistency.

Open Replicator backups (only)The -orf filename option is used to specify the ORS copy:

1. Create the ORS session.

2. Activate the ORS session.

3. When the ORS session is in the copied state, make the BCV devices ready to the host.

4. Complete the ORS session.

When the Open Replicator session is activated, TxIM provides another common utility for both TF/EIM and TF/SIM to check the status of the existing ORS session, and to terminate the session if the existing session is complete.

In the case of the disaster recovery, the data in the remote LUNs can be copied back to the production host to facilitate the DR operation.



Backing up Exchange 2003 and 2007 servers (non-VSS)You can backup a stand-alone or clustered Windows 2003 servers with multiple Exchange 2003 or with multiple Exchange 2007 databases using a single TF/EIM command.

Note: Exbackup2003 and Exbackup2007 cannot be used on the same backup host.

The TF/EIM commands ExBackup2003 and ExBackup2007 produce an exact copy of the production volumes that hold the Exchange Information Stores and Logs. This provides the capability for administrators to perform either a full- or single-mailbox restore when needed.

The following summarizes the TF/EIM tasks to backup a Windows server with an Exchange database using ExBackup2003 or ExBackup2007:

◆ Parse and validate the input parameters.

◆ If MSCS is installed, determine which node is the active Exchange node.

◆ Initialize event logging on the backup server.

◆ Query the active directory for information about the Exchange server, including number of storage groups, information stores, and so on.

◆ Scan the production server for -1018 errors.

◆ Use Solutions Enabler mapping to determine which standard and BCV devices correspond to those Exchange storage groups and information stores.

◆ Establish these database and log devices (full establish, if specified).

◆ Poll the BCV pairs until fully synchronized.

◆ For each storage group whose devices have fully synchronized:

• Dismount all of its information stores (except for Hot Splits).

• Poll BCV pairs again to verify synchronization.

• Split BCVs from the standard devices.

• Remount all of the information stores (except for Hot Splits).

Backing up Exchange 2003 and 2007 servers (non-VSS) 93

94


• Mount each information store's BCV on the backup server and begin running ESEUTIL*.

• Use the Exchange backup API to perform log management on the production server.

◆ If an SRDF environment remote backup is desired:

• Establish the remote mirror (R2) with the local BCV (R1-BCV) for each database and log volume.

• Split the remote mirror (R2) with the local BCV (R1-BCV) for each database and log volume.

◆ If a remote BCV (BRBCV) of the remote mirror (R2) is desired:

• Establish the remote BCV (BRBCV) with the remote mirror (R2) for each database and log volume.

• Split the remote BCV (BRBCV) with the remote mirror (R2) for each database and log volume.

ESEUTIL* is run against each information store BCV separately, and in sequence. But each storage group can be running ESEUTIL at the same time. So if there are four storage groups, there could be four instances of ESEUTIL* running at any given time.

Running ExBackup2003/2007You can run ExBackup2003 or ExBackup2007 on a stand-alone Exchange server or an MSCS clustered Exchange server by specifying the -s option as follows:

ExBackup2003 <-s ServerName> -f InitFileor

ExBackup2007 <-s ServerName> -f InitFile

Optional selections This section describes the optional selections to this server backup command. For more information on these options, refer to “ExBackup2003/2007” on page 220.

Multiple servers You can backup multiple production servers by specifying a list of the server names for backup in an initialization file, using the -f option that identifies the file name target.

Backup types To leverage the Volume Shadow Copy Service (VSS) and create a VSS compliant backup, use the -vss option. To create a differential backup of Exchange Server (backup the transaction logs only), use the -vssdiff option. To create a copy backup of Exchange Server



(backup all data but do not truncate logs), use the -copyonly option. To create a non-VSS backup, use the -nologdelete option

Local snapshottechnologies

TF/EIM uses TimeFinder/Mirror as its default snapshot technology. To force a full TimeFinder/Mirror establish, specify the -full option. To use multiple BCVs, specify the -multi option. To use the EMC TimeFinder/Snap technology, specify the -snap option. To use the TimeFinder/Clone technology, specify the -clone option.

Remote snapshottechnologies

To backup Exchange Server to devices on a remote Symmetrix array, you can utilize a synchronous SRDF link in conjunction with TimeFinder. To create a remote TimeFinder/Mirror backup use the -rbcv option. To create a remote TimeFinder/Clone backup use the -rclone option. To make a remote copy of a local BCV, utilizing a split SRDF link, use the -brbcv option.

Open Replicator The -orf FileName option instructs TF/EIM to use Open Replicator for Symmetrix (ORS) device files for the data migration operations. Use the -pace option to set the copy pace for the operation. Values can range from 0 to 9, with 0 being the fastest pace, and 9 being the slowest pace. Use the -orsdiff option to perform a differential data migration.

Transaction logmanagement

With Exchange 2003 and 2007 Server, the TF/EIM log management process completes successfully, but does not actually truncate the transaction logs. However, when VSS full backup is used (-vss) on Windows 2003, TF/EIM is able to successfully truncate the logs using the newer VSS interfaces. For this reason, TF/EIM enforces a command line restriction for Exchange 2003/2007 servers, where the user either has to use the -vss option, or the -nologdelete option. The same restriction applies when using an .ini file to pass the TF/EIM options.

VSS restore TF/EIM integrates with VSS during restores (however, TF/EIM does not automate the restore). Use the restore action to perform a VSS restore. For a restore, the -sg and -vss options are required, as well as the -bcd and -wmd options to pass in the XML files. The -logs option during a restore tells TF/EIM to restore the transaction logs and the databases. The -db option allows the user to specify individual databases to restore.

Backing up Exchange 2003 and 2007 servers (non-VSS) 95

96


VSS cleanup In the event that a VSS import fails on the backup server, it is possible that the replica devices (BCV, clone, etc.) can be left in an inappropriate TimeFinder state, masked away from the host, or with the HIDDEN bit set. To cleanup the TEIM environment after a failure like this, use the -cleanup option with your existing TEIM backup command. The -cleanup option will make a best effort to resolve the above conditions and prepare the environment for another backup.

Test mode If you are tentative about running a backup command on a server (or particularly a command that involves multiple servers), you can specify the -test option that only validates and checks for proper command syntax, Enginuity and Exchange versions, etc. In test mode, the command will not execute any controls on devices or BCV devices in the database and not actually start the backup processes (such as establishing BCV pairs or dismounting devices).

Return codes The backup command returns a zero upon success or a non-zero value for various warnings and failures. A list of return codes can be found in ExBackupErr2003.h or ExBackupErr2007.h in the TF/EIM directory.

Usage menu Use the -h option to display the usage menu.



Backing up multiple Exchange Server instancesAcross a common network, you can backup multiple Exchange Server instances using a single TF/EIM command for each version of Exchange. Depending on the server version, the backup command varies:

For Exchange 2003, the following TF/EIM command is used:

ExBackup2003 -f InitFile

For Exchange 2007, the following TF/EIM command is used:

ExBackup2007 -f InitFile

The command executes an initialization file that is formatted with separate backup commands which can target each of the production server node names you select with different backup parameters. If the file is in the TF/EIM working directory, you can specify an .ini file name with the -f option.

If you have an alternate directory from the working default, then specify a full path name with the -f option.

Although each backup can have its own output file, another output file can be specified with the -o option. This output file will contain all the general output from the TF/EIM command.

Note: There are other options with these commands. For more information, refer to Appendix A.

For more information about the command initialization file, refer to “Creating a backup command initialization file” on page 98.

Backing up multiple Exchange Server instances 97

98


Creating a backup command initialization fileThe backup command file contains sets of commands directed to various servers across the network. The ExBackup commands on Windows platforms kick off these command entries organized in sections. As shown in the following examples, each command section is headed by the name in brackets ([]) of the server being targeted. Each server command section is one backup command, but with various required and optional parameter entries to modify the command action.

Initialization file for ExchangeExample

[EXCHANGE1]Split=hotstoragegroup=SG1verbose=trueoutput=c:\program files\emc\TimeFinder Integration Modules\TEIM\Exchange1.log

[EXCHANGE2]Split=instantmulti=trueverbose=trueoutput=c:\program files\emc\TimeFinder Integration Modules\TEIM\Exchange2.loglog_delete=false

Initialization file for Exchange with VSSExample

[EXCHANGE1]Split=vssstoragegroup=SG1verbose=trueoutput=c:\program files\emc\TimeFinder Integration Modules\TEIM\Exchange1.log

[EXCHANGE2]Split=vssstoragegroup=SG1,SG2,SG3Vssdiff=truePreestablish=trueverbose=trueoutput=c:\program files\emc\TimeFinder Integration Modules\TEIM\Exchange2.log



File commands The following are possible command parameter entries for each backup command or server section in the initialization file:

log_delete

When set to TRUE (default), truncates the transaction logs. This parameter is optional. Possible values are TRUE and FALSE.

output

Specifies a program output file to record backup activity. This parameter is optional.

symapidb

Specifies an alternate Solutions Enabler SYMAPI database file when not using the Solutions Enabler default file name. This parameter is optional.

Exchange only The following file commands are applicable to Exchange Servers only:

bcd

Specifies the name and location of the file to create as the Backup Components Document for a VSS backup. This parameter is optional, and only applies to VSS backups.

brbcv

When set to TRUE, specifies that TF/EIM should make a remote backup of a local BCV using SRDF and TimeFinder/Mirror. This parameter is optional. The default value is FALSE.

clone

When set to TRUE, specifies that TF/EIM should use local TimeFinder/Clone to perform the backup. This parameter is optional. The default value is FALSE.

copyonly

When set to TRUE, specifies that TF/EIM should perform a Copy Exchange Server backup using VSS. This type of backup copies all data, but doesn't perform log truncation. This parameter is optional, and only applies to VSS backups. The default value is FALSE.

Creating a backup command initialization file 99

100


full

When set to TRUE, specifies that TF/EIM should perform a full establish on all BCVs. This parameter is optional. The default is FALSE. When using this option, you must set it to the same value for each server in the file.

multi

When set to TRUE, specifies that TF/EIM should use multiple BCVs in a rotating fashion. This parameter is optional. The default is FALSE. When using this option, you must set it to the same value for each server in the file.

OrfSpecifies the name and location of the file to use for an Open Replicator backup. This file contains the names of the source and target devices for Open Replicator. This parameter is optional. The default value is FALSE.

Orsdiff

When set to TRUE, specifies that TF/EIM should use a differential Open Replicator session for the backup. This parameter is optional and only applies to Open Replicator backups. The default value is FALSE.

Orspace

Specifies the pace that should be applied to the Open Replicator session. This value must be an integer between 0 and 9, and only applies to Open Replicator backups. This parameter is optional, and the default value is 0.

preestablish

When set to TRUE, specifies that TF/EIM perform a backup operation only when the following scenarios apply:

STD - BCV = synchronizedR1 - R2 - RBCV = synchronizedSTD - R1BCV - R2 - BRBCV = synchronizedSTD - R1BCV = synchronized

protbcvest

When set to TRUE, specifies that TF/EIM perform a protected BCV establish. This parameter is optional. The default is FALSE. When using this option, you must set it to the same value for each server in the file.



rclone

When set to TRUE, specifies that TF/EIM should use remote TimeFinder/Clone to perform the backup. This parameter is optional. The default value is FALSE.

rbcv

When set to TRUE, specifies that TF/EIM should use remote TimeFinder/Mirror to perform the backup. This parameter is optional. The default value is FALSE.

rwreadwrite

When set to TRUE, specifies that TF/EIM should clear the READONLY flags on the replica devices after a VSS backup. This parameter is optional. The default value is FALSE.

savepool

Specifies a SAVE device pool to be used by TF/EIM. This parameter is optional. This option must be set to TRUE. When using this option, it must be set to the same value for each server in the file.

snap

When set to TRUE, specifies that TF/EIM should use EMC TimeFinder/Snap as the snapshot technology. This parameter is optional. The default is FALSE. When using this option, you must set it to the same value for each server in the file.

split

Specifies the type of split action required. Possible values are:

HOT— a Hot Split will be performedINSTANT— an instant split will be performedVSS — VSS will be used for snapshot (Exchange 2003 and Exchange 2007 only)

The default is to perform a normal offline split.

storagegroup

Specifies storage group names to be backed up. This parameter is optional. When using this option, only the storage groups specified will be backed up.

Creating a backup command initialization file 101

102


vssdiff

When set to TRUE, specifies that TF/EIM should perform a Differential Exchange Server backup using VSS. This type of backup only copies the transaction logs, and doesn't perform transaction log truncation. This parameter is optional, and only applies to VSS backups. The default value is FALSE.

wmd

Specifies the name and location of the file to create as the Writer Meta Document for a VSS backup. This parameter is optional, and only applies to VSS backups.



Restore proceduresRestore procedures vary depending on your Windows environment.

Exchange 2003/2007 VSS restoresTF/EIM integrates with VSS to perform restores, however, the process to restore a database with transaction log recovery is still partly manual. To restore a database using VSS, you must begin with a TF/EIM restore command on the backup TF/EIM server. The restore command will be of the form:

ExBackup2003 (or Exbackup2007) –s server -sg storage_group restore -db database -wmd WMD_file -bcd BCD_file -v

If more than one database needs to be restored, then additional –db options can be added to the command.

When this command is run, TF/EIM will direct the user through a series of steps that will perform the VSS restore. Some of the steps are automated by TF/EIM, but most require manual intervention.

Examples The following are examples of TF/EIM VSS restore commands for various scenarios, assuming a server name of Server1 and a storage group name of SG1.

◆ To restore a single database with transaction log replay, use the following command:

ExBackup2007 –s Server1 –sg SG1 –vss –v restore –db DB1 –bcd TEIM_SG1_bcd.xml –wmd TEIM_SG1_wmd.xml

This command will restore the DB1 database in the SG1 storage group. This command will require that the entire SG1 storage group be taken offline during the restore.

◆ To restore multiple databases with transaction log replay, use the following command:

ExBackup2003 –s Server1 –sg SG1 –vss –v restore –db DB1 –db DB2 –db DB3 –bcd TEIM_SG1_bcd.xml –wmd TEIM_SG1_wmd.xml

This command will restore the DB1, DB2, and DB3 databases in the SG1 storage group. This command will require that the entire SG1 storage group be taken offline during the restore.

Restore procedures 103

104


◆ To perform a point-in-time restore of an entire storage group:

ExBackup2007 –s Server1 –sg SG1 –vss –v restore –logs –bcd TEIM_SG1_bcd.xml –wmd TEIM_SG1_wmd.xml

This command will restore the entire SG1 storage group, including its logs. This restore is a point-in-time restore because there will be no transaction log recovery and therefore the data will be restored back to the time of the backup.

Note: Individual databases can not be restored when the transaction logs are also being restored. All databases in a storage group share the same transaction logs, so if those transaction logs are restored then all databases must be restored as well.

Restoring a database using Open Replicator

TF/EIM (Exchange Server 2003)To restore the production Exchange database:

1. Dismount the Exchange mailbox and public stores for the storage group to be restored.

2. Unmount the file systems used by the production Exchange database.

3. Start the data migration from the remote LUNs to the local LUNs with symrcopy command.

4. Wait until the data migration is complete, and mount the file systems on the production host.

5. Remount the production Exchange mailbox and public store.

Note: For TF/EIM the -snap option is not supported.

Exchange Server Hot Split database restore with transaction log replayThis section highlights the steps necessary to perform a full Exchange Server database restore with transaction log replay, using the Hot Split BCV backup copy. Typically, you would perform a full database restore when one or more production databases have failed.



In the following example, it is assumed that the production server database has failed, and has been dismounted from the specific storage group.

The BCV copy of the database will be preserved by splitting the BCV from the standard volume prior to initiating a production server transaction log recovery.

Note: During the symmir restore operation for the specific database, all the remaining databases in the storage group remain mounted and available for access to the enterprise. But these databases will need to be dismounted in order to initiate the transaction log recovery.

To perform a full Exchange Server database restore with transaction log replay, using a Hot Split BCV backup, complete the following steps:

1. Using SIU, dismount the BCV from the backup/recovery server.

2. Using SIU, dismount the standard volume from the production server.

CAUTION!Only dismount with SIU (symntctl umount -drive) for both the BCV from the backup/recovery server and the standard volume from the production server. Do not use mountvol or other utilities. Using non-SIU commands to dismount these volumes could result in data corruption.

3. Using TimeFinder/Mirror, perform a restore operation of the BCV (including the split of the BCV); or using EMC TimeFinder/Snap, perform a restore of the VDEV.

4. Using SIU, rescan the backup/recovery server.

5. Using SIU, mount the BCV on the backup/recovery server.

6. Using SIU, rescan the backup/recovery server.

7. Using SIU, mount the standard volume on the production server.

8. Perform transaction log verification on the production host.

9. Dismount all of the Exchange databases in the storage group.

10. Rename the storage group checkpoint file.

11. Remount the Exchange databases in the storage group.


106


TimeFinder restore ofthe Hot Split BCV

There are no exact TF/EIM guidelines for TimeFinder/Mirror device group creation and there is no single set of commands that will complete the restore operation for all setups.

In the following example, it is assumed that a TimeFinder/Mirror device group exists for each storage group, and the TimeFinder/Mirror device group is named sg1. This restore example is for a single database in a storage group. In this situation, restoring the entire TimeFinder/Mirror device group is not possible, since a single device within that TimeFinder/Mirror device group needs to be restored. To restore the database that resides on DEV001 in device group sg1, use the TimeFinder/Mirror command:

symmir -g sg1 restore dev DEV001

This command performs an incremental restore operation on just the tracks that have changed. The changed tracks will be copied back to the standard volume.

The restore operation can be monitored revealing status, using the following command:

symmir -g sg1 query

Once the copying of data from the BCV to the standard volume is complete and the BCV state is shown as Restored, the BCV can be split from the standard volume with the following command:

symmir -g sg1 split

Again, query the TimeFinder/Mirror device group and check that the BCV state is now Split.

Snap restore of theHot Split BCV

Once again, it is assumed that the current device group is named sg1, and the desire is to restore a single database that resides on DEV001 of that device group.

First, to view the snap session that currently exist for the standard device that needs to be restored, use the following command:

symsnap –g sg1 query –multi

At this point, choose the VDEV that you would like to restore onto DEV001. In this example, we will assume that we want to restore VDEV001 to DEV001. To initiate the restore operation, use the following command:

symsnap –g sg1 restore DEV001 VDEV ld VDEV001



To monitor the status of the restore operation, use the following command:

symsnap –g sg1 query

Once the restore is complete, the state of the snap session will be Restored. At this point, you should terminate the snap session with the following command:

symsnap –g sg1 terminate DEV001 VDEV ld VDEV001

Now, the standard device has been brought back to the point in time of the backup. Note that the VDEV is no longer a valid snapshot of the standard device.

Remount devices To remount the BCV to the backup/recovery server and the standard volume to the production server, first rescan both servers by issuing the following command:

symntctl rescan

Then issue the following command:

symntctl mount -drive n -vol HarddiskVolume9

Note: You must use SIU to perform this mount; otherwise, the volumes will be locked and all access will be denied. It is also possible to mount the volumes using their GUID rather than their volume name.

Transaction logverification

The transaction log verification process ensures that the production server has all the transaction logs necessary to complete recovery. This process involves identifying the Exchange Server required logs. The required logs are required in order to make the database logically consistent. Log verification is accomplished using the Exchange Server utility eseutil.exe. This utility extracts header information so that the log generations (lGeneration) can be identified.

To perform transaction log verification, perform the following steps:

1. Identify the required logs in a File Dump for the newly restored database by executing the following command:

eseutil /mh S:\exchsrvr\mdbdata\priv.edb

Obviously, the database path will vary for different configurations. Because this is a Hot Split operation, the state of the database is properly reported as Dirty Shutdown.


108


The Log Required field is the most interesting field in the file dump. As shown in Figure 12 on page 109, this field shows a range of numbers indicating the range of transaction logs that are required for recovery. Note that the numbers in this range are decimal (for example 2184-2185), while the actual transaction log numbers are identified as hexadecimal in their file name, using the following form:

E0000n.log

As shown in Figure 12 on page 109, the first number in the Log Required field was identified as 2184, yet the corresponding transaction log file name is E0000888.log. (The decimal number 2184 translates to 888 in hexadecimal.)



Figure 12 File dump sample for log required

2. Verify that the required logs are present in the transaction log directory, and that all transaction logs are sequential, by running the following command from the transaction log directory:

eseutil /ml E0n


110


Figure 13 is a sample output showing the transaction log listings in the hexadecimal format.

Figure 13 Transaction log listing

The E0n value is the log prefix for the particular storage group where the restore is taking place. This value is E00 for the first storage group on the server, E01 for the second storage group, E02 for the third storage group, and E03 for the fourth storage group. This value can be programmatically determined by opening the Exchange System Manager, selecting properties on the given storage group, and identifying the Log file prefix value.

First, verify that this command reports that no damaged log files were found. Then, verify that the required logs are all shown in the list of transaction logs (Figure 13). Finally, verify that all transaction logs shown in the output are sequential (that is, no transaction log generations are missing).

If any of the above steps fail, then you will need to restore some log files from the backup in order to complete the restore.



Dismount databasesin storage group

Up to this point, the database being restored was dismounted, but all of the other databases on the production server were mounted and servicing users. Now, all of the databases in the storage group where the restore is taking place must be dismounted. Note that only the one storage group where the restore is occurring needs to be dismounted, not all storage groups.

All databases in this storage group need to be dismounted because these databases all share the same set of logs. So if transaction log replay is going to be necessary on any one database in the storage group, all databases will need to be offline.

Using the Exchange System Manager, dismount all of the databases in this storage group.

Renaming the storagegroup checkpoint file

Prior to mounting the databases in the storage group to initiate transaction log replay, the current checkpoint file (E0n.chk) must be renamed, or deleted. Renaming the checkpoint file is essential for a full recovery of the Exchange Server database. The checkpoint file is found in the system file path for the storage group. This path can be found by opening Exchange System Manager, selecting properties for the storage group, and noting the System path location value. The checkpoint file must not exist in the specified Exchange Server system path in order for transaction log replay to occur. Either delete this checkpoint file or rename it to anything other than its original E0n.chk name.

Note: Each storage group will have a unique system path and checkpoint file. Ensure that the correct checkpoint file is renamed or moved.

RemountingExchange databasesin the storage group

Once the checkpoint file is deleted or renamed, all of the databases in the targeted storage group may be remounted in order begin the transaction log recovery process. The first database in the storage group to be mounted will begin the transaction log replay. It is not necessary that the restored database be the first database mounted; any of the databases in the storage group can be mounted first. Once the Exchange Server database engine begins to replay the logs, you can use the Windows Server Event Viewer to monitor the recovery process. The first database to be mounted will take the longest time since the transaction log replay will be occurring. The other databases in the storage group will be much faster to mount since the transaction log replay will have already completed.


112


Single mailbox recovery using a Hot Split databaseThis section highlights additional recovery setup considerations and tasks when a Hot Split database is in use.

A single mailbox recovery using a Hot Split Database is nearly identical to that for an offline split database. Therefore, follow the exact steps and procedures outlined in Microsoft's Mailbox Recovery for Microsoft Exchange Servers (technet.microsoft.com).

When using a Hot Split database to perform a single mailbox recovery, you must consider and perform the following tasks:

1. When Hot Splits are being used, it is required to setup the production server so that all checkpoint files are located on the standard volumes, and subsequently copied to the BCVs. Therefore, these checkpoint files will be available to the backup server (for the sole purpose of the single mailbox recovery). The backup server must be configured to use the checkpoint files that originated from the production server, and now reside on the BCV, otherwise the single mailbox recovery process will fail.

Ensure that the System file location for the storage group on the backup server where the single mailbox recovery is taking place is set to point to the location of the checkpoint file on the BCV. The “System file location” can be changed by opening the Exchange System manager on the backup server, selecting Properties on the storage group, and browsing to the path for the “System file location.” Failure to make this change will cause an Exchange error report that identifies the database as inconsistent when you attempt to mount it on the backup server.

2. The storage groups on the backup server must be configured exactly as they are on the production server. In particular, the order of the storage groups must be the same, due to the reliance on transaction log prefixes (which is determined by the order of storage groups). For example, assume that the storage group named “Executive SG” is the 2nd storage group on the production server. This would mean that the transaction log prefix for all transaction logs in the “Executive SG” would be E01. Therefore, when the backup server is configured for single mailbox recoveries, the “Executive SG” must be the 2nd storage group on the backup server so that it will keep its transaction log prefix of E01. If “Executive SG” is configured as 1st, 3rd, or 4th



storage group on the backup server, the transaction log prefix becomes different and the databases in that storage group will fail to mount.

3. All databases in the storage group must be accessible in order to perform a single mailbox recovery for any one database in that storage group. For example, assume that the storage group has 4 databases, and you are performing a single mailbox recovery from the 1st database in that storage group. All four of those databases must be present in order for the single mailbox recovery to work. In addition, the paths to all 4 databases must be identical (including the drive letters) on the backup server to what they were on the production server. This is because the database paths are hard-coded in the database headers.

Exchange database restore from a remote siteThe flexibility of an SRDF Exchange storage environment that was established by TF/EIM, offers the following SRDF environment restore and restart procedures:

◆ Restoring from the R2 to the production server on the local Symmetrix array.

◆ Restoring from the remote BCV to the production server on the local Symmetrix array.

Restoring data fromthe R2

To restore the Exchange data from the R2 location, you must do two TimeFinder/Mirror operations (shown in Figure 14):

1. Restore from the R2 to the R1/BCV.

2. Restore from the R1/BCV to the standard.

Figure 14 Restoring data from the R2

Standard R1BCV

R1BCV

R2

RP-000010


114


To restore the R1/BCV from the R2, do the following:

1. Use SIU to unmount the R1BCVs.

2. Verify that the R2 volumes are not mounted to a host at this time. If they are, use SIU to unmount them.

3. Open a command prompt.

4. Verify that the R1BCV and the R2 are in a split state with the following command:

symrdf -g DgName query -bcv

5. Restore the R2 to the R1BCV with the following command:

symrdf -g DgName restore -bcv

6. Verify the status with the following command:


7. Once the status shows restored, split the pair with the following command:

symrdf -g DgName split -bcv

8. Verify the connection state with the following command:


If the device groups that were created contain both the database volumes and the transaction log volumes, care must be taken during the restore procedures. By running the restore commands on the device group level, both the logs and the databases can be overwritten. To avoid this, specify a logical device name within the command. For example, to restore logical device number 001 in the device group, sg1rdf, enter the following command:

symrdf -g sg1rdf restore DEV001 -bcv

To restore the standard from the R1/BCV:

1. Make sure that the standard volumes have been dismounted with SIU on the production server.

2. Restore the BCV with the following command:






4. Split the pair with the following command:


5. Verify connection state with the following command:


Restoring data fromthe remote BCV

To restore the Exchange data from the remote BCV device, you must do the following three TimeFinder/Mirror operations (shown in Figure 15):

1. Restore the data from the remote BRBCV to the R2 mirror.

2. Restore the R2 to the R1/BCV mirror.

3. Restore from the R1/BCV mirror to the standard.

Figure 15 Restoring data from the remote BCV

To restore (in turn) the R2 mirror from the Remote BRBCV, the R1/BCV from the R2 mirror, and the standard from the R1/BCV:

1. Verify that the BRBCV, R2, R1-BCV, and the standard volume have all been unmounted with SIU.

2. Verify that the BRBCV and the R2 are in a split state.

3. Restore the BRBCV to the R2 with the following command:

symmir -g DgName restore -rdf -bcv



Standard R1BCV

R2

R2 RemoteBRBCV

RP-000011

R1BCV


116


5. Once the status shows restored, split the pair with the following command:


6. Verify the connection state with the following command:

symmir -g DgName query -rdf -bcv7. Restore the data from the R2 mirror to the R1/BCV, as described

on page 114.

8. Restore the R1/BCV to the standard device, as describe on page 114.

Cluster restores with and without maintenance modeVolumes and LUNs under MSCS control undergo specific health checks in order to determine their availability. Should any of these health checks fail, MSCS will attempt to offline the disk resource or move the disk resource to another node. When a volume or LUN is in a locked or Not Ready state, the cluster health checks are likely to fail. Some normal administrative tasks cause volumes or LUNs to become exclusively locked or Not Ready (for example: a chkdsk command, or a TimeFinder restore).

To solve this problem, Microsoft introduced a new MSCS feature called maintenance mode in Windows 2003 Service Pack 1. Shortly after SP1's release a post SP1 hotfix was released that contains an extended maintenance mode.

The goal of maintenance mode is to help enable certain administrative tasks against volumes or LUNs which would otherwise cause resources such as disks to fail. Correct usage of the maintenance modes will suppress the normal volume and disk LookAlive/IsAlive checks so that operations such as TimeFinder restores (which will set a LUN Not Ready for a short amount of time) can be done without impacting an entire resource group.

In order to perform TimeFinder or SRDF based restores without impacting the disk resource, extended maintenance mode must be used.

The act of enabling extended maintenance mode is equivalent to performing an offline of the disk resource. The disk resource will be offline "internally", however, to the cluster service and dependent applications, the disk resource will appear online. For more information regarding MSCS health checks and maintenance mode,



including information on how to obtain the hotfix for extended maintenance mode, refer to http://support.microsoft.com.

EMC supports the use of extended maintenance mode in performing TimeFinder or SRDF family restores based on replicas created by TF/EIM or TF/SIM. An important thing to note when using extended maintenance mode is to ensure the correct disk signature is being restored. In some environments, the BCV or R2 device may be presented to a backup or reporting host. If the backup/reporting host detects a signature conflict due to multiple copies of the same LUN, or a problem with multipathing, Windows will automatically change the disk signature of the conflicting device. Should that modified signature be restored to the cluster from which it came, the clustered resource will fail the next time the signature is checked. In its current form, extended maintenance mode will not check the signature being restored. Therefore a restore may appear to have been performed without a problem, but the next time that disk resource is moved or placed offline, the resource will fail with an invalid signature when it attempts to come online. So it is imperative to validate disk signatures before performing any restores into a MSCS environment.

It is important to ensure that all application level access to the volume(s) being placed in Extended Maintenance mode must be terminated. In the case of restorations, the database store will typically be detached or deleted from the storage engine. This style of operation will terminate user access to the device. Taking a resource offline by placing it in Extended Maintenance mode without first appropriately addressing user/process access, is not supported, and may result in adverse effects.

TF/EIM restore with VSS and Extended Maintenance modeThe following example shows the TimeFinder/Mirror restore process with Exchange 2003 or Exchange 2007, TF/EIM, and VSS with Extended Maintenance mode:

Note: Exchange 2007 users must mark the storage groups for overwrite before executing the restore.

1. Verify the signature of both the BCV(s) to be restored and clustered production LUN(s):

a. To obtain the signature of the clustered disk resource, on the clustered host:


118


From a command prompt run:cluster res ResourceName /priv

b. To obtain the signature of the BCV, on the backup or reporting host:

Ensure the Symmetrix Integration Utilities (SIU) are installed.

From a command prompt run:symntctl list -physical

c. To write a signature to a BCV device on the backup or reporting host, use the following command:

symntctl signature -pd diskn -sig

2. Issue the appropriate TF/EIM restore command from the TF/EIM backup host, for example:

exbackup2003 (or Exbackup2007) restore -vss -v -s VS_Name -bcd TEIM_VS_Name_09-22-06_BCD.xml -wmd TEIM_VS_Name_09-22-06_WMD.xml -sg StorageGroup-db DBName

3. Follow the prompts displayed by the TF/EIM restore command. The prompts will not display all of the steps needed in order to properly utilize maintenance mode. The additional steps needed are denoted by a * in the outline below:

Prompt 1: Please dismount all databases in storage group, Storage_Group.Has this been completed

successfully?"

Manually follow this step, then enter "y"

Prompt 2: TEIM will initiate a VSS restore of Storage_Group……SUCCESS

Allow this step to complete automatically.

Prompt 3: "On the backup server, please use SIU to dismount all BCVs/VDEVs being restored. Has this been

completed successfully?"




Prompt 4: "Please perform a TimeFinder restore of necessary databases. Has this been completed

successfully?"

* Before completing this step:

• Enable maintenance mode for the clustered disk resources to be restored:

– From a command prompt run:cluster res ResourceName /maint:on

• Enable extended maintenance mode for the clustered disk resources to be restored:

– From a command prompt run:cluster res ResourceName /extmaint:on

– The error displayed while enabling extended maintenance mode "System error 997" is expected and documented in Microsoft KB article 903650.

• Restore the BCVs using the appropriate device group or device file:

– From a command prompt run:symmir -g DgName restore -protect

• If protected restore cannot be used, wait for the devices to go into a restored state, then split the appropriate device group or device file:

– From a command prompt run:symmir -g DgName split

• Take the restored clustered disk resources out of extended maintenance mode:

– From a command prompt run:cluster res ResourceName /extmain:off

– The error displayed while disabling extended maintenance mode "System error 997" is expected and documented in Microsoft KB article 903650.

• Take the restored clustered disk resources out of maintenance mode:

– From a command prompt run:cluster res ResourceName /maint:off


120


Once the above steps have been completed, then enter "y"

Prompt 5: TEIM will complete the VSS restore of Storage_Group……SUCCESS


Prompt 6: TEIM will clear the READONLY flags on the STDs………...SUCCESS


Note: Extended Maintenance Mode will force the use of the cached disk attribute values of the disk resource. Therefore the READONLY attribute may not be displayed from the clustered host following the TimeFinder restore. This step will ensure that the on-disk attributes are consistent with the cached disk resource attributes. For more information please reference Microsoft KB 918188 (http://support.microsoft.com/kb/918188/en-us).

Prompt 7: "On the backup server, please use SIU to mount all BCVs/VDEVs that were restored. Has this been


Depending on the nature of the restore (i.e., the use of protected restore), the BCV may still be "restoring" at this step in the process. This step should be followed at the users discretion.

Once the appropriate action is determined, then enter "y"

Prompt 8: "Please remount databases to start recovery process. Has this been completed successfully?"


At this point the exbackup200n restore is complete and should display "ExBackup200n has completed successfully."

4. If the option to use protected restore was used, monitor the progress of the restore and ensure to split the BCV devices once they are in a restored state.

– From a command prompt run:symmir -g DGName split -protect



TF/EIM Restore with VSS without Extended Maintenance modeThe following example shows the TimeFinder/Mirror restore process with Exchange 2003 or Exchange 2007, TF/EIM, and VSS on a clustered production host without Extended Maintenance mode:

1. Ensure that the signature of both the BCV(s) to be restored matches the corresponding clustered production LUN(s):

a. To obtain the signature of a clustered disk resource, on the clustered host:

From a command prompt run:

cluster res ResourceName /priv

b. To obtain the signature of a BCV on the backup or reporting host, ensure the Symmetrix Integration Utilities (SIU) are installed, and from a command prompt run:


c. To write a signature to a BCV device on the backup or reporting host, run the following:

symntctl signature -pd diskn -sig

2. Issue the appropriate TF/EIM restore command from the TF/EIM backup host, for example:

exbackup2003 (or Exbackup2007) restore -vss -v -s VS_Name –bcd TEIM_VS_Name_09-22-06_BCD.xml –wmd TEIM_VS_Name_09-22-06_WMD.xml -sg StorageGroup[-db DBName

3. Follow the prompts displayed by the TF/EIM restore command:

Prompt 1: "Please dismount all databases in storage group, Storage_Group.Has this been completed

successfully?"


Prompt 2: TEIM will initiate a VSS restore of Storage_Group……SUCCESS


Prompt 3: "On the backup server, please use SIU to dismount all BCVs/VDEVs being restored. Has this been




122


Prompt 4: "Please perform a TimeFinder restore of necessary databases. Has this been

completedsuccessfully?"

* Before completing this step:

• In Cluster Administrator, remove the dependencies in Exchange on the disks that contain the Exchange databases and log files to be restored:

– For Exchange 2003, remove the disk dependencies from the Exchange System Attendant.

– For Exchange 2007, no dependency changes should be made to any storage group or disk resources during a TF/EIM restore.

• In Cluster Administrator, take offline all disks that contain the Exchange database and logs that you want to restore.

• Restore the BCVs using the appropriate device group or device file:


symmir -g DgName restore -protect

• If protected restore cannot be used, wait for the devices to gointo a restored state, then split the appropriate device group or device file:



• In Cluster Administrator, bring the disk resources and related Exchange resources back online. This step should not be done until TF/EIM has completed restoring the Exchange 2003 Storage Groups and the restored database(s) have been mounted.

Note: When restoring an Exchange 2007 database, do not bring the Exchange 2007 Storage Group Resource back online when you bring the disk resources online.

Once the above steps have been completed, enter "y"

Prompt 5: TEIM will complete the VSS restore of Storage_Group……SUCCESS




Prompt 6: TEIM will clear the READONLY flags on the STDs………...SUCCESS


Prompt 7: "On the backup server, please use SIU to mount all BCVs/VDEVs that were restored. Has this been


Depending on the nature of the restore (i.e., the use of protected restore), the BCV may still be "restoring" at this step in the process. This step should be followed at the users discretion.

Once the appropriate action is determined, enter "y"

Prompt 8: "Please remount databases to start recovery process. Has this been completed successfully?"


At this point the exbackup200n restore is complete and should display "ExBackup200n has completed successfully."

◆ For Exchange 2003 in Cluster Administrator, add back the disk dependencies of the disks that were restored.

Note: For Exchange 2003, the Exchange System Attendant must be taken offline to add back disk dependencies. .


124


Troubleshooting Exchange ServerTable 6 lists and describes some typical errors (with possible cause and action) that can occur in a Windows Exchange environment.

Table 6 Troubleshooting Exchange Server operations (1 of 2)

Error code Error string Cause Action

18

265

“Failed to create a handle to \\?\Volume{6de534a0-8adf-11d6-bd71-00d0b7081386}. ERROR = The process cannot access the file because another process has locked a portion of the file.”“Failed to mount \Device\HardiskVolume3 at E:\ on API1102. ERROR = Cannot create a file when that file already exists.”

TF/EIM is being run from a Terminal Services session.

If remote access is necessary, use a true console emulator such as VNC, RemotelyAnywhere, or PCAnywhere.

48 “Failed to initialize SYMAPI session on API1100. ERROR = The remote connection is refused. The symapi server is probably not running.”

The symapi service (storsrvd) is not installed or started on the production server.

Install and start storsrvd. Installing Solutions Enabler will prompt the installer to install and start the symapi service.

52 “Failed to get information for device on API1102.ERROR = The Symmetrix ID is not known.”

A database or set of logs is not stored on the Symmetrix array with a BCV.

Review all database and log paths to ensure that they are pointing to a Symmetrix disk which has a BCV.

92 “Failed to find the target volume name for the M:\ mount point.ERROR = The device is not connected.”

Exchange IFS (M:\) drive not fully dismounted from backup server.

To fully dismount the m: drive, open a command window and make the entry:subst m: /d

104 “Failed to construct an ExServer object with name Shyexchclus2.ERROR = Failed to create an ExStorageGroup object.”

The local language for the backup server is different from that of the production server.

Change the local language of the backup server to match the production server.

138 “Circular logging is currently enabled for the SG2 storage group. Please disable circular logging on all storage groups before running TF/EIM.”

Circular logging is enabled on production server.

Disable circular logging and reboot production server (or restart the Exchange services).

323 “ESEUTIL failed to verify the consistency of F:\SG2PrivA.edb.ERROR = 4294967295.”

Version of ESEUTIL.exe is too old and does not have the checksum (- k) options.

Upgrade to Exchange with 2000 Service Pack 1 or greater.



904 “Error Msg: Event ID 904,Category: Callback, Source: ESE Backup, Description: Information Store (2136) Callback function call ErrESECBGetDatabasesInfo ended with error 0x8004010F.”

The fully qualified domain name (FQDN) is being passed to TF/EIM instead of the NetBIOS name.

Pass the NetBIOS name to TF/EIM. For Example, use Exch1 rather than Exch1.emc.com.

112 Call to CoCreateInstance failed for the class EMCExClient. ERROR = Class not registered.

The SE_ESM service component does not get registered correctly on the backup host.

Reinstall Solutions Enabler to register the service component.

306 "There is nothing to backup on ServerName."

1. All public and mailbox stores on the Exchange 2007 server are dismounted.

2. The SE_ESM service component does not have enough authority to execute the powershell command to retrieve information from Exchange Server.

1. Remount any stores that you would like to backup.

2. Change the SE_ESM service component registration with domain admininstrator account. Refer to “EMC Solutions Enabler installation” on page 73 for details. This should be done on both the production and backup host.

- - Fail to initialize SYMAPI session on ServerName. Error = The remote client/server handshake failed.

The Exchange Virtual Server name does not reside in the symapi certificate repository on the production host. It caused the storsrvd to fail to autheticate the TEIM client application.

On the production host, In the cert directory of the EMC Solutions Enabler installation, execute the following command:C:\Program Files\EMC\SYMAPI\config\cert> "Program Files\EMC\SYMCLI\bin\magage_server_cert.bat" Create <Production Host Name> <Exchange Virtual Server Name>

Table 6 Troubleshooting Exchange Server operations (2 of 2)

Error code Error string Cause Action

Troubleshooting Exchange Server 125

126



6Invisible Body Tag

This chapter describes the EMC TimeFinder SQL Server Integration Module (TF/SIM) and the related software that manage the Microsoft SQL Server environment. The chapter also describes the complete setup of an SQL Server enterprise Business Continuance environment.

◆ Overview........................................................................................... 128◆ Setting up an SQL Server storage environment .......................... 135◆ Configuring the TimeFinder/Mirror environment..................... 139◆ Configuring the TimeFinder/Snap environment........................ 141◆ Configuring the TimeFinder/Clone environment ...................... 142◆ Configuring the SRDF environment ............................................. 144◆ Configuring the Open Replicator environment .......................... 148◆ Configuring Windows server disks............................................... 149◆ Creating a backup for dynamic disks with TimeFinder............. 150

TF/SIM Overview andSetup

TF/SIM Overview and Setup 127

128

TF/SIM Overview and Setup

OverviewThe TimeFinder/SQL Server Integration Module (TF/SIM) provides a comprehensive backup and recovery management interface specifically for Windows servers that support Microsoft SQL Server databases. TF/SIM integrates and collectively automates the command actions and behavioral features of EMC TimeFinder, SRDF, and the tools supplied with Microsoft SQL Server products.

Note: Unless otherwise noted, the term "SQL Server" means SQL Server 2000 and SQL Server 2005.

TF/SIM provides a command line interface that you can use to back up and restore SQL databases, using both the Microsoft Virtual Device Interface (VDI) and the database snapshot functionality. TF/SIM provides an integrated method for quickly creating point-in-time database copies that can be used for decision support systems or database maintenance. TF/SIM also provides a database backup that can be quickly restored in disaster-recovery scenarios.

TF/SIM further enhances the availability of the database to mission critical applications. TF/SIM can be used to greatly reduce backup and restore times and, in conjunction with typical database administration tasks, provide a more stable and available production database platform.

To use TF/SIM, you should have experience using TimeFinder/Mirror and SRDF environment CLIs, and SQL Server-based commands. You should also have a working knowledge of SQL Server backup and recovery methodologies.

For SQL Server databases managed by TF/SIM, you can:

◆ Back up either a database, multiple databases, or a specified database filegroup. TF/SIM provides a near instantaneous point-in-time back up of the production database/filegroup or multiple databases from a single instance of SQL Server, with little impact on your application (by hot splitting TimeFinder local or remote BCV or RDF devices, or activating a virtual copy session with Snap devices).

◆ Integrate EMC and Microsoft solutions to fast restore a database from the BCV and allow transaction backups from the production server to roll forward on the restored database in case of disaster recovery.



◆ Restore either a single database, multiple databases, or a specified database filegroup for a disaster recovery situation.

◆ Restore a standby database with the new location.

◆ Create a near instantaneous standby database that can be used for decision support and a transactionally consistent way to update a database guarding against logical corruption.

TF/SIM with VSS Microsoft SQL Server 2005 provides support for creating snapshots from SQL Server databases using Volume Shadow Copy Service (VSS). This is accomplished by providing a VSS compliant writer (the SQL writer) so that a third-party backup application can use the VSS framework to back up database files. TF/SIM V4.1 supports backup and restore operations using VSS for Microsoft SQL Server 2005.

Note: All TF/SIM VSS operations can only be issued from the backup host.

tsimvss support The tsimvss command supports most of the same functionality as tsimsnap and tsimsnap2, with the following exceptions:

◆ Does not support Windows Server 2003 Enterprise Edition Itanium.

◆ Does not support Filegroup backups.

◆ VSS backup copy cannot be recovered to the backup host with either the Standby or Norecovery modes, only the Recovery mode is supported.

◆ VSS restore to the production SQL Server instance must be to the same instance and database name from which the backup was taken.

◆ VSS restore to the production SQL Server can only be done with either the Norecovery or Recovery modes, Standby is not supported.

◆ Only supported in client/server mode; cannot be run from the production host.

◆ Does not support the -concurrent or -both_sides options.

Refer to Appendix B, “TimeFinder/IMs Support Matrix,” for a list of all supported options for tsimvss, tsimsnap, and tsimsnap2.

Overview 129

130


tsimvss comparison with tsimsnap and tsimsnap2The following are tsimvss behavioral differences from tsimsnap and tsimsnap2:

◆ Mounting to the backup host is controlled by the device starting state; -mountonly and -nomount are no longer options.

◆ SPC2 director flag is now required for clustered Windows 2003 SP1 or higher hosts.

◆ The 10 second write I/O freeze window is enforced.

◆ The tsimvss command requires the SQL Server Writer Service be started and set to automatic.

◆ Hosts running tsimvss must be able to import devices following the backup. For example, if using the -rbcv option, the TF/SIM host must be able to unmask and import the RBCV devices.



SQL Server snapshots SQL Server contains a Virtual Device Interface (VDI) that allows for snapshot backups. It provides a high-performance alternative to using named pipes for backups. Creating an SQL Server snapshot of a database enables you to roll forward transactions from a transaction backup device to a separate instance. An original standard host instance that has been restored from TimeFinder BCVs, or clones, can also be rolled forward. You can use the BCV copy for backup or for a near-instantaneous creation of a standby database.

In SQL Server, information provided in VDI metadata can be used to restore a database from existing files created by TimeFinder. Using SQL Server with TimeFinder, a standby database can be created in seconds, where it may take hours for very large databases without the integration of TimeFinder technologies.

Standby database A standby database is an exact copy of a production database that can be brought online in the event the standard production host or SQL Server fails. It can also be used as a reporting server for decision support. The read-only, standby database is created by performing a snapshot backup of the database on the standard host and a snapshot restore from the BCV or clone host.

Note: The normal operation is read only, but it is possible to have a read/write standby database for restoring.

Periodically, transaction log backups from the production Standard server are applied to the BCV standby database to ensure that the standby remains up-to-date with the standard production server. In the event of a production database or server failure, one or more of the databases on the standby server are made available to the user process.

You can also combine EMC TimeFinder with the SQL Server standby feature as a tool for updating a standby database without impacting production. The transaction log on the standard host is backed up to a BCV (or clone) paired device and synchronized periodically to the BCV host. The database server on the BCV side applies those transaction logs to the standby database. The standby server can be updated after every transaction backup, or as needed.

You may choose to keep the second standby server hours behind, in case of logical corruption or operator error, with the knowledge that

SQL Server snapshots 131

132


in the event of disaster, the logs are physically on the backup device and available for application. The standby server may also be used for read-only operations. This allows the database to be used for decision-support queries or DBCC checks.

Disaster recoverybackup

A copy of the database files created on BCVs is split from the production database and retained as a disaster recovery backup. The point-in-time database copy created by a TF/SIM backup action can be used to restore a production database using a TF/SIM restore action.

If the production database fails, but the server is still available, a TF/SIM restore command is issued from the standard host to allow the BCV copy to replace the corrupt database and allow transactions to be replayed to a known point-in-time. Clone and VDEV devices can also be used for disaster recovery backup.

Concurrent BCVs TF/SIM supports concurrent BCVs to provide two sets of point-in-time production database backups using concurrent BCV split. To use this feature, establish two concurrent BCV pairs before running tsimsnap/tsimsnap2 backup. TF/SIM will automatically detect and use the concurrent BCVs. Be sure to verify the concurrent BCV pair and establish all devices used by the database(s) with concurrent BCVs; otherwise, tsimsnap/tsimsnap2 backup will only backup the database with a single set of BCVs.

Remote backup TF/SIM provides client-server support to backup single or multiple databases from a centralized location. TF/SIM can remotely backup the production database with TimeFinder/SRDF, mount the file system on the backup server for tape backup, and initialize the standby database for decision support.

This feature requires that storsrvd be running on the production host and that the Solutions Enabler SRM Component be installed on the production host.



SQL Server 2005 TF/SIM supports all SQL Server 2005 features. The following TF/SIM features require SQL Server 2005:

Copy-only backup Normally, the SQL Server views a tsimsnap/tsimsnap2 backup command as a full database/filegroup backup. To specify that the backup process should not affect the normal sequence of backups, you can specify the -copyonly option with the tsimsnap/tsimsnap2 backup command. A copy-only backup does not affect the overall backup and restore procedures for the database and it does not reset the sequence of the database differential backup.

Database backupincluding full-text

catalog

In SQL Server 2005, the full-text catalog is added to the database meta data information. This means that backing up a database will backup the full-text catalog in conjunction with the database data and log files. However, you do not need to bring the full-text catalog online to restore the database. By default, the tsimsnap/tsimsnap2 backup command will include the devices that contain the full-text catalog files. To ignore the full-text catalog files during the backup process, specify the –nocatalog option with the tsimsnap/tsimsnap2 backup command.

Database backupincluding database

snapshot

A database snapshot is a point-in-time read-only copy of a database. Its primary use is to aid in the recovery of a database by allowing you to return a database to the state it was in when the snapshot was created. Database snapshot uses a copy-on-write process, where a database page is not copied unless the database is being updated.

Because a database snapshot cannot be backed up, the tsimsnap2 backup -alludb | -instance command does not include an option to target a database snapshot for backup. The tsimsnap backup command will fail to backup a database snapshot, as TF/SIM will verify that a database is not a database snapshot before backing it up.

Before running a TF/SIM restore operation, you should verify that all database snapshots are dropped.

Database piecemealrestore

In SQL Server 2000, a user cannot access a database unless all database file groups are recovered and brought online. In SQL Server 2005, the recovery process is enhanced to enable you to bring the database online once you have restored the primary tablespace. To use the piecemeal restore, specify the –partial option with the Tsimsnap restore –fg command.

SQL Server snapshots 133

134


Timeout Use the option -t Interval to timeout the application if the Hot Split takes too long to complete. If the -t option is not specified, there is no timeout by default. There are no minimum or maximum time intervals required, however, at least 10 seconds is recommended to avoid unexpected behavior. To safeguard the application from timeout, you can first run the TF/SIM backup command without the -t option, check the SQL Server Errorlog, and find the interval between the database I/O freeze and thaw event. Use that as a guideline to set the timeout interval.

VSS Backup The tsimvss.exe is the binary that uses the SQL Server 2005 VSS framework to backup and restore the databases. Due to the limitation of the SQL Server 2005 VSS support, tsimvss.exe can only backup database level components, there is no database filegroup backup support. If the user choose to restore the SQL Server database to another instance of SQL Server, the restored database can only be restored using -recovery mode. There is no capability of rolling forward the transaction log. If the user tries to restore the database backup to the production database for disaster recovery purposes, the restored database can be restored into -recovery or -norecovery mode. The database transaction log can be rolled forward only when the database gets restored into -norecovery mode.



Setting up an SQL Server storage environmentThe following sections describe how to setup an SQL Server business continuance environment, involving the various production and standby servers. The environment setup includes certain setup requirements for the volume configurations, plus the Windows operating systems, SQL Server software, and the EMC Solutions Enabler software in the server system. The proper operation of the Solutions Enabler TF/SIM backup/restore interface is dependent on the resulting configuration.

Figure 16 illustrates an SQL Sever storage environment that incorporates a local site connected to the remote site through an SRDF link. Both production and standby server storage environments need to be setup.

Figure 16 SQL Server business continuance environment

Local site

Productionserver R1

Standby serverR1 BCV

Symmetrix

Remote site

Failoverserver R2

Standby serverR2 BCV

Symmetrix

SRDF

STD BCV R2 BCV

Link

Setting up an SQL Server storage environment 135

136


Solutions Enabler EMC Solutions Enabler, which can provide the TimeFinder, Open Replicator, and SRDF components, is required. Refer to the EMC Solutions Enabler Installation Guide, and verify that the software with the required licenses are enabled. If not, enable the licenses using symlmf.

When prompted by the Solutions Enabler install program, select Custom install and select the SQL COMPONENT in the Custom Setup window, as shown in Figure 17.

Figure 17 SQL Component in the Custom Setup window



In addition, for tsimvss the storsqld service on the backup host must be modified to run under a domain account with SQL Server access, as shown in Figure 18.

Figure 18 EMC storsqld service setting

Environment variableconvenience

For ease of use, add the environment variable C:\Program Files\EMC\SYMCLI\bin to the path in the Environment settings on all hosts.

For Windows systems, open Computer Management, right-click Computer Management (local), and select Properties. Click the Advanced tab, click Environment Variables, and add C:\Program Files\EMC\SYMCLI\bin to the path variable.

Drive letterdesignations

Use Windows Computer Management to make sure that all the drive letters are set correctly.

The recommended setting for the CD-ROM is the Z:\ drive.

Transaction logconsiderations

It is often the case that the SQL transaction logs are placed on a Windows volume set and the SQL databases are placed on Windows

Setting up an SQL Server storage environment 137

138


stripe sets (without parity). Although it is not required, separating the transaction log volume from the database volume has its benefits. Transaction logs are written sequentially while the database is a random read/write I/O. Therefore, isolating the volumes improves performance and fault tolerance, while enhancing recoverability. Moreover, a separate backup device for the transaction log enables you to update a standby database.

Veritas StorageFoundation

When your SQL Server databases have dynamic disks on your server, Veritas Storage Foundation (SFW) is required. For more information, refer to “Volume management software” on page 44.

TF/SIM configurations The following setup procedures use MS-DOS, TimeFinder and SRDF SYMCLI, and SIU commands. Separate setup procedures target the:

◆ Production server storage

◆ Backup or standby server storage

◆ Storage for both production and standby servers

Symmetrix storage must be configured with TimeFinder/Mirror BCV devices of the appropriate type, size, and internal location to mirror the SQL Server storage and log devices that you intend to backup and restore. Ensure the SYMCLI environment is enabled. If not, run symlmf and enter the Solutions Enabler licensing keys for Base, and TimeFinder/Mirror. If you are using remote BCV or RDF devices, enter the additional license key for SRDF.



Configuring the TimeFinder/Mirror environmentPerform the following steps to setup the SQL backup or standby server storage on the local Symmetrix (BCV) side:

1. Create a device group with the same name that was used for the production server with the following SYMCLI base command:

symdg create DgName -type GroupType

where:

GroupType is either REGULAR, RDF1, or RDF2, as in the example:

symdg create sqadg1 -type REGULAR

2. Verify the creation of the group with one of the following commands:

symdg list symdg show DgName

3. Add devices to the new group with the following command:

symld -g DgName add pd PdevName [LdevName]

Repeat for each device. The default logical device name (LdevName) is Dev### unless assigned in the command, for example:

symld -g sqadg1 add pd PHYSICALDRIVE2 DriveE

4. Associate BCV devices with the group with the following command:

symbcv -g DgName associate dev SymDevName [LdevName]

Repeat for each device. The default logical device name (LdevName) is BCV###, unless assigned in the command:

symbcv -g sqadg1 associate dev 061 BCVdriveE

5. Verify that all devices have been created correctly with the following command:

symdg show DgName

For example:

symdg show sqadg1

Configuring the TimeFinder/Mirror environment 139

140


6. Synchronize the BCV devices with the following SYMCLI TimeFinder/Mirror component command:

symmir -g DgName -full establish [LdevName]

Note: To concurrently synchronize multiple BCVs, the second set of BCVs must be established individually with the following command: symmir -g DgName -full establish LdevName BCV ld BCVLdevName

7. View the status by performing a TimeFinder/Mirror query:


Once all devices are synchronized, you can now run a TF/SIM backup command.



Configuring the TimeFinder/Snap environmentPerform the following steps to set up the SQL production server storage in an EMC TimeFinder/Snap environment:

1. Create a device group with the following SYMCLI base command:


where GroupType is either REGULAR, RDF1, or RDF2, as in the example:


If the database uses devices from multiple Symmetrix arrays, you must create one device group per Symmetrix array.



3. Add devices to the new group with the following command:


Repeat for each device. The default logical device name (LdevName) is Dev###, unless assigned in the command:


4. Add VDEV devices to the new group with the following SYMCLI base command for each device:

symld -g DgName add dev SymDevName [SymDevName]


symdg show DgName

6. Create the virtual copy session with the following SYMCLI TimeFinder/Snap component command:

symsnap -g DgName create

7. View the status by using the following TimeFinder/Snap query:

symsnap -g DgName query

Configuring the TimeFinder/Snap environment 141

142


Configuring the TimeFinder/Clone environmentTimeFinder/Clone functionality is controlled by copy sessions, which pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of the device pairs.

A copy session must first be created to define and set up the clone devices. The session is then activated, enabling the target device to be accessed by its host. When the information is no longer needed, the session can be terminated.

To provide the initial clone to standard device association, you must create device groups on the backup/recovery server. The actual device group arrangement is completely up to you, as long as each standard device and clone being used by SQL is included.

Although TF/SIM does not use these device groups directly, they can be very helpful to you during restore scenarios. Therefore, use care when designing the device groups.

To configure your TimeFinder/Clone environment, do the following:


symdg create DgName



3. If the clone devices are BCV devices, add the BCV devices to the device group with the following command:


4. Verify the device group contains all of the devices that it shouldwith the following command:

symdg show DgName

5. Create the clone session with the following command:

symclone -g DgName create SymDevName SYM ld SymDevName



This creates a clone copy session on the devices, which can take a long time depending on the size of the devices. Make sure you remove any mount points from the clone devices on the backup/recovery server before creating the clone session. To determine the current state of the clone session, enter the following command:

symclone -g DgName query

6. Once this command shows that all of the clone sessions are created, run the following command to activate the clone sessions for all the devices in the device group:

symmir -g DgName activate

At this point, the clone devices connected to the backup/recovery server should have the identical volume labels as their paired standard devices.

Any clone devices that are dynamic disks are most likely offline after the split. Use the SFW to bring these disks back online.

Configuring the TimeFinder/Clone environment 143

144


Configuring the SRDF environmentThis section explains how to configure the following SRDF environments:

◆ “Standard SRDF” (below)◆ “Remote TimeFinder/Mirror (RBCV)” on page 145◆ “Remote mirroring of local TimeFinder/Mirror (BRBCV)” on

page 146◆ “Remote TimeFinder/Clone (RClone)” on page 147

Standard SRDF Perform the following steps to set up the SQL production server storage in an SRDF environment:



where:

GroupType is either RDF1 or RDF2, as in the example:

symdg create sqadg1 -type RDF1

If the database uses devices from multiple Symmetrix arrays, you must create one device group per Symmetrix array.



3. Add devices to the new group with the following SYMCLI base command:


for each device. The default logical device name (LdevName) is Dev###, unless assigned in the command, for example:



symdg show DgName



Remote TimeFinder/Mirror (RBCV)Using the R1 host, perform the following steps to set up a remote BCV pair on the standby SQL server in an SRDF environment:

1. Check the RDF paired devices status with the following command:

symrdf -g DgName query

2. If the device group is not synchronized, synchronize R2 with R1 devices with the following command:

symrdf -g DgName establish

3. Additionally, associate the R2 BCV devices to the new device group with the following:

symbcv -g DgName -rdf associate dev SymDevName[LdevName]

4. For BCV pairs, to synchronize R2 and BCV devices, enter the following command:

symmir -g DgName -rdf -full establish LdevName BCVdev SymDevName

In an SRDF environment, R2 devices are always synchronized with R1 devices, waiting for the failure to happen. You can periodically synchronize and split R2 BCV devices to obtain an updated standby database on the R2 BCV host.

5. View the status of the devices by performing a query:

symmir -g DgName query -rdf

6. Once this command shows that all devices are synchronized, split the BCV devices in the device group with the following command:

symmir -g DgName -split -rdf

Once all devices are split, you can run a TF/SIM backup command.

Configuring the SRDF environment 145

146


Remote mirroring of local TimeFinder/Mirror (BRBCV)Using the production host, perform the following steps to set up a BRBCV pair in an SRDF environment:


symdg create DgName

where:

GroupType is either REGULAR, RDF1, or RDF2, as in the example:


2. Add the standard devices to the new group with the following command:

symld -g DgName add SymDevName

3. Associate all of the local BCVs with the device group with the following command:


4. Associate all of the remote BCVs (BRBCVs) with the device group with the following command:

symbcv -g DgName associate dev SymDevName -bcv -rdf

5. Establish the standard and local BCVs with the following command:

symmir -g DgName -full establish

This performs a full establish on the devices. To determine the state of the BCV pairs, use the following command:


6. Wait until all the devices are synchronized, and then split the devices in the device group with the following command:


7. Establish the R2 and remote BCV device pairs with the following command:

symmir -g DgName -full establish -rdf -bcv



To determine the state of the establish command, use the following command:


8. Wait until all the devices are synchronized, and then split the devices in the device group with the following command:


Remote TimeFinder/Clone (RClone)Using the R1 host, perform the following steps to configure a remote TimeFinder/Clone pair on the standby SQL server in an SRDF environment:

1. Check the RDF paired devices status with the following command:

symrdf -g DgName query

2. If the device group is not synchronized, synchronize R2 with R1 devices with the following command:

symrdf -g DgName establish

3. Associate the remote BCV devices to the new device group with the following:

symbcv -g DgName -rdf associate dev SymDevName [LdevName]

Or add a remote standard device to the new device group with the following:

symld –g DgName –rdf add dev SymDevName [LdevName]

4. For TimeFinder/Clone pairs, create a session with a remote BCV by entering the following command:

symclone -g DgName -rdf create [-diff | -copy | -precopy] LdevName BCVdev SymDevName

Or create a session with a remote standard device by entering the following command:

symclone -g DgName -rdf create [-diff | -copy | -precopy] LdevName SYMdev SymDevName

Configuring the SRDF environment 147

148


Configuring the Open Replicator environmentOpen Replicator operations use a device file as described in the following section.

Open Replicator device fileTo specify ORS operations, an optional file (-orf FileName) is used. This specifies the device pairing relation between the local Symmetrix and remote Symmetrix or CLARiiON devices. It uses the following formats to be consistent with SYMCLI command for Open Replicator:

Symdev = src symid:symdevname symdev = tgt symid:symdevnameSymdev = src symid:symdevname clardev = tgt clarid:clardevnameSymdev = src symid:symdevname wwn=tgt device wwn

Target devices that are only accessible through the SAN cannot be specified with Symmetrix device names. Any World Wide Name (WWN) of a remote system must be obtained using platform-native tools.

Example device file entries:

# dev_file_1# control and remote device pairs# Symmetrix and StorageID:device always listed first

symdev=0000187900041:0102 wwn=123456781234567820000000c920b484symdev=041:0103 wwn=123456781234567820000000c9274156symdev=58:1C5 clardev=APM00034801589:39symdev=58:1C5 symdev=000184500160:19C

# End



Configuring Windows server disksWindows platforms support mount points. Make use of a mount point and create the directory of the mount points on both the standard and BCV host. The file system on Windows can have multiple mount point assignments; however, TF/SIM only supports a single mount point for the file system used for the database.

Basic disks To use basic disks with a single mount point:

1. From the standard host, start with all Symmetrix device groups in a synchronized state and use Computer Management to create volumes.

2. Flush the newly created file system with the following SIU command:

symntctl flush -drive DriveLetter: | -path MountPoint

3. Split the device group that contains the new volumes with the following TimeFinder command:


4. From the BCV host, run Computer Management to rescan the disks.

5. Change the drive letters or mount points to match the corresponding setup on the standard production host.

Dynamic disks The initial setup of the dynamic disks on a server determines the outcome of using EMC TimeFinder for backup and recovery:

◆ It is important to keep dynamic disk groups and TimeFinder/Mirror device groups on a one-to-one basis. For every dynamic disk group, create a TimeFinder/Mirror device group, and vice versa. To help keep the one-to-one relationship clear, consider naming the dynamic disk groups the same as the TimeFinder/Mirror device groups.

◆ It is not necessary to create the disk group on the backup server. Since the LDM database resides on every dynamic disk, it is copied over to the backup server on each of the BCVs. All disk group definitions are stored in this database and will immediately appear on the backup server (in an offline state). You can create the TimeFinder/Mirror device groups on either the production server or the backup server.

Configuring Windows server disks 149

150


Creating a backup for dynamic disks with TimeFinderThe following procedure describes the process for using TimeFinder/Mirror to create a BCV of a dynamic disk. If the disk group on the backup server containing the BCVs is not online, skip steps 1 and 2.

To create a backup for a dynamic disk, perform the following:

1. Dismount any drive letters or reparse points currently assigned to the BCVs in the dynamic disk group on the backup server. Do not use mountvol to perform this dismount. The following SIU command is recommended:

symntctl umount -drive DriveLetter: | -path MountPoint -nolock

2. Deport the dynamic disk group on the backup server with the following command. This step is only a precaution, the dynamic disk groups are deported automatically once the TimeFinder/Mirror establish is performed and the BCVs become not ready to the server.


3. Establish the TimeFinder/Mirror device group using the following command:

symmir -g DgName establish

4. Rescan the storage bus on the backup server with the following command. The dynamic disk group and all of its dynamic disks are listed as unreadable, and therefore, offline.

symntctl rescan

5. Split the TimeFinder/Mirror device group with the following command:


6. Rescan the storage bus on the backup server with the following command. The dynamic disk group and all of its dynamic disks are readable, but still offline and foreign to the host.

symntctl rescan



7. Import the dynamic disk group with the following command. Accept the default to keep the dynamic disk group name the same. The final result is that the dynamic disk group and all of its dynamic disks are online and healthy.


8. Mount the file system on the backup server with the following command:

symntctl mount -drive DriveLetter: -vol VolName

Note: This backup procedure is the same for all types of dynamic volumes.

Creating a backup for dynamic disks with TimeFinder 151

152



7Invisible Body Tag

This chapter describes how to perform backup and restore operations to Microsoft SQL Server databases using the EMC TimeFinder-SQL Server Integration Module (TF/SIM) command line interface.

◆ TF/SIM execution environments................................................... 154◆ Backing up a database or filegroup locally (tsimsnap) .............. 160◆ Concurrently backing up a database (tsimsnap)......................... 162◆ Restoring a database or filegroup locally (tsimsnap) ................. 164◆ Backing up a database or filegroup remotely (tsimsnap) .......... 169◆ Running TF/SIM backup using SRDF.......................................... 170◆ Backing up multiple databases locally (tsimsnap2).................... 172◆ Concurrently backing up multiple databases (tsimsnap2) ........ 174◆ Restoring multiple databases locally (tsimsnap2)....................... 176◆ Backing up multiple databases remotely (tsimsnap2)................ 185◆ Backing up SQL Server instance remotely (tsimsnap2) ............. 188◆ SQL backup and restore methods (tsimsnap/tsimsnap2) ......... 191◆ Restoring a database with VSS (tsimvss)...................................... 209

SQL Server Backupand Restore

Operations with TF/SIM

SQL Server Backup and Restore Operations with TF/SIM 153

154

SQL Server Backup and Restore Operations with TF/SIM

TF/SIM execution environmentsThe various TF/SIM backup and restore commands target different combinations and versions of the Microsoft Windows operating system and the SQL Server.

For information on the supported versions of Windows and SQL Server, refer to “EMC and third-party requirements” on page 21.

The TF/SIM commands with their brief descriptions are listed in Table 7.

For information on the syntax of these commands, refer to Appendix A

Considerations and guidelinesConsider the following guidelines before running TF/SIM:

◆ The snap device support is primarily targeted for point-in-time restore in case of database corruption. Though you may mount the VDEV devices to another host and use it to initialize the standby database, it is not recommended, as all reads from the standby database would eventually come from the source devices. This would degrade the production database performance.

◆ The TF/SIM remote backup requires the backup server to either be in the same domain as the production database host, or to have a trusted relationship established with the production database host.

Table 7 TF/SIM commands

Command Description

tsimsnap For a stand-alone or a clustered Windows Server, backs up or restores a Mircrosoft SQL Server database.

tsimsnap2 For Windows Server, backs up or restores multiple databases of the specified SQL Server instance through a single backup or standby server.

tsimvss For TF/SIM VSS backup and restore operations from the backup host.



◆ TF/SIM for IA64 requires the Itanium for Windows installation of EMC Solutions Enabler.

◆ TF/SIM for x64 requires the x64 installation of EMC Solutions Enabler.

◆ The TF/SIM remote backup requires that storsrvd be up and running on the production database host and that the EMC Solutions Enabler SRM component be installed on the production database host. It does not require an SRM license.

◆ Always run the local backup/restore command on the local SQL Server host since SQL Server 2000 does not support remote snapshot backup/restore. In an MSCS environment, run the backup/restore command on the active node where the production database resides. To run the backup/restore command from the remote host, the service rcmdsvc from the Windows 2000 Resource Kit can be installed and started on the SQL Server host; use rcmd to run tsimsnap.exe or tsimsnap2.exe remotely. The extended SQL Server stored procedure xp_cmdshell can also be used to run the command remotely.

◆ The TF/SIM operation uses a Windows trusted connection to connect to the local SQL Server. The user account that executes the command must have SQL Server sysadmin role.

◆ For an individual database/filegroup restore for disaster recovery, each database should be located on its own volume so that file systems can be unmounted without impacting other databases. This allows you to detach a specific database, unmount its file system, and perform TimeFinder or SRDF environment restore operations while the remaining databases are online.

◆ For backup of multiple databases that reside on shared Symmetrix devices, consider using tsimsnap2 to backup all the databases at the same time.

◆ Consider the performance impact when putting multiple databases on shared Symmetrix devices.

◆ For single-database backup using tsimsnap or multiple-database backup using tsimsnap2, the database can be in the simple recovery model if you do not need to perform transaction log backups. For filegroup backup using tsimsnap, the databases must be running in the full recovery model.

TF/SIM execution environments 155

156


◆ For SRDF environments, TF/SIM only supports synchronous RDF mode.

◆ No two NTFS volumes, being used for SQL data, can be located on the same LUN. Failure to follow this rule will result in TF/SIM failures.

◆ Operations using tsimvss must be performed from the backup host only (not from the production host).

◆ The SQL writer service must be installed and started on the production host.

Event logging and error files for WindowsThe two basic TF/SIM executables (tsimsnap.exe and tsimsnap2.exe) are accompanied by the message file tsim_err.dll that ties in with the Windows operating system event logging. The message files allow the executable to log all important events, errors, and failures to the Windows event log. Each event has a corresponding event ID, event description, and possibly an accompanying block of data for debugging purposes. All events are logged to the application event log with the EMCtsim source name. All the error messages generated by tsimsnap or tsimsnap2 can be found in the tsim_err.h file in the installation directory.

tsimsnap/tsimsnap2 execution sequenceThe TF/SIM commands streamline and simplify the various tasks and processes involved in an otherwise complex SQL backup or restore operation. The following execution sequence details the tasks and processes performed by these commands:

◆ Backup (locally):

• Check the status of the devices used by the database/filegroup, and abort if they are in an invalid state.

• Get file system information for the database/filegroup.

• Initialize and create a Virtual device set.

• Execute the SQL command to back up the database/filegroup with snapshot.

• Write metadata information for the database.

• Flush the file system and perform a TimeFinder BCV split.



• Notify SQL Server of the completion of the backup event and update the database backup history information.

◆ Backup (remotely):

• Validate to verify that the user has SQL Server sysadmin authority to perform the operation on the production and possibly standby SQL Server.

• From the production database host, retrieve the file list from the database, and thereby get all the fill systems used by the database.

• Resolve the devices used by the production database, identify the standard-BCV/RDF pair relationship, and verify that all devices used by the production database are in a SPLIT state.

• If standby database initialization is requested, verify that no one is connected to the database.

• Detach the standby database on the backup server and umount the file systems used by the standby database, if required.

• Establish the standard BCV/RDF pairs and wait until all devices are synchronized.

• Freeze the database I/O on the production database.

• Split the TimeFinder RDF devices.

• Resume the database I/O and notify the SQL Server when the event is complete.

• Mount the file systems on the backup server, if required.

• Restore the standby database to the standby SQL Server, if required.

◆ Restore (disaster recovery in automatic mode):

• Check the status of the devices used by the database, and abort if they are in an invalid state (BCV must be split).

• Get device group information, initialize and create a Virtual device set, unmount the file system, restore the device group, and mount the file systems.

• Restore the database/filegroup with snapshot using metadata information.


158


tsimvss execution sequenceBackup operations can be done from the backup host only.

The following steps outline the workflow for the database backup operation:

◆ Detach the database from the SQL Server instance if the -recovery option is specified.

◆ Dismount the volume from the backup host.

◆ Mask the volume from the backup host.

◆ Establish the TimeFinder devices.

◆ Create the VSS Shadow Copy from the production host.

◆ Import the VSS Shadow Copy to the backup host.

◆ Clear the readonly flag when necessary.

◆ Mount the volume to the backup host.

◆ Restore the database to the SQL Server instance. If the BCV volume was mounted to the different location, database relocation is necessary.

Open Replicator execution sequenceThe -orf FileName option is used to specify the ORS copy:

◆ Check the database files and resolve the Symmetrix devices used by the database files.

◆ Validate the devices status to be in the proper state. For BCV devices, they should be in split state. For clone devices they should be in the created state with -precopy or -copy option.

◆ Establish the BCV pairs.

◆ Suspend the database I/O.

◆ Split TimeFinder devices or activate the clone session.

◆ Resume the database I/O.

◆ For clone devices, wait until the clone device is in the copied state.

◆ Make the BCV or clone devices not-ready to the backup host.

◆ Create the Open Replicator session.



◆ Activate the Open Replicator session.

◆ Wait until the Open Replicator session is complete, and then make the BCV device ready to the host.

Note: The BCVs on the backup host are mounted or unmounted based on the options specified.

Command line start upThe TF/SIM commands (tsimsnap, tsimsnap2, and tsimvss) have various arguments and options. For command syntax and descriptions, refer to the remainder of this chapter and Appendix A.

To use TF/SIM console for command line entry:

1. From the Start menu, select Programs > EMC > TimeFinder Integration Modules > TimeFinder-SQL Server Integration Module > TSIM/TSIM CLI.

The TF/SIM Console (MS-DOS command prompt window) opens to the \Program Files\EMC\TimeFinder Integration Modules\TSIM directory.

2. Enter DOS commands at the prompt.

3. Enter exit to close the Console window.


160


Backing up a database or filegroup locally (tsimsnap)You can back up an SQL Server database or filegroup on a Windows server with one TF/SIM command. The TF/SIM command tsimsnap backup produces an exact copy of the database or filegroup on the standby or backup server. Once you have backed up an exact copy of the production devices that hold the SQL Server information (data and logs), you can perform database or filegroup restore actions when needed.

The tsimsnap backup command is issued only from the production connected host or the standard/R1 device host for SRDF environments. The TF/SIM backup operation:

◆ Suspends writes to the specified database/filegroup.

◆ Automatically writes metadata information about the specific database/filegroup. Metadata information is normally measured in kilobytes, so it is not necessary to have additional storage.

◆ Does the following, depending on whether using TimeFinder/Mirror or TimeFinder/Snap:

• For TimeFinder/Mirror, it performs an automatic TimeFinder/SRDF split of the devices associated with the database/filegroup.

• For TimeFinder/Snap, it activates the virtual copy session for the devices used by the database/filegroup.

The backup operation splits the production and standby devices while they are in online mode (Hot Split). TF/SIM verifies that the TimeFinder/Mirror instant split feature is supported by all Symmetrix arrays used by the database. If supported (Enginuity version 5x67 and later), the instant split behavior assists the Hot Split action.



Running TF/SIM backup locallyBefore backing up a database or filegroup, make sure the devices used by the specified database data and log files, or specified filegroup data files, are in synchronized mode:

◆ In an SRDF environment, R2 devices must be synchronized with R1 devices. Also, any R2 BCV devices must be synchronized with R2 STD devices and R2 devices must be synchronized with R1 devices if a remote BCV split is performed with tsimsnap backup. Before establishing the local or remote BCV or RDF devices, make sure you unmount the file systems, if the file systems have been mounted on any host.

◆ If concurrent BCV is used to get two concurrent point-in-time backups of the production database, make sure all concurrent BCVs are synchronized with either the devices used by the production database data and log files, or with the specified file group data files.

◆ In a virtual snap environment, VDEV devices must be in the created mode with standard devices.

◆ In a remote virtual snap environment, R2 devices must be synchronized with R1 devices and remote VDEV devices must be in the created mode with R2 devices.

To backup a Microsoft SQL Server database, use the following form:

tsimsnap backup -d SqlDbName -f MetaFile

In addition to targeting a specific database with the -d option, you must specify a meta file name that holds the storage parameters concerning the database. If you do not want to use the default TF/SIM directory, you can specify a full path name to the meta file.

The meta data file should be located on a normal Symmetrix device or local host drive. Optionally, it can be on a shared device and be made accessible through the network. This file is generally small, and can be copied on a diskette for backup purposes.

Refer to “tsimsnap” on page 228 for the complete command syntax and descriptions.

Backing up a database or filegroup locally (tsimsnap) 161

162


Concurrently backing up a database (tsimsnap)You can backup an SQL Server database or filegroup with local and remote BCV/VDEV on a Windows server with one TF/SIM command. The TF/SIM command tsimsnap backup -both_sides produces an exact concurrent point-in-time backup of the database or filegroup on the standby or backup server. Once you have backed up an exact copy of the production devices that hold the SQL Server Information (data and logs), you can perform database or filegroup restore actions when needed.

The tsimsnap backup -both_sides command is issued only from the R1 device host for SRDF environments. The TF/SIM backup operation:



◆ For TimeFinder/Mirror, it performs an automatic local and remote TimeFinder/Mirror split of the devices associated with the database/filegroup.

◆ For virtual Snap environments, it performs an automatic local and remote virtual copy session for the devices associated with the database/filegroup.

The backup operation splits the production and standby devices while they are in online mode (Hot Split). TF/SIM verifies that the TimeFinder/Mirror instant split feature is supported by all Symmetrix arrays used by the database. If supported (Enginuity version 5x67 and later), the instant split behavior assists the Hot Split action.



Running TF/SIM backup locallyBefore running a backup, make sure the devices used by the specified database data and log files, or specified filegroup data files, are in synchronized mode:

◆ R1 BCV devices must be synchronized with R1 devices. Also, any R2 BCV devices must be synchronized with R2 STD devices and R2 devices must be synchronized with R1 devices. Before establishing the local or remote BCV or RDF devices, make sure you unmount the file systems, if the file systems have been mounted on any host.

◆ If concurrent BCV is used to get two concurrent point-in-time backups of the production database, make sure all concurrent BCVs are synchronized with either the devices used by the production database data and log files, or with the specified file group data files.

◆ In a virtual snap environment, local VDEV devices must be in the created mode with R1 devices and the remote VDEV devices must be in created mode with the R2 devices. In addition, the R2 devices must be synchronized with the R1 devices.


tsimsnap backup -d SqlDbName -f MetaFile -both_side

In addition to targeting a specific database with the -d option, you must specify a meta file name that holds the storage parameters concerning the database. If you do not want to use the default TF/SIM directory, you can specify a full path name to the meta file.


Concurrently backing up a database (tsimsnap) 163

164


Restoring a database or filegroup locally (tsimsnap)For a disaster recovery situation, you can restore an SQL Server database or filegroup on a Windows server using a single TF/SIM command. Using the command tsimsnap restore from the production (standard) host, you can restore the production server from its local BCV, or from the remote R2 mirror in an SRDF environment.

This command is not intended to create a database that runs as a separate instance. The command should only be used in a disaster recovery scenario to restore a database/filegroup from a TimeFinder/Mirror BCV or TimeFinder/Snap VDEV to the standard devices.

The restore operation automatically performs the following tasks:

◆ Suspends any writes to the database and/or filegroups.

◆ Unmounts the file system on the standard host.


• For TimeFinder/Mirror, it performs a TimeFinder/Mirror restore action, and then splits the restored device from the backup devices.

• For TimeFinder/Snap, it performs a symsnap restore action.

◆ Mounts the file system on the standard side host.

◆ Restores the database or filegroup with snapshot.

Running TF/SIM restoreBefore running the TF/SIM restore command in this automatic mode, make sure the devices used by the database/filegroup are in the split status. Make sure the file system on which the metadata file resides is not used by the database, and no application or service is holding the file system handles for the database. You can issue the symntctl openhandle command to check if applications other than SQL Server are holding the file system handle.

If the file systems used by the BCV devices are mounted on a BCV host, unmount those file systems before running a TF/SIM restore or a TimeFinder/Mirror (symmir) restore action.



To restore a Microsoft SQL Server database, use the following form:

tsimsnap restore -d SqlDbName -f MetaFile-norecovery|-recovery|-standby|

In addition to targeting a specific database with the -d option, you must specify the meta file name (or full path) that has the meta data information concerning the database you want to restore (-f option).

Manual mode Using the -m option, you can override the default automatic mode by selecting manual mode, which breaks this overall restore operation into individual tasks. This mode is used for clustered servers and dynamic disks, or other services that must be turned off with manual intervention. It also allows for a restored database to be relocated on different devices.

Manual mode requires you to do the following:

◆ Detach the database using the sp_detach_db stored procedure or SQL Enterprise Manager on the standard host.

◆ Unmount the file systems.

◆ Do the following, depending on whether you are using TimeFinder/Mirror or TimeFinder/Snap:

• For TimeFinder/Mirror, perform a TimeFinder/Mirror restore, and then split the devices once they are restored.

• For TimeFinder/Snap, perform a symsnap restore action.

◆ Manually mount the file systems on the standard host where the selected database resides before executing the manual restore operation.

◆ Restore the database/filegroup with snapshot with the tsimsnap restore -m command.

With the manual mode, you can specify the name of the relocation text file (.txt) using the -rf option. To move the database to different devices, first mount all file systems used by the database to the new location before running with this option. This relocation text file contains and lists the logical and physical device name where each file resides in the database storage.

If only a single filegroup needs to be restored, and you need to restore the transaction log to the end of the transaction log backup chain, you must use the automatic mode to restore the filegroup from the BCV back to a standard device.

Restoring a database or filegroup locally (tsimsnap) 165

166


If a point-in-time restore is required, the complete set of the filegroup backups must be restored, using either manual or automatic mode. When restoring in automatic mode, the restore sequence does not matter. For restoring in manual mode, the primary filegroup needs to be restored first, then restore all the other filegroups used by the database.

It is strongly recommended to split the device group before running this command to preserve the BCV copy of the database.

The point-in-time database backup copy can be used for either the complete database or individual filegroup restores. If any BCV copy of the filegroup gets updated after the point-in-time database backup, only individual filegroup restores can be used.

Example For a relocation example, Figure 19 on page 167 shows databaseXYZ original logical filename and physical filename pair from the database query. To relocate the database, create a new text file databaseXYZ_relocation.txt and put the original logical filename and the new physical filename in each line of the file (as shown in Figure 20 on page 167).

Run the following command to restore the databaseXYZ to the new location with standby state:

tsimsnap restore -d databaseXYZ -f n:\databaseXYZ.dmp-rf n:\databaseXYZ_relocation.txt -m -standby



Figure 19 Database query: Logical and physical filename pairs

Figure 20 Relocation file with old logical and new physical filenames

Restoring a database or filegroup locally (tsimsnap) 167

168


Restoring a database using Open ReplicatorTo restore the production database directly from the remote LUNs:

1. Detach the production database from the SQL Server instance.

2. Unmount the file systems used by the production database.

3. Start the data migration from the remote luns to the local LUNs with the symrcopy command.

4. Wait until the data migration is complete, and mount the file systems on the production host.

5. Restore the production database with the tsimsnap restore command.

To restore the production database from the remote LUNs via the local BCV:

1. Start the data migration from the remote luns to the local BCV LUNs with the symrcopy command.

2. Detach the production database from the SQL Server instance.

3. Unmount the file systems used by the production database.

4. Run the symmir -g dgname restore command to restore the local BCV devices.

5. Mount the file systems on the production host.

6. Restore the production database withthe tsimsnap restore command.



Backing up a database or filegroup remotely (tsimsnap)You can backup an SQL Server database or filegroup on a Windows server remotely with one TF/SIM command. The command tsimsnap backup -ph produces an exact copy of the database or filegroup on the standby or backup server for tape backup or decision support.

The tsimsnap backup -ph command is issued from the remote backup host. The TF/SIM backup operation:

◆ Detaches the standby database from the standby SQL Server, if needed.

◆ Unmounts all the file systems used by the standby database, if needed.


• For TimeFinder/Mirror, it establishes BCV/RDF devices and waits all the devices used by the database to synchronize.

• For TimeFinder/Snap, it creates the virtual copy session for all devices used by the database filegroup (only if the virtual copy session has not yet been created).



• For TimeFinder/Mirror, it performs an automatic TimeFinder/SRDF split of the devices associated with the database/filegroup.

• For TimeFinder/Snap, it activates the local/remote virtual copy session for the devices used by the database/filegroup.

◆ Mounts the file system used by the database, if needed.

◆ Restores the database into no recovery/standby/recovery mode to the standby SQL Server, if needed.

Backing up a database or filegroup remotely (tsimsnap) 169

170


The backup operation splits the production and standby devices while they are in online mode (Hot Split). TF/SIM verifies that the TimeFinder/Mirror instant split feature is supported by all Symmetrix arrays used by the database. If supported (Enginuity version 5x67 and above), the instant split behavior assists the Hot Split action.

Running TF/SIM backup using SRDFBefore running a backup, make sure the devices used by the specified database data and log files, or specified filegroup data files, are in split mode:

◆ In an SRDF environment, R2 devices must be split from R1 devices, any R2 BCV devices must be split from R2 STD devices, and R2 devices must be synchronized with R1 devices if a remote BCV split is performed with tsimsnap backup.

◆ In a BRBCV environment, the standard devices must be split from their BCV devices, the R2 devices must be split from their BCV devices, and the R2 BCV devices must be split from their R2 devices.

◆ In a virtual snap environment, VDEV devices must be visible to the backup server.

◆ In a remote virtual snap environment, VDEV devices must be visible to the backup server and R2 devices must be synchronized with R1 devices.

◆ VDEV devices can be in either a terminated or created state prior to running TF/SIM remotely. If the VDEV devices are terminated then TF/SIM will automatically select the appropriate VDEVS which are present to the backup server. If the VDEV devices are already created, TF/SIM will simply activate the already created VDEV sessions.


tsimsnap backup -d SqlDbName -f MetaFile -ph hostname

In addition to targeting a specific database with the -d option, you must specify a meta data file name that holds the storage parameters concerning the database. If you do not want to use the default TF/SIM directory, you can specify a full path name to the meta file. With TF/SIM in remote backup mode, the meta data file will be put onto the production host.




You can specify to update the BCV/R2/R2BCV/BRBCV only using the -nomount option.

You can specify to update the BCV/R2/R2BCV/BRBCV and mount the file system on the backup server for tape backup, using the -mountonly option. If the file systems on the BCV/R2/R2BCV/BRBCV were not mounted before running the TF/SIM command, TF/SIM will not mount the file system with the -mountonly switch.

You can specify to update the BCV/R2/R2BCV/BRBCV, mount the file system on the backup server, and restore the database into either norecovery mode, recovery mode, or standby mode, using the appropriate option (-norecovery, or -recovery, or -standby).

Note: If the same drive letter assignment is not available on the backup host, use the -relocate option with either the -norecovery, -recovery, or -standby option, along with the new drive letter/mount point. TF/SIM will mount the file system with the new driver letter mount point and restore the database with relocation on the backup host.

Note: If either the -norecovery, the -recovery, or the -standby option is used, the metadata file must be located on one of the file systems the production database it is using. This enables the database restore process local access to the metadata file on the backup server, without having to access the network drive.

Refer to “tsimsnap” on page 228 for the complete command syntax and descriptions.

Backing up a database or filegroup remotely (tsimsnap) 171

172


Backing up multiple databases locally (tsimsnap2)You can backup multiple SQL Server databases on a Windows server using one TF/SIM command. The TF/SIM command tsimsnap2 backup produces an exact copy of the databases on the standby or backup server. Once you have backed up an exact copy of the production devices that hold the SQL Server information (data and logs), you can perform database or filegroup restore actions on any or all of the databases when needed.

The tsimsnap2 backup command is issued only from the production connected host or the standard/R1 device host for SRDF environments. The TF/SIM backup operation:

◆ Suspends writes to the specified databases.

◆ Automatically writes metadata information about each of the specific databases. Metadata information for each database is normally measured in kilobytes, so it is not necessary to have additional storage.


• For TimeFinder/Mirror, it performs an automatic TimeFinder/SRDF split of the devices associated with the specified databases.

• For TimeFinder/Snap, it activates the virtual copy session for the devices used by the specified databases.

This TF/SIM command backs up or restores multiple databases for a stand-alone or a clustered Windows SQL Server instance that reside on Symmetrix devices. The backup operation consolidates the backup timeframes by concurrently backing up multiple databases together. Once you have backed up an exact copy of the production devices that hold the SQL Server information (data and logs), you can perform database or filegroup restore actions on any or all databases when needed. The backup operation writes information about the specific databases in metafiles stored in the specified meta directory. The default file names take on the form DbName_snapshot.dmp for the various meta files in this directory.

If the Symmetrix array supports instant split, then TimeFinder/Mirror instant split behavior will assist a hot-split task portion of the backup activities. Before starting a backup operation, all database devices must be synchronized, and if an SRDF



environment exists, R2 devices and their BCVs are synchronized with R1 devices.

The command, issued only from the standard/R1 host, automatically writes metadata information about the specific databases in the specified directory. Metadata information is normally measured in kilobytes, so it is not necessary to have additional storage.

The command performs an automatic TimeFinder/Mirror local/remote BCV or RDF split of the devices associated with the databases, during the database write suspension period. The backup process splits the production and standby devices while they are in online mode (Hot Split). TF/SIM verifies that the TimeFinder/Mirror instant split feature is supported by all Symmetrix arrays used by the database. If supported (Enginuity version 5x67 and later), the instant split behavior assists the Hot Split action.

Running TF/SIM backup locally Before backing up multiple databases locally, make sure all the devices used by the databases are in synchronized mode.

In an SRDF environment, R2 devices must be synchronized with R1 devices, and R2 BCV devices must be synchronized with R2 devices. Before establishing the local or remote BCV or RDF devices, make sure you unmount the file systems, if the file systems have been mounted on any host.

To backup multiple Microsoft SQL Server databases, use the following form:

tsimsnap2 backup -alludb | -d SqlDbName SqlDbName... |-instance

You can target all user databases in your database instance with the -alludb option, or you can specify a series of databases with the -d option, or you can target all the databases in your database instance, using the -instance option. There is no limit on the number of the databases to be backed up. You need to consider the appropriate number of the databases to be backed up according to the host CPU and memory resource availability.

Refer to “tsimsnap2” on page 238 for the complete command syntax and descriptions.

Backing up multiple databases locally (tsimsnap2) 173

174


Concurrently backing up multiple databases (tsimsnap2)You can backup multiple SQL Server databases with local and remote BCV/VDEV devices on a Windows server with one TF/SIM command. The TF/SIM command tsimsnap2 backup -both_side produces an exact concurrent point-in-time backup of the databases on the standby or backup server. Once you have backed up an exact copy of the production devices that hold the SQL Server information (data and logs), you can perform database or filegroup restore actions on any or all of the databases when needed.

The tsimsnap2 backup -both_side command is issued only from the R1 device host for SRDF environments. The TF/SIM backup operation:



◆ For TimeFinder/Mirror, it performs an automatic local and remote TimeFinder/Mirror split of the devices associated with the specified databases.

◆ For virtual snap environments, it performs an automatic local and remote virtual copy session for the specified databases.

This TF/SIM command backs up or restores multiple databases for a stand-alone or a clustered Windows SQL Server instance that reside on Symmetrix devices. The backup operation consolidates the backup timeframes by concurrently backing up multiple databases together. Once you have backed up an exact copy of the production devices that hold the SQL Server information (data and logs), you can perform database or filegroup restore actions on any or all databases when needed. The backup operation writes information about the specific databases in metafiles stored in the specified meta directory. The default file names take on the form DbName_snapshot.dmp for the various meta files in this directory.

If the Symmetrix array supports instant split, then TimeFinder/Mirror instant split behavior will assist a hot-split task portion of the backup activities. Before starting a backup operation, all database devices must be synchronized, and if an SRDF



environment exists, R2 devices and their BCVs are synchronized with R1 devices.

The command, issued only from the standard/R1 host, automatically writes metadata information about the specific databases in the specified directory. Metadata information is normally measured in kilobytes, so it is not necessary to have additional storage.


Running TF/SIM backup locally Before running a multiple backup operation, make sure all the devices used by the databases are in synchronized mode.

R1 devices must be synchronized with R1 devices, and R2 BCV devices must be synchronized with R2 devices. Before establishing the local or remote BCV or RDF devices, make sure you unmount the file systems, if the file systems have been mounted on any host.


tsimsnap2 backup -alludb | -d SqlDbName SqlDbName... |-instance -both_sides

You can target all user databases in your database instance with the -alludb option, or you can specify a series of databases with the -d option, or you can target all the databases in your database instance, using the -instance option. There is no limit on the number of the databases to be backed up. You need to consider the appropriate number of the databases to be backed up according to the host CPU and memory resource availability.


Concurrently backing up multiple databases (tsimsnap2) 175

176


Restoring multiple databases locally (tsimsnap2)For a disaster recovery situation, you can restore multiple SQL Server databases on a Windows server using a TF/SIM command. For example, using tsimsnap2 restore from the production (standard) host, you can restore the production server from its local BCV or from the remote R2 mirror in an SRDF environment.

Running TF/SIM restoreBefore running the TF/SIM restore command, you must mount the file system for the specified databases first. The tsimsnap2 restore command restores the specified databases into norecovery, standby, or recovery status. If either the norecovery or standby option has been used to restore the databases, then additional transaction logs from the production databases can be rolled forward.

Make sure the devices used by each database are in the split status. Make sure the file system where the metadata file resides is not used by the particular database, and no application or service is holding the file system handles for the database. You can execute symntctl openhandle to check if there is any application other than SQL Server holding the file system handle.

If the file systems used by the BCV devices are mounted on a BCV host, unmount those file systems before running a TF/SIM restore or a TimeFinder/Mirror (symmir) restore action.

To restore multiple Microsoft SQL Server databases, use the following form:

tsimsnap2 restore -d SqlDbName SqlDbName... -f MetaFileDir-norecovery|-recovery|-standby

You can target and specify a series of databases with the -d option. There is no limit on the number of the databases to be restored. You need to consider the appropriate number of the databases to be restored according to the host CPU and memory resource availability.

You must specify one of three possible states to have the databases restored to: norecovery, recovery, or standby state.




Initializing multiple databases on the standby hostUsing the multiple TF/SIM restore command, you can initialize (create) multiple standby databases to another instance on the standby host side.

Before running the TF/SIM restore command, you must mount the file system disks for the specified dataset first. Using the locally-attached BCV host, you specify the BCV databases, the standby server name, and its target instance name:

tsimsnap2 restore -d SqlDbName SqlDbName... -f MetaFileDir -norecovery|-recovery|-standby[-s VirtSqlServName[\InstanceName] |

HostName[\InstanceName]]

Initializing multiple databases on the BCV hostThis section presents a TF/SIM backup and restore method to initialize multiple standby databases under the BCV host. Once standby databases have been initialized on the BCV side, you can update them using either TimeFinder/Mirror log shipping or network log shipping.

The tsimsnap2 backup suspends writes to multiple databases and automatically writes metadata information about those databases. It also performs an automatic TimeFinder/Mirror split of the devices associated with the databases. You enter the databases and directory name where the metadata information files reside.

The TF/SIM multiple restore command makes use of the combination of the point-in-time BCV backup copy of the databases and the metadata files to instantaneously restore the databases with standby mode.

Restoring multiple databases locally (tsimsnap2) 177

178


The following steps describe how multiple standby databases can be created on the BCV side with TF/SIM multiple backup and restore actions. If the file system is not mounted on the BCV host, start from step 5:

1. On the BCV host, detach those multiple standby databases using the SQL command, sp_detach_db dbname, or SQL Server Enterprise Manager.

2. Unmount the standby database file systems with the following SIU command:

symntctl umount -drive DriveLetter | -path MountPoint

If Windows dynamic disks are used, apply the -nolock option with this command.

3. If Windows dynamic disks are used, deport the disk group used by the databases on BCV host with the following command:


4. Establish the devices used by the databases with the following TimeFinder/Mirror command:


5. If Windows dynamic disks are used, rescan the disks on the BCV host with the following SIU command:

symntctl rescan

6. Once the device group is synchronized, run the following TF/SIM multiple backup command on the standard host to get a point-in-time backup of the production databases:

tsimsnap2 backup -d DbName DbName... -f MetaDirName

7. If Windows dynamic disks are used, rescan the disks and import the disk group on the BCV host by with the following SIU commands:

symntctl rescanvxdg import -g DgName -Csymntctl rescan

8. Mount the file systems used by the databases on the BCV host with the following command:

symntctl mount -drive DriveLetter -vol VolName [-dg DgName]



9. Run a TF/SIM multiple restore to restore those multiple databases with snapshot:

tsimsnap2 restore -d DbName DbName... -f MetaDirName -standby

10. Backup the transaction log from the production databases on the standard host.

11. Restore the transaction log backups to the multiple databases, using the SQL commands.

12. Use network or TimeFinder/Mirror log shipping to update the standby databases.

Restoring a database on a production clustered hostTo restore an SQL Server database on a production host in an MSCS clustered environment:

1. Detach the corrupt SQL database.

2. In Cluster Administrator, remove the dependencies in SQL Server on the disks that contain the databases:

a. To obtain the signature of the clustered disk resource, on the clustered host, use the following command:

cluster res ResourceName /priv


– Ensure the Symmetrix Integration Utilities (SIU) are installed, by entering the following command:


– After verifying the signature, ensure the BCV is unmounted on the backup host with SIU.

3. In Cluster Administrator, take offline all disks that contain the database you want to restore.

4. From a command prompt, run the following TimeFinder/Mirror restore command that targets the device group that contains the disks that hold the SQL database:



180


5. Once the device group is restored, split the device group database with the following command:


6. Repeat steps 4 and 5 for all device groups that contain the SQL database you want to restore.

7. In Cluster Administrator, take offline the entire SQL Cluster Resource.

8. In Cluster Administrator, add the disk dependencies of all disks containing the SQL database files to the SQL Server resource.

9. In Cluster Administrator, bring the entire SQL resource online.

10. Restore the database using the appropriate tsimsnap or tsimsnap2 restore command.

Restoring a database on a production clustered host with extended maintenance mode

The following example shows the TimeFinder/Mirror restore process with SQL Server and TF/SIM on a clustered host with extended maintenance mode enabled:

1. Detach the SQL database to be restored.

2. Verify the signature of both the BCV(s) to be restored and clustered production LUN(s):

a. To obtain the signature of the clustered disk resource, on the clustered host:

– From a command prompt run:cluster res ResourceName /priv


– Ensure the Symmetrix Integration Utilities (SIU) are installed.

– From a command prompt run:symntctl list -physical

– After verifying the signature, ensure the BCV is unmounted on the backup host with SIU.

3. Enable maintenance mode for the clustered disk resources to be restored:



a. From a command prompt run:cluster res ResourceName /maint:on

4. Enable extended maintenance mode for the clustered disk resources to be restored:

a. From a command prompt run:cluster res ResourceName /extmaint:on

b. The error displayed while enabling extended maintenance mode "System error 997" is expected and documented in Microsoft KB article 903650.1

5. Restore the BCVs using the appropriate device group or device file:

a. From a command prompt run:symmir -g DgName restore -protect

6. If protected restore cannot be used, wait for the devices to go into a restored state, then split the appropriate device group or device file:

a. From a command prompt run:symmir -g DgName split

7. Take the restored clustered disk resources out of extended maintenance mode:

a. From a command prompt run:cluster res ResourceName /extmain:off

b. The error displayed while disabling extended maintenance mode "System error 997" is expected and documented in Microsoft KB article 903650.1

8. Take the restored clustered disk resources out of maintenance mode:

a. From a command prompt run:cluster res ResourceName /maint:off

9. Restore the database using the appropriate tsimsnap or tsimsnap2 restore command.

10. If the option to use protected restore was used, monitor the progress of the restore and ensure to split the BCV devices once they are in a restored state.

1. This issue is resolved in Windows 2003 SP2.


182


a. From a command prompt run:symmir -g DGName split -protect

Disaster recovery strategy for multiple databasesIn a disaster recovery situation, you may need to restore the standard or production side database devices with the BCV standby side databases. The standard side databases must be recovered to either the norecovery, recovery or standby state.

If multiple databases are sharing Symmetrix devices, the granularity of a single database BCV/RDF restore becomes impossible because this command restores every database in the directory. In this situation, you must use Solutions Enabler commands to execute the restore operations separately for all databases that share the Symmetrix devices, or manually copy the single database files from the backup server back to the standard side for a single database restore.

From the local BCV To restore the production databases from the local BCV on the production host:

1. Detach or drop the specified databases first.

2. Unmount the file systems of the databases to be restored with the following SIU command:


3. Execute the following TimeFinder/Mirror restore command, targeting the database device group to restore the database from the local BCV:

symmir -g DbDgName restore

4. Once the device group is restored, split the device group, with the following TimeFinder/Mirror command:

symmir -g DbDgName split

5. Mount the file systems of the specified databases with the following command:

symntctl mount

6. Restore the databases with a TF/SIM SQL snapshot:

tsimsnap2 restore -d DbName DbName... -norecovery|-standby



7. Using SQL commands, restore additional transaction logs to the point-in-time before the database corruption (the databases from the last TF/SIM command must now be in the norecovery or standby state).

The production restore operation from the local BCV is complete.

From the remote BCV To restore the production database from a remote BCV on the production host:

1. Detach or drop the specified database first.



3. Split the RDF link with the following SRDF command:

symrdf -g DbDgName split

4. Restore devices from the R2 BCV to the R2 with the following TimeFinder/Mirror command on the R1 host:

symmir -g DbDgName restore -rdf

5. Once the device group is restored, split the device group with the following TimeFinder/Mirror command:

symmir -g DbDgName split -rdf

6. Restore devices from R2 to R1, with the following SRDF command on the R1 host:

symrdf -g DbDgName restore

7. Once the device group is restored, split the RDF link with the following SRDF command:


8. Mount the file systems used by the specified database with the following command:

symntctl mount

9. Restore the specified databases with a TF/SIM SQL snapshot:



184



The production restore operation from the remote BCV is now.

From the remote R2 To restore the production database from a remote R2 device on the backup server:

1. Detach or drop the specified database first.



3. Restore devices from R2 to R1, with the following SRDF command on the R1 host:

symrdf -g DbDgName restore

4. Once the device group is restored, split the RDF link with the following SRDF command:


5. Mount the file systems used by the specified database with the following command:

symntctl mount

6. Restore the specified databases with a TF/SIM SQL snapshot:



The production restore operation from the remote R2 on the backup server is complete.



Backing up multiple databases remotely (tsimsnap2)You can backup multiple SQL Server databases on a Windows server using one TF/SIM command. The TF/SIM command tsimsnap2 backup -ph produces an exact copy of the databases on the standby or backup server.

The tsimsnap2 backup -ph command is issued from the remote backup host. The TF/SIM backup operation:

◆ Detach the standby databases from the standby SQL Server, if needed.

◆ Unmount all the file systems used by the standby databases, if needed.

◆ Establish BCV/RDF devices and wait until all the devices used by the database get synchronized, or create the local/remote virtual copy session for all devices used by the specified databases.




• For TimeFinder/Mirror, it performs an automatic TimeFinder/SRDF split of the devices associated with the specified databases.

• For TimeFinder/Snap, it activates the local/remote virtual copy session for the devices used by the specified databases (only if the virtual copy session has not yet been created).

◆ Mount the file system used by the databases, if needed.

◆ Restore the databases into recovery/standby/recovery mode to the standby SQL Server, if needed.

This TF/SIM command backs up or restores multiple databases for a stand-alone or a clustered Windows SQL Server instance that reside on Symmetrix devices. The backup operation consolidates the backup timeframes by concurrently backing up multiple databases together. Once you have backed up an exact copy of the production devices that hold the SQL Server information (data and logs), you can perform database or filegroup restore actions on any or all databases

Backing up multiple databases remotely (tsimsnap2) 185

186


when needed. The backup operation writes information about the specific databases in metafiles stored in the specified meta directory. The default file names take on the form DbName_snapshot.dmp for the various meta files in this directory.

The command, issued from the backup host, automatically writes metadata information about the specific databases in the specified directory. Metadata information is normally measured in kilobytes, so it is not necessary to have additional storage.


Running a TF/SIM backup using SRDFBefore backing up multiple database remotely, make sure all the devices used by the databases are in split mode.

◆ In an SRDF environment, R2 devices must be split from R1 devices if the backup is an -rdf backup; otherwise, the R2 devices need to remain synchronized if it is a -rbcv backup.

◆ In a BRBCV environment, the standard devices must be split from their BCV devices, the R2 devices must be split from their BCV devices, and the R2 BCV devices must be split from their R2 devices.

◆ In a virtual snap environment, VDEV devices must be visible to the backup server.

◆ In a remote virtual snap environment, VDEV devices must be visible to the backup server and R2 devices must be synchronized with R1 devices.


tsimsnap2 backup -alludb | -d SqlDbName SqlDbName... -ph HostName



You can target all user databases in your database instance with the -alludb option, or you can specify a series of databases with the -d option. There is no limit on the number of the databases to be backed up. You need to consider the appropriate number of the databases to be backed up according to the host CPU and memory resource availability.

Also, you can specify to overwrite any existing database dump files, using the -overwrite option.


You can specify to update the BCV/R2/R2BCV/BRBCV and mount the file system on the backup server for tape backup, using the -mountonly option. If the file systems on the BCV/R2/R2BCV/BRBCV were not mounted before running the TF/SIM command, the TF/SIM will not mount the file system with the -mountonly switch.

You can specify to update the BCV/R2/R2BCV/BRBCV, mount the file system on the backup server, and restore the database into norecovery mode, or recovery mode, or standby mode, using the appropriate option (-norecovery, or -recovery, or -standby).

Note: If the same drive letter assignment is not available on the backup host, use the -relocate option with either the -norecovery, -recovery, or -standby option, along with the new drive letter/mount point. TF/SIM will mount the file system with the new driver letter mount point and restore the database with relocation on the backup host.

Note: If either the -norecovery, the -recovery, or the -standby option is used, the metadata file must be able to locate on one of the file systems the production database it is using. This enables the database restore process local access to the metadata file on the backup server, without having to access the network drive.

Backing up multiple databases remotely (tsimsnap2) 187

188


Backing up SQL Server instance remotely (tsimsnap2)You can backup all databases from the SQL Server Instance (except tempdb) on a Windows server using the TF/SIM command. The TF/SIM command tsimsnap2 backup -instance -ph produces an exact copy of the all databases from the production SQL Server Instances on the standby or backup server.

The tsimsnap2 backup –instance -ph command is issued from the remote backup host. The TF/SIM backup operation:

◆ If there is any service that is dependent on SQL Server and –scm switch is used, TF/SIM prompts you to shut down all services that are dependent on SQL Server. If you do not want to see the prompt, specify –noprompt.

◆ Shut down the standby SQL Server if it resides on the BCV devices used by the production database and the switch –scm is provided.

◆ Umount all file systems used by the SQL Server instance.

◆ Establish BCV/RDF device pairs used by the SQL Server instance.

◆ Wait until all devices are synchronized, suspend the databases I/O, split the devices, resume the databases I/O.

◆ Mount all file systems on the backup server.

◆ Startup the SQL Server instance on the backup server if the switch –scm is provided. If –detachudb switch is provided, startup the SQL Server service with –T3608.

◆ Detach all user databases from the standby SQL Server instance depending on whether the switch –detachudb is provided.

◆ Restart SQL Server service normally if –scm switch is provided.

◆ Start up the services that are dependent on SQL Server if they were shutdown by TF/SIM before.

The backup operation writes information about the specific databases in metafiles stored in the specified meta directory. The default file names take on the form DbName_snapshot.dmp for the various meta files in this directory. The command, issued from the backup host, automatically writes metadata information about the specific databases in the specified directory. Metadata information is



normally measured in kilobytes, so it is not necessary to have additional storage.

The command performs an automatic TimeFinder/Mirror local/remote BCV or RDF split of the devices associated with the SQL Server instance, during the database write suspension period. The backup process splits the production and standby devices while they are in online mode (Hot Split). TF/SIM verifies that the TimeFinder/Mirror instant split feature is supported by all Symmetrix arrays used by the database. If supported (Enginuity version 5x67 and later), the instant split behavior assists the Hot Split action.

Running a TF/SIM instance backup using SRDFIf the standby SQL Server instance needs to be setup, an exact same configuration needs to be used on the standby SQL Server as the production SQL Server. Before running an instance backup operation, make sure all the devices used by all the databases from the SQL Server Instance are in split mode. In an SRDF environment, R2 devices must be split from R1 devices. In a remote BCV environment, R2 BCV devices must be split from R2 devices, and R2 devices must be synchronized with R1 devices.

To backup Microsoft SQL Server instance, use the following form:

tsimsnap2 backup –instance -ph HostName

You can specify to overwrite any existing database dump files, using the -overwrite option.


You can specify to update the BCV/R2/R2BCV/BRBCV and mount the file system on the backup server for tape backup, using the -mountonly option.

If the –scm option is used, the metadata file must be able to locate on one of the file systems the production database it is using. This enables the database restore process local access to the metadata file on the backup server, without having to access the network drive.

The –detachudb option allows you to recover a user database into a mode other than the recovery. To do this, TF/SIM must make sure that there is no user database in the SQL Server database catalog. This can be done only after the Hot Split, as the master database from the

Backing up SQL Server instance remotely (tsimsnap2) 189

190


backup server is copied over from the production host. If you do not provide the –scm switch, TF/SIM does not shut down the SQL Server instance. In which case, it is your responsibility to shut down SQL Server before proceeding with the instance backup remotely.



SQL backup and restore methods (tsimsnap/tsimsnap2)There are many task sequences and command options in SQL, TF/SIM, and TimeFinder management utilities for you to choose to initialize and restore a database. In some cases, a site may have multiple BCVs, which translates into multiple copies. Some sites may want to have total control over recovery and perform these tasks in a very controlled and methodical manner. Other sites prefer executing a command and letting a program automatically handle the recovery.

This section presents some additional recovery methods (not previously described) you might use or optimize that best meets your needs.

This section describes how to use TF/SIM to automate recovery tasks, including the following:

◆ Initializing and updating the standby database

◆ Initializing an instantaneous database backup on a local BCV and restoring it for disaster recovery

◆ Initializing an instantaneous database backup on a virtual snap and restoring it for disaster recovery

◆ Database filegroup backup and restore considerations and scenarios for disaster recovery

Initializing and updating the standby databaseThe combination of the point-in-time BCV backup copy of the database and the metadata file can be used to initialize the standby database instantaneously. After the standby database has been initialized on the BCV host, it can be updated by either TimeFinder/Mirror log shipping or network log shipping. (Log shipping feeds transaction log backup files from a source database to the destination database, keeping them synchronized).

The tsimsnap backup command suspends writes to a database and automatically writes metadata information about the specific database. It also performs an automatic TimeFinder/Mirror split of the devices associated with the database. You enter a database name and filename where the metadata information will reside.

SQL backup and restore methods (tsimsnap/tsimsnap2) 191

192


The following steps initialize a standby database for the BCV host. If the file system has not been mounted on the BCV host, start at step 5:

Note: The following steps can be done with a single command: tsimsnap restore -d DbName -f MetaFileName -ph HostName -standby

1. On the BCV host, detach the standby database using the SQL command sp_detach_db dbname or SQL Server Enterprise Manager.

2. Unmount the standby database file systems with the following SIU command:


If Windows dynamic disks are used, use the -nolock option with this command.

3. If Veritas dynamic disks are used, deport the disk group used by the databases on BCV host with the following command:


4. Establish the devices used by the databases with the following TimeFinder/Mirror command:



symntctl rescan6. Once the device group is synchronized, run the following

TF/SIM backup command on the standard host to get a point-in-time backup of the production database:

tsimsnap backup -d DbName -f MetaFileName

7. If Veritas dynamic disks are used, rescan the disks and import the disk group on the BCV host with the following SIU commands:

symntctl rescanvxdg import -g DgName -C

8. Mount the file systems used by the database on BCV host with the following command:

symntctl mount -drive DriveLetter -vol VolName[-dg DgName]



9. Run the following TF/SIM restore action in manual mode to restore the standby database with snapshot:

tsimsnap restore -d DbName -f MetaFileName -m -standby

After the standby database is initialized on the BCV host, you can update it by shipping the transaction log from the production database. This can be done by either network log shipping using the SQL Server maintenance plan or by TimeFinder/Mirror log shipping. To ship the transaction log (update), use the following TimeFinder/Mirror and SIU commands:

1. Establish the device group used by the transaction log backup device with the following command:



symntctl rescan

3. After the device group is synchronized, use the SQL Server Enterprise Manager or SQL command to back up the transaction log to the transaction backup device from the standard or production host as shown in Figure 21.

Note: You must choose how often the standby database will be updated and how often the transaction log is backed up.

Figure 21 Updating standby database using BCV transaction backup

2

1

3

ProductionDatabase

ProductionLogs

Log BackupDevice

BCVDatabase

BCVLogs

BCVLog Backup

Device


194


4. Flush the file system used by the transaction log backup device from the standard host with the following command:

symntctl flush -drive DriveLetter: | -path MountPoint

5. Split the transaction log backup device with the following TimeFinder/Mirror command:


6. If Veritas dynamic disks are used, rescan the disks and import the disk group on the BCV host with the following SIU commands:

symntctl rescanvxdg import -g DgName

7. From the BCV host, mount the transaction log backup device with the following SIU command:


8. From the BCV host, use the SQL Server Enterprise Manager or the SQL command to restore the transaction log backup file to update the standby database.

9. Unmount the file system from the BCV host with the following SIU command:


If Windows dynamic disks are used, use the -nolock option with this command.

10. If Veritas dynamic disks are used, deport the disk group used by the databases on the BCV host with the following command:


11. Repeat steps 1 through 7 to update the remaining standby databases.

The standby databases are now initialized and updated.



Initialize/recovery of backup database on local BCVYou can create an instantaneous database backup to have the local BCV available for disaster recovery (restore) operations. If you are splitting off a local BCV and do not plan on using the copy as a standby database, you can choose the metadata location to be a normal device on the standard host. The metadata file can be written to either a Symmetrix mirrored device or a local disk on the host. This is important for restore purposes in automatic mode as the file must be available to read at all times. Part of the restore process unmounts the file systems on which the database resides. This procedure temporarily makes the file unavailable. For this reason, you should keep the metadata information in more than one place. Typically, the general file size is in kilobytes, so storage should not be an issue.

The tsimsnap backup suspends writes to a database and automatically writes metadata information about the specific database. It also performs an automatic TimeFinder/Mirror split of the local BCV devices associated with the database. You can enter a database name and filename where the metadata information will reside. After tsimsnap backup completes, keep frequent backups of the database transaction log to reduce recovery time.

The following steps initialize the backup database on the local BCV:

1. Establish the device groups used by the production database with the following TimeFinder/Mirror command:


2. After the device group is synchronized, perform a TF/SIM backup to get a point-in-time back up of the production database:

tsimsnap backup -d DbName -f MetaFileName

At this point, the file systems used by the database on the BCV host can be mounted to be backed up from disk to tape or other media.

3. Back up the additional transaction log from the production database in the scheduled time interval.

If at some point for a point-in-time recovery, the production database becomes corrupt, analyze the time of the corruption and back up the trailing transaction log from the production database. Unmount the file systems used by the BCV devices on the BCV host if they have been mounted. Use symntctl openhandle to see if there is any


196


process or service other than SQL Server that holds the filesystem handles used by the production database. Stop those processes or services if they are holding file system handles:

1. Run the following TF/SIM restore command in automatic mode to restore the corrupt database to the previous point-in-time of the database back up with snapshot in standby mode:

tsimsnap restore -d DbName -f MetaFileName -standby

If the production database is running on top of MSCS or you want to take control of every step during the restore process, the following procedure can be used on the standard host:

a. Detach or drop the corrupt database.

b. Unmount the file systems with the following SIU command:



c. Restore the BCV back to standard devices with the following TimeFinder/Mirror restore command:


d. After the device group is restored, split the device group with the following command:


e. Mount the file systems used by the database with the following command:


f. Run the following TF/SIM restore command in manual mode to restore the production database with snapshot in standby mode:


2. Restore additional transaction log backups to the standby and stop the transaction log recovery database with standby mode. Restore the last transaction log backup before the point-in-time of the database corruption. Make the restored database read/write.



3. Once restore is successful, resync the device group and issue tsimsnap backup to get a new point-in-time backup of the production database for disaster recovery.

Initialize/recovery of backup database on virtual snapYou can create an instantaneous database backup to have the VDEV available for disaster recovery (restore) operations. The metadata file can be written to either a Symmetrix mirrored device or a local disk on the host. This is important for restore purposes in automatic mode as the file must be available to read at all times. Part of the restore process unmounts the file systems on which the database resides. This procedure temporarily makes the file unavailable. For this reason, you should keep the metadata information in more than one place. Typically, the general file size is in kilobytes, so storage should not be an issue.

The tsimsnap backup -snap suspends writes to a database and automatically writes metadata information about the specific database. It also automatically activates the virtual copy session to the local VDEV devices associated with the database. You can enter a database name and filename where the metadata information will reside. After tsimsnap backup completes, keep frequent backups of the database transaction log to reduce recovery time.

The following steps initialize the backup database on the VDEV:

1. Create the virtual copy session for the device groups used by the production database with the following TimeFinder/Snap command:


2. After the virtual copy session is enabled, perform a TF/SIM backup to get a point-in-time back up of the production database with the following command:

tsimsnap backup -d DbName -f MetaFileName -snap

3. Back up the additional transaction log from the production database in the scheduled time interval.

If at some point for a point-in-time recovery, the production database becomes corrupt, analyze the time of the corruption and back up the trailing transaction log from the production database. Unmount the file systems used by the VDEV devices if they have been mounted to


198


any host. Use symntctl openhandle to see if there is any process or service other than SQL Server that holds the filesystem handles used by the production database. Stop those processes or services if they are holding file system handles.

1. Run the following TF/SIM restore command in automatic mode to restore the corrupt database to the previous point-in-time of the database back up with snapshot in standby mode:

tsimsnap restore -d DbName -f MetaFileName -standby -snap

If the production database is running on top of MSCS or you want to take control of every step during the restore process, the following procedure can be used on the standard host:

a. Detach or drop the corrupt database.

b. Unmount the file systems with the following SIU command:



c. Restore the VDEV back to standard devices with the following command:

symsnap -g DgName restore

d. Mount the file systems used by the database with the following command:

symntctl mount -drive DriveLetter -vol VolName [-dg DgName]

e. Run the following TF/SIM restore command in manual mode to restore the production database with snapshot in standby mode:


2. Restore additional transaction log backups to the standby and stop the transaction log recovery database with standby mode. Restore the last transaction log backup before the point-in-time of the database corruption. Make the restored database read/write.

3. Once restore is successful, terminate the old virtual copy session with the following command:

symsnap -g DgName terminate



4. Create a new virtual copy session with the following command:


5. Issue tsimsnap backup to get a new point-in-time backup of the production database for disaster recovery.

Database filegroup backup and recovery A filegroup backup/restore operation can dramatically reduce the overall backup/recovery time if well planned. A complete database filegroup backup set and transaction log backup chain are needed to restore the database to the consistent state. The complete filegroup backup set for a database can come from a TF/SIM database backup operation, and from an individual TF/SIM filegroup backup operation.

After getting the complete filegroup backup set, you can update a specific filegroup depending on the amount of data changed in the filegroup to reduce the recovery time in case of any failure in the production database. However, by doing that, the integrity of the database backup may be destroyed if the same BCV pair has been used for that case. The only way to restore the database is to use an individual filegroup restore. To restore a specific filegroup from the database backup, specify the metadata file created by them when using:

tsimsnap restore -d DbName -fg FileGrpName -f MetaFile

There are basically two scenarios for filegroup restore: database corruption and media failure. In both cases, we assume that the complete filegroup backup set has been created and the transaction log backup chain has been maintained.

◆ Database Corruption

In the case of database corruption such as table truncation and logical database corruption, backup the trailing transaction log from the production database. In this case, the transaction log backup includes the transactions that corrupt the database, therefore, a restore to the point-in-time before the corruption is needed to recover the database. Restore the complete filegroup backup set by restoring each filegroup separately using tsimsnap restore -fg (in manual or automatic mode); then restore with


200


no recovery the transaction log backup chains that cover the first filegroup backup, and restore with recovery the last transaction log backup (to the point-in-time before the corruption).

◆ Media failure

When a disk in a specific filegroup gets damaged, back up the trailing transaction log from the damaged database. If the database gets into suspect mode:

• Run the SQL command backup log with no_truncate to back up the active portion of the log without truncating it.

• Replace the damaged disk and recreate the file system on that disk.

• Restore that specific filegroup by executing tsimsnap restore -fg (in automatic mode for basic disks in a non-clustered environment only).

• Restore additional transaction log backup versions that include the time frame after the specific filegroup backup with no recovery.

• Restore the last transaction log backup with recovery to bring the database back to a consistent state.

Filegroup backup/restore considerationsIn a filegroup backup/restore scenario consider the following:

◆ The database needs to be in the full recovery mode. Unlike tsimsnap backup for a full database, log writes are not suspended, so it is necessary to do a transaction log backup from the Enterprise Manager or with Transact SQL.

◆ All devices used by the specific filegroup must be in a synchronized state before running tsimsnap backup -fg (devices used by the filegroup may exist in single or multiple Symmetrix device groups).

Note: To allow greater flexibility and granularity, put all filegroup data files in their own Symmetrix device group and put the log files in a separate device group.

◆ To leverage the ability to restore single filegroups, only files from a single filegroup should exist on Symmetrix logical devices.



◆ TF/SIM operations must be performed on the same SQL Server host targeted for backup/restore as remote snapshot backup/restore is not supported.

Filegroup best practice backup and restore examplesThe following example scenarios illustrate the best practices for implementing backup and restore operations assisted with TF/SIM. In these scenario examples, we are managing database emcdb, which includes three filegroups, primary, emcdb_fg1, emcdb_fg2, and log files. The database is in the full recovery mode (Figure 22).

Figure 22 Filegroup backup example environment

BCVSTD

BCVSTD

BCVSTD

BCVSTD

BCVSTD

BCVSTD

SSPI-000004

Productiondatabases

BCVdatabase copy

FilegroupPrimary

Filegroupemcdb_fg1

Filegroupemcdb_fg2

Log


202


Table 8 shows the components of the example database emcdb.

Backup scenario 1For backup scenario 1, you need to back up the full database with tsimsnap backup, and then use tsimsnap backup -fg to back up the individual filegroup during the week (Figure 23 on page 203).

1. Create a full database backup every Sunday at 12:00 midnight with the following command:

tsimsnap backup -d emcdb -f c:\metadata\emcdb.dmp

2. Back up the transaction log every 15 minutes (Enterprise Manager or Transact SQL) with the following command:

3. Back up filegroup emcdb_fg1 Monday at midnight (updated frequently) with the following command:

tsimsnap backup -d emcdb -fg emcdb_fg1 -f c:\metadata\emcdb_fg1.dmp

Note: This backup overwrites the BCV copy of the filegroup created by the previous full database backup.

4. Back up the transaction log every 15 minutes (Enterprise Manager or Transact SQL).

5. Back up filegroup emcdb_fg2 Wednesday at midnight (updated frequently) with the following command:


Note: This backup overwrites the BCV copy of the filegroup created by the previous full database backup.

Table 8 Filegroup backup example environment

Filegroup name Description

Primary One file on one Symmetrix device.

emcdb_fg1 Three files on two Symmetrix devices. Each Symmetrix device contains only files from filegroup emcdb_fg1.

emcdb_fg2 Three files on two Symmetrix devices. Each Symmetrix device contains only files from filegroup emcdb_fg2.

Log files Two files on one Symmetrix device.




7. Back up the filegroup primary Thursday at midnight (updated frequently) with the following command:

tsimsnap backup -d emcdb -fg Primary -f c:\metadata\emcdb_primary.dmp

Note: This back up overwrites the BCV copy of the filegroup created by the previous full database backup.

Figure 23 Database backup schedule for example scenario 1

In the following scenarios, the filegroup name and metadata file names vary depending on when the corruption occurs.

Restore 1 of scenario 1In the following restore 1 of scenario 1, corruption in filegroup emcdb_fg1 was discovered at 10:00 AM on Tuesday morning:

1. Back up the trailing transaction log.

2. Restore all individual filegroups one at a time with the following commands:

tsimsnap restore -d emcdb -fg Primary -f c:\metadata\emcdb.dmptsimsnap restore -d emcdb -fg emcdb_fg1 -f c:\metadata\emcdb_fg1.dmptsimsnap restore -d emcdb -fg emcdb_fg2 -f c:\metadata\emcdb.dmp

3. Restore all transaction log backups that were created since Sunday 12:00 PM.

4. Restore the transaction log created at the beginning of the restore process, and stop at a point-in-time before the corruption to recover the database into a consistent state.

Data

Full databasebackup

emcdb_fg1 emcdb_fg2Log Log Log Log Log Log Log Log Primary Log LogLog

Filegroupbackup

Filegroupbackup

Filegroupbackup

Sunday Monday Tuesday Wednesday Thursday

SSPI-000005


204


Then, corruption in filegroup emcdb_fg1 was discovered at 10:00 AM on Thursday:



tsimsnap restore -d emcdb -fg primary -f c:\metadata\emcdb.dmptsimsnap restore -d emcdb -fg emcdb_fg1 -f c:\metadata\emcdb_fg1.dmptsimsnap restore -d emcdb -fg emcdb_fg2 -f c:\metadata\emcdb_fg2.dmp


4. Restore the transaction log created at the beginning of the restore process, and stop at the point-in-time before the corruption to recover the database into a consistent state.

Again, corruption was discovered on Thursday night:



tsimsnap restore -d emcdb -fg primary -f c:\metadata\emcdb_primary.dmptsimsnap restore -d emcdb -fg emcdb_fg1 -f c:\metadata\emcdb_fg1.dmptsimsnap restore -d emcdb -fg emcdb_fg2 -f c:\metadata\emcdb_fg2.dmp

3. Restore all transaction log back ups that were created since Monday 12:00 PM.




Restore 2 of scenario 1In the following restore 2 of scenario 1, a media failure on a Symmetrix device used by emcdb_fg1 was discovered at 10:00 AM on Tuesday:


2. Restore filegroup emcdb_fg1:

tsimsnap restore -d emcdb -fg emcdb_fg1 -f c:\metadata\emcdb_fg1.dmp

3. Restore all transaction log backups that were created since filegroup emcdb_fg1 was backed up on Monday at 12:00 PM.

4. Restore the transaction log created at the beginning of the restore process to recover the database into consistent state.

Backup scenario 2For backup scenario 2, we need to back up the full database once a week using tsimsnap backup -fg on each filegroup in the database. Then use tsimsnap backup -fg to back up individual filegroups during the week (Figure 24 on page 206):

1. Create a complete database filegroup backup set every Sunday at midnight with the following commands:

tsimsnap backup -d emcdb -fg primary -f c:\metadata\emcdb_primary.dmptsimsnap backup -d emcdb -fg emcdb_fg1 -f c:\metadata\emcdb_fg1.dmptsimsnap backup -d emcdb -fg emcdb_fg2 -f c:\metadata\emcdb_fg2.dmp


3. Back up filegroup emcdb_fg1 Monday at midnight (updated frequently) with the following command:


Note: This backup overwrites the BCV copy of the filegroup created by previous full database backup.



206


5. Back up filegroup emcdb_fg Wednesday at midnight (updated frequently) with the following command:


Note: This back up overwrites the BCV copy of the filegroup created by previous full database backup.


7. Back up filegroup primary Thursday at midnight (updated frequently) with the following command:

tsimsnap backup -d emcdb -fg primary -f c:\metadata\emcdb_primary.dmp

Note: This backup overwrites the BCV copy of the filegroup created by previous full database backup.

Figure 24 Database backup schedule for example scenario 2

Data

The complete filegroupbackup set

emcdb_fg1 emcdb_fg2Log Log Log Log Log Log Log Log Primary Log LogLog

Filegroupbackup

Filegroupbackup

Filegroupbackup

Sunday Monday Tuesday Wednesday Thursday

SSPI-000006



Restore 1 of scenario 2In the following restore 1 of scenario 2, corruption in filegroup emcdb_fg1 was discovered at 10:00 AM on Tuesday:






Restore 2 of scenario 2In the following restore 2 of scenario 2, corruption in filegroup emcdb_fg1 was discovered at 10:00 AM on Thursday:







208


Restore 3 of scenario 2Then, if the corruption was discovered after the primary filegroup on Thursday night, we would need to do the following:


2. Restore all individual filegroups one at a time with the following command:


3. Restore all the transaction log backups that were created since Monday 12:00 PM.


Restore 4 of scenario 2Again, a media failure on a Symmetrix device used by emcdb_fg1 was discovered at 10:00 AM on Tuesday:


2. Restore filegroup emcdb_fg1:

tsimsnap restore -d emcdb -fg emcdb_fg1 -f c:\metadata\emcdb_fg1.dmp

3. Restore all transaction log backups that were created since filegroup emcdb_fg1 was backed up on Monday at 12:00 PM.

4. Restore the transaction log created at the beginning of the restore process to recover the database into a consistent state.



Restoring a database with VSS (tsimvss)To restore a database to a production SQL Server instance using VSS:

1. Detach the database from the SQL Server instance if -norecovery or -recovery is specified.

2. Dismount the volume from the production host.

3. Restore the devices from the BCV.

4. Wait until the devices are restored, then split the TimeFinder devices.

5. Mount the volume back to the production host.

6. Restore the database with VSS.

Restoring a database with VSS (tsimvss) 209

210



AInvisible Body Tag

This appendix describes the command syntax of the SYMCLI TimeFinder/Integration Modules. The commands appear in the following order:

◆ SYMCLI conventions....................................................................... 212◆ symntctl ............................................................................................. 213◆ ExBackup2003/2007 ........................................................................ 220◆ tsimsnap ............................................................................................ 228◆ tsimsnap2 .......................................................................................... 238◆ tsimvss ............................................................................................... 248

TimeFinder/IMsCommand Reference

TimeFinder/IMs Command Reference 211

212

TimeFinder/IMs Command Reference

SYMCLI conventionsCategories of information shown below (similar to UNIX man pages) are listed for each command, where applicable:

◆ SYNTAX lists the arguments and options for each command.

◆ DESCRIPTION provides a description of the command.

◆ ARGUMENTS explains the command arguments.

◆ OPTIONS explains the command options.

◆ PARAMETERS explains the command parameters.

◆ RETURN CODES specifies the primary success and failure codes for each command.

◆ EXAMPLES provides examples of the syntax and output, if any, of the command.



symntctlThis SIU command integrates and extends the, otherwise limited, Windows 2000 disk management functionality so that it operates with and on the Symmetrix Business Continuance storage devices more effectively.

SYNTAX symntctl -h

symntctllist

-physical [-brief]-volume [-brief]-pd diskN-vol VolName [-dg DgName] [-brief]

signature -pd diskN -sig Signature | -erase | -initialize

mount <-vol VolName [-dg DgName]> | -guid VolGuid |-sid SymId -symdev SymDev-drive DriveLetter -path MountPnt-part Partition

umount [-nolock] [-force]-drive DriveLetter-path MountPnt-vol VolName-guid VolGuid

flush-drive DriveLetter-path MountPnt-vol VolName [-dg DgName]-guid VolGuid

openhandle-drive DriveLetter-path MountPnt-vol VolName [-dg DgName]-guid VolGuid

locks -releaseall-release VolGuid-listall

mask -sid SymID -symdev SymDev [-wwn wwn | -iscsi iscsi]

symntctl 213

214


unmask -sid SymID -symdev SymDev [-wwn wwn | -iscsi iscsi]

symntctl rescan

DESCRIPTION This command integrates and extends the, otherwise limited, Windows 2000 resource management functionality so that it operates with and on the Symmetrix Business Continuance storage devices (volumes) more effectively.

ARGUMENTS flush

Causes all pending unwritten file system entries in cache to be flushed to disk.

list

Lists all visible physical devices or volumes. Or lists specific disk numbers or volume names.

locks

Controls file system locks held on devices typically during TimeFinder/Mirror establish and split operations. Currently, you can only release locks.

mask

Removes access to the specified Symmetrix device on all HBAs on the host where the specified device is visible.

mount

Mounts the specified volume name or GUID to the specified drive letter or mount point.

openhandle

Displays any open sessions (processes) working with the specified drive or mount point. This command is typically called prior to an unmount or split command while running diagnostics.

rescan

Scans the drive connections and discovers any new disks available to the system.



signature

Manipulates the disk signature of a specified disk.

unmask

Adds access to the specified Symmetrix device on all HBAs on the host that are connected to the specified Symmetrix array.

umount

Unmounts the specified volume from the specified drive letter or mount point. The unmount process flushes any pending writes to it and locks the driver from further use.

OPTIONS -brief

Requests an abreviated display of information associated with the specified list action.

-c

Clears the host id.

-dg

Specifies a device group (volume group) as the target for the specified action.

-drive

Specifies a drive as the target for the specified action.

-erase

Erases the signature of the specified disk.

-force

Requests that a volume’s open handles be ignored during the umount. These open handles will not be broken.

-guid

Specifies a volume’s global unique identifier as the target for the specified action.

-initialize

Assigns a signature to any disks found without a signature.

symntctl 215

216


-iscsi

Specifies the ISCSI initiator name.

-listall

Lists all of the locks currently held by the SIU service.

-nolock

Skips the auto-lock behavior in the specified (umount) action.

-path

Specifies a device mount point as the target to the specified action. This directory path (of the form device:\dir) must be empty.

-pd

Specifies a physical disk as the target for the specified action. Note that the host-visible disk identifiers of the form diskN can be viewed with the list -physical command.

-physical

Specifies a drive as the target for the specified action.

-release

Releases the lock on a specified volume, as identified by its GUID.

-releaseall

Releases all file system locks held on devices.

-part

Specifies the partition number on the disk to be mounted.

-sid

Specifies the ID of the Symmetrix array containing the volume on which the action is to be performed.

-symdev

Specifies the ID of the Symmetrix device on which the action is to be performed.



-sig

Writes the signature passed in -sig to the specified disk.

-vol

Specifies a volume name as the target for the specified action.

-volume

Confines the list action to just displaying volume configuration across the system.

-wwn

Specifies the World Wide Name of the HBA.

PARAMETERS DgName

The name of the device group.

diskN

The number of the physical disk in the system of the form diskN.

DriveLetter

The drive letter designation as viewed in the Windows directories (such as E:).

MountPnt

A device mount point or directory path (of the form device:\dir).

Partition

The partition number (greater than, or equal to one) on the Symmetrix device that is to be mounted. If omitted, this value defaults to one. Not valid for dynamic disks.

Signature

An 8-digit hex number for each disk.

SymID

A 2 to 12-digit Symmetrix ID.

SymDev

A 3 to 5-digit Symmetrix device ID.

symntctl 217

218


VolName

The volume name of the device.

VolGuid

The global unique identifier (128-bit integer) of a volume. For example: Volume{d33eea9d6-1320-11d5-b37c-806d6172696f}

RETURN CODES The following are possible status or error codes that can be returned by this command:

0 Command was successful1 Command failed

EXAMPLES To flush any unwritten file system buffers to drive E, enter:

symntctl flush -drive E:

To flush any unwritten file system buffers to mount point E:\drivex, enter:

symntctl flush -path E:\drivex

To flush any unwritten file system buffers to volume volumex, enter:

symntctl flush -vol volumex

To flush a volume with a GUID of Volume{ecba40b5-d522-11d5-98cb-00b0d0b03303}, enter:

symntctl flush -guid Volume{ecba40b5-d522-11d5-98cb-00b0d0b03303}

To list information about the physical configuration of all devices, enter:


To list the physical configuration for disk 3, enter:

symntctl list -pd disk3

The following example output displays after entering symntctl list -vol for volume HarddiskVolume7:

Volume Information

[6] Vol Name: HarddiskVolume7Dev Group:GUID: Volume{ecba40b5-d522-11d5-98cb-00b0d0b03303}Mount Point: 1h:\



Partition:Disk 6, Starting: 0 MB Length: 4494 MB

To release all the locks cached by the SIU service, enter:

symntctl locks -releaseall

To mount a basic volume called volumex to drive x, enter:

symntctl mount -drive x -vol volumex

To mount a dynamic volume called volumex of devicegroupx to mount point x:\volumex, enter:

symntctl mount -path x:\volumex -vol volumex -dg devicegroupx

To mount a volume with the a GUID of Volume{ecba40b5-d522-11d5-98cb-00b0d0b03303} to drive x, enter:

symntctl mount -drive x -guid Volume{ecba40b5-d522-11d5-98cb-00b0d0b03303}

To unmount a volume associated with drive x, enter:

symntctl umount -drive x

To unmount a volume called volumex of devicegroupx, enter:

symntctl umount -vol volumex -dg devicegroupx

To unmount a volume with a GUID of Volume{ecba40b5-d522-11d5-98cb-00b0d0b03303} from drive x, enter:


To change the signature of disk 4 to 1ED67A70, enter:

symntctl signature -pd disk4 -sig 1ED67A70

To erase the signature of disk 4, enter:

symntctl signature -pd disk4 -erase

To initialize the signature of all disks that have 0 for their signatures, enter:

symntctl signature -initialize

symntctl 219

220


ExBackup2003/2007The ExBackup2003 command is for Windows 2000/2003 Servers, this TF/EIM command backs up a single or a clustered Exchange 2003 Server.

The ExBackup2007 command is for Windows 2003 Servers, this TF/EIM command backs up a single or a clustered Exchange 2007 Server.

SYNTAX TimeFinder/Mirror-specific command options

ExBackup2003 | ExBackup2007 <-s ServerName>[-sg StorGroup] [-o OutFile] [-test] [-scc] [-nologdelete] [-v] [-h][-hot | -instant] [-full] [-multi] [-preestablish][-protbcvest][-rbcv]

Clone-specific command options

ExBackup2003 | ExBackup2007 <-s ServerName>[-sg StorGroup] [-o OutFile] [-test] [-scc] [-nologdelete] [-v] [-h][-clone | -rclone]

Snap-specific command options

ExBackup2003 | ExBackup2007 <-s ServerName>[-sg StorGroup] [-o OutFile] [-test] [-scc] [-nologdelete] [-v] [-h][-snap] [-svp PoolName]

SRDF-specific command options

ExBackup2003 | ExBackup2007 <-s ServerName>[-sg StorGroup] [-o OutFile] [-test] [-scc] [-nologdelete] [-v] [-h][-rbcv | [-brbcv] | -rclone]

Open Replicator-specific command options

ExBackup2003 | ExBackup2007 <-s ServerName>[-sg StorGroup] [-o OutFile] [-test] [-scc] [-nologdelete] [-v] [-h][-orf DevFile [-orsdiff]] [-pace Pace]

VSS-specific command options

ExBackup2003 | ExBackup2007 <-s ServerName>[-sg StorGroup] [-o OutFile] [-test] [-scc] [-v] [-h][-vss [-copyonly] | -vssdiff] [-bcd BcdFile] [-wmd WmdFile][-cleanup] [-rw]

ExBackup2003 |ExBackup2007 restore [-db Database | -logs]



DESCRIPTION This command for Windows with Exchange Servers, produces an exact copy of the production devices that hold the Exchange Information (data and logs). With the valid backup copy, you can perform both full and single mailbox restores when needed.

ARGUMENTS None.

OPTIONS -bcd

Specifies the name of the backup components document XML files (requires VSS). These files are created during backups and are required for restores. For backups, a default filename will be used if one is not specified.

-brbcv

Specifies that BCVs should be used on the remote Symmetrix array for this SRDF backup.

-cleanup

For VSS only. Performs a cleanup of the backup server after a VSS failure. Includes splitting of BCVs, unmasking of devices, and clearing of volume flags with VDS.

-clone

Uses EMC TimeFinder/Clone to perform the operation.

-copyonly

Specifies a copyonly backup. A copyonly backup backs up the Exchange log files, and does not truncate the transaction logs. This option can only be used with VSS.

-db

Specifies the name of an individual database to be restored. Multiple databases can be specified by using this option multiple times in a single command. This option cannot be combined with the -logs option.

-f

Specifies an initialization file that lists multiple production server names to be involved in the backup operation.

ExBackup2003/2007 221

222


-full

Performs a full establish on all BCVs in the backup.

-h

Provides brief, online help information.

-hot

Specifies that a Hot Split will be performed in the backup operation, where TF/EIM performs an online snapshot of the Exchange database (Exchange is not stopped before the split). The split is assisted with the TimeFinder/Mirror instant split behavior.

-instant

Specifies an instant split be performed (as opposed to a normal split) on the production/BCV pair (for Symmetrix Enginuity version 5x67). Not required when the -hot option is being specified or for 5x68 or later. Instant split behavior is the default mode for Symmetrix 5x68 Enginuity levels and later.

-logs

During a restore, this option specifies that the transaction logs will be restored in addition to the databases. This option cannot be combined with the -db option.

-multi

Uses multiple BCVs in a rotating fashion (oldest first).

-nologdelete

Specifies that TF/EIM is not the manager of the production server transaction logs. No logs will be deleted by TF/EIM.

-o

Specifies a program output file to record backup activity.

-orf

Specifies the device file for the Open Replicator operation.



-orsdiff

Specifies a differential operation. This option can only be used with -orf.

-pace

Sets the pace for the Open Replicator operation. Values range from 0 to 9, with 0 being the fastest pace, and 9 being the slowest pace.

-preestablish

Specifies that all devices must be in synchronized mode before any backup operation. Clone devices must be in the created or recreated state.

-protbcvest

Performs a protected BCV establish on all BCVs in the backup set. All BCVs in the backup set must be mirrored internally.

restore

This action is used to perform a VSS restore. This option requires the -vss, -bcd, and -wmd options.

-rclone

Specifies that the operation will be performed on remote clone devices.

-rw

Specifies that the READONLY flags should be cleared from all BCVs/VDEVs, thus making them read-write.

-s

Performs sequential Exchange database consistency checks when backing up multiple Exchange databases that share the same LUNs.

-scc

Performs sequential Exchange database consistency checks when backing up multiple Exchange databases that share the same LUNs.

ExBackup2003/2007 223

224


-sg

Targets a specific storage group to back up.

-sid

Specifies the ID of the Symmetrix array on which the action is to be performed.

-snap

Use EMC TimeFinder/Snap to perform the snapshots.

-svp

Specifies a particular SAVE device pool that TF/EIM should use for it’s snap operations. Requires the -snap option.

-test

Specifies that the backup command execution entered on the command line is a test and will not execute any controls on devices, BCV devices in the database and not actually start the backup processes (such as establishing BCV pairs or dismounting devices). Only the command validation and checking elements are performed (such as checking Enginuity levels or Exchange versions).

-v

Provides a more detailed, verbose listing.

-vss

Specifies that VSS should be used to create the snapshot. The use of VSS will enforce the -multi switch because VSS assumes multiple BCVs by default. This option is only available on Windows 2003.

-vssdiff

Specifies a VSS Differential Snapshot backup.

-wmd

Specifies the name of the Writer Metadata Document XML file (requires VSS). This file is created during backups and is required for restores. For backups, a default filename will be used if one is not specified.



PARAMETERS BcdFile

The name of the Backup Components Document XML file that the TF/EIM should use for VSS operations.

ClustServer

An MSCS cluster name for the backup operation.

Database

The name of an individual database to be restored.

DevFile

The device file.

InitFile

Initialization file name that contains a list of multiple production server names involved in the backup operation.

OutFile

Program output file name to record backup activity.

Pace

Sets the pace value for the session.

PoolName

The name of the TimeFinder/Snap SAVE device pool to be used by TF/EIM.

ServerName

An Exchange server name for the backup operation.

StorGroup

The storage group name to be backed up.

SymID


WmdFile

The name of the Writer Metadata Document XML file that the TF/EIM should use for VSS operations.

ExBackup2003/2007 225

226


RETURN CODES Upon success, the command returns a zero. For various failures and warnings, the command returns a non-zero value. For further information about all possible return codes, refer to header file (ExBackup2003Err.h or ExBackup2007.h) in the TF/EIM directory.

EXAMPLES To back up an Exchange 2003 server in verbose mode, enter:

ExBackup2003 -s ExchangeServerName -v -vss | -nologdelete

To back up a single storage group, Ex1, on the Exchange 2003 server named Ex1 using instant splits, enter:

ExBackup2003 -s ExchangeServerName -sg SG1 -instant -vss |-nologdelete

To back up a single virtual server, Ex1, of the clustered Exchange 2003 server named Excsl in verbose mode, enter:

ExBackup2003 -s ExchangeServerName -v -vss | -nologdelete

To test a Hot Split backup of a single server, Ex1 in verbose mode, enter:

ExBackup2003 -s ExchangeServerName -hot -v -test -vss | -nologdelete

To perform a TimeFinder/Snap backup of server Ex1, while specifying the SAVE device pool to use, enter:

ExBackup2003 -s ExchangeServerName -hot -snap -svp MailDevs -v -vss | -nologdelete

To restore a storage group named Sg1 on an Exchange 2003 server named Ex1 using EX1_BCD.xml and EX1_WMD.xml as the XML data, enter:

ExBackup2003 -s ExchangeServerName -sg Sg1 -vss restore -bcd EX1_BCD.xml -wmd EX1_WMD.xml -v

Back up Exchange databases in an SRDF environment (R1 > R2 > RBCV)

This environment supports both local and remote VSS backups.

To create a local VSS backup to local BCV devices on the R1 side enter:

Exbackup2003 –v –vss –s ExchangeServerName

To create a remote non-VSS backup to the RBCV device enter:

Exbackup2003 –v –nologdelete –s ExchangeServerName –rbcv

To create a remote VSS backup to the remote clone device, enter:

Exbackup2007 –v -vss –nologdelete –s ExchangeServerName –rclone



Note: If the R1 and R2 devices are synchronized when the backup command is issued, TF/EIM will only establish and split the R2 and their RBCV devices

(STD > R1BCV > R2 > BRBCV environment)

This environment supports both local and remote VSS backups.

Note: In the case of remote VSS backups, the VSS snapshot is taken on the R1BCV device and shipped to the R2 and then to the BRBCV.

To create a local VSS backup enter:

Exbackup2007 –v –vss –s ExchangeServerName

To create a VSS backup on the BRBCV device enter:

Exbackup2007 –v –vss –s ExchangeServerName –brbcv

To create a non-VSS backup to the BRBCV device enter:

Exbackup2003 –v –nologdelete –s ExchangeServerName –brbcv

Back up Exchange databases with VSS Differential and Copyonly flags

To create a VSS Differential backup enter:

Exbackup2003 –v –vssdiff –s ExchangeServerName

To create a VSS Copyonly backup enter:

Exbackup2007 –v –vss –s ExchangeServerName –copyonly

Back up Exchange databases with Clone devices

To create a VSS backup on Clone devices, create or recreate the Clone devices and enter:

Exbackup2007 –v –vss –s ExchangeServerName –clone

To create a VSS Differential backup on Clone devices, create or recreate the Clone devices and enter:

Exbackup2003 –v –vssdiff –s ExchangeServerName –clone

To create a VSS Copyonly backup on Clone devices, create or recreate the Clone devices and enter:

Exbackup2007 –v –vss –s ExchangeServerName –copyonly -clone

ExBackup2003/2007 227

228


tsimsnapFor a stand-alone or a virtual clustered Windows server, this TF/SIM command can back up or restore a Microsoft SQL Server database.

SYNTAX To create a snapshot of the database on a standard host:

tsimsnap backup -d SqlDbName [-fg FileGrpName]-f MetaFile[-both_side | -both_side -snap | -clone | -concurrent| -nrtgt |-rbcv | -rclone | -rsnap -bh BackupHostName | -rdf | -snap] [-skip] [-copyonly] [-nocatalog] [-t Interval] [-overwrite] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

To create a snapshot of the database on a backup host:

tsimsnap backup -d SqlDbName [-fg FileGrpName]-f MetaFile [-protbcvest] -ph Hostname[-ps VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

[-brbcv | -clone | -multi | -rbcv | -rclone | -rdf][-skip] [-copyonly] [-nocatalog] -nomount |-mountonly | -norecovery | -recovery | -standby [-relocate] [-overwrite] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]


[-concurrent | -nrtgt] [-skip] [-copyonly][-nocatalog] -nomount | -mountonly [-overwrite] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]


-rsnap | -snap [[-sid Symid] -svp PoolName ...][-skip] [-copyonly] [-nocatalog] -nomount | -mountonly[-overwrite] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]



To migrate the database to another Symmetrix or CLARiiON array from the backup host:

tsimsnap backup -d SqlDbName[-fg FileGrpName]-f MetaFile[-snap | -clone] -orf DevFileName [-orsdiff][-skip] [-copyonly] [-nocatalog] -nomount| -mountonly | -norecovery | -recovery | -standby[-t Interval] [-overwrite] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

To restore a database with snapshot running on a standard host for disaster recovery:

tsimsnap restore -d SqlDbName -f MetaFile[-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]] [-protbcrest][-noprompt] -norecovery | -recovery | -standby

tsimsnap restore -d SqlDbName -fg FileGrpName-f MetaFile [-snap | -protbcvrest] [-partial][-noprompt] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

To restore a database with snapshot running tsimsnap restore manually with SQL restore only:

tsimsnap restore -d SqlDbName -f MetaFile -m[-rf RelocateFileName] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]-norecovery | -recovery | -standby

tsimsnap restore -d SqlDbName -fg FileGrpName[-partial] -f MetaFile -m [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

DESCRIPTION This TF/SIM command backs up or restores a Microsoft SQL Server database for a stand-alone or a clustered Windows server. Both the backup and restore actions can be confined to a specified filegroup name in the database.

You can confine the backup to a specific filegroup name within the specified database, using the -fg option. On the production server, using the -s option, you can target a specific:

◆ Virtual SQL Server name with or without an instance name, or◆ Host name with or without an instance name.

tsimsnap 229

230


In a TimeFinder environment, you can use the -nrtgt option to make the BCV devices not ready after a TimeFinder/Mirror split.

You can specify to use the oldest available BCV pair for backup, using the -multi option.

You can specify to use all BCV pairs for backup, using the -concurrent option.

In a SRDF environment, you can use the -rbcv option to split the remote BCV from its R2 mirror, or use the -rdfsplit option to split the R2 from the R1 device.

In a virtual snap environment, you can use the -snap option to activate a virtual copy session.

In a remote virtual snap environment, you can use the -rsnap option to activate a virtual copy session. The -bh BackupHostName option is required to specify the host that can see either the R2 devices, or the remote VDEVs. If the Symmetrix array is running Enginuity version 5x71 or later, the -bh option is not required.

You can specify to overwrite any existing database dump file, using the -overwrite option.

Once you have backed up an exact copy of the production devices that hold the SQL Server information (data and logs), you can perform database or file group restore actions when needed.

The TF/SIM local backup operation:




• For TimeFinder/Mirror, it performs an automatic TimeFinder/Mirror SRDF split of the devices associated with the database/filegroup.

• For TimeFinder/Snap, it activates the virtual copy session for the devices used by the database/filegroup.

The restore operation automatically performs the following tasks:

◆ Suspends any writes to the database and/or filegroups.

◆ Unmounts the file system on the standard host.




• For TimeFinder/Mirror, it performs a TimeFinder/Mirror restore action, and then splits the restored device from the backup devices.

• For TimeFinder/Snap, it performs a symsnap restore action.

◆ Mounts the file system on the standard side host.

◆ Restores the database and/or filegroup from the metadata file.

If you select manual mode, you can break this overall restore operation into individual tasks. This mode is used for clustered servers or other services that must be turned off with manual intervention. It also allows for a restored database to be relocated. For more detail on manual mode tasks, refer to “Manual mode” on page 165.

Note: The -remote option is considered obsolete, but will still work in old scripts for compatibility.

ARGUMENTS backup

Requests a backup operation be performed on a specified SQL Server database or file group.

restore

Requests a restore operation be performed on a specified SQL Server database or file group.

OPTIONS -bh

Specifies the BackupHostName on which the backup server resides.

-both_sides

Specifies to produce an exact concurrent local and remote point-in-time backup of the database or filegroup.

-brbcv

Specifies to use BRBCV pairs for backup.

-clone

Specifies to use clone devices.

tsimsnap 231

232


-concurrent

Specifies to use all available BCV pairs for backup.

-copyonly

Specifies that the backup not affect the normal sequence of backups. This option is only available for SQL Server 2005.

-d

Specifies the name of the SQL Server database for the backup or restore action.

-f

Specifies the name of a meta file to hold the metadata.

-fg

Confines the backup or restore action to a specific file group name.

-m

Specifies the manual mode that enables you to break the restore operation into individual tasks. Use manual mode for clustered servers, dynamic disks and to initialize standby databases.

-multi

Specifies to use the next available BCV pair for the backup.

-mountonly

Specifies to mount the file systems on the backup host if they were not mounted prior to running the TF/SIM command.

-nocatalog

Specifies that the backup does not include full-text catalog. This option is only available for SQL Server 2005.

-nomount

Specifies not to mount the file systems on the backup host.



-noprompt

Specifies not to prompt for permission before shutting down all SQL-dependent services, or restoring database/filegroup in automatic mode.

-norecovery

Requests the database be left in the norecovery mode after a restore operation. An additional transaction log needs to be restored to recover the database to a consistent state. This is one of three states (norecovery, recovery, and standby). (Not used with the -fg option.)

-nrtgt

Makes the local BCV devices not ready after the tsimsnap backup command split the local BCV devices. This option cannot be used with the -rdf option.

-orf

Specifies the file to use for Open Replicator operations.

-orsdiff

Specifies a differential operation. This option can only be used with -orf.

-overwrite

Specifies to overwrite any existing database dump file.

-pace


-partial

Specifies to perform a partial database restore. This option is only available for SQL Server 2005.

-ph

Specifies the HostName on which the production server resides.

tsimsnap 233

234


-protbcvest

Specifies to perform a protective BCV establish.

-protbcvrest

Specifies to perform a protective BCV restore.

-ps

Specifies a production database server name for the database to be backed up or restored. Or, it can specify a production host name\database instance to target the action. Not required for a stand-alone SQL Server default install base.

-rbcv

Specifies to backup databases with remote BCV devices.

-rclone

Specifies to backup databases with remote clone devices.

-rdf

Specifies to backup databases with remote RDF devices.

-recovery

Requests the database be left in the recovery mode (read/write) after a restore operation. This is one of three modes (norecovery, recovery, and standby). (Not used with the -fg option.)

-relocate

For use when the same drive letter assignment is not available on the backup host. This option mounts the file system with the new driver letter mount point and restores the database with relocation on the backup host.

-remote

Obsolete, can be used for old script compatibility only. Specifies to split the remote BCV. Use -rbcv option for this function.



-rf

Specifies the name of the relocation file when in manual mode (-m). To locate each database file, the file lists the logical and physical device name where each file resides in the database. For details on formatting this file, refer to Figure 20 on page 167.

-rsnap

Specify to backup the database using remote virtual snap devices.

-s

Specifies a clustered SQL Server name for its database to be backed up or restored. Or, it can specify a host name\database instance to target the action. Not required for a stand-alone SQL Server default install base.

-sid


-skip

Specifies that the backup operation should ignore any existing Symmetrix device lock.

-snap

Specifies to backup/restore the database using virtual snap devices.

-standby

Requests the database be left in the recovery mode (read/write) after a restore operation. This is one of three modes (norecovery, recovery, and standby). (Not used with the -fg option.)

-svp

Specifies a SAVE device pool.

-t

Indicates the number of seconds to wait before timing out an application if the Hot Split takes too long.

tsimsnap 235

236


PARAMETERS BackupHostName

The backup host name.

ClustServName

The Virtual SQL Server name.

FileGrpName

The specific filegroup name.

FileName

The name of the device file to use for an Open Replicator operation.

HostName\InstanceName

A host name with or without a database instance name.

Interval

The length of the time, in seconds, before timing out an application.

MetaFile

The name of a meta file that holds the metadata. Can be a full path name.

PoolName

The name of the SAVE device pool.

RelocateFileName

The name of the relocation file (filename.txt).

SqlDbName

The name of the SQL Server database for the backup or restore action.

SymID


VirtSqlServName\InstanceName

A cluster name with or without a database instance name.



RETURN CODES Upon success, the command returns a zero. For various failures and warnings, the command returns a non-zero value. For further information about all possible return codes, refer to header file tsim_Err.h in the TF/SIM install directory.

EXAMPLES To backup filegroup ProdDbfg03 in database ProdDB with the meta file is n:\ProdDB.dmp, enter:

tsimsnap backup -d ProdDb -f n:\ProdDB.dmp -fg ProdDBfg03

To restore database ProdDB with the meta file is n:\ProdDB.dmp and put the database in standby mode, enter:

tsimsnap restore -d ProdDb -f n:\ProdDB.dmp -standby

To manually restore database ProdDB with the meta file n:\ProdDB.dmp and put the database in norecovery mode, enter:

tsimsnap restore -d ProdDb -f n:\ProdDB.dmp -m -norecovery

To manually restore database ProdDB with the meta file n:\ProdDB.dmp and put the database in a new location with file n:\ProdDBlocation2.txt, and to finally put it in standby mode, enter:

tsimsnap restore -d ProdDb -f n:\ProdDB.dmp -m -rf ProdDBlocation2.txt -standby

tsimsnap 237

238


tsimsnap2For Windows systems, this TF/SIM command backs up and restores multiple databases from the specified SQL Server instance.

SYNTAX To create a snapshot of the databases on a standard host:

tsimsnap2 backup -d SqlDbName [-f MetaFile][-both_sides |-both_side -snap | -clone | -concurrent -nrtgt | -rbcv | -rclone | -rsnap | -bh BackupHostName |-rdf | -snap ] [-skip] [-copyonly] [-nocatalog][-t Interval] [-overwrite][-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

To create a snapshot of the databases on a backup host:

tsimsnap2 backup -d SqlDbName -f MetaFile -ph HostName [-ps VirtSqlServName[\InstanceName] | HostName[\InstanceName]] [-orf Filename] [-orsdiff][-brbcv | -clone | -multi | -rbcv | -rclone |-rdf][-protbcvest] [-skip][-copyonly] [-nocatalog] [-t Interval] -nomount | -mountonly | -norecovery | -recovery | -standby [-relocate][-overwrite] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

tsimsnap2 backup -d SqlDbName -f MetaFile -ph HostName [-ps VirtSqlServName[\InstanceName] | HostName[\InstanceName]][-concurrent | -nrtgt] [-skip] -copyonly] [-nocatalog][-t Interval] -nomount | -mountonly [-overwrite][-protbcvest][-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

tsimsnap2 backup -d SqlDbName -f MetaFile -ph HostName [-ps VirtSqlServName[\InstanceName] | HostName[\InstanceName]]-snap | -rsnap [[-sid SymID] -svp PoolName ...][-skip] [-copyonly] [-nocatalog] -nomount [-overwrite][-protbcvest] [-t Interval][-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]



To create a snapshot of all user databases or the instance of SQL Server on a standard host:

tsimsnap2 backup [-alludb | -instance] [-f MetaFile][-both_side | -both_side | -snap | -clone | -nrtgt| -rbcv | rclone | -rsnap -bh BackupHostName | -rdf | -snap ] [-skip] [-copyonly][-nocatalog] [-overwrite] [-t Interval][-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

To create a snapshot of all user databases on a backup host:

tsimsnap2 backup -alludb -f MetaFile-ph HostName [-ps VirtSqlServName[\InstanceName] | HostName[\InstanceName]][-clone | -multi | -rbcv | -rclone | -rdf] [-skip] [-copyonly] [-nocatalog] [-protbcvest] [-t Interval]-nomount | -mountonly | -norecovery | -recovery |

-standby [-relocate][-overwrite] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

tsimsnap2 backup -alludb -f MetaFile-ph HostName [-ps VirtSqlServName[\InstanceName] | HostName[\InstanceName]] [-concurrent | -nrtgt] [-protbcvrest][-skip] [-copyonly] [-nocatalog] [-t Interval]-nomount | -mountonly [-overwrite][-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

To create a snapshot of the instance of SQL Server on a backup host:

tsimsnap2 backup -instance -f MetaFile-ph HostName [-ps VirtSqlServName[\InstanceName] | HostName[\InstanceName]][-clone | -multi | -rbcv | -rclone| -rdf | -rsnap |-snap [-svp PoolName]][-skip][-copyonly][-nocatalog][-protbcvrest][-t Interval][-nomount |-mountonly] [-scm] [-detachudb] [-overwrite] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

tsimsnap2 239

240


tsimsnap2 backup -instance -f MetaFile-ph HostName [-ps VirtSqlServName[\InstanceName] | HostName[\InstanceName]][-concurrent | -nrtgt | -rsnap | -snap] [-protbcvrest] [-skip] [-copyonly] [-nocatalog][-t Interval] -nomount | -mountonly [-overwrite][-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

To migrate the database to another Symmetrix or CLARiiON from a backup host:

tsimsnap2 backup DbName ... -f MetaFile[-snap | -clone] -orf DevFileName [-orsdiff][-skip] [-copyonly] [-nocatalog] -nomount| -mountonly | -norecovery | -recovery | -standby[-t Interval] [-overwrite][-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]]

To restore the snapshot of databases:

tsimsnap2 restore -d SqlDbName [-f MetaFile] [-s VirtSqlServName[\InstanceName] | HostName[\InstanceName]] -norecovery | -recovery | -standby

DESCRIPTION This TF/SIM command backs up or restores multiple databases for a stand-alone or a clustered SQL Server instance that resides on Symmetrix devices.

The backup operation consolidates the backup timeframes by concurrently backing up the multiple databases. Once you have backed up an exact copy of the production devices that hold the SQL Server information (data and logs), you can perform database or file group restore actions when needed. The backup operation writes information about the specific databases in metafiles stored in the specified meta directory. The default file names take on the form DbName_snapshot.dmp for the various meta files in this directory.

On the production server, using the -s option, you can target a specific:

◆ Virtual SQL Server name with or without an instance name, or◆ Host name with or without an instance name.

In a TimeFinder environment, you can use the -nrtgt option to make the BCV devices not ready after a TimeFinder/Mirror split.



In an SRDF environment, you can specify to either backup the database to the remote BCV from its R2 mirror, using the -rbcv option or to backup the R2 device from the R1, using the -rdf option.

In a virtual snap environment, you can use the -snap option to backup the database to the VDEVs.

In a remote virtual snap environment, you can use the -rsnap option to backup the database to the remote VDEVs.

If the Symmetrix array supports instant split, then TimeFinder/Mirror instant split behavior will assist a hot-split task portion of the backup activities. Before starting a backup operation, all database devices must be synchronized, and if an SRDF environment exists, R2 devices and their BCVs must be synchronized with R1 devices.

The TF/SIM backup operation:


◆ Automatically writes metadata information about the specific database. Metadata information is normally measured in kilobytes, so it is not necessary to have additional storage.

◆ Performs an automatic TimeFinder/Mirror SRDF split of the devices associated with the databases.

The restore operation restores the specified database into the following recovery modes:

◆ Norecovery

◆ Standby

◆ Recovery

Note: The -remote option is still supported for script compatibility only.

ARGUMENTS backup


restore


tsimsnap2 241

242


OPTIONS -alludb

Specifies the backup action to be performed on all user databases of the SQL Server instance.

-bh

Specifies the BackupHostName on which the backup server resides.

-both_sides

Specifies to produce an exact concurrent local and remote point-in-time backup of the specific databases.

-brbcv

Specifies to use BRBCV pairs for backup.

-clone

Specifies to backup/restore the database using clone devices.

-concurrent

Specifies to use all available BCV pairs for backup.

-copyonly


-detachudb

Specifies to detach all user databases from the standby SQL Server instance.

-d

Specifies the database name or names of the SQL Server instance for the backup or restore action.

-f

Specifies the name of the meta file directory to hold the metadata files.

-instance

Specifies the backup action to be performed on all databases of the SQL Server instance (tempdb excluded).



-mountonly

Specifies to not mount the file systems if they were not mounted prior to running the TF/SIM command.

-multi

Specifies to use the next available BCV pair for the backup.

-nocatalog

Specifies that the backup does not include full-text catalog. This option is only available for SQL Server 2005.

-nomount

Specifies to update the BCV/R2/R2BCV without updating the file system.

-norecovery

Requests the database be left in the norecovery mode after a restore operation. An additional transaction log needs to be restored to recover the database into a consistent state. This is one of three modes (norecovery, recovery, and standby).

-nrtgt

Makes the local BCV devices not ready after the tsimsnap2 backup command split the local BCV devices.

-orf


-orsdiff

Indicates an Open Replicator differential data copy operation.

-overwrite


-pace


tsimsnap2 243

244


-ph

Specifies the HostName on which the production server resides.

-protbcvest

Specifies to perform a protective BCV establish.

-protbcvrest

Specifies to perform a protective BCV restore.

-ps

Specifies a production database server name for the database to be backed up or restored. Or, it can specify a production host name\database instance to target the action. Not required for a stand-alone SQL Server default install base.

-rbcv


-rclone


-rdf

Specifies to backup databases with remote RDF devices.

-recovery

Requests the database be left in the recovery mode (read/write) after a restore operation. This is one of three modes (norecovery, recovery, and standby).

-relocate

For use when the same drive letter assignment is not available on the backup host. This option mounts the file system with the new driver letter mount point and restores the database with relocation on the backup host.

-remote

Obsolete, can only be used for old script compatibility. Specifies to split the remote BCV. Use -rbcv option for this function.



-rsnap

Specify to backup the database using remote virtual snap devices.

-s

Specifies a clustered SQL Server name for its databases to be backed up or restored. Or, it can specify a host name\database instance to target the action. Not required for a stand-alone SQL Server default install base.

-scm

Specifies that the metadata file must be able to locate on one of the file systems the production database it is using.

-sid


-skip

Specifies that the backup operation should ignore any existing Symmetrix device lock.

-snap

Specifies to backup/restore the database using virtual snap devices.

-standby

Requests the database be left in the recovery mode (read/write) after a restore operation. This is one of three modes (norecovery, recovery, and standby).

-svp

Specifies a SAVE device pool.

-t

Indicates the number of seconds to wait before timing out an application if the Hot Split takes too long.

PARAMETERS ClustServName

The Virtual SQL Server name.

tsimsnap2 245

246


FileName

The name of the device file to use for an Open Replicator operation.

HostName\InstanceName

A host name with or without a database instance name.

Interval

The length of the time, in seconds, before timing out an application.

MetaFileDir

The name of the meta file directory that holds the metadata files (DbName_snapshot.dmp).

PoolName

The name of the SAVE device pool.

SqlDbName

The name of the SQL Server database for the backup or restore action. More than one database name can be targeted.

SymID


VirtSqlServName\InstanceName

A virtual SQL Server name with or without a database instance name.

RETURN CODES Upon success, the command returns a zero. For various failures and warnings, the command returns a non-zero value. For more information about all possible return codes, refer to header file tsim_Err.h in the TF/SIM install directory.

EXAMPLES To concurrently backup databases ProdDB and ProdPMDb with the meta files in n:\SQLMetaFiles, enter:

tsimsnap2 backup -d ProdDb ProdPMDb -f n:\SQLMetaFiles



To concurrently backup all user databases on SQL Server Production1\Batch2 instance with the meta files in n:\SQLMetaFiles, enter:

tsimsnap2 backup -alludb -f n:\SQLMetaFiles -s Production1\Batch2

To restore databases ProdDB and ProdPMDb into a recovery mode with the meta files in n:\SQLMetaFiles, enter:

tsimsnap2 restore -d ProdDb ProdPMDb -f n:\SQLMetaFiles -recovery

tsimsnap2 247

248


tsimvssThis command is used to backup the SQL Server databases and restore the databases to another instance of SQL Server.

SYNTAX To backup the SQL Server databases and restore the databases to another instance of SQL Server:

To create a snapshot of the database(s) from the backup host:

tsimvss backup -ps <ProdSQLServerName> -d <DbName...>[-clone | -rclone | -snap | -preestablish | -multi |

[-brbcv | -rbcv [-multi | -preestablish]]][[-bcd <FileName> -wmd <FileName>] [-overwrite]][[-ls <LocalSQLServerName>] -recovery] |-readwrite/-rw] [-copyonly]

To perform VSS cleanup from backup host:

tsimvss backup -ps <ProdSQLServerName> -d <DbName...>[-clone | -rclone | -snap | -multi | [-brbcv | -rbcv [-multi]][-readwrite/-rw] -cleanup

To create a snapshot of the SQL Server instance from backup host:

tsimvss backup -instance -ps <ProdSQLServerName> [-clone | -rclone | -snap | -preestablish | -multi |

[-brbcv | -rbcv [-multi | -preestablish]]][[-bcd <FileName> -wmd <FileName>] [-overwrite]][-readwrite/-rw] [-cleanup]

To create a snapshot of the all user databases from backup host:

tsimvss backup -alludb -ps <ProdSQLServerName> [-clone | -rclone | -snap | -preestablish | -multi | [-brbcv | -rbcv [-multi | -preestablish]]][[-bcd <FileName> -wmd <FileName>] [-overwrite]][[-ls <LocalSQLServerName>] -recovery] | [-readwrite/-rw] [-cleanup]

To migrate the database to another Symmetrix or CLARiiON array from the backup host:

tsimvss backup -ps <ProdSQLServerName> -d <DbName...>[-clone] -orf <DevFileName> [-orsdiff] [-pace <0-9>][[-bcd <FileName> -wmd <FileName>] [-overwrite]][-copyonly] [-cleanup] [-readwrite/-rw] [-ls <LocalSQLServerName>]



To restore a database snapshot to the Production SQL Server from backup host:

tsimvss restore -ps <ProdSQLServerName> -d <DbName...>-bcd <FileName> -wmd <FileName>

[-brbcv | -clone | -multi | -rbcv | -clone | -snap][[-ls <LocalSQLServerName>] -recovery | -norecovery] | [-readwrite/-rw]

DESCRIPTION Microsoft SQL Server 2005 provides support for creating snapshots from SQL Server databases using Volume Shadow Copy Service (VSS). This is accomplished by providing a VSS compliant writer (the SQL writer) so that a third-party backup application can use the VSS framework to back up database files.

Note: TF/SIM VSS does not support the database filegroup backup/restore due to the limitation of the VSS SQL Writer interface.

The tsimvss command supports VSS backup operations with TimeFinder local BCVs, VDEVs, and clones and BRBCVs for SRDF operations.

ARGUMENTS backup


restore


OPTIONS -alludb

Specifies to backup all the user databases from the SQL Server instance.

-bcd

Specifies the backup components document.

-brbcv

Specifies to backup with BRBCV devices. This is the only supported method for RDF with VSS.

tsimvss 249

250


-cleanup

Specifies to cleanup the current status of the volume on the backup host.

-clone

Specifies to backup with clone devices.

-copyonly


-d

Specifies the database(s) to be backed up.

-instance

Specifies to backup all databases from the SQL Server instance.

-ls

Specifies the local SQL Server Name. It is only required if -norecovery or -recovery is used to indicate the database initialization on the backup host.

-orf


-orsdiff

Indicates an Open Replicator differential data copy operation.

-overwrite


-pace




-preestablish

Specifies that all devices must be in synchronized mode before any backup operation. Clone devices must be in the created or recreated state.

-ps

Specifies production SQL Server name. It must be a remote SQL Server instance. There is no need to specify the production host name as tsim could discover the production host name with the T-SQL command:

SELECTSERVERPROPERTY('ComputerNamePhysicalNetBIOS'))

-multi

Specifies to use the next available BCV pairs.

-norecovery

Specifies to restore the database into norecovery mode to roll forward an additional transaction log.

-rbcv


-rclone


-recovery

Specifies to restore the database into recovery mode.

-readwrite

Specifies to clear the readonly flag on the backup volume. (The abbreviated form -rw can be used.)

-snap

Specifies to backup with VDEV devices.

-wmd

Specifies the writer metadata document.

tsimvss 251

252


PARAMETERS DbName

The database name.

DeviceFileName

The Open Replicator device file name.

FileName

The file name.

LocalSQLServName

The local SQL server name.

ProdSQLServName

The production SQL server name.


BInvisible Body Tag

This appendix describes the TimeFinder, SRDF, and Open Replicator support for the SYMCLI TimeFinder/Integration Modules. Topics include the following:

◆ ExBackup2003/ExBackup2007 support........................................ 254◆ tsimsnap support ............................................................................. 256◆ tsimsnap2 support ........................................................................... 258◆ Open Replicator support................................................................. 261◆ tsimvss support ................................................................................ 264

TimeFinder/IMsSupport Matrix

TimeFinder/IMs Support Matrix 253

254

TimeFinder/IMs Support Matrix

ExBackup2003/ExBackup2007 supportTable 9 lists the supported options for ExBackup2003 and ExBackup2007

Table 9 ExBackup2003/ExBackup2007 supported options

Option

Replication Technology

TF/Mirror(default)

TF/Snap (-snap)

TF/Clone(-clone)

Remote TF/Mirror (-rbcv)

Remote TF/Clone(-rclone)

Remote copy of a local TF/Mirror(-brbcv)

-vss Yes Yes Yes Yes Yes Yes

-nologdelete Yes Yes Yes Yes Yes Yes

-hot Yes Yes Yes Yes Yes Yes

-multi Yes Yes No Yes No Yes

-vssdiff Yes Yes Yes Yes Yes Yes

-copyonly Yes Yes Yes Yes Yes Yes

-preestablish Yes No No Yes No Yes

-rw Yes Yes Yes Yes Yes Yes

-full Yes No No Yes No Yes

-protbcvest Yes No No Yes No Yes

-svp No Yes No No No No

-orf Yes No Yes No No No

-cleanup Yes Yes Yes Yes Yes Yes



VSS configurations The following VSS configurations are supported with TF/EIM:

Table 10 VSS supported configurations

Environment VSS support

TimeFinder/Local STD (or R1) —> BCV—> VDEV—> Clone

STD (or R1) —> R1BCV

TimeFinder/Remote STD (or R1) —> R1BCV —> R2 —> BRBCVR1 —> R2 —> RBCVR1 —> R2 —> RClone

ExBackup2003/ExBackup2007 support 255

256


tsimsnap supportThis section supplies the supported backup and restore operations for tsimsnap.

tsimsnap backup from the production hostTable 11 identifies the tsimsnap backup operations supported from the production host.

tsimsnap backup from the backup hostTable 12 identifies the tsimsnap backup operations supported from the backup host.

Table 11 tsimsnap backup support from the production host

Configuration BCV Snap Clone RDF RBCV BRBCV RSnap RClone

Single database

Full Yes Yes Yes Yes Yes Yes Yes Yes

Copy only Yes Yes Yes Yes Yes Yes Yes Yes

File group Yes Yes Yes Yes Yes Yes Yes Yes

Table 12 tsimsnap backup support from the backup host

Configuration BCV Snap Clone RClone RDF BRBCV RBCV Multi Concurrent RSnap

Single database

Full Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Copy Only Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

File group Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Nomount Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Mount only Yes No No No Yes Yes Yes Yes Yes No

Recovery Yes No No No Yes Yes Yes Yes No No

Norecovery Yes No No No Yes Yes Yes Yes No No

Standby Yes No No No Yes Yes Yes Yes No No



tsimsnap restore from the production hostTable 13 identifies the tsimsnap restore operations supported from the production host.

Table 13 tsimsnap restore support from the production host

Configuration BCV Clone Snap RBCV BRBCV RClone RSnap

Single database

Recovery Yes Yes Yes Yes Yes Yes Yes

Norecovery Yes Yes Yes Yes Yes Yes Yes

Standby Yes Yes Yes Yes Yes Yes Yes

tsimsnap support 257

258


tsimsnap2 supportThis section supplies the supported backup and restore operations for tsimsnap2.

tsimsnap2 backup from production hostTable 14 identifies the tsimsnap2 backup operations from the production host supported for each database type.

Table 14 tsimsnap2 backup support from the production host

Configuration BCV Snap Clone RDF RBCV BRBCV RSnap RClone

Single database



File group No No No No No No No No

Multiple databases




All User databases






tsimsnap2 backup from the backup hostTable 15 identifies the tsimsnap2 backup operations from the backup host supported for each database type.

Table 15 tsimsnap2 backup support from the backup host


Single database




Mount only Yes No No No Yes Yes Yes Yes Yes No




File group No No No No No No No No No No

Multiple database




Mount only Yes No No No Yes Yes Yes Yes No No





All user databases




tsimsnap2 support 259

260


tsimsnap2 restore from the production hostTable 16 identifies the tsimsnap2 restore operations from the production host supported for each database type.

Mount only Yes No No No Yes Yes Yes Yes No No





Table 15 tsimsnap2 backup support from the backup host (continued)


Table 16 tsimsnap2 restore support from the production host


Single database




Multiple database




All User databases






Open Replicator supportThis section supplies the supported backup and restore operations for Open Replicator using the tsimsnap and tsimsnap2 commands.

Open Replicator database backupTable 17 identifies the supported Open Replicator database backup operations for each database type.

Table 17 Open Replicator backup database support

Symmetrix to Symmetrix Symmetrix to CLARiiON

Mirror Clone Mirror Clone

Configuration Full Diff Full Diff Full Diff Full Diff

Single database



Recovery Yes Yes No No Yes Yes No No

Norecovery Yes Yes No No Yes Yes No No

Standby Yes Yes No No Yes Yes No No

Mount only Yes Yes No No No No No No

Nomount Yes Yes No No Yes Yes No No

Multiple database






Mount only Yes Yes No No No No No No


Open Replicator support 261

262


Open Replicator restore from production hostTable 18 and Table 19 show the restore operations supported for Open Replicator from the production host.

tsimsnapTable 18 identifies the supported Open Replicator restore operations using the tsimsnap command. .

All User databases






Mount only Yes Yes No No Yes Yes No No


Instance

Normal Yes Yes Yes Yes Yes Yes Yes Yes

SCM Yes Yes No No Yes Yes No No

Table 17 Open Replicator backup database support




Table 18 Open Replicator restore support using tsimsnap


Single database






tsimsnap2Table 19 identifies the supported Open Replicator restore operations using the tsimsnap2 command.

Refer to Table 21, “tsimvss Open Replicator backup database support,” and Table 23, “tsimvss Open Replicator database restore support,” for Open Replicator support using the tsimvss command.

Table 19 Open Replicator restore support using tsimsnap2


Single database




Multiple database




All user databases




Open Replicator support 263

264


tsimvss supportThis section provides the supported backup and restore operations for the tsimvss command.

tsimvss backup databaseTable 20 identifies the TimeFinder and SRDF backup operations supported for each database type.

Table 20 tsimvss TimeFinder/SRDF backup database support

Configuration

Multi BCV

PreEst Snap Clone BRBCV RBCV RCloneBCV Mirror Split

Single databasea


Copy Only Yes Yes Yes Yes Yes Yes Yes Yes

Recovery Yes Yes No No No Yes Yes No

Multiple databasesa




All User databasesa




Instanceb


SCM Yes Yes Yes No No Yes Yes No

a. No Recovery is not supported for any database backup operations.

b. Copy only is not supported for database instance backup operations.



tsimvss backup using Open ReplicatorTable 21 identifies the Open Replicator backup operations supported for each database type.

Table 21 tsimvss Open Replicator backup database support




Single databasea




Multiple databasesa




All User databasesa




Instanceb


SCM Yes Yes Yes No No Yes Yes No

a. No Recovery is not supported for any database backup operations.

b. Copy only is not supported for database instance backup operations.

tsimvss support 265

266


tsimvss restore databaseTable 22 identifies the TimeFinder and SRDF restore operations supported for each database type.

Table 22 tsimvss TimeFinder/SRDF database restore support

Configuration

Multi BCV

PreEst Snap Clone BRBCV RBCV RCloneBCV Mirror Split

Single databasea

Recovery Yes Yes Yes Yes Yes Yes Yes Yes

No Recovery Yes Yes Yes Yes Yes Yes Yes Yes

Multiple databasesa



All User databasesa



Instanceb

a. Copy Only is not supported for any database restore operations.

b. Instance is not supported for database restore operations.



tsimvss restore using Open ReplicatorTable 23 identifies the Open Replicator restore operations supported for each database type.

Table 23 tsimvss Open Replicator database restore support




Single database



Multiple databases



All User databases



Instancea

a. Database instance is not supported for any recovery operations.

tsimvss support 267

268



Index

Aautomatic mode, overriding 165

Bbackup

for disaster recovery 132multiple databases 186

backup databaseinitializing 195on virtual snap 197recovering 195

basic diskssynchronizing the BCV for 57

BCVsynchronizing steps 58

BCV device 26BCV remote mirroring 83Business continuance volumes 26

Ccache buffer flush 50checkpoint file

location requirement 72renaming 111

client-server, TF/SIM 132cluster restores 116cluster servers

manual mode for 165clustered host

restoring on 179code examples

for ExBackup2003 226

for tsimsnap 237for tsimsnap2 246

cold push operationsample of 35

concurrent BCVs, TF/SIM 132

Ddatabase

dismounting 111filegroup, backing up 199remounting 111restore from remote site 113

database restorewith VSS 209

databases 75deporting a disk group

with Veritas 47device masking 54devices

discovering 45remounting 107scanning 45

disaster recoveryfor multiple databases 182

disaster recovery backup 132disk configuration

viewing 46disk groups

configuring 44disk signatures 49Dynamic disks

synchronizing the BCV for 58dynamic disks


270

Index

creating a BCV 56restoring with TimeFinder 60

Eerror files, Windows 160event logging, Windows 160ExBackup 2003

syntax 220ExBackup2003

code examples 226options supported 254

ExBackup2007options supported 254

Exbackup2007 93Exchange backup 68Exchange backup API 19Exchange backup recovery server 75Exchange Server

2003 and 2007 93and Open Replicator 92and TimeFinder/Clone 81, 142configuring TimeFinder 77features 72installation requirements 70troubleshooting 124VSS supported operations 255

Exchange system software 69execution sequence for TF/SIM 156

Ffilegroup

best practices 201considerations 200recovery 199

files, license 40flush cache 50

Hhandles 53

Iimporting a disk group

with Veritas 47initialization file

backup using 98installation

Exchange system software 69

Llicense file 40license keys 22License Management Facility (LMF)

invoking 40listing

disk configuration 46locks

on drives 54releasing 54

Logical Disk Manager 44

Mmailbox

recovery, single 112restores 19, 68

maintenance mode 116manual mode 165metadata information, saving 195, 197mounting BCV or SRDF volumes 51MSCS

restores 116multiple BCVs 78multiple BCVs with TF/EIM 95multiple databases

backing up 172, 186backing up remotely 185disaster recovery for 182initializing 177

Oopen handles 53Open Replicator

backups supported for 261configuring 87, 92, 148description of 34execution sequence 158restores supported for 262running TF/SIM 158sample copy session 35tsimvss backups supported 265


Index

tsimvss restore operations 267

Pproduction server, configuring 141, 144

Rrecovery tips 124remote BCV

restoring data from 115requirements

Exchange Server 21SIU 21, 43SQL Server 21TEIM 23TF/EIM 21TF/SIM 21Veritas 25Windows 21, 22

rescan, SIU 45restoring

data from the R2 113data from the remote BCV 115databases 164, 176other methods 191procedures for 103standard from the R1/BCV 114the R2 mirror from the remote BRBCV 115

Ssetup, TF/EIM 69signatures, manipulating 49SIU

features 42overview 19, 42requirements 21, 43

Snapshot, SQL Server 2000 131SQL databases, restoring multiple 176SQL Server

and TF/SIM 19, 128backing up locally 160backing up multiple databases 172backing up remotely 169, 185concurrently backing up 162, 174instance, backing up 188recovery methods 191

snapshots 131transaction logs 137

SRDFconfigurations supported 30configuring 83

SRDF and TF/EIM 32standard device 26standard remote mirroring 85standby database

initializing 191updating 191

standby databases 131initializing multiple 177

standby serverwith BRBCV 146

Storage Area Network 34SYMAPI 68, 128SYMCLI 18Symmetrix Command Line Interface 18Symmetrix Integration Utilities (see SIU) 41symntctl

flush 50list 46locks 54mount 51openhandle action 53rescan 45syntax 213

Ttest mode 96TF/EIM 68

command start up 90Open Replicator restores 104operations 89platforms supported 90requirements 21setup 69VSS restores 103

TF/SIM 19command line entry 159configuring production server 141, 144event logging 156executable files 160execution sequence 156, 158guidelines for running 154


272

Index

instantaneous database backup 195, 197multiple standby databases, initializing 177requirements 21restore methods, other 191running backup remotely 170running locally 163running restore 164setting up production server 139standby database 191standby server 146timeout option 134with Open Replicator 158

TimeFinder 68and Exchange 19configuring for Exchange backup server 77creating a BCV of a dynamic disk 56in SQL Server environment 138restoring dynamic disks 60

TimeFinder/Cloneconfiguring 81, 142sample copy session 30

TimeFinder/Snapconfiguring 79sample copy session 28using VSS with 79

transaction logillustration of 110verification process 107

transactions, rolling forward 131tsimsnap

backup operations supported 256code examples 237restore operations supported 257syntax 228

tsimsnap2backup operations supported, from backup

host 259backup operations supported, from

production host 258code examples 246restore operations supported, from

production host 260syntax 238, 248

tsimvssbackup with VSS 248backups supported 264command syntax 248

execution sequence 158restore operations supported 266restoring a database with 209

Uunmount operations 52

VVeritas Storage Foundation for Windows

dynamic disk groups (VDGs) 44requirements 25

Virtual Device Interface (VDI) 19, 128volume configuration

managing 46viewing 46

volume layout, TF/EIM requirements 71volume sets, defining 47VSS

Exchange Server support 255SRDF configuration supported 83tsimvss 248

WWindows

configuring basic disks 149configuring dynamic disks 149environment requirements 22error files 160event logging 160


Documents

New EMC TimeFinder /Integration Modules (TF/EIM, TF/SIM, SIU) · 2020. 3. 6. · 14 EMC TimeFinder/Integration Modules Version 4.1 Product Guide Preface EMC Solutions Enabler Symmetrix