DR environment for Azure Api Management | backup and restore

Azure API Management allows the entire service configuration to be backed up to a storage account.
Either on an ad-hoc basis or on a predefined schedule using Azure Automation, you can back up and restore the configuration to another API Management instance (in another region for DR).

I’ve found that it takes about 15 minutes to restore the configuration, during which you cannot make any other changes to the APIM service, or use the Publisher/Developer portal. This includes any changes that you try to apply using Powershell/Xplat-cli/API, you will receive an error that you cannot make changes whilst the configuration is being applied.

It should be noted that after restoration, the usage statistics are not carried across, the APIM instances usage statistics will remain. The backup/restore is really intended for syncing Production with other non Production environments (DR, Pre-prod, etc). Not to be used to apply release changes to your production environment.

Official MSDN Docs;
Backup-AzureRmApiManagement : https://msdn.microsoft.com/en-us/library/mt619281.aspx
Restore-AzureRmApiManagement : https://msdn.microsoft.com/en-us/library/mt619278.aspx

Powershell script

14 Replies to “DR environment for Azure Api Management | backup and restore”

  1. Gord,

    Does this work across two different user accounts (with different subscriptions) from 2 different domains?

    FYI, I have one user account (Account1@mycorpacct.com) from one directory/domain (mycompany.onmicrosoft.com) that was used to create the source API Management services to be backed-up. In my case, this is test environment from our corporate account.

    Then, I have another account (Account2@theclient.com) from a different directory/domain (myclient.onmicrosoft.com) that will be used to restore the backup into. In my case, this is our client’s production environment, with a different domain.

    Is this supported?


  2. Gord,

    Thanks for the quick reply. I’ve tested the BACKUP part using the following Powershell script below and it works.

    #Connect-AzureRmAccount = this has been called previously using my credential for the SOURCE directory
    $resourceGroupNameSource = “ILCFast-RG”
    $storageAccountNameSource = “ilcfaststorageaccount”
    $storageKey = (Get-AzureRmStorageAccountKey -ResourceGroupName $resourceGroupNameSource -StorageAccountName $storageAccountNameSource)[0].Value
    $storageContext = New-AzureStorageContext -StorageAccountName $storageAccountNameSource -StorageAccountKey $storageKey
    Write-Output “SOURCE:”
    Write-Output “resourceGroupNameSource: $resourceGroupNameSource”
    Write-Output “storageAccountNameSource: $storageAccountNameSource”
    Write-Output “storageKey: $storageKey”
    Write-Output “storageContext: $storageContext”

    $apiNameSource = “ILCFastAPIManagement”
    $targetContainerName = “testcontainername1”
    $targetBlobName = “testBlobName”
    Write-Output “DESTINATION:”
    Write-Output “apiNameSource: $apiNameSource”
    Write-Output “targetContainerName: $targetContainerName”
    Write-Output “targetBlobName: $targetBlobName”
    Backup-AzureRmApiManagement -ResourceGroupName $resourceGroupNameSource -Name $apiNameSource -StorageContext $StorageContext -TargetContainerName $targetContainerName -TargetBlobName $targetBlobName

    What remains is the RESTORE part. I’m working on it now but I have the following questions in my head:
    1) Can the 2nd different account from a different directory/domain have access to the data from the backup Blob (“testBlobName”) from the source?
    2) If not, can you just copy the blob and restore it to the target domain?


  3. Gord,

    Thank you for your reply. I have a few more questions:

    1) You’re saying once I have the storage key to the source blob, then I can access it’s contents? That sounds correct. But won’t the Restore-AzureRmApiManagement script be run in the context of the SOURCE credentials still, therefore I am still logged-in to the SOURCE directory and therefore has no access to the TARGET domain/directory and all its resources?
    2) Or, do I need to call Connect-AzureRmAccount the 2nd time to switch to the TARGET before I call the Restore-AzureRmApiManagement script? But in that case, will the storage key (from the SOURCE) still work?


    1. The storage context is independent of an AzureRm connection. Once you’ve backed up the source APIM you will need to connect -azurerm to the subscription with the destination.

  4. Gord,

    I’m still having problem doing the restore. When I call Connect-AzureRmAccount on the TARGET subscription, it’s showing blank subscription name, subscription id, and tenantid. I don’t know if it’s because of the following factors:
    1) For the 2nd email account I used for Connect-AzureRmAccount script, I have 2 directories connected to that email account and the default directory is my corporate directory and not my TARGET directory (my client’s directory).
    2) Another complication could be that I’m not a global admin of the TARGET subscription. FYI, the client’s Azure subscription is also via CSP (we are a CSP) and I’m not the one who manage the entire thing.
    3) I may be tagged as Owner for this CSP-created account but I can see a lot of grayed-out features in most Azure services / blades, indicating my access is quite limited.


  5. Gord,

    Just to update you and document also. To address the problem, we’ve created a new user who has the client’s domain as the default directory. There’s no need to switch to another directory/domain.

    After calling Connect-AzureRmAccount on this account, calling Restore-AzureRmApiManagement worked flawlessly.

    Another item though that was critical was that the pricing tier of the source API Management service should be the same as the pricing tier of the target API Management service. We initially have a mismatch (source is Developer, target is Basic) but creating a new Developer tier for the API Management service fixed it.

    I cannot emphasize enough how important your feedback was. Without your help, especially your last statement*, I would not have any idea how to move forward and address this.



    *(The storage context is independent of an AzureRm connection. Once you’ve backed up the source APIM you will need to connect -azurerm to the subscription with the destination.)

  6. Gord,

    I was relaxing already but it turns out there’s another kink. 🙂 Well, it turns out that during the restore, the underlying logic apps were not migrated and they still reside in the old location.

    1. Is this the default behaviour: it only migrates the APIs and not the Logic Apps?
    2. Am I missing something, an additional flag perhaps to include the Logic Apps during the restore?
    3. Is restoring the Logic Apps done through manual process?


    1. You’re only backing up the APIM config. It points to the logic apps, and that’s it. It won’t move them.
      2. If you want a logic app backed up and restored in another subscription I’d look at the way you deploy logic apps and I’d do it to 2 regions. The kink here is that your apim configuration will point to the original logic app. What’s your ambition, DR/HA?
      3.Normally it’s through a deployment pipeline in something like Azure DevOps

  7. Gord,

    As usual thanks for being my MSDN. 🙂

    Yes, the goal is for my dev environment (our Logic Apps and APIs located in our corporate Azure) to be completely migrated to my client’s production Azure environment. Once that’s done, my dev environment can be removed.

    1. Will DevOps be the most appropriate solution to this?
    2. Or will I be forced to manually edit my Logic Apps individually, create a template from it (this seems to be the norm when I read the Azure literature), edit the template to point to my target location, then run it there?


    1. I usually see these situations (msdn -> ea) resolved by phoning azure support and getting the subscription moved.

      Also If you’re logged in as a user with permissions in both subscriptions, you can resource group move most services over.

      Otherwise it needs a bit more planning.

  8. Gord,

    That might be the last recourse (phone Azure support) if the others don’t work out.

    Thanks for all the help. I cannot emphasize how grateful I am.

Leave a Reply

Your email address will not be published. Required fields are marked *