Back up the Exchange server databases by executing swsrpvssbackup_exchange (Exchange VSS backup execution command) on the Exchange server. This command backs up the databases in units of storage groups.
Note
When backups are executed, all databases (i.e., 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 (ie, files with extensions *.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 having been run.
For synchronous type backups, shadow copies are created when EC or REC in the equivalency 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 any unnecessary log data.
A "writer metadata" document and "backup components" document are saved to the following locations on the backup server. These files are used for restoration:
File | Output location |
---|---|
Writer metadata document |
|
backup components document |
|
Note
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, future processes will be put on hold until the shadow copy creation for the prior processes completes.
The progress status of the Advanced Copy and the information about the shadow copies that have been created can be checked by executing swsrpshadowadm_exchange (Exchange VSS shadow copy management command).
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 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 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 (ie, the writer metadata document and the backup component document) that are required for restoration are saved to the backup server.
When data is backed up to tape, both the data in the backup volume and these two metadata files need to be backed up. The flow of backup processing including a backup to tape is shown in the figure below.
If a backup disk (LUN) uses volumes (i.e., partitions), the mount point is temporarily released and the volumes are 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 be active when the backup is taken.
The mount point is released and the volume is deleted while the volume is locked by the requester. If locking of the volume fails, the system will continue to attempt locking until successful. The standard retry operation is as follows:
If locking fails, it is retried at one second intervals.
If the locking cannot be achieved in 20 retries (i.e., 21 times including the first attempt), processing is cancelled and the command terminates abnormally.
The maximum number of retries (the default value = 20) and the retry interval (for which the default value = 1 second) can be changed by creating a configuration file called the VSS copy destination disk locking specification file.
This configuration file can also be used to instruct in the pre-processing of the copy destination volume:
Disable all the file handles in the volume before subsequent attempts at locking are performed (using the Forced lock function).
Create a VSS copy destination disk locking specification file with the following file name on the backup server:
<Environment directory>\etc\repl\data\VSSDSTLOCK.INI |
The format of this file is the same as for the copy destination volume locking specification file, except that the section name is "gXdY" instead of "gXdYpZ".
The state of the backup disk changes to either A, B, or C in the following figure. If the backup disk is in either state B or C when the backup is to be executed, it is placed into state A before backup processing can begin.
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.