| ETERNUS SF AdvancedCopy Manager Operator's Guide 13.0 -Microsoft(R) Windows(R) 2000- -Microsoft(R) Windows Server(TM) 2003- |
|
Contents
Index
|
This chapter explains the procedure for backing up or restoring the Exchange server databases using the backup management function or the replication management function of AdvancedCopy Manager.
To understand the contents of this chapter, the reader is requested to have a basic knowledge of Exchange server and Volume Shadow Copy Service (VSS) in addition to AdvancedCopy Manager.
Also, before reading this chapter, the user is recommended to read the Exchange Server 2003 Disaster Recovery Operations Guide issued by Microsoft Corporation. The latest version of this document can be downloaded from the following URL:
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/disrecopgde.mspx
Exchange server is a trademark or registered trademark of Microsoft Corporation in the United States and other countries.
AdvancedCopy Manager provides the function to back up and restore the Microsoft Exchange server databases.
The advanced copy function of the Fujitsu storage system ETERNUS can link with VSS to implement a high-speed online backup of the Exchange server databases.
The backup data of an Exchange server database includes the backups of the following files that constitute the Exchange server database:
EDB file and STM file (database files)
The paired EDB file and STM file constitutes a database. Each file exists in each information store.
LOG file (transaction log file)
The LOG file contains a transaction log. At least one LOG file exists in each storage group.
CHK file (checkpoint file)
The checkpoint file points to the latest transaction, which has already been committed to the database, in the transaction log. One checkpoint file exists in each storage group.
A linkage with VSS enables the online backup of the Exchange server database.
Backup is performed in units of storage groups. Because backup processing is performed without stopping the messaging service, store access is enabled even during backup processing.
Because the backup data testing (ESEUTIL) and log deletion are executed as part of the online backup processing, these types of operation need not be executed after backup processing.
Backup can be created instantly and without placing a burden on the Exchange server, using advanced copy functions (OPC/EC, REC or QuickOPC)
Advanced copies are executed by the ETERNUS/GR hardware provider. (*1)
Storage group configuration files (*.edb, *.stm, *.log or *.chk) are copied to the backup volume.
*1: This function can only be used by ETERNUS/GR hardware providers. Other vendors' providers cannot be used.
REC is executed in the following operation modes in this function.
Transfer mode= Synchronous
Split mode=Automatic Split
Recovery mode=Automatic Recovery
The transport function of VSS shadow copy can be used to make a backup (shadow copy) on the disk connected to the backup server. The function thus enables a backup to tape without placing any loads on the Exchange server.
|
Server |
Component |
Description |
|---|---|---|
|
Exchange server |
Exchange Writer |
Exchange writer |
|
ACM Requester |
The ACM Exchange 2003 requester that provides backup and restore functions for Exchange. |
|
|
ETERNUS Provider |
ETERNUS/GR hardware provider that offers a shadow copy creation function using the advanced copy function (OPC/EC, REC, QuickOPC). |
|
|
Backup server |
ESEUTIL |
Exchange server database consistency check and recovery utility The ACM Requester uses this component to check backup data for consistency. |
|
ACM Requester |
Exchange 2003 requester provided by ACM. This component manages (status check and deletion) the shadow copy according to instructions from the ACM Requester on the Exchange server. |
|
|
ETERNUS Provider |
ETERNUS/GR hardware provider, which manages the copy destination disk (LUN). |
The advanced copy function of the Fujitsu storage system ETERNUS can link with VSS to restore the Exchange server databases from the online backup data.
A linkage with VSS enables a restoration from the online backup data.
As with a backup, a restoration is performed in units of storage groups. All databases (stores) are dismounted during restoration processing.
Two restoration modes are supported: roll forward restoration (restoration to the latest point) and point-in-time restoration (restoration to the backup point).
When the online backup data is stored on tape, it must be restored in advance to the backup disk.
Advanced Copy (OPC) can also be used for a restoration to resume a job operation quickly without placing any loads on the Exchange server.
OPC is executed by the conventional ACM function (replication creation command).
Because log application and mounting are enabled soon after the execution of OPC logical copying, a job operation can be restarted quickly without waiting for the completion of OPC physical copying.
When you perform restoration by EC/REC, the operation stop time until restarting operation in the case of using EC/REC becomes longer than that in the case of using OPC because you need to wait until all the data of disk is copied. For this reason, if OPC can be used, we recommend you to perform a restoration by OPC.
The suspension of EC is executed by the conventional ACM function (replication creation command).
Log application and mounting are enabled soon after the execution of suspending EC/REC.
*1: With VSS, the requester restores the necessary files without using a provider for restoration processing file copying.
The requester performs restorations using existing functions (swsrpstartsync and swsrpmake).
In the point-in-time restoration mode, the Exchange server database and log file are restored so that the database is restored to the state it was in when it was backed up. Data created after the backup is not restored.
In the roll-forward restoration mode, the previous backup data and currently remaining transaction log are used to restore the database to the latest state. This mode can be used when the log file is normal even though the database is damaged. It cannot be used when both the database and log file are damaged.
This section explains the following procedures for designing the backup operation of the Exchange server database:
Designing server configurations
Designing storage groups
Preparing backup volumes
The storage management server centrally manages and operates multiple storage servers.
Install the AdvancedCopy Manager manager function on this server. The storage management server can work also as a storage server.
This storage server is used for the Exchange server operation.
Install the AdvancedCopy Manager agent function on this sever. Instruct the database backup or restoration from this server.
Storage groups subject to a backup and the disks (transaction volumes) to which the storage groups are allocated must be connected to this server.
The Exchange server must be used in the cluster operation mode implemented by Microsoft Cluster Server (MSCS).
It is necessary to apply Service Pack 1 and later versions of Windows Server 2003 to the Storage server (Exchange server).
This storage server is used for the backup server operation.
Install the AdvancedCopy Manager agent function on this sever.
Also, install the Exchange server system management tool to check the backup data.
The disks (backup volumes) to which the database volumes are backed up must be connected to the backup server.
The backup server cannot be used in cluster operation mode.
ETERNUS multi-path drivers are required if both multi-path disk control and path load balancing are performed.
It is necessary to apply Service Pack 1 and later versions of Windows Server 2003 to the Storage server (Backup server).
Advanced Copy for backup is performed in units of disks (LUNs), not in units of partitions. For this reason, when multiple partitions are created on a disk, the individual partitions must contain files belonging to a specific storage group (see Example A below). Operation cannot be performed with a configuration in which one disk contains files belonging to different storage groups (see Example C below) or contains files of other applications (see Example B below).
The operation can be performed problem free in the configuration shown in Example A. Rather than this configuration, however, a configuration consisting of multiple disks as shown below is recommended for better performance and easy management.
The Exchange server linkage function provides the backup/restore function that backs up or restores the Exchange server databases in units of storage groups. AdvancedCopy Manager copies data in units of volumes (partitions). For this reason, if two or more storage groups exist in the same volume, the backup/restore function of AdvancedCopy Manager cannot be used. With these restrictions in mind, the following notes must be followed when designing the physical layout of storage groups.
Do not store files other than the Exchange server database files subject to a backup in the volume in which the database files are to be allocated. If a file other than an Exchange server database is stored in the same volume, AdvancedCopy Manager also backs it up. Accordingly, when it is restored, the latest data in the file other than the database files is damaged.
Only one storage group can be stored in the same volume. Suppose storage groups 1 and 2 are stored in the same volume. When storage group 1 is backed up, the files in storage group 2 are also copied. When only storage group 1 is later restored, storage group 2 is also restored, which results in the destruction of the database in storage group 2 (see the figure below).
When a backup is performed from a volume that contains a database subject to a backup and a database not subject to a backup, data integrity of the database not subject to a backup is not guaranteed.
No database can be allocated to the volume that contains Exchange server and AdvancedCopy Manager executable files and control files.
To move an already allocated database file, use the Exchange system manager.
|
Restoration mode |
|||
|
Point-in-time |
Roll-forward |
||
|
Log file allocation |
Database files and log files are allocated to the same volume. |
Enabled |
Disabled |
|
Database files and log files are allocated to separate volumes. |
Enabled |
Enabled |
|
When a log file is stored on the volume containing a database, the roll-forward restoration cannot be performed. This is because Advanced Copy performs copying in units of volumes. If a log file is stored in the volume containing a database and copy is performed, the log file at the time of backup overwrites the latest log file. When the roll-forward restoration is specified, AdvancedCopy Manager checks whether the database file and log file are stored on the same drive.
The roll-forward restoration can be performed when a transaction log file and database file are stored on separate drives.
The point-in-time restoration can be performed regardless of the log file allocation.
CHK file allocation has nothing to do with the available restoration modes.
Thus, allocate the database files and log files to separate the volumes when the roll-forward restoration is required. Although Exchange normally creates database files and transaction log files in the same volume, the Exchange system manager can be used to move the transaction log files to another volume.
As shown in the figure below, a database file can be distributed and stored in multiple volumes. When a storage group is distributed and stored in multiple volumes, AdvancedCopy Manager backs up all the volumes.
Circular logging must be disabled to implement the backup of Exchange server databases by AdvancedCopy Manager. A backup cannot be performed if circular logging is enabled.
With circular logging disabled, the log files are sequentially created as the amount of logged data increases and accordingly they squeeze the free volume space. When a backup is successful, however, backed-up data that is no longer needed in the volume is deleted.
Backup disks must be placed on the ETERNUS storage system.
If the backup disk is placed on the same disk array device as the transaction volume, the OPC, EC, and QuickOPC functions can be used. If the backup disk is placed on a different disk array device from the transaction volume, the REC functions can be used.
There should be no complications if the backup disk is the same size as or larger than the transaction disk. However, if the transaction disk and the backup disk are of different sizes, some space will be wasted and the operating procedure will become complicated. Accordingly, it is recommended that transaction disks and backup disks be of the same size.
A backup volume must be prepared before the operation explained in "Reading information on the devices under control of the storage server" in the ETERNUS SF AdvancedCopy Manager Operator's Guide is performed (see Preparation). A backup volume must be created so that the partition size and start offset match those of the transaction volume (because Advanced Copy is executed in units of disks when the backup is performed). In a "1 LUN = 1 partition" configuration, it is enough to match the partition size; the start offset need not be recognized.
Create copy set groups using the copy set registration command (eternus_copyset).
Register with the copy set group all copy sets related to the storage group being backed up.
Only one transaction disk can be registered with a copy set group. Copy sets with the same transaction disk but different backup disks cannot be registered in the same copy set group.
To keep multiple generations of shadow copies, prepare multiple copy set groups.
Exchange linkage commands (swsrpXXX_exchange) perform processing on particular copy sets based on the storage group name and the copy set group name. Accordingly, multiple storage groups can be registered in a single copy set group.
To keep multiple generations of shadow copies, create a copy set group for each generation you wish to keep.
If separate copy set groups are created for each storage group, the number of copy set groups required is given by <number of storage groups> x <number of generations kept>.
There must be only one backup server for storage groups. If storage groups are made up of multiple disks, it is not possible to back up each disk to a different backup server.
However, if a copy set group includes multiple storage groups, each storage group can use a separate backup server.
If multiple backup servers are used for a single storage group, use a different backup server for each copy set group.
Before starting the Exchange server backup operation, do the following preparations:
Registering the provider
Configuring the Exchange server environment
Preparing a drive letter map file
Registering the provider copy set
Saving the provider management file
Creating a device management file
Saving the device management file
Setting up the original and replica volumes
Registering database information
On both the Exchange server and backup server, execute the provider registration/deletion command(eternus_provider) to register the ETERNUS hardware provider. Do this operation with the Exchange server on all nodes that make up the cluster group.
Set up the Exchange server based on the results of the backup operation design.
This function supports Exchange server 2003 Service Pack 1 and Service Pack 2. Apply Service Pack 1 or Service Pack 2 if it has not been applied.
Allocate the Exchange server EDB, STM, CHK, and LOG files.
See "Designing storage groups" for details.
Be sure to install the Exchange server system management tools on the backup server and apply Service Pack 1 and Service Pack 2 to it.
Create a cluster environment for Storage server transactions.
Refer to the following manuals for more information about creating a cluster environment for Storage server transactions .
ETERNUS SF AdvancedCopy Manager Cluster Application Guide
"Notes on cluster operation" in this manual
"Notes on replication operation in cluster operation" in this manual
The drive letter map file defines the drive letters (or mount points) to be assigned to the shadow copies (backup volumes).
Create a drive letter map file with the following file name on the backup server:
Configuration settings directory\etc\repl\data\EXDMAP.INI
An example of the settings in the drive letter map file is shown below.
[DRVMAP] g1d1p1=F: g1d2p1=C:\mnt |
During backup processing, a drive letter is assigned to a backup volume based on the settings in the drive letter map file.
The drive letter assignment is not performed if no drive letter is defined in the drive letter map file or the file contains a setting error (the relevant drive letter is in use, an invalid directory is specified for a mount point, etc.)
Complete the following additional steps when performing the operations explained in "Preparation"
Register all the transaction volumes (to which *.edb, *.stm, *.log, and *.chk are allocated) and their backup volumes as replica volumes.
Set the transaction volumes as original volumes and the backup volumes as replica volumes (do not incorrectly set the original and replica volumes).
Set the Exchange server (original volume server) as an operation server (specify "ORG" or "BOTH" as an argument of the -o option in the replicated volume information setting command).
Do not specify the u option because the restoration needs to be performed.
Execute the copy set registration command on the Exchange server to register the correspondence between transaction disks and backup disks. Execute the command in the primary node making up the cluster group.
Example:
C:\>C:\Win32app\AdvancedCopyManager\bin\eternus_copyset -set -o g1d1@ EXCHG-SVR -t g1d11@BKUP-SVR -c QOPC -g BK1 eternus_copyset set successfully completed. C:\> |
Save the provider management files in case of emergency. The files to be saved are as follows:
[Exchange server]
ACM shared-data shared-disk drive:\etc\opt\swstorage\etc\prov_copyset.ini
[Backup Server]
Configuration settings directory\etc\prov_copyset.ini
Create a device definition file on the backup server according to the following procedure:
Confirm the OLU number and physical device number of the copy destination device.
Execute the eternus_getolu command to confirm the OLU number and physical device number of the copy destination device.
See copy place disk number display command(eternus_getolu) for the eternus_getolu command.
Confirm the device instance IDs of the copy destination devices.
Confirm the device instance IDs of all copy destination devices.
Confirm the device instance IDs as follows:
Start Computer Management.
Select [Start] -> [Management Tool] -> [Computer Management].
Select [Disk Management] from [Computer Management] to display the properties of the device subject to a backup. Confirm the location (Bus Number, Target ID, LUN).
From [Computer Management], select [Device Manager] -> [Disk Drive] to display the disk drives.
Select Disk Device (such as FUJITSU GR740 SCSI Disk Device) from [Disk Drive] to confirm the device subject to a backup.
Select Disk Device (such as FUJITSU GR740 SCSI Disk Device) and right-click, then select Properties. Confirm the Disk Device for which the location (Bus Number, Target ID, LUN) confirmed in 2) of Step 2 matches the location (Bus Number, Target ID, LUN) indicated in the displayed Properties.
When the location confirmed in 2) of Step 2 matches a location confirmed in 4) of Step 2, select Detail to confirm the device instance ID.
Save the combination of the physical disk number and the device instance ID confirmed in 5) of Step 2 to a text file.
The device instance ID can be displayed by executing the eternus_getins command.
See device instance ID display command (eternus_getins) for the eternus_getins command.
Create a device definition file.
Create a device definition file using a combination of the destination device OLU number confirmed in Step 1 and the device instance ID confirmed in Step 2.
Name the following device definition file with notepad:
ACM configuration settings directory\etc\eternus_hardope.def
The definition format is as follows:
OLU number, device instance ID
Example:
| 149,MPIO\DISK&VEN_FUJITSU&PROD_E4000&REV_0000\1&7F6AC24&0&4534353053323041232323232020202020203641303030303330333033390000 150,MPIO\DISK&VEN_FUJITSU&PROD_E4000&REV_0000\1&7F6AC24&0&4534353053323041232323232020202020203641303030303330333033390001 151,MPIO\DISK&VEN_FUJITSU&PROD_E4000&REV_0000\1&7F6AC24&0&4534353053323041232323232020202020203641303030303330333033390002 152,MPIO\DISK&VEN_FUJITSU&PROD_E4000&REV_0000\1&7F6AC24&0&4534353053323041232323232020202020203641303030303330333033390003 |
For the sake of safety, save the device definition file of the backup server.
Save the following file:
ACM configuration settings directory \etc\eternus_hardope.def
Register Exchange server database information in the management file using the Exchange2003 database information registration command (swsrpdbinfo_ex2k3). Before backing up or restoring the Exchange server databases, execute this command on the Exchange server to perform an initialization. Execute this command also after the Exchange server configuration has been changed.
Example: This example stores the database information of the storage group FirstStorageGroup. Execute the command from the business server (EXCHG-SVR).
C:\>set SWSTGNODE=nodeAGT C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpdbinfo_ex2k3 -evs VSVR -sgname FirstStorageGroup swsrpdbinfo_ex2k3 successfully completed C:\> |
Back up the Exchange server databases by executing the Exchange VSS backup command (swsrpvssbackup_exchange) on the Exchange server. This command backs up the databases in units of storage groups.
When backups are executed, all databases (stores) in the storage group must be mounted. If any databases are not mounted, the backup processing will terminate abnormally.
Example:
C:\>set SWSTGNODE=nodeAGT C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpvssbackup_exchange -evs VSVR -sgname FirstStorageGroup -copygrp BK1 swsrpvssbackup_exchange successfully completed C:\> |
When this command is executed, the following processing is performed:
Shadow copies of all of the files that make up the storage group (*.edb, *.stm, *.log and *.chk) are created on the backup volume for the specified copy set group. After the shadow copies have been created, the backup volume becomes read-only.
For snapshot type backups, shadow copies are created as a result of OPC or QuickOPC running.
For synchronous type backups, shadow copies are created when an EC or REC in equivalence maintenance state is suspended.
After a shadow copy is created, ESEUTIL is used to verify the backup data (the -skipchk option can be used to skip the backup data verification). After the backup is finished, Exchange deletes (abandons) any unnecessary log data.
A writer metadata document and a backup components document are saved to the following locations on the backup server. These files are used for the restoration.
|
File |
Output location |
|---|---|
|
Writer metadata document |
[If the copy set group name is "BkupGroup" (the default name)] Configuration settings directory\etc\repl\data\exchange\<Exchange server storage server name>\metadoc\<storage group name>.wmd.xml [If the copy set group name is anything other than "BkupGroup" (the default name)] Configuration settings directory\etc\repl\data\exchange\<Exchange server storage server name>\metadoc\<storage group name>.<copy set group name>.wmd.xml |
|
backup components document |
[If the copy set group name is "BkupGroup" (the default name)] Configuration settings directory \etc\repl\data\exchange\<Exchange server storage server name>\metadoc \<storage group name>.bcd.xml [If the copy set group name is anything other than "BkupGroup" (the default name)] Environment settings directory\etc\repl\data\exchange\<Exchange server storage server name>\metadoc \<storage group name>.<copy set group name>.bcd.xml |
Backup notes
The VSS specifications do not allow multiple sets of backup processing to be executed in parallel. When two or more storage groups exist, multiple sets of backup processing need to be executed sequentially, not in parallel. If multiple backup processes are executed in parallel, later processes will be put on hold until the shadow copy creation for the prior processes completes.
The progress status of the advanced copy and information about the shadow copies that have been created can be checked by executing the Exchange VSS shadow copy management command (swsrpshadowadm_exchange).
Example: (For snapshot type backups)
C:\>set SWSTGNODE=nodeAGT
C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpshadowadm_exchange status -evs VSVR -sgname FirstStorageGroup -copygrp BK1
[Shadow Copy Status]
Original-Volume Replica-Volume Latest-Creation-Time Snapshot-ID SnapshotSet-ID SnapshotSet-ID
g1d1p1@EXCHG-SVR(\\?\Volume{XXXX}\) g1d11p1@BKUP-SVR(\\?\Volume{XXXX}\) 2005/06/23 03:23 {XXXX} {XXXX}
g1d2p1@EXCHG-SVR(\\?\Volume{XXXX}\) g1d12p1@BKUP-SVR(\\?\Volume{XXXX}\) 2005/06/23 03:23 {XXXX} {XXXX}
[AdvancedCopy Status]
Type Group-Name Original-Disk Replica-Disk Status Execute Trk Update
QOPC BK1 g1d1@EXCHG-SVR g1d11@BKUP-SVR snap ---- on 3%
QOPC BK1 g1d2@EXCHG-SVR g1d12@BKUP-SVR snap 83% on ----
C:\> |
Example: (For synchronous type backups)
C:\>set SWSTGNODE=nodeAGT
C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpshadowadm_exchange status -evs VSVR -sgname FirstStorageGroup -copygrp BK1
[Shadow Copy Status]
Original-Volume Replica-Volume Latest-Creation-Time Snapshot-ID SnapshotSet-ID SnapshotSet-ID
g1d1p1@EXCHG-SVR(\\?\Volume{XXXX}\) g1d11p1@BKUP-SVR(\\?\Volume{XXXX}\) 2005/06/23 03:23 {XXXX} {XXXX}
g1d2p1@EXCHG-SVR(\\?\Volume{XXXX}\) g1d12p1@BKUP-SVR(\\?\Volume{XXXX}\) 2005/06/23 03:23 {XXXX} {XXXX}
[AdvancedCopy Status]
Type Group-Name Original-Disk Replica-Disk Status Execute Trk Update
EC BK1 g1d1@EXCHG-SVR g1d11@BKUP-SVR suspend ---- ---- ----
EC BK1 g1d2@EXCHG-SVR g1d12@BKUP-SVR suspend ---- ---- ----
C:\> |
When a backup is executed, the metadata documents (writer metadata document and backup component document) required for the restoration are output to the backup server.
When data is backed up to tape, not only the data in the backup volume but also these two files need to be backed up. A flow of backup processing including a backup to tape is shown in the figure below.
If a backup disk (LUN) has volumes (partitions), the volumes are temporarily deleted before synchronous processing starts (for synchronous type backups) or before backup processing starts (for snapshot type backups). Accordingly, no processes that use the backup volumes can exist when the backup is taken.
The volume is deleted while the volume is locked by the requester. If locking the volume fails, locking is retried. The standard retry operation is as follows:
If locking fails, it is retried one second later.
If the lock cannot be acquired in 20 retries (21 times including the first attempt), processing is canceled and the command terminates abnormally.
The maximum number of retries (default value = 20) and the retry interval (default value = 1 second) can be changed by creating a setup file called the VSS copy destination disk locking specification file.
This setup file can also be used to instruct the following operation for preprocessing of the copy destination value:
Disable all the file handles in the volume before locking is retried. (Forced lock function)
Create a VSS copy destination disk locking specification file with the following file name on the backup server:
Configuration settings directory\etc\repl\data\VSSDSTLOCK.INI
The setting format of this file is the same as the copy destination volume locking specification file except that the section name is "gXdY" instead of "gXdYpZ."
Because only one backup disk can be associated with a transaction disk, one backup disk is used repeatedly.
The backup disk is in one of states A to B in the following figure. If the backup disk is in state B or C when the backup is to be executed, it is put back in state A before backup processing begins.
Because the backup disk is never put in state C except before the initial backup, it moves between states A and B during the backup operation.
The following steps must be completed before performing a restoration:
Dismount the storage group (only when performing a restoration using EC/REC))
Stop resource monitoring for the physical disk
Stop the EC/REC session (only for synchronous type backups)
Stop the QuickOPC session (only for differential snapshot type backups)
Start restoration synchronous processing and coordinate equivalence maintenance state (only when performing a restoration using EC/REC)
Use the Exchange system manager to restore using EC/REC. From the Exchange system manager, dismount all of the stores in the storage group to be restored. After dismounting the stores, close the Exchange system manager.
The transaction volume that is the copy destination for EC/REC is an MSCS shared volume, and therefore, resource monitoring for the target physical disk must be stopped before the EC/REC is executed. If EC/REC is executed without stopping resource monitoring, the cluster group will fail over.
The disks for which resource monitoring is to be stopped differ according to the restoration method. Refer to "Executing the restoration" for more information.
For "Point-in-Time" restorations, all physical disk resources where storage groups (*.edb, *.stm, *.log and *.chk) are located must be stopped.
For "roll forward" restorations, only physical disk resources where database files (*.edb and *.stm) are located must be stopped.
For roll forward restorations, no problems will occur if resource monitoring is stopped for all physical disk resources where storage groups are located.
Stop resource monitoring by switching the resources to maintenance mode using the cluster command.
Example:Switching physical disk resource "Disk J:" to maintenance mode
C:\>cluster ExampleCluster res "Disk J:" /maint:on Setting maintenance mode for resource 'Disk J:' Resource Group Node Status -------------------- -------------------- --------------- ------ Disk J: GRP1 NODE1 Online(Maintenance) C:\> |
For synchronous type backups, all EC/REC sessions that have been set up on the transaction disk must be canceled using the Exchange VSS synchronous processing command (swsrpvsssync_exchange) before the restoration is executed. The EC/REC sessions that have been set up for the transaction disk can be checked using the Exchange VSS shadow copy management command (swsrpshadowadm_exchange).
Restoration cannot be executed if there are any backup disks on the transaction disk that are being copied via EC/REC or that are suspended or in equivalence maintenance state.
For differential snapshot type backups, all of the QuickOPCs that have been set up on the transaction disk must be canceled using the Exchange VSS shadow copy management command (swsrpshadowadm_exchange) before the restoration is executed.
Restoration cannot be executed if there are any backup disks on the transaction disk that are undergoing QuickOPC.
To cancel QuickOPCs where physical copies are in progress, the shadow copies must be deleted first.
If restoration synchronous processing has been started on the volume being restored, synchronous processing waits until equivalence maintenance status is reached.
Start restoration synchronous processing using the Replication creation command (swsrpstartsync).
Use either the Exchange operation status display command (swsrpstat_exchange) or the operation staus dislay command (swsrpstat) to wait until synchronous processing reaches equivalence maintenance state.
The volumes that are subject to restoration synchronous processing depend on the restoration method.
Restoration is performed separately for each storage group, using the Exchange VSS restoration execution command (swsrpvssrestore_exchange) on the Exchange server. When this command is executed, all of the databases (stores) in the storage group are dismounted. Restoration is performed using advanced copies, but the processing content is different depending on the copy execution status when the restoration command is executed.
If restoration synchronous processing is not being performed, restoration is performed by starting an OPC logical copy.
If restoration synchronous processing is being performed and is in equivalence maintenance state, restoration is performed by suspending the EC/REC.
There are two restoration methods:
Point-in-time restoration (restoring to the point when the backup was taken)
Roll forward restoration (restoring to the latest point)
Point-in-time restoration works by restoring all of the databases in the storage group to the state they were in when the backup was taken. Point-in-time restorations are executed by specifying the "point" option with the Exchange VSS restoration execution command (swsrpvssrestore_exchange). If the "point" option is specified, this command will restore the storage group to the point when the backup was taken by restoring all of the files (*.edb, *.stm, *.log and *.chk) that make up the storage group.
Example:
C:\>set SWSTGNODE=nodeAGT C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpvssrestore_exchange -evs VSVR -point -sgname FirstStorageGroup -copygrp BK1 swsrpvssrestore_exchange successfully completed C:\> |
Roll forward restorations restore all of the databases in the storage group to the latest point.
Roll forward restorations are executed by specifying the "roll" option with the Exchange VSS restoration execution command (swsrpvssrestore_exchange). If the "roll" option is specified, the restore is performed as follows:
Only database files (*.edb and *.stm) are restored.
Logs are applied using the log files that exist on the transaction volume.
Databases are restored to the latest point.
Example:
C:\>set SWSTGNODE=nodeAGT C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpvssrestore_exchange -evs VSVR -roll -sgname FirstStorageGroup -copygrp BK1 swsrpvssrestore_exchange successfully completed C:\> |
In order to execute a roll forward restoration, the following conditions must be met:
All of the transaction logs that have been created since the latest complete backup was taken must exist.
The generation numbers (the "XXXXX" part of EOnXXXXX.log) of the existing log files must be consecutive.
A new backup must be created immediately if the database path is changed.
A new backup must be created immediately after the commands ESEUTIL /p (restores faults or damaged databases) or ESEUTIL /d (defrags or compresses databases) are executed.
A backup of all databases in the storage group must be taken immediately after any databases are added or deleted.
.
If restoration has been performed using EC/REC, the following operations must be performed after the restoration:
Stop restoration synchronous processing
Restart resource monitoring for physical disks.
Mount the storage group.
Stop restoration synchronous processing by executing the replication cancel command (swsrpcancel) on the Exchange server.
Example:
C:\>set SWSTGNODE=nodeAGT C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpstat_exchange -evs VSVR -sgname FirstStorageGroup Server Original-Volume Replica-Volume Direction Status Execute EXCHG-SVR g1d1p1@EXCHG-SVR g1d11p1@BKUP-SVR reverse suspend ---- EXCHG-SVR g1d2p1@EXCHG-SVR g1d12p1@BKUP-SVR reverse suspend ---- EXCHG-SVR g1d1p1@EXCHG-SVR g1d13p1@BKUP-SVR ---- ---- ---- EXCHG-SVR g1d2p1@EXCHG-SVR g1d14p1@BKUP-SVR ---- ---- ---- C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpcancel g1d11p1@BKUP-SVR g1d1p1@EXCHG-SVR FROM=g1d3p1@BKUP-SVR, TO=g1d1p1@EXCHG-SVR swsrpcancel completed C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpcancel g1d12p1@BKUP-SVR g1d2p1@EXCHG-SVR FROM=g1d4p1@BKUP-SVR, TO=g1d2p1@EXCHG-SVR swsrpcancel completed C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpstat_exchange -evs VSVR -sgname FirstStorageGroup Server Original-Volume Replica-Volume Direction Status Execute EXCHG-SVR g1d1p1@EXCHG-SVR g1d11p1@BKUP-SVR ---- ---- ---- EXCHG-SVR g1d2p1@EXCHG-SVR g1d12p1@BKUP-SVR ---- ---- ---- EXCHG-SVR g1d1p1@EXCHG-SVR g1d13p1@BKUP-SVR ---- ---- ---- EXCHG-SVR g1d2p1@EXCHG-SVR g1d14p1@BKUP-SVR ---- ---- ---- swsrpvssrestore_exchange successfully completed C:\> |
Restart resource monitoring by canceling maintenance mode for the physical disks where resource monitoring has been stopped.
Example:
C:\>cluster ExampleCluster res "Disk J:" /maint:off Setting maintenance mode for resource 'Disk J:' Resource Group Node Status -------------------- -------------------- --------------- ------ Disk J: GRP1 NODE1 Online C:\> |
For point-in-time restorations, use the Exchange system manager to mount all stores that have been dismounted. For roll forward restorations, the stores do not need to be mounted as they are mounted already.
When data backed up to tape is to be restored, the backup data on the tape first needs to be restored on the backup server and then the Exchange VSS restore command needs to be entered.
If the backup volume is used as a shadow copy, the backup data on the tape must be restored after deleting the shadow copy. The figure below shows a flow of a restoration from tape.
To change resources that configure the backup operation, the AdvancedCopy Manager settings need to be changed. This section explains how to change the various types of settings.
To reconfigure the device used for an original or replica volume, first delete the original or replica volume and then reconfigure the device and set up the original or replica volume.
The original or replica volume must be deleted before the device used for it is reconfigured. Otherwise, the original or replica volume may not be deleted after the device reconfiguration.
Delete the original or replica volume on the device to be reconfigured. See "Deleting original/replica volumes" for more information.
Reconfigure the device.
Add the device information. See "Reading information on devices under control of the Storage server" for this operation.
Set the original or replica volume.
Prepare a drive letter map file.
To reconfigure the disk (LUN), follow the procedure below: On the primary node of the Exchange server, check the copy status using the status lookup command (eternus_query). If any copy processing is executing, stop it using the copy stop command (eternus_stopcopy).
On the primary node of the Exchange server, execute copy set deletion command (eternus_copyset) to delete the copy set information of the provider.
Delete the original or replica volume on the device to be reconfigured. See "Deleting original/replica volumes" for more information.
Reconfigure the device.
Add the device information. See "Reading information on devices under control of the storage server" for this operation.
On the primary node of the Exchange server, execute copy set registration command (eternus_copyset) to register the copy set information of the provider.
Execute "Saving the provider management file".
Execute "Creating a device definition file".
Execute "Saving a device definition file".
Set the original or replica volume.
Prepare a drive letter map file.
If the storage group information registered by the Exchange2003 database information registration command (swsrpdbinfo_ex2k3) is changed, the Exchange2003 database information registration command (swsrpdbinfo_ex2k3) needs to be executed again to make AdvancedCopy Manager reflect the changes.
The change in the storage group information is caused by a change in the device information on the original or replica volume. The device information must be changed before the Exchange storage group information registration command is executed.
To change the Storage server name, follow the procedure below:
On the primary node of the Exchange server, check the copy status using the status lookup command (eternus_query). If any copy processing is executing, stop it using the copy stop command (eternus_stopcopy).
On the Exchange server primary node, execute the copy set deletion command (eternus_copyset) to delete the copy set information of the provider.
Delete the original or replica volume on the device to be reconfigured. See "Deleting original/replica volumes" for more information.
Change the Storage server name. For details, see "Changing the Storage server name".
On the primary node of the Exchange server, execute copy set registration command (eternus_copyset) to register the copy set information of the provider.
Execute "Saving the provider management file".
Set the original or replica volume.
The backup operation of the Exchange server databases can be stopped by the following Steps:
Deleting the shadow copy
Stopping copy processing in execution
Delete the shadow copy by executing the Exchange VSS shadow copy management command (swsrpshadowadm_exchange) on the Exchange server.
Example:
C:\>set SWSTGNODE=nodeAGT C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpshadowadm_exchange delete -evs VSVR -sgname FirstStorageGroup-copygrp BK1 swsrpshadowadm_exchange delete successfully completed C:\> |
Executing this command:
Deletes the shadow copy existing on the backup server.
Deletes the backup server writer metadata documents and the backup component documents.
Makes the hardware provider stop the OPC physical copying if it is in progress.
For synchronous type backups, the synchronous processing must be stopped first.
Stop synchronous processing by executing the Exchange VSS synchronous processing command (swsrpvsssync_exchange) on the Exchange server.
Example:
C:\>set SWSTGNODE=nodeAGT C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpvsssync_exchange cancel -evs VSVR -sgname FirstStorageGroup -copygrp BK1 swsrpvsssync_exchange successfully completed C:\> |
It is also possible to stop synchronous processing by executing the EC stop command (eternus_stopcopy).
To perform differential snapshot type backups, tracking processing must be stopped first.
Stop tracking processing by executing the Exchange VSS shadow management server command (swsrpshadowadm_exchange) on the Exchange server.
Example:
C:\>set SWSTGNODE=nodeAGT C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpshadowadm_exchange stopqopc -evs VSVR -sgname FirstStorageGroup -copygrp BK1 swsrpshadowadm_exchange successfully completed C:\> |
It is also possible to stop tracking processing by executing the copy stop command (eternus_stopcopy).
Stop restoration copy processing by executing the replication cancel command (swsrpcancel) on the Exchange server.
Example:
C:\>set SWSTGNODE=nodeAGT C:\> C:\Win32App\AdvancedCopyManager\bin\swsrpcancel g1d11p1@BKUP-SVR FROM=g1d3p1@BKUP-SVR, TO=g1d1p1@EXCHG-SVR swsrpcancel completed C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpcancel g1d12p1@BKUP-SVR g1d2p1@EXCHG-SVR FROM=g1d4p1@BKUP-SVR, TO=g1d2p1@EXCHG-SVR swsrpcancel completed C:\>C:\Win32App\AdvancedCopyManager\bin\swsrpstat_exchange -evs VSVR -sgname FirstStorageGroup Server Original-Volume Replica-Volume Direction Status Execute EXCHG-SVR g1d1p1@EXCHG-SVR g1d11p1@BKUP-SVR ---- ---- ---- EXCHG-SVR g1d2p1@EXCHG-SVR g1d12p1@BKUP-SVR ---- ---- ---- EXCHG-SVR g1d1p1@EXCHG-SVR g1d13p1@BKUP-SVR ---- ---- ---- EXCHG-SVR g1d2p1@EXCHG-SVR g1d14p1@BKUP-SVR ---- ---- ---- C:\> |
When this command is executed, any restoration copy processing in progress will be stopped.
It is not generally possible to use a transaction volume as a normal file system after restoration copy processing has been stopped; the transaction volumes must be reformatted so that they can be used again.
To uninstall AdvancedCopy Manager that has been used to perform the backup operation of the Exchange server databases, the following operations must be performed in advance:
Stopping backup copy processing.
Deleting the copy set of the provider.
Deleting original and replica volumes.
Deleting database information
Deleting the Storage server.
Canceling the cluster settings for the storage server.
Canceling the provider registration.
Uninstall AdvancedCopy Manager.
On the primary node of the Exchange server, check the copy status using the status lookup command (eternus_query). If any copy processing is executing, stop it using the copy stop command (eternus_stopcopy).
Delete the copy set information of the provider on the prime node of the Exchange server.
See copy set deletion command (eternus_copyset) for information on how to delete the copy set.
Delete the original and replica volumes that have been set up.
See replica volume information deletion command (swsrpdelvol) for information on how to delete the original and replica volumes.
Delete Exchange server database information in the management file.
Refer to"Exchange2003database information registration command(swsrpdbinfo_ex2k3)" about the deletion method of database information.
Delete the storage server to be uninstalled from the control of AdvancedCopy Manager.
See the description about the server deletion in the ETERNUS SF AdvancedCopy Manager User's Guide for information on how to delete the storage server from the Web client.
For information on how to delete the storage server with a command, see server information deletion command (stgxfwcmdelsrv).
Cancel the cluster settings for the storage server on the Exchange server.
Refer to the ETERNUS SF AdvancedCopy Manager Operator's Guide for cluster environment for more information about canceling cluster settings.
Cancel the provider registration on both the Exchange server and the backup server.
Refer to the provider registration command (eternus_provider) for more information about how to cancel the provider registration.
Do not cancel the provider registration if there are other storage groups on the backup and Exchange servers where operations will continue.
|
Contents
Index
|