How to take copy only backups with SQL Managed Instance.

When using Azure SQL Managed Instance, it’s important to note that copy-only backups can’t be made for databases that utilise service-managed Transparent Data Encryption. This is the default for all new SQL Managed Instances. Service-managed TDE employs an internal encryption key that can’t be exported, so backups can’t be restored outside of that specific environment.

In this article, I’ll guide you through the process of setting up your Azure SQL Managed Instance (SQL MI) to create copy-only backups to Azure Blob Storage. We’ll achieve this by using Managed Identity combined with customer-managed encryption keys.

By following these steps, you’ll ensure that SQL MI can encrypt backups with your own key and safely store them in your storage account without needing shared keys or SAS tokens.

Step 1: Set Up Your Backup Encryption Key in Azure Key Vault

Start by confirming you have a Key Vault that contains an encryption key for your backups. It’s crucial to have the appropriate permissions for this Key Vault, and it’s best to use a dedicated key for this purpose.

Make a note of the Key Identifier:

https://contoso.vault.azure.net/keys/contosokey/01234567890123456789012345678901

You will need this later when configuring SQL MI. This key will serve to encrypt the backup prior to it being sent to Azure Blob Storage.

Step 2: Grant Access to the SQL MI Managed Identity

SQL Managed Instance operates with a system-assigned managed identity, which allows it to perform encryption and decryption tasks during backup and restore processes. You’ll need to grant this identity appropriate permissions for using the encryption key stored in Key Vault.

To do this in the Key Vault:

1. Go to Access Control (IAM) or Access Policies, based on whether you’re using RBAC or Access Policies.
2. Open the SQL MI managed identity.
3. Assign the “Key Vault Crypto Service Encryption User” permission.

Step 3: Authorise SQL MI to Access the Storage Account

Now, you’ll need to ensure that SQL MI has permission to write backup files to your chosen storage account. This permission will enable SQL MI to create and manage blobs within the specified container without the need for storage account keys or SAS tokens.

To grant access in your storage account:

1. Navigate to Access Control (IAM).
2. Select the SQL MI managed identity.
3. Assign it the “Storage Blob Data Contributor” role.

Step 4: Register the Encryption Key with SQL Managed Instance

Once you’ve set up Key Vault permissions, you need to register the encryption key within SQL MI. You can do this in a couple of ways:

A) Through the Azure Portal:

Go to your SQL Managed Instance in the portal, select Security from the menu, then open Transparent Data Encryption. Here, you can choose your desired key from the dropdown menu. Don’t forget to click save!

B) Using Azure Cloud Shell/PowerShell:

First, add the key with the following command:

Add-AzSqlInstanceKeyVaultKey -ResourceGroupName 'ContosoResourceGroup' -InstanceName 'ContosoManagedInstanceName' -KeyId 'https://contoso.vault.azure.net/keys/contosokey/01234567890123456789012345678901'

Then, set the key with this command:

Set-AzSqlInstanceTransparentDataEncryptionProtector -Type AzureKeyVault -InstanceName "ContosoManagedInstanceName" -ResourceGroupName "ContosoResourceGroup"-KeyId "https://contoso.vault.azure.net/keys/contosokey/01234567890123456789012345678901" -AutoRotationEnabled $true

Step 5: Create a Credential for the Blob Container

Your next step is to create a SQL credential that links your Azure Blob Storage container to the managed identity of SQL MI.

Run this SQL command on your SQL Managed Instance:

CREATE CREDENTIAL [https://contoso.blob.core.windows.net/myfirstcontainer]
WITH IDENTITY = 'Managed Identity';

Important: The name of the credential must perfectly match the URL of the container since it’s required for the BACKUP DATABASE … TO URL command.

Congratulations! You’ve now set up your SQL MI to perform copy-only backups. In the sections below, I’ll cover some common issues you might face while trying to execute these backups.

Common Issues You May Encounter with Copy-Only Backups

Error 1:

Msg 3271, Level 16, State 1, Line 1
A nonrecoverable I/O error occurred on file ” Backup to URL received an exception from the remote endpoint. Exception Message: Unable to connect to the remote server.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

This issue typically arises from:

• A blocked port 443 due to network security groups (NSGs) or firewalls.
• SQL MI unable to access the storage blob container due to a network misconfiguration.

Check your network settings in the storage account, NSGs, and firewall rules. Use this script to verify connectivity from SQL MI to the storage account: test connectivity script.

Error 2:

Msg 3201, Level 16, State 1, Line 1
Cannot open backup device ”. Operating system error 86 (The specified network password is not correct.).
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

This usually indicates an issue with credentials or permissions. Ensure that your SQL MI managed identity has the “Storage Blob Data Contributor” role and that the CREATE CREDENTIAL query was executed with the correct URL.

Error 3:

Msg 3202, Level 16, State 1, Line 1
Write on “” failed: 1117 (The request could not be performed because of an I/O device error.)
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

This error may happen if your database exceeds the blob storage block limit. By default, SQL Server/MI writes in 1 MB blocks—so if a backup file exceeds 48 GB (50,000 x 1 MB), you’ll encounter this issue.

To prevent this error, split the backup files by using BLOCKSIZE and MAXTRANSFERSIZE in your TSQL command. Here’s an example:

BACKUP DATABASE […] TO 
URL = '/backup/DB_part01.bak', 
[…]
URL = '/backup/DB_part20.bak', 
WITH
COPY_ONLY,
COMPRESSION,
MAXTRANSFERSIZE = 4194304,
BLOCKSIZE = 65536;

Disclaimer

Keep in mind that the products and options mentioned here might change in the future. This article reflects the state of Azure SQL Managed Instance as of April 2026.

I hope you found this guide useful! I would love to hear your thoughts in the comments section below.