How to take copy only backups with SQL Managed Instance.

In Azure SQL Managed Instance, copy-only backups cannot be created for databases encrypted with service-managed Transparent Data Encryption (The default choice for all newly provisioned SQL MI). Service-managed TDE relies on an internal encryption key that cannot be exported, which means the backup cannot be restored outside that environment.

In this article, I will explain how to prepare your Azure SQL Managed Instance (SQL MI) to take copy-only backups to Azure Blob Storage by using Managed Identity together with customer-managed encryption keys.

These steps ensure that SQL MI can encrypt the backup by using your own key and securely write it to your storage account without relying on shared keys or SAS tokens.

Step 1: Create or Identify a Backup Encryption Key in Azure Key Vault

First, ensure that you have a Key Vault containing a key that will be used to encrypt the backup. It is essential to have elevated privileges over this key vault and its recommended use a dedicated key for the backup encryption.

Note the Key Identifier:

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

as it will be required later when adding the key to SQL MI. This key will be used by SQL MI to encrypt the backup before it is written to Azure Blob Storage.

Step 2: Grant Key Vault Permissions to the SQL MI Managed Identity

SQL Managed Instance uses a system-assigned managed identity. This allows SQL MI to use the key for encryption and decryption operations during backup and restore. This identity must be granted a key vault specific permission to use the encryption key stored in Key Vault.

In the Key Vault:

1) Navigate to Access control (IAM) or Access policies (depending on whether RBAC or Access Policies are enabled).

2) Open the SQL MI managed identity.

3) Grant it this permission:  "Key Vault Crypto Service Encryption User". 

Step 3: Grant Storage Permissions to the SQL MI Managed Identity

Next, SQL MI must be authorized to write backup files to the target storage account. This permission allows SQL MI to create, write, and manage blobs within the specified container. No storage account keys or SAS tokens are required when using Managed Identity.

In the storage account that hosts your backup container:

1) Go to Access control (IAM).

2) Choose the SQL MI managed identity.

3) Assign it this role: "Storage Blob Data Contributor"

Step 4: Add the Encryption Key to SQL Managed Instance

After Key Vault access has been configured, the encryption key must be registered within SQL MI. You can add the key in two ways:

A) From Azure portal:

Navigate to the relevant SQL Managed Instance, then select the Security option from the left-hand menu. Under Security, open Transparent Data Encryption. From there, you will be able to select the appropriate key from the available drop-down list. Click save after your choice is complete.

B) From Azure Cloud Shell/PowerShell:

We add the key first with this command:

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

Then we set it 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 Target Blob Container

Finally, create a SQL credential that maps the Azure Blob Storage container to SQL MI’s managed identity.

Run the following statement on the SQL Managed Instance:

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

Important notes: The credential name must exactly match the container URL. This credential is used by SQL Server during BACKUP DATABASE … TO URL.

You have now successfully configured your SQL MI to be able to take copy only backups! The below sections will explain the common errors that you may run into while taking copy only backups.

Common errors that you may encounter when attempting copy-only backups:

1) Error#1:

Msg 3271, Level 16, State 1, Line 1
A nonrecoverable I/O error occurred on file '<URL to bak 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 error is caused by:

A) port 443 block from NSGs/firewalls.

B) SQL MI is not able to reach the storage blob container due to some network misconfiguration from either side. 

Please review your network settings in the storage account and your NSGs and firewall. Use this script to test connectivity to the storage account from SQL MI: how-to-test-tcp-connection-from-mi

2) Error#2:

Msg 3201, Level 16, State 1, Line 1

Cannot open backup device '<URL to the bak file>'. 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 error is caused by misconfigured credentials or missing permissions. Please verify that your SQL MI managed identity has the "Storage Blob Data Contributor" role and the above CREATE CREDENTIAL query was executed with the correct URL name. 

3) Error#3:

Msg 3202, Level 16, State 1, Line 1
Write on "<URL to bak file>" 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 occurs because your database has passed the blob storage block limit. SQL Server/MI by default writes 1 MB blocks - so when the individual backup file is more than 48GB (50,000 x 1 MB) - you get this error.

You need to split the backup files to avoid this failure of backup and use BLOCKSIZE and MAXTRANSFERSIZE size in TSQL Example below:

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

Disclaimer
Please note that products and options presented in this article are subject to change. This article reflects for Azure SQL Managed Instance in April 2026.

I hope this article was helpful for you, please feel free to share your feedback in the comments section.