Disaster Recovery - Fail over from an inaccessible primary volume

If a catastrophic failure or disaster causes an outage on the primary site, customers can perform the following actions to quickly access their data on the secondary site. When the primary volume is inaccessible, you can force a failover to the remote replica.

Authorized hosts and volumes must be in the same data center. For example, you can't have a replica volume in London and the host in Amsterdam. Both must be in London or both must be in Amsterdam.

This action breaks the replication relationship and restoring the connection between the primary and the replica location can be time-consuming.

Fail over to the replica volume in the UI

Go to your list of IBM Cloud® Block Storage for Classic. From the Classic Infrastructure menu, click Storage > Block Storage for Classic.
Locate and click the volume name.
Click Actions > Failover.
When the primary location is unavailable, the option of Disaster Recovery Failover becomes active. Check the box to confirm you understand the failover cannot be undone without a support case.
Click Yes to proceed.

Failing over to the replica volume from the CLI

Before you begin, decide on the CLI client that you want to use.

You can either install the IBM Cloud CLI and install the SL plug-in with ibmcloud plugin install sl. For more information, see Extending IBM Cloud CLI with plug-ins.
Or, you can install the SLCLI.

Initiating a failover from the IBMCLOUDCLI

You can use the ibmcloud sl block replica-failover command to fail over operations from the source file share to the replica file share. The following example initiates a failover from the source share 560156918 to the replica share 560382016.

$ ibmcloud sl block disaster-recovery-failover 560156918 560382016
OK
Failover of volume 560156918 to replica 560382016 is now in progress.

Initiating a failover from the SLCLI

Use the following command to fail a block volume over to a specific replicant volume.

$ slcli block disaster-recovery-failover --help
Usage: slcli block disaster-recovery-failover [OPTIONS] VOLUME_ID

Options:
--replicant-id TEXT  ID of the replicant volume
 -h, --help           Show this message and exit.

Fail over to the replica volume by using the API

REST API

URL - https://USERNAME:APIKEY@api.softlayer.com/rest/v3/SoftLayer_Network_Storage/primaryvolumeId/disasterRecoveryFailoverToReplicant
Request body
```
{"parameters": [replicavolumeid]}
```

SOAP API

URL - https://api.softlayer.com/soap/v3/SoftLayer_Network_Storage

Request body

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://api.service.softlayer.com/soap/v3.1/">
<SOAP-ENV:Header>
 <ns1:authenticate>
  <username>USERNAME</username>
  <apiKey>APIKEY</apiKey>
 </ns1:authenticate>
 <ns2:SoftLayer_Network_StorageInitParameters>
  <id>primary Volume Id</id>
 </ns2:SoftLayer_Network_StorageInitParameters>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
 <ns1:disasterRecoveryFailoverToReplicant>
   <replicantId xsi:type="int">replica Volume ID</replicantId>
 </ns1:disasterRecoveryFailoverToReplicant>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Fail back to the original primary site in the UI

After a disaster event, IBM Cloud® begins remediation work to return the impacted locations to normal operations. When the site is restored, you can initiate a Failback to the original site by clicking Storage, Block Storage for Classic in the IBM Cloud® console.

Click your active volume ("target").
Next, click Replica and click Actions.
Select Failback. When the primary location is marked unavailable, the option of Disaster Recovery Failback becomes active.

During the Disaster Recovery Failover, the system is forced to fail over to the replica site and the replication relationship is severed. To be able to fail back to the original site after the site is restored to normal operations, the system must reestablish the replication bond. This operation can take a considerable amount of time. Expect a message that shows the failover is in progress. Additionally, an icon appears next to your volume on the Block Storage for Classic that indicates that an active transaction is occurring. Hovering over the icon produces a window that shows the transaction. The icon disappears when the transaction is complete. During the Failback process, configuration-related actions are read-only. You can't edit any snapshot schedule or change snapshot space. The event is logged in replication history.
Next, click View All Block Storage for Classic.
Click your replica volume ("source"). This volume now has an Inactive status.
Mount and attach your storage volume to the host. For more information, Connecting your storage.

If you need further assistance, create a support case.

Fail back from the CLI

To fail back a file volume from a specific replicant volume, use the following command.

$ slcli block replica-failback --help
Usage: slcli block replica-failback [OPTIONS] VOLUME_ID

Options:
 --replicant-id TEXT  ID of the replicant volume
 -h, --help           Show this message and exit.

During the Disaster Recovery Failover, the system is forced to fail over to the replica site and the replication relationship is severed. To be able to fail back to the original site after the site is restored to normal operations, the system must reestablish the replication bond. This operation can take a considerable amount of time. During the Failback process, configuration-related actions are read-only. You can't edit any snapshot schedule or change snapshot space. The event is logged in the replication history.

When the original volume is active, you can mount and attach it to the host. For more information, Connecting your storage.

If you need further assistance, create a support case.