HP StorageWorks SAN Virtualization Services Platform administrator guide (5697-0204, January 2010)

11. Each SVSP domain now sees the VSM servers of the other SVSP domain with status degraded
because the FC HBAs that previously used to connect the SVSP domains are no longer used.
Delete the FC HBAs that previously used to connect the SVSP domains from the HBA lists on both
SVSP domains. You can access the HBA list from the HBA node in the tree.
Testing or validating your ability to recover from a DR site
without detaching or splitting the async mirror group
The objective is to verify that the DR site has data from which you can recover. This can be achieved
by creating snapshots on the mirror PiTs of the destination element and presenting them to a test
server. During this process, all mirror service tasks remain operational, and none of the PiTs that were
created is modified. All the data modifications which the application does on the snapshot are written
aside to a dedicated temporary virtual disk which makes the snapshot writable. When the test is
complete, the snapshot is no longer needed, and should be deleted in order to allow the PiT from
which it was created to be deleted as part of the regular mirror process of deleting older PiTs to
maintain the user defined limit on the total number of PiTs.
To test/validate the data on the DR site:
1. Log in to the DR site's SVSP domain.
2. Create a snapshot from a PiT of the destination element that you want to validate, and present
it to a test server.
3. Test the application against the snapshot that was presented to a test server, and make sure the
snapshot is usable. There is a chance that the application will not be able to use the snapshot
as it is. This is because mirror standard PiTs are taken at times which are asynchronous to the
application state and capture only the data on back-end LU, whereas the application, may, at
that time, have some data in the host cache that was not yet committed to back-end LU. You may
need to run some application specific recovery procedures to bring the application online. By
definition, the problem should not affect user PiTs that were taken while all application data was
fully committed to back-end LU.
4. When the test is completed, stop the test application, unmount the snapshot, and delete the
snapshot from the SVSP domain.
Testing a DR site or switching between sites
In an actual disaster event, you must use the detach feature rather than the split feature to stop tasks
so that you can resume production from destination virtual disks. However, when you want to test
failover and failback to and from your DR site, you can take steps to ensure that no data is lost. These
are the same steps that you would use if you need to perform a planned switchover from one site to
another.
To fail over from the main site to the DR site:
1. Plan a downtime window, based on the organization’s schedule and the amount of source data
waiting to be replicated.
2. Shut down the application at the scheduled time.
3. Unmount the virtual disk on the host.
4. Log in to the main site's SVSP domain.
5. Remove the host’s permission to access the source virtual disk of an async mirror group.
6. Create a user PiT on the group.
Site failover recovery with asynchronous mirrors98