A failover request can be triggered for a storage account in the event a primary endpoint becomes unavailable for any reason. The failover occurs from the storage account's primary cluster to the secondary cluster for RA-GRS accounts. The secondary cluster will become primary after failover and the account is converted to LRS. In the case of a Planned Failover, the primary and secondary clusters are swapped after failover and the account remains geo-replicated. Failover should continue to be used in the event of availability issues as Planned failover is only available while the primary and secondary endpoints are available. The primary use case of a Planned Failover is disaster recovery testing drills. This type of failover is invoked by setting FailoverType parameter to 'Planned'. Learn more about the failover options here- https://learn.microsoft.com/en-us/azure/storage/common/storage-disaster-recovery-guidance
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{accountName}/failover?api-version=2022-09-01
With optional parameters:
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{accountName}/failover?api-version=2022-09-01&failoverType=Planned
URI Parameters
Name
In
Required
Type
Description
accountName
path
True
string
The name of the storage account within the specified resource group. Storage account names must be between 3 and 24 characters in length and use numbers and lower-case letters only.
resourceGroupName
path
True
string
The name of the resource group within the user's subscription. The name is case insensitive.
POST https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/res4228/providers/Microsoft.Storage/storageAccounts/sto2434/failover?api-version=2022-09-01&failoverType=Planned
import com.azure.core.util.Context;
/** Samples for StorageAccounts Failover. */
public final class Main {
/*
* x-ms-original-file: specification/storage/resource-manager/Microsoft.Storage/stable/2022-09-01/examples/StorageAccountFailover.json
*/
/**
* Sample code: StorageAccountFailover.
*
* @param azure The entry point for accessing resource management APIs in Azure.
*/
public static void storageAccountFailover(com.azure.resourcemanager.AzureResourceManager azure) {
azure
.storageAccounts()
.manager()
.serviceClient()
.getStorageAccounts()
.failover("res4228", "sto2434", null, Context.NONE);
}
}
const { StorageManagementClient } = require("@azure/arm-storage");
const { DefaultAzureCredential } = require("@azure/identity");
/**
* This sample demonstrates how to A failover request can be triggered for a storage account in the event a primary endpoint becomes unavailable for any reason. The failover occurs from the storage account's primary cluster to the secondary cluster for RA-GRS accounts. The secondary cluster will become primary after failover and the account is converted to LRS. In the case of a Planned Failover, the primary and secondary clusters are swapped after failover and the account remains geo-replicated. Failover should continue to be used in the event of availability issues as Planned failover is only available while the primary and secondary endpoints are available. The primary use case of a Planned Failover is disaster recovery testing drills. This type of failover is invoked by setting FailoverType parameter to 'Planned'. Learn more about the failover options here- https://learn.microsoft.com/azure/storage/common/storage-disaster-recovery-guidance
*
* @summary A failover request can be triggered for a storage account in the event a primary endpoint becomes unavailable for any reason. The failover occurs from the storage account's primary cluster to the secondary cluster for RA-GRS accounts. The secondary cluster will become primary after failover and the account is converted to LRS. In the case of a Planned Failover, the primary and secondary clusters are swapped after failover and the account remains geo-replicated. Failover should continue to be used in the event of availability issues as Planned failover is only available while the primary and secondary endpoints are available. The primary use case of a Planned Failover is disaster recovery testing drills. This type of failover is invoked by setting FailoverType parameter to 'Planned'. Learn more about the failover options here- https://learn.microsoft.com/azure/storage/common/storage-disaster-recovery-guidance
* x-ms-original-file: specification/storage/resource-manager/Microsoft.Storage/stable/2022-09-01/examples/StorageAccountFailover.json
*/
async function storageAccountFailover() {
const subscriptionId = "{subscription-id}";
const resourceGroupName = "res4228";
const accountName = "sto2434";
const credential = new DefaultAzureCredential();
const client = new StorageManagementClient(credential, subscriptionId);
const result = await client.storageAccounts.beginFailoverAndWait(resourceGroupName, accountName);
console.log(result);
}
storageAccountFailover().catch(console.error);
using System;
using System.Threading.Tasks;
using Azure;
using Azure.Core;
using Azure.Identity;
using Azure.ResourceManager;
using Azure.ResourceManager.Models;
using Azure.ResourceManager.Resources;
using Azure.ResourceManager.Storage;
using Azure.ResourceManager.Storage.Models;
// Generated from example definition: specification/storage/resource-manager/Microsoft.Storage/stable/2022-09-01/examples/StorageAccountFailover.json
// this example is just showing the usage of "StorageAccounts_Failover" operation, for the dependent resources, they will have to be created separately.
// get your azure access token, for more details of how Azure SDK get your access token, please refer to https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication?tabs=command-line
TokenCredential cred = new DefaultAzureCredential();
// authenticate your client
ArmClient client = new ArmClient(cred);
// this example assumes you already have this StorageAccountResource created on azure
// for more information of creating StorageAccountResource, please refer to the document of StorageAccountResource
string subscriptionId = "{subscription-id}";
string resourceGroupName = "res4228";
string accountName = "sto2434";
ResourceIdentifier storageAccountResourceId = StorageAccountResource.CreateResourceIdentifier(subscriptionId, resourceGroupName, accountName);
StorageAccountResource storageAccount = client.GetStorageAccountResource(storageAccountResourceId);
// invoke the operation
await storageAccount.FailoverAsync(WaitUntil.Completed);
Console.WriteLine($"Succeeded");
POST https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/res4228/providers/Microsoft.Storage/storageAccounts/sto2434/failover?api-version=2022-09-01&failoverType=Planned
import com.azure.core.util.Context;
import com.azure.resourcemanager.storage.models.FailoverType;
/** Samples for StorageAccounts Failover. */
public final class Main {
/*
* x-ms-original-file: specification/storage/resource-manager/Microsoft.Storage/stable/2022-09-01/examples/StorageAccountFailoverPlanned.json
*/
/**
* Sample code: StorageAccountFailoverPlanned.
*
* @param azure The entry point for accessing resource management APIs in Azure.
*/
public static void storageAccountFailoverPlanned(com.azure.resourcemanager.AzureResourceManager azure) {
azure
.storageAccounts()
.manager()
.serviceClient()
.getStorageAccounts()
.failover("res4228", "sto2434", FailoverType.PLANNED, Context.NONE);
}
}
const { StorageManagementClient } = require("@azure/arm-storage");
const { DefaultAzureCredential } = require("@azure/identity");
/**
* This sample demonstrates how to A failover request can be triggered for a storage account in the event a primary endpoint becomes unavailable for any reason. The failover occurs from the storage account's primary cluster to the secondary cluster for RA-GRS accounts. The secondary cluster will become primary after failover and the account is converted to LRS. In the case of a Planned Failover, the primary and secondary clusters are swapped after failover and the account remains geo-replicated. Failover should continue to be used in the event of availability issues as Planned failover is only available while the primary and secondary endpoints are available. The primary use case of a Planned Failover is disaster recovery testing drills. This type of failover is invoked by setting FailoverType parameter to 'Planned'. Learn more about the failover options here- https://learn.microsoft.com/azure/storage/common/storage-disaster-recovery-guidance
*
* @summary A failover request can be triggered for a storage account in the event a primary endpoint becomes unavailable for any reason. The failover occurs from the storage account's primary cluster to the secondary cluster for RA-GRS accounts. The secondary cluster will become primary after failover and the account is converted to LRS. In the case of a Planned Failover, the primary and secondary clusters are swapped after failover and the account remains geo-replicated. Failover should continue to be used in the event of availability issues as Planned failover is only available while the primary and secondary endpoints are available. The primary use case of a Planned Failover is disaster recovery testing drills. This type of failover is invoked by setting FailoverType parameter to 'Planned'. Learn more about the failover options here- https://learn.microsoft.com/azure/storage/common/storage-disaster-recovery-guidance
* x-ms-original-file: specification/storage/resource-manager/Microsoft.Storage/stable/2022-09-01/examples/StorageAccountFailoverPlanned.json
*/
async function storageAccountFailoverPlanned() {
const subscriptionId = "{subscription-id}";
const resourceGroupName = "res4228";
const accountName = "sto2434";
const credential = new DefaultAzureCredential();
const client = new StorageManagementClient(credential, subscriptionId);
const result = await client.storageAccounts.beginFailoverAndWait(resourceGroupName, accountName);
console.log(result);
}
storageAccountFailoverPlanned().catch(console.error);
using System;
using System.Threading.Tasks;
using Azure;
using Azure.Core;
using Azure.Identity;
using Azure.ResourceManager;
using Azure.ResourceManager.Models;
using Azure.ResourceManager.Resources;
using Azure.ResourceManager.Storage;
using Azure.ResourceManager.Storage.Models;
// Generated from example definition: specification/storage/resource-manager/Microsoft.Storage/stable/2022-09-01/examples/StorageAccountFailoverPlanned.json
// this example is just showing the usage of "StorageAccounts_Failover" operation, for the dependent resources, they will have to be created separately.
// get your azure access token, for more details of how Azure SDK get your access token, please refer to https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication?tabs=command-line
TokenCredential cred = new DefaultAzureCredential();
// authenticate your client
ArmClient client = new ArmClient(cred);
// this example assumes you already have this StorageAccountResource created on azure
// for more information of creating StorageAccountResource, please refer to the document of StorageAccountResource
string subscriptionId = "{subscription-id}";
string resourceGroupName = "res4228";
string accountName = "sto2434";
ResourceIdentifier storageAccountResourceId = StorageAccountResource.CreateResourceIdentifier(subscriptionId, resourceGroupName, accountName);
StorageAccountResource storageAccount = client.GetStorageAccountResource(storageAccountResourceId);
// invoke the operation
StorageAccountFailoverType? failoverType = StorageAccountFailoverType.Planned;
await storageAccount.FailoverAsync(WaitUntil.Completed, failoverType: failoverType);
Console.WriteLine($"Succeeded");