Recovering from a disaster using Global Mirror
Use this information to complete the high-level steps that must be done to recover from a disaster using Global Mirror processing.
About this task
A failure at the local or primary site stops all I/O to and from the local storage server. The local server cannot communicate with the remote sites. This might impact the formation of consistency groups, because the entire process is managed and controlled by the master storage server, which is the primary storage server.
Your initial goal is to swap operations between the local and remote sites and then restart the applications. This requires that you make available a set of consistent volumes at the remote site, before the application can restart at the remote site.
When the local site is operational again, you want to return processing to the local site. Before you can return processing to the local site, you must apply changes from the remote site to the local site. These changes are the transactions that occurred after you started failover processing to the remote site.
- The local site contains A volumes (the source volume), which are copied to the recovery site using Global Copy
- The recovery (or remote) site contains B volumes (the target volume and FlashCopy source volume) and C volumes (the FlashCopy target volume)
- A storage unit at the local site is designated as the Global Mirror master and all other local (or production) storage units are designated as subordinate storage units. The master storage unit sends commands to its subordinate storage units. These subordinates work together to create a consistency group and to communicate the FlashCopy commands to the recovery (or remote) site. All status is relayed back to the Global Mirror master.