Azure SQL (LTR): You Don’t Need to Copy LTR Backups Across Regions to Restore Them

Summary

Customers sometimes attempt to copy Azure SQL Long-Term Retention (LTR) backups across regions using Copy-AzSqlDatabaseLongTermRetentionBackup, only to hit the error:

LongTermRetentionMigrationRequestNotSupported
LTR backup migration copy feature is not supported on subscription

This blog clarifies why this happens, when LTR backup copy is actually supported, and most importantly the correct and supported way to restore an LTR backup into a different region without copying it.

The Common Scenario

A customer has:

• An LTR backup stored in Region A
• A need to restore the database into Region B
• The assumption that the LTR backup must first be copied cross-region

They attempt:

Copy-AzSqlDatabaseLongTermRetentionBackup

and immediately receive a platform validation error stating the feature isn’t supported on their subscription.

Why This Error Happens

The key misunderstanding is what the LTR backup copy API is actually for.

Copy-AzSqlDatabaseLongTermRetentionBackup is NOT a general-purpose feature

This API is:

• Backend-gated
• Allowlist-only
• Intended only for region decommissioning scenarios

In other words:

• It is not supported for normal customer-driven migrations
• There is no portal toggle or feature registration
• Subscriptions are only allowlisted when Microsoft is retiring a region, and LTR backups must be preserved elsewhere. 

Because of this, most subscriptions - will receive:

LongTermRetentionMigrationRequestNotSupported

The Correct & Supported Solution

Good news:

You do NOT need to copy the LTR backup to another region to restore it there.

Azure SQL allows you to:

Restore an LTR backup directly to any Azure SQL logical server, in any region.

Supported Approach: Restore LTR Backup Directly

Use Restore-AzSqlDatabase with the -FromLongTermRetentionBackup switch.

Example (PowerShell)

Restore-AzSqlDatabase `
    -FromLongTermRetentionBackup `
    -ResourceId $ltrBackup.ResourceId `
    -ServerName $serverName `
    -ResourceGroupName $resourceGroup `
    -TargetDatabaseName "Test" `
    -ServiceObjectiveName P1

• This works across regions
• No backend enablement required
• Fully supported and documented

How This Works (Important Concept)

• LTR backups are stored in geo-redundant storage
• The restore operation does not depend on the original region
• The platform automatically handles data access and restores placement

So, while the backup physically originated in Region A, you are free to restore it to Region B, C, or any supported Azure region without copying it first.

When Is LTR Backup Copy Actually Used?

Only in this scenario:

Microsoft-initiated region decommissioning

In that case:

• LTR backups must be relocated to remain available
• Subscriptions are temporarily allowlisted
• Copy-AzSqlDatabaseLongTermRetentionBackup is enabled at the backend

Outside of this scenario, the API is intentionally restricted.

Key Takeaways

• You can restore an LTR backup to any region directly
• You do not need (and usually cannot use) LTR backup copy
• Backup copy is gated and reserved for region retirement scenarios
• Use Restore-AzSqlDatabase -FromLongTermRetentionBackup instead

Final Recommendation for Customers

If customers encounter this error:

• Reassure them this is not a misconfiguration or permission issue
• Explain that LTR restore is the correct solution
• Avoid escalation for feature enablement unless a region retirement is involved