HP Application Recovery Manager software Integration guide (March 2008)

completed when the waiting period expires, Application Recovery Manager
aborts the backup session.
You can increase the waiting period duration by setting the
OB2VSS_WAIT_TIMEOUT omnirc variable. The variable value determines the
period (in seconds) for which Application Recovery Manager agent waits for
mirrors, which are created in one session, to become fully synchronized. If the
OB2VSS_WAIT_TIMEOUT variable is set to more than 2 hours (7200 seconds),
you should additionally increase the value of the global variable SmIdleTimeout
past the value of OB2VSS_WAIT_TIMEOUT. The value of SmIdleTimeout
should be specified in minutes, rather than seconds.
If backup sessions are lengthy and there is a possibility that VSS backup window
will not be met, it is highly recommended that you first switch the Disk Array XP
VSS hardware provider to resync mode. Afterwards, consecutively run backup
sessions until the backup session count reaches the current value of the Number
of replicas rotated option. This will start creation of replicas that will be used in
scheduled backups. Shadow copy creation failures or timeouts in these backup
sessions can be ignored.
There is a problem with Microsoft Exchange Server 2007 when running in a CCR
environment with Disk Array XP as the VSS hardware provider, and where the
backup system is the virtual server. In such setup, in case of a failover, the backup
system may change the physical node where the virtual server runs.
Such physical node change may happen in two cases:
When backup sessions are configured to always use the system where the
database copy resides (in the GUI, the Exchange Replication service instance
is selected as the backup object, and the additional Exchange option Revert
the active node on failure is selected).
When the system where the production database resides is used as the backup
system.
The problem does not occur in a setup where the backup system is a physical
node. In such setup, in case of a failover, the next backup session will fail to
rotate replicas which were used in the oldest session. Such replica rotation failure
should not prevent the current session from succeeding. Consider the following:
If only one disk array is used, ensure that the VSS hardware provider does
not run out of disk space (LUNs that belong to secondary volumes (S-VOLs))
due to replica rotation failure.
If two disk arrays are used, ensure that the second array is configured in the
same way as the first disk one.
As soon as the old backup system is up and running, you should use the
omnidbvss command to manually delete all the sessions that should have been
deleted in the replica rotation process. Do not use tools like Command View XP
Integrating the Application Recovery Manager ZDB integrations and Microsoft Volume
Shadow Copy Service
36