--- name: FileStorage-disaster-recovery title: Fail over from an inaccessible primary volume for disaster recovery description: Quickly access your data on the secondary site when catastrophic failure makes the primary volume inaccessible by forcing failover to the remote replica. last-updated: 2026-06-09 --- > ## Documentation Index > The table of contents for this documentation set is at https://cloud.ibm.com/docs/FileStorage?format=markdown > The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt > Use these files to discover more information as needed. # Fail over from an inaccessible primary volume for disaster recovery {: #dr-inaccessible} Quickly access your data on the secondary site when catastrophic failure makes the primary volume inaccessible by forcing failover to the remote replica. {: shortdesc} If a catastrophic failure or disaster causes an outage on the primary site, you can perform the following actions to quickly access your data on the secondary site. When the primary volume is inaccessible, you can force a failover to the remote replica. Before you start the failover, make sure that all host authorization is in place. 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. {: note} You can create the authorization in the [UI](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-managingstorage&interface=ui&format=markdown#authhostUI), from the [CLI](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-managingstorage&interface=cli&format=markdown#authhostCLI), with the API, or with [Terraform](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-managingstorage&interface=terraform&format=markdown#authhostterraform). This action breaks the replication relationship and restoring the connection between the primary and the replica location can be time-consuming. {: important} ## Failing over to the replica volume in the console {: #DRFailoverUI} {: ui} 1. Go to your list of File Storage for Classic. From the**Infrastructure** ![VPC icon](../icons/vpc.svg) > **Classic Infrastructure** menu, click **Storage** > **File Storage for Classic**. 2. Locate and click the volume name. 3. Click **Actions** ![Actions icon](../icons/action-menu-icon.svg "Actions") > **Failover**. 4. When the primary location is disabled, the option of Disaster Recovery Failover becomes active. 5. Click **Yes** to proceed. ## Failing over to the replica volume from the CLI {: #DRFailoverCLI} {: cli} Before you begin, decide on the CLI client that you want to use. * You can either install the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?format=markdown){: external} and install the SL plug-in with `ibmcloud plugin install sl`. For more information, see [Extending IBM Cloud CLI with plug-ins](https://cloud.ibm.com/docs/cli?topic=cli-plug-ins&format=markdown). * Or, you can install the [SLCLI](https://softlayer-python.readthedocs.io/en/latest/cli/){: external}. ### Initiating a failover from the IBMCLOUDCLI {: #DRFailoverICCLI} You can use the `ibmcloud sl file 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`. ```sh $ ibmcloud sl file file disaster-recovery-failover 560156918 560382016 OK Failover of volume 560156918 to replica 560382016 is now in progress. ``` {: codeblock} ### Initiating a failover from the SLCLI {: #DRFailoverSLCLI} Use the following command to fail a file volume over to a specific replicant volume. ```sh $ slcli file disaster-recovery-failover --help Usage: slcli file disaster-recovery-failover [OPTIONS] VOLUME_ID Options: --replicant-id TEXT ID of the replicant volume -h, --help Show this message and exit. ``` ## Failing over to the replica volume with the API {: #DRFailoverAPI} {: api} ### REST API {: #drrestaapi} * URL: `https://USERNAME:APIKEY@api.softlayer.com/rest/v3/SoftLayer_Network_Storage/primaryvolumeId/disasterRecoveryFailoverToReplicant` * Request body ```python { "parameters": [replicavolumeid] } ``` ### SOAP API {: #drsoapapi} * URL: `https://api.softlayer.com/soap/v3/SoftLayer_Network_Storage` * Request body ```python USERNAME APIKEY primary Volume Id replica Volume ID ``` 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 action 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. If you need further assistance, create a [support case](https://cloud.ibm.com/unifiedsupport/supportcenter){: external}. ## Failing back to the original primary site in the console {: #DRFailbackUI} {: 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**, **File Storage for Classic** in the [IBM Cloud® console](https://cloud.ibm.com/cloud-storage/file){: external}. 1. Click your active volume ("target"). 2. Next, click **Replica**, and click **Actions** ![Actions icon](../icons/action-menu-icon.svg "Actions"). 3. Select **Failback**. When the primary location is marked disabled, 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 action can take a considerable amount of time. Expect a message that shows that the failover is in progress. Additionally, an icon appears next to your volume on the **File 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. {: note} 4. Next, click **View All File Storage for Classic**. 5. Click your replica volume ("source"). This volume now has an **Inactive** status. 6. Mount and attach your storage volume to the host. For more information, see [connecting your storage](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-getting-started&format=markdown#mountingstorage). If you need further assistance, create a [support case](https://cloud.ibm.com/unifiedsupport/supportcenter){: external}. ## Failing back from the CLI {: #DRFailbackCLI} {: cli} ### Initiating a failback from the IBMCLOUDCLI {: #DRFailbackICCLI} You can use the `ibmcloud sl file replica-failback` command to fail back operations from the replica file share to the original source file share. The following example initiates a failback to the original source share `560156918`. ```sh $ ibmcloud sl file replica-failback 560156918 OK Failback of volume 560156918 is now in progress. ``` {: codeblock} For more information about all of the parameters that are available for this command, see [ibmcloud sl file replica-failover](https://cloud.ibm.com/docs/cli?topic=cli-sl-file-storage-service&format=markdown#sl_file_replica_failover){: external}. ### Initiating a failback from the SLCLI {: #DRFailbackSLCLI} To fail back a file volume from a specific replicant volume, use the following command. ```sh $ slcli file replica-failback --help Usage: slcli file 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 action 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, see [connecting your storage](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-getting-started&format=markdown#mountingstorage). If you need further assistance, create a [support case](https://cloud.ibm.com/unifiedsupport/supportcenter){: external}.