Building an On-Premises Disaster Recovery Option for Azure SQL Managed Instance
Many organisations are moving their SQL Server workloads to Azure SQL Managed Instance to gain the benefits of a fully managed cloud database platform. However, some industries still have compliance, regulatory, sovereignty, or internal risk requirements that demand a disaster recovery copy outside Azure, often within an on-premises data centre.
This creates an important question:
Can we build an on-premises DR SQL Server environment from an Azure SQL Managed Instance?
The answer is yes, but the right architecture depends on your Recovery Point Objective, Recovery Time Objective, compliance requirements, SQL Server version, licensing, and operational model.
This article explains the available options and the recommended approach.
Understanding the challenge
Azure SQL Managed Instance is a Platform-as-a-Service database offering. It is highly compatible with SQL Server, but it is not the same as managing a traditional SQL Server virtual machine.
That means some traditional DR methods, such as native SQL Server log shipping from SQL Managed Instance to an on-premises SQL Server, are not available in the same way.
For organisations that require an on-premises DR copy, the main options are:
1. Azure SQL Managed Instance Link to SQL Server
2. Copy-only backup and restore to SQL Server
3. Transactional replication
4. Azure SQL Managed Instance Failover Groups
5. Built-in Azure backup and Long-Term RetentionEach option has different strengths and limitations.
Option 1: Azure SQL Managed Instance Link to On-Premises SQL Server
The most suitable option for a true DR design is Azure SQL Managed Instance Link.
Managed Instance Link allows databases to be replicated between Azure SQL Managed Instance and SQL Server using distributed availability group technology. With SQL Server 2022 and later, Microsoft supports configuring the link from SQL Managed Instance to SQL Server, enabling hybrid disaster recovery and failback scenarios.
A typical architecture would look like this:
Primary Database Platform:
Azure SQL Managed Instance
Replication:
Managed Instance Link / Distributed Availability Group
DR Platform:
On-premises SQL Server 2022 or SQL Server 2025This design allows the organisation to maintain a near-real-time copy of selected databases on an on-premises SQL Server environment.
Key requirements
To configure Azure SQL Managed Instance as the primary and SQL Server as the secondary DR target, version compatibility is critical.
For SQL Server 2022, Microsoft requires:
On-premises SQL Server 2022 CU10 or later
Azure SQL Managed Instance using SQL Server 2022 update policyFor SQL Server 2025, the SQL Managed Instance must be configured with the SQL Server 2025 update policy.
Benefits
Managed Instance Link provides:
Near-real-time data replication
Manual DR failover capability
Supported hybrid DR architecture
Possible failback to SQL Managed Instance
Better RPO/RTO than backup-based DR
A cleaner model than transactional replicationLimitations
There are still important design considerations:
Failover is not normally automatic like an Azure failover group
SQL Agent jobs, logins, linked servers, credentials and server-level objects need separate handling
Network connectivity must be reliable
ExpressRoute or site-to-site VPN is recommended
Only supported SQL Server versions should be usedFor a compliance-driven on-premises DR requirement, this is usually the best architecture to design around.
Option 2: Copy-Only Backup and Restore to On-Premises SQL Server
Azure SQL Managed Instance supports copy-only full backups, which can be stored in Azure Blob Storage and restored to supported SQL Server versions. Microsoft supports restoring SQL Managed Instance copy-only backups to SQL Server 2022 or SQL Server 2025 depending on the SQL Managed Instance update policy.
The architecture is simple:
Azure SQL Managed Instance
|
| Copy-only full backup
|
Azure Blob Storage
|
| Restore
|
On-premises SQL ServerBest use cases
This option is useful for:
Compliance database copies
Periodic DR refresh
Test restore validation
Offline recovery copies
Exit strategy from SQL Managed Instance
Non-real-time standby environmentsLimitations
This is not a warm standby DR solution.
The major limitations are:
It is not near-real-time
Restore time depends on database size and network speed
Manual or scripted process is required
RPO may be several hours or days depending on backup frequency
It does not provide automatic failoverThis option works well as a compliance recovery copy, but not as the main DR solution for business-critical systems with low RPO and RTO.
Option 3: Transactional Replication to On-Premises SQL Server
Azure SQL Managed Instance supports transactional replication and can participate as a publisher, distributor, or subscriber.
This means data can be replicated from SQL Managed Instance to an on-premises SQL Server subscriber.
A possible architecture is:
Azure SQL Managed Instance Publisher
|
Distributor
|
On-premises SQL Server SubscriberBest use cases
Transactional replication is useful when the business needs:
Selected table replication
Reporting database on-premises
Near-real-time data distribution
Partial data copy for compliance
Integration with downstream systemsLimitations
Transactional replication should not normally be treated as full DR for the entire SQL Managed Instance.
Reasons include:
It is table/article based
Not all objects are replicated automatically
Schema changes require careful management
SQL Agent jobs, logins, users and permissions need separate handling
Failover is more complex
Application cutover needs custom planningTransactional replication can be a good supporting option, but for a proper DR architecture, Managed Instance Link is stronger.
Option 4: Azure SQL Managed Instance Failover Groups
If the compliance requirement allows the DR environment to remain in Azure, then Failover Groups are the standard Azure-native DR option.
Failover Groups allow replication and failover of user databases from one SQL Managed Instance to another SQL Managed Instance in a different Azure region.
Example:
Primary:
Azure SQL Managed Instance - Australia East
Secondary:
Azure SQL Managed Instance - Australia Southeast
Access:
Failover Group ListenerBenefits
Azure-native DR
Regional resilience
Simplified failover management
Suitable for production-grade cloud DR
Can support automatic or manual failover policiesLimitation for on-premises compliance
This option does not provide an on-premises DR SQL Server. It is best suited where the organisation accepts Azure as both the primary and DR hosting platform.
Option 5: Built-In Azure SQL Managed Instance Backups and Long-Term Retention
Azure SQL Managed Instance automatically backs up databases and supports point-in-time restore. New, restored, and copied databases have point-in-time restore capability, with short-term retention configurable between 1 and 35 days. Long-Term Retention can also be configured for compliance needs.
This provides strong protection for:
Accidental deletion
Data corruption
Point-in-time recovery
Compliance retention
Long-term archive requirementsHowever, this is not the same as having an on-premises DR SQL Server ready for failover.
It should be part of the overall recovery strategy, but not the only DR mechanism if the business requires an on-premises standby environment.
Recommended Architecture
For a compliance requirement where Azure SQL Managed Instance is the primary platform and an on-premises SQL Server DR environment is required, the recommended architecture is:
Primary:
Azure SQL Managed Instance
DR:
On-premises SQL Server 2022 CU10 or later
or SQL Server 2025, depending on SQL MI update policy
Replication:
Azure SQL Managed Instance Link
Connectivity:
ExpressRoute or site-to-site VPN
Failover:
Manual DR failover
Supporting controls:
Azure backup, Long-Term Retention, monitoring, DR runbooks and regular DR testingThis gives the organisation a practical balance between cloud modernization and compliance-driven on-premises recovery.
Important Design Considerations
Before implementing the solution, organisations should assess the following areas.
1. RPO and RTO
Define the required:
RPO - how much data loss is acceptable
RTO - how quickly the service must be restoredIf the RPO is low, Managed Instance Link is more suitable than backup and restore.
2. SQL Server Version
The on-premises SQL Server version must be compatible with the SQL Managed Instance update policy.
This is a critical planning item. Choosing the wrong SQL Server version may block replication or restore options.
3. Network Connectivity
A stable network is required between Azure and the on-premises data centre.
Recommended options include:
ExpressRoute
Site-to-site VPN
Private DNS
Firewall rules
Controlled routing
Monitoring of latency and packet loss4. Server-Level Objects
Database replication does not automatically solve every dependency.
The following items should be scripted and synchronised separately:
SQL logins
Users and permissions
SQL Agent jobs
Linked servers
Credentials
Certificates
Database mail
Operators and alerts
Maintenance jobs
Application connection strings5. DR Testing
A DR design is only useful if it is regularly tested.
Microsoft provides guidance for DR drills using Managed Instance Link, where planned failover can be used to validate the secondary environment.
A proper DR test should confirm:
Database consistency
Application connectivity
Login mapping
Job execution
Reporting workloads
Performance after failover
Rollback or failback processDecision Matrix
| Requirement | Recommended Option |
|---|---|
| On-premises DR with failover | Managed Instance Link |
| Azure-to-Azure regional DR | SQL MI Failover Group |
| Compliance copy on-premises | Copy-only backup and restore |
| Selected table replication | Transactional replication |
| Long-term archive | Azure Long-Term Retention |
| Reporting copy on-premises | Transactional replication |
| Lowest operational complexity in Azure | Failover Group |
Conclusion
Building an on-premises disaster recovery option for Azure SQL Managed Instance is possible, but the architecture must be selected carefully.
For most compliance-driven scenarios, the strongest option is Azure SQL Managed Instance Link to an on-premises SQL Server 2022 or SQL Server 2025 environment. This provides near-real-time replication, manual DR failover capability, and a supported hybrid recovery model.
Backup and restore, transactional replication, failover groups, and long-term retention still have important roles, but they solve different problems.
A mature DR strategy should combine:
Managed Instance Link for operational DR
Azure backups for point-in-time recovery
Long-Term Retention for compliance
Documented runbooks for failover
Regular DR testing
Monitoring and alertingThis approach allows organisations to benefit from Azure SQL Managed Instance while still meeting strict compliance requirements for on-premises disaster recovery.