IBM XIV Storage System Copy Services and Migration

The mirror has the following characteristics:► When a mirror is created, it is always initially in inactive mode.► A Mirror can only be deleted when its is in inactive mode.► Transitions between the two states can only be performed from the XIV with the master.► In a DR situation, a role change changes the slave peers (at the secondary system) to amaster role (so that production can resume at the secondary). When the primary site isrecovered, and before the link is resumed, the master must be changed to a slave(change_role).DeletionWhen a mirror pair (volume or consistency group) is inactive, the mirror relationship can bedeleted. When a mirror relationship has been deleted, the XIV forgets everything about therelation. If you want to set up the mirror again, the XIV must do an initial copy again from thesource to the target.Note that when the mirror is deleted, the slave volume becomes a normal volume again, butthe volume is locked, which means that it is write protected. To enable writing to the volumego to the Volumes list panel. Right-click the volume and select Unlock.The slave volume must also be formatted before it can be part of a new mirror. Formattingalso requires that all snapshots of that volume be deleted.5.2 Disaster recoveryThere are two broad categories of disaster, one that destroys the primary (local) site or thedata there and one that makes the primary site or the data there unavailable but that leavesthe data intact. However, within these broad categories there are a number of situations thatmay exist. Some of these and the recovery procedures are considered below:►►►A disaster that makes the XIV at the primary site unavailable but the site itself and theservers there are still availableIn this scenario the volumes/CG on the XIV at the secondary site can be switched tomaster volumes/CG, servers at the primary site can be redirected to the XIV at thesecondary site, and normal operations can start again. When the XIV at the primary site isrecovered the data can be mirrored from the secondary site back to the primary site.When it is synchronized the peer roles can be switched back to the master at the primarysite and the slave at the secondary site and the servers redirected back to the local site.A disaster that makes the entire primary site and data unavailableIn this scenario, the standby (inactive) servers at the secondary site are activated andattached to the secondary XIV to continue normal operations. This requires changing therole of the slave peers to become master peers.After the primary site is recovered, the data at the secondary site can be mirrored back tothe primary site to become synchronized once again. If desired, a planned site switch canthen take place to resume production activities at the primary site. See 5.3, “Role reversal”on page 134, for details related to this process.A disaster that breaks all links between the two sites but both site remain runningIn this scenario the primary site continues to operate as normal. When the links arereestablished the data at the primary site can be resynchronized with the secondary site.See 5.4, “Resynchronization after link failure” on page 136, for more details.Chapter 5. Synchronous Remote Mirroring 133