HP StorageWorks SAN Virtualization Services Platform Best Practices Guide (5697-0935, May 2011)

virtual disk as the source virtual disk. The merge creates a new task, resuming mirroring from the
newest PiT that is identical on the source and destination.
Merge with rollback disabled
To re-establish an asynchronous mirror task between virtual disks that were properly split, the last
PiT copied from the source to the destination is identical to the source, and the PiT’s temporary
virtual disk on the destination site is empty, so the merge succeeds.
Merge with rollback disabled is safe, because it will not discard unsynchronized data and fail if
unsynchronized data exists. It is usually part of a planned failback after a failover.
Merge with rollback enabled
To merge a virtual disk after detaching an asynchronous mirror task, the last PiT temporary virtual
disk on the source and destination may not be empty. You can perform a merge, allowing the
mirror to rollback to a PiT earlier than the newest PiT on the destination. In this case, the
asynchronous mirror service finds the most recent PiT on the destination that is identical to a PiT
on the source and rolls back the destination virtual disk to that PiT, erasing newer PiTs as necessary.
The merge fails if no common PiT can be found.
In case of a real failure or disaster, a detach would be performed, as this is the only option available
at that time. This is generally referred to as an unplanned failover. An unplanned failover on
asynchronous mirrors almost always involves losing the latest data. You can minimize recovery
after an unplanned failover if you have user-created PiTs rather than automatic PiTs.
To perform an unplanned failover:
1. Detach the mirror. Splitting the mirror is not possible during a failure of the source site;
detaching is the only option available to make the destination site available to hosts.
2. Move host permissions from the source to destination site. If the disaster recovery site has a
second set of application servers, add host permissions to these servers on the destination site.
Remember to remove host permissions from the source site.
3. Run the application on the destination site.
4. Merge from the destination site with rollback enabled. Once the former source site is up again,
the merge function can be used to reconnect the mirror, but in the reverse direction. Start the
merge from the destination site (in use by the application at this time). The rollback option will
allow the mirror engine to discard any data still in the last PiT’s temporary virtual disk and
even possibly roll back to an older PiT, if necessary, to find the newest identical PiT.
A planned failover and failback are almost identical except for the direction of the mirror. In an
unplanned failover, data loss must be accepted. A planned failover or failback must be performed
without losing data or even the risk of losing data. A planned failover or failback uses merge with
the rollback option disabled. This requires that the mirror task be split instead of detached prior
to the merge.
To perform a planned failover or failback:
1. Unmount the source site. This typically involves stopping the application or shutting down the
host.
2. Remove host permissions to the source site.
3. Create a user PiT on the source site and wait until the PiT has been synchronized to the
destination site.
4. Suspend the asynchronous mirror task.
5. Split the asynchronous mirror task.
6. Initiate the merge from the destination site with the rollback option disabled.
Detach, split, and merge 51