SEO Summary: Stuck staring at a greyed-out restore button during a DR drill? Here is the unvarnished truth about Azure Recovery Services Vault cross-region limitations and the three ways we actually solve it in production.

Azure Cross-Region Restore: Why Your RSV is Ignoring You (and How to Fix It)

I still wake up in a cold sweat thinking about the “Black Friday Incident” of 2019. We had a primary region outage in East US 2. No big deal, right? I had backups. I had a Recovery Services Vault (RSV). I had a fresh coffee in my hand. I went to restore prod-sql-04 to Central US, and the option simply… wasn’t there.

The “Cross Region Restore” feature was either disabled or not fully replicated. I spent the next six hours manually shoveling VHDs across the continent while the CTO paced behind my desk asking for updates every ten minutes. If you are reading this because you just realized you can’t restore your VM to a different region, I feel your pain. Put the coffee down, take a breath, and let’s fix this.

The “Why”: Why is Azure Being Difficult?

Here is the hard truth: Azure Recovery Services Vaults are notoriously clingy. By default, the data inside a vault is strictly coupled to the region where the vault lives. It’s a hard boundary issue.

Even if you set your storage redundancy to Geo-Redundant Storage (GRS), that just means Microsoft is copying your data to a paired region for their durability assurances. It doesn’t automatically mean you get to touch it whenever you want. Unless you explicitly enable Cross Region Restore (CRR), that secondary copy is essentially “dark” data—it’s there, but you can’t restore from it until Microsoft declares a regional disaster (which almost never happens), or you flip the switch (which takes time to propagate).

Pro Tip: Changing a Vault from LRS (Locally Redundant) to GRS is impossible once you have protected items in it. If you set up the vault wrong on Day 1 with LRS, you are looking at a migration, not a setting change.

The Fixes

Solution 1: The “Official” Fix (If You Have Time)

If you aren’t currently in a fire-fighting scenario and you’re just reading this because a Restore Drill failed, this is the clean path. You need to enable CRR. This allows you to restore data in the secondary region even if the primary region is technically “up.”

Go to your RSV -> Properties -> Backup Configuration -> Update. Ensure storage is GRS, and check the box for Cross Region Restore.

The Catch: It can take up to 24 hours for the data to actually sync and become restorable in the secondary region. If prod-app-01 is down right now, this won’t help you immediately.

Solution 2: The “AzCopy” Shuffle (The Real World Fix)

This is the method I use when things are broken, the boss is yelling, and the “Restore to Secondary Region” button is greyed out. It’s manual, it’s annoying, but it works 100% of the time regardless of your vault settings.

Instead of trying to restore the VM directly to the new region, we restore the Disks to a Storage Account in the original region, move them ourselves, and rebuild.

1. Restore Disks: In the RSV, choose “Restore” -> “Restore Disks” (do not select “Create New Virtual Machine”). Target a Storage Account in the source region.
2. Copy to Target: Use AzCopy to blast those VHDs to a Storage Account in your target region (e.g., West US).
3. Rebuild: Create a new VM from those VHDs in the target region.

Here is the script I keep in my back pocket for this exact scenario. It uses SAS tokens to move data backbone-to-backbone (which is incredibly fast):

# 1. Generate SAS tokens for source and destination containers in Azure Portal
# 2. Run AzCopy from your local machine or a jump box

$sourceSas = "https://stdpdisks01.blob.core.windows.net/vhds/prod-db-01-os.vhd?sp=r&st=..."
$destSas = "https://stdrdisks01.blob.core.windows.net/vhds/prod-db-01-os.vhd?sp=rw&st=..."

# The Magic Command
azcopy copy $sourceSas $destSas --recursive=true

Once the copy finishes, you create a Managed Disk from the VHD in the new region and attach it to a new VM config. It’s hacky, but it bypasses the RSV region lock entirely.

Solution 3: The “Nuclear” Option (Architecture Shift)

If you are finding yourself doing the AzCopy shuffle frequently, you are using the wrong tool. Azure Backup is for corruption and accidental deletion. It is not a high-performance DR tool.

If your RTO (Recovery Time Objective) is less than 4 hours, stop fighting with RSV and implement Azure Site Recovery (ASR). ASR replicates the VM continuously. The failover involves clicking one button, and the VM spins up in the secondary region with the same IP (assuming you networked it right).

My advice? Use Solution 2 to save your job today. Then use Solution 3 to save your sanity for next time.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions