Step by Step Guide to Setting Up Geo-Redundancy for Azure SQL Managed Instance

You turn on geo-redundancy in Azure SQL Managed Instance by setting up geo-redundant or geo-zone-redundant backup storage. If you need to, you can also set up failover groups for disaster recovery in other regions. Geo-redundancy keeps your data safe from local problems, mistakes, and rare big outages. With features like point-in-time restore and automatic failover, you can lower downtime and keep your apps running. Some setups can recover in just 30 seconds, which is good for strict business needs.

Key Takeaways

• Pick the right backup storage redundancy. You can choose local, zone, geo, or geo-zone. Pick based on your disaster recovery needs and what your region supports.

• Turn on geo-redundancy when you make a new instance. You can also update old instances to add this. This helps protect your data in different regions. It also helps lower downtime.

• Make failover groups between managed instances in different regions. This lets you switch fast if there is a problem. Your apps can keep running during outages.

• Test your geo-redundancy setup often. Pretend to do failovers and practice geo-restore. This helps make sure your disaster recovery plan works.

• Look out for common problems like network or DNS issues. Follow best practices to keep your geo-redundant environment safe and reliable.

Prerequisites

Get ready before you set up geo-redundancy for your Azure SQL Managed Instance. This helps you avoid problems and makes setup easier.

Permissions

You must have the right permissions to work with Azure SQL Managed Instances.

• Azure Subscription: You need an active Azure subscription.

• Role Requirements: You should be a Contributor or Owner on the subscription or resource group.

• Resource Provider Registration: Register the Microsoft.Sql resource provider in your subscription.

💡 Tip: If you do not have these permissions, ask your Azure administrator for help. You can check your access in the Azure portal under "Access control (IAM)".

Network Setup

Plan your network before you start.

• Virtual Network (VNet): Put your instance in an Azure VNet.

• Subnet: Use a subnet just for the managed instance.

• Network Security: Open the ports needed for SQL (default is 1433).

• Region Selection: Pick the Azure region that matches your disaster recovery plan.

Instance Requirements

You can pick backup storage redundancy when you create or update your instance.

• New Instance: When making a new managed instance, choose the backup storage redundancy you want (local, zone, or geo-redundant).

• Existing Instance: You can change the backup storage redundancy later in the Azure portal or CLI.

• Service Tier: Pick the service tier that fits your needs.

Note: Geo-redundant backup storage lets you restore your data in another region if your main region goes down.

If you follow these steps, you will have a strong start for a reliable geo-redundant setup.

Geo-Redundancy Options

Backup Storage Types

You can pick from different backup storage redundancy options for your Azure SQL Managed Instance. Each type gives a different level of safety and strength. The table below shows how these options compare:

Note: Automated backups use these storage types to keep your data safe. You can keep backups for 1 to 35 days for short-term needs, or up to 10 years for long-term needs.

Zone vs. Geo-Redundancy

You need to choose the right storage type for your disaster recovery plan. Here is what each option does:

• Locally Redundant Storage (LRS): Protects your data if hardware breaks in one data center. It does not help if the whole data center has a problem.

• Zone-Redundant Storage (ZRS): Keeps your data safe if one zone fails. It does not help if the whole region fails.

• Geo-Redundant Storage (GRS): Sends your data to a far away region. This helps if a big disaster hits your main region, but not if a single zone fails.

• Geo-Zone-Redundant Storage (GZRS): Gives you both zone and region safety. It protects against zone problems and big disasters by using both types.

You should pick geo-redundancy like GRS or GZRS if you want to recover from big disasters. GZRS is best if you need your data always ready and your region has zones. If your region does not have zones, GRS is the best for disaster recovery. ZRS is good for local safety but does not let you use geo-restore.

💡 Tip: Geo-restore only works with geo-redundant storage. Always check if your region has the redundancy type you want.

Enable Geo-Redundancy

Setting up geo-redundancy keeps your data safe if a region goes down. It helps you get your data back fast. You can turn this on when you make a new instance or update one you already have. For even better disaster recovery, you can set up failover groups in different regions.

Configure During Creation

When you make a new Azure SQL Managed Instance, you pick your backup storage redundancy. This step protects your data from the start.

1. Open the Azure Portal and start making a new managed instance.

2. On the Basics tab, type in your instance details.

3. Go to the Configure Managed Instance section.

4. On the Compute + Storage page, pick your backup storage redundancy. You can choose local, zone, geo, or geo-zone options.

5. If you want zone redundancy, set the zone redundant option to Yes. This is only in the Business Critical service tier and some regions.

6. Check your settings and finish making the instance.

Note: You cannot change some redundancy options after you make the instance. Think about your geo-redundancy needs before you start.

If you pick geo-redundant or geo-zone-redundant storage now, you get the best protection. Your backups will be in another region. You can restore your data even if your main region fails.

Update Existing Instance

You can turn on geo-redundancy for backup storage on an existing managed instance. This helps you make your disaster recovery plan better without making a new instance.

Do these steps in the Azure Portal:

1. Go to your managed instance.

2. Click Configure Managed Instance.

3. On the Compute + Storage pane, pick Geo or GeoZone for backup storage redundancy.

4. Click Apply to save your changes.

You can also use Azure CLI or PowerShell:

• Azure CLI:

az sql mi update --name <instance-name> --resource-group <resource-group> --backup-storage-redundancy Geo

• PowerShell:

Set-AzSqlInstance -Name <instance-name> -ResourceGroupName <resource-group> -BackupStorageRedundancy Geo

💡 Tip: Changing backup storage redundancy only changes point-in-time restore backups. It does not change long-term retention backups. How long it takes depends on your database size.

If you want zone redundancy, you must use the Business Critical service tier. Set the zone redundant option to Yes when you set it up. This spreads your instance across more than one zone. You can only turn this on or change it in the Azure Portal or with the ARM REST API. CLI and PowerShell will support this soon.

Set Up Failover Groups

To protect your data across regions, set up failover groups between managed instances in different Azure regions. This lets you switch to another region if your main one fails.

Before you start, make sure you do these things:

• Put managed instances in two different Azure regions. Paired regions work best.

• Both instances need the same DNS zone.

• Use the same service tier and compute size for both.

• Set up network connections between the virtual networks. Global virtual network peering is best.

• Make and sync logins and other system objects on the secondary instance. System databases do not copy over by themselves.

• Sync instance properties and retention policies on both instances.

To make a failover group:

1. In the Azure Portal, go to your main managed instance.

2. Click Failover groups in the settings menu.

3. Click Add group.

4. Pick your secondary managed instance in a different region.

5. Set the group name and choose the failover policy. Customer managed failover gives you more control and helps stop data loss.

6. Add the databases you want to protect.

7. Check and create the failover group.

Best Practice:

• Keep the number of databases in each failover group small. This makes failover faster and keeps the system from getting too busy.

• Watch geo-replication lag with system views like sys.dm_geo_replication_link_status. This helps you find and fix delays that could cause data loss.

• Turn on zone redundancy on both main and secondary instances for extra safety.

Setting up failover groups with geo-redundancy helps your business keep working, even during big outages. You can control failover, lose less data, and keep your apps running.

Test and Validate

Testing your geo-redundancy setup helps make sure your disaster recovery plan works. You should pretend there is a failover and practice geo-restore. This shows if your system is ready for real problems.

Simulate Failover

You can pretend to failover to see if your Azure SQL Managed Instance works right. This helps you find problems before a real outage happens.

1. Make sure you have the right permissions. You need to be a Subscription Owner, Managed Instance Contributor, or have a custom role that lets you do failovers.

2. Use PowerShell to start a failover:

   • Log in to your Azure account.

   • Pick your subscription.

   • Run this command:

Invoke-AzSqlInstanceFailover -ResourceGroupName <resource-group> -Name <instance-name>

1. • If you use Business Critical tier, add -ReadableSecondary to failover a readable secondary node.

2. You can also use Azure CLI:

   • Run:

az sql mi failover -g <resource-group> -n <instance-name>

1. • For readable secondary, add --replica-type ReadableSecondary.

2. For more advanced needs, use the REST API. Get an authentication token and make the failover call with the right details.

3. You cannot start a failover if a full backup is waiting or a restore is happening. Wait at least 15 minutes between failovers.

🛠️

Geo-Restore Process

If your main region is down and you do not use failover groups, geo-restore helps you get your database back in another region. This uses geo-redundant backups to bring your data online.

1. Go to the Azure portal and make a new SQL Database in a different region.

2. On the settings page, pick to restore from an existing backup.

3. Choose the newest geo-replicated backup from your source region.

4. Match the compute and storage settings to your old database. You can change these after the restore.

5. Start the restore.

6. You can also use PowerShell:

   • Run:

Get-AzSqlDatabaseGeoBackup -ResourceGroupName <resource-group> -ServerName <server-name> -DatabaseName <database-name>

1. • Then restore:

Restore-AzSqlDatabase -FromGeoBackup -ResourceGroupName <target-resource-group> -ServerName <target-server> -TargetDatabaseName <new-database-name>

1. After you restore, update your app connection strings to use the new instance.

2. Practice disaster recovery drills often to make sure your team and apps are ready.

⚠️

Troubleshooting

Common Issues

You might run into problems when setting up geo-redundancy for Azure SQL Managed Instance. Sometimes, you cannot pick zonal redundancy because your region or hardware does not allow it. For example, Premium-series (memory optimized) hardware is still in preview and is not everywhere yet. If you see the zonal redundancy choice is greyed out, check your region and hardware.

Active geo-replication does not work with Azure SQL Managed Instance. You have to use Auto-Failover Groups for geo-redundancy and high availability. You need to know how failover groups work and set them up right. If you skip this, you might not get the protection you want.

DNS problems can make failover groups stop working. If you use Private Link and Azure Key Vault, your setup needs Private DNS to work. When Private DNS fails, connections use public DNS instead. Azure Key Vault blocks these because of firewall rules. Your managed instance may think the key is revoked, which can break failover groups and make databases not work. Network Security Group rules that block Private Endpoints or DNS problems also cause trouble. Always check your network and DNS settings to stop these issues.

Limitations

Azure SQL Managed Instance geo-redundancy has some limits. You cannot use active geo-replication. Only Auto-Failover Groups give cross-region disaster recovery. Not every region supports all redundancy or hardware choices. Some features, like zone redundancy, only work in certain service tiers or regions.

You cannot change some redundancy settings after you make your instance. If you pick the wrong one, you might need to make a new instance. Failover groups need both primary and secondary instances to use the same DNS zone and service tier. System databases do not copy by themselves, so you must sync logins and jobs.

⚠️

Troubleshooting Steps:

1. Wait for running tasks to finish or stop stuck ones.

2. Add retry logic with exponential backoff in your apps.

3. Clear connection pools after failover events.

4. Double-check your connection strings and network settings.

5. Make sure you do not connect to a read-only replica by mistake.

6. Watch for short error codes and retry connections if needed.

7. Test if you can connect using SQL Server Management Studio or network tools.

8. If you still have problems, ask Microsoft support for help.

---

You now know how to keep your Azure SQL Managed Instance safe. It is important to test your disaster recovery plan often. This helps you make sure it will work when needed. To keep things running well, try these tips:

• Turn on zone redundancy for better safety.

• Use failover groups to keep your business going.

• Make geo-replicated backups and use geo-restore if needed.

• Set up alerts for service health and metrics.

• Watch your instance with Azure SQL analytics.

Check the Azure SQL Managed Instance overview docs often. This helps you learn about new features and advice.

FAQ

What happens if my primary region goes down?

You can use geo-restore or failover groups to get your data back in another region. This helps your apps keep working and makes downtime shorter. Always practice your disaster recovery plan to be sure it works.

Can I change backup storage redundancy after creating my instance?

You can change backup storage redundancy for point-in-time restore backups. You cannot change it for long-term retention backups. Some choices, like geo-zone-redundant storage, might not be in every region.

Do I need to set up failover groups for geo-redundancy?

You do not have to use failover groups for basic geo-redundancy. Failover groups help you recover faster and switch over automatically. Use them if you want your business to keep running in other regions.

How do I know if my region supports zone or geo-redundancy?

Look at the Azure documentation to see which regions are supported. Some redundancy types only work in certain regions or service tiers. You can also check the Azure Portal when setting up your instance to see what is available.