Forem: Rajeshwaran M

Azure Site Recovery BCDR Strategy

Rajeshwaran M — Sat, 20 Sep 2025 11:10:31 +0000

What is Azure Site Recovery

Azure Site Recovery replicates your virtual-machine workloads between Azure regions. You can also use Site Recovery to migrate VMs from other environments, such as on-premises infrastructure, to Azure. You will learn that Site Recovery does much more than just backing up and restoring infrastructure.

With ASR, you can:

Replicate workloads across Azure regions.

Migrate on-premises VMs (VMware, Hyper-V, or physical servers) to Azure.

Protect and recover Azure VMs across paired regions.

ASR provides more than just backup—it delivers orchestrated failover and recovery, ensuring your critical applications remain available.

Multiple data consistency options

Crash Consistency

Snapshot of all data on disk every 5 minutes.
Retention up to 72 hours for application servers.

Application consistency

Snapshot of data on disk + in-memory data every hour.
Retention up to 72 hours for databases.

Multi VM consistency

Consistent recovery points across multiple VMs
Replication group created for all enabled VMs.
Shared crash & app consistent recovery points for all VMs in a group

Platform Support:

Windows OS: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2

Linux OS: RHEL 5,6,7,8 - CentOS 5,6,7,8 - Ubuntu 14.0- 20.04 LTS
SUSE Enterprise Server 11-15, OEL 6-8, Debian 7-9

vSphere & vCenter: 5.5,6.0,6.5,6.7, 7.0

Azure Platform: Managed Disk, Encrypted Storage, Azure Hybrid Benefit

Benefits of Azure Site Recovery

Business Continuity: Keeps workloads running during outages or maintenance.

Cost-Effective: Reduces DR costs by leveraging Azure infrastructure.

Compliance & Reliability: Meets regulatory requirements for disaster recovery.

Scalable & Flexible: Supports hybrid, on-premises, and cloud-native workloads.

Recovery Objectives

RPO (Recovery Point Objective): Defines acceptable data loss (seconds to minutes).

RTO (Recovery Time Objective): Defines how fast workloads can be recovered.

Account Permissions

Site Recovery uses role-based access control in Azure, which enables fine-grained access control and enables you to use several built-in Site Recovery roles

Roles
Site Recovery Contributor- Full permissions for SR operation, suitable for disaster recovery admins

Site Recovery Operator- Operator has permissions to run and administer site recovery failover and failback operations, suitable for disaster recovery operators.

Site Recovery Reader- To view Site Recovery operations, suitable for IT monitoring executives.

Lab Setup:
To set up DR, we will follow the steps below to replicate resources in the target environment.

Step 1:
Create a resource group for both the source and the target environments, as shown in the screenshot below.

Step 2:
Create a Linux VM in the source environment so that we can fail it over to the target location.

Step 3:
Create a VNet and an Azure Recovery Services vault to replicate our source resources.
Also, make sure to create a Recovery Services vault in the target Resource Group.

Step 4:
Go to the Recovery Services vault, click Enable Site Recovery as shown in the screenshot, and enable replication for the VM.

When you enable replication in the target environment’s Recovery Services vault, it automatically installs the Site Recovery Mobility Service extension on the source VMs.

In Azure Site Recovery (ASR), an Automation Account is used to run Recovery Plans with automated scripts during failover and failback operations.
Key Purposes:
Automated Recovery Actions:

Execute PowerShell or Python scripts during failover
Perform custom configuration tasks that can't be handled by ASR alone
Automate post-failover activities like IP address changes, DNS updates, or application-specific configurations

Recovery Plan Enhancement:

Add manual actions and automated scripts between VM groups
Sequence complex multi-tier application recovery
Handle dependencies between different application components

Common Automation Scenarios:

Network Configuration: Update load balancer settings, firewall rules, or network security groups
Application Configuration: Start services, update connection strings, or modify configuration files
DNS Updates: Change DNS records to point to the new environment
Notification: Send alerts or notifications to teams about the failover status

Consistency & Reliability:

Ensures repeatable, standardized recovery procedures
Reduces human error during high-stress disaster situations
Provides audit trails for compliance requirements

Example Use Case:
During a failover, ASR might recover your VMs successfully, but you still need to:

Update your application's database connection string to point to the recovered database
Restart specific services in a particular order
Update external DNS records

The Automation Account handles these tasks automatically through runbooks, making your disaster recovery truly automated rather than just VM recovery.
Note: Automation Account is optional - you only need it if you require custom scripts in your Recovery Plans.

Enable Replication:

Azure Site Recovery has a High Churn option that you can choose to protect VMs with a high data change rate. With this, you can use a Premium Block Blob type of storage account. By default, the Normal Churn option is selected.
Enabling the replication option takes some time, so please wait. It took 51 minutes for me

Step 5:
Run a disaster recovery drill for Azure VMs. Please follow the steps below
In the vault > Replicated items, select the VM and on the Overview page, check that the VM is protected and healthy.

Double-click on the replicated Items and select Test Failover.

In Test Failover, you will be prompted to choose a recovery point. The Azure VM in the target region is created using data from the selected recovery point. Select the Latest one from that list as shown in the screenshot below.

Monitor the test failover in notifications.

After the failover finishes, the Azure VM created in the target region appears in the Azure portal under Virtual Machines. Make sure that the VM is running, sized appropriately, and connected to the network you selected.

Final Step:
Clean up resources
To clean up, select the Cleanup test failover button to clean up the created resources.

Put some notes, and then click OK

you ran a disaster recovery drill to check that failover works as expected. Please feel free to let me know in the comments section if I have made any mistakes. Happy Learning :)

Resources:
Source Region: east-us
Resource Group: asr-source
Vnet: vnet-asr
StorageAccount Cache: szk0h1vaultdrasrcache
VM: vm1
PublicIP: vm1-ip

Target Region: west-us
Resource Group: asr-target
Vnet: vnet-asr-DR
Vault: vault-DR
Automation Account: vault-DR-spe-asr-automationaccount

Reference:
https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-tutorial-enable-replication

https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-tutorial-dr-drill

https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-tutorial-failover-failback

Jump Server Setup

Rajeshwaran M — Tue, 05 Aug 2025 12:38:55 +0000

What is Jump Server?
A jump server is a specially configured server that acts as a secure gateway to access other servers in a private network.

Think of your internal servers are like a secure building, and the jump server is like a security checkpoint at the entrance. You can't directly enter the building from the street - you must first go through the security checkpoint, get verified, and then access the rooms inside.

This guide implements a secure jump server architecture where:

Jumpbox: A VM deployed in a public subnet with a public IP.

Target VMs: Private Azure VMs (no public IP) in the same Virtual Network.

Access: The admin connects to the jumpbox via RDP/SSH and then to the target VMs via their private IP.

Public Subnet

Address Prefix: 10.0.1.0/24

NSG Rules: Allow RDP/SSH from your home public IP

Public IP: ✅ Yes (for Jumpbox only)

Private Subnet

Address Prefix: 10.0.2.0/24

NSG Rules: Allow access only from Jumpbox IP

Public IP: ❌ No public IPs

Step 1 :
Create a Resource group as shown in the screenshot below, I'm going to call it rg-jumpbox

Step 2 :
Create Vnet
Go to Azure Portal
Search for Virtual networks → Click + Create

Also, create public and private subnets while creating a VNet, as shown in the screenshot below

Once both subnets are added, click Review + create → Create

Step 3:
Create an NSG group for the public subnet and the private subnet

In Azure Portal, search for Network security groups

Click + Create

Step 4:

Create an NSG rule to allow SSH/RDP connection only from your home IP

After creating PublicSubnet-NSG, open it.

Go to Inbound security rules → Click + Add

Source: your public IP (check https://whatismyipaddress.com)
Destination port ranges: 3389 or 22
Protocol: TCP
Action: Allow
Priority: 100
Name: Allow-Admin-RDP

Associate the NSG with the public subnet

Follow the same steps for the private subnet and associate the private NSG with the private subnet.

Source: your Jumpbox subnet or your jumpbox VM IP
Destination port ranges: 3389 or 22
Protocol: TCP
Action: Allow
Priority: 100
Name: Allow-Jumpbox-RDP or Allow-Jumpbox-SSH

Step 5:
Create a Jump Server and a Test VM to check the RDP connection

TestVM

I was able to connect the Test VM from the jump server

s2s vpn connection check

Rajeshwaran M — Sat, 14 Jun 2025 13:33:04 +0000

Before we check the connection, we should peer the Hub and Spoke network
Please follow the steps to enable the VNet peering between the Hub and Spoke.

In hub-and-spoke network architecture, gateway transit allows spoke virtual networks to share the VPN gateway in the hub, instead of deploying VPN gateways in every spoke virtual network.

Go to the Hub VNet, select the peering option

Peering link name: Name the link. Example: spoke-to-hub
Virtual network deployment model: Resource Manager
I know my resource ID: Leave blank. You only need to select this if you don't have read access to the virtual network or subscription you want to peer with.
Subscription: Select the subscription.
Virtual Network: select the spoke VNet from the dropdown

The peering connection should be configured as shown in the screenshot below

To check the connection between the on-prem and the hub network, we are going to deploy the Windows Jump host on the spoke VNet and deploy the Windows VM in the on-prem VNet.

Step 1:
Create a Windows Jump Host in the spoke VNet. Also, please keep in mind that, by default, Azure blocks ICMP traffic, so we need to add inbound and outbound rules to the Windows Jump Host to allow ICMP. Please refer to the NSG rule below.

One more thing: the Windows machine firewall also blocks ICMP traffic, so you need to enable the following rule in Windows Firewall: File and Printer Sharing (Echo Request - ICMPv4-In).

Also, add the remote IP address range to the scope, as shown in the screenshot below. I spent 3 days finding these settings. 🙂

Open Windows PowerShell on the Jump Host and try the tnc command to check the RDP connection to the remote network as shown in the screenshot below.

Step 2:
Create a Windows machine in the spoke VNet. As you may already know, by default, Azure blocks ICMP traffic, so we need to add inbound and outbound rules to the Windows VM to allow ICMP. Please refer to the NSG rule below.

Here, we also need to modify Windows firewall settings as we did before enabling the File and Printer Sharing (Echo Request - ICMPv4-In) rule.

Open Windows PowerShell on the Windows VM and try the tnc command to check the RDP connection to the remote network, as shown in the screenshot below.

I referred to the following Microsoft document to complete this setup. It took me a long time to figure things out—even though I had Microsoft documentation for reference, I was scratching my head trying to figure out the NSG rule and Windows Firewall. Eventually, I managed to resolve it.

https://learn.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portal

https://learn.microsoft.com/en-us/azure/virtual-network-manager/tutorial-create-secured-hub-and-spoke

https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-peering-gateway-transit

If I’ve made any mistakes or incorrectly mentioned any steps, please feel free to let me know in the comments section. Happy learning! I’ll try to post another interesting project soon. See you all :)

Site-to-Site VPN Connection setup on Azure

Rajeshwaran M — Sat, 14 Jun 2025 06:04:26 +0000

What is s2s VPN?
A Site-to-Site VPN (S2S VPN) is a type of IPsec VPN connection that securely connects two networks (sites) over the public internet.
Typically, between your on-premises network (e.g., a physical office, data center, or Proxmox-hosted Linux box) and your Azure virtual network (VNet) or other cloud network.

Simple Example:
Location Network IP Range
On-prem (Office) Router + Firewall 192.168.1.0/24
Azure VNet Virtual network 10.0.0.0/16

With S2S VPN:

A VM in Azure can talk to your on-prem file server at 192.168.1.10

Your on-prem server can talk to a VM in Azure at 10.0.0.4

All traffic is encrypted using IPsec/IKE protocols.

In the example below, I'm going to simulate the on-premises environment in Azure. Please find below the resource details for reference

Create 1 On-Prem VNet

Name: onpremvnet
Address Range: 172.0.0.0/16
Within an on-premises VNet, create a Gateway Subnet
Subnet Name: GatewaySubnet
Address Range: 172.0.1.0/27

Create 1 Hub VNet
Name: hubvnet
Address Range: 10.100.0.0/16
Within HubVnet, create a Gateway Subnet
Subnet Name: GatewaySubnet
Address Range: 10.100.1.0/27

Create 2 Spoke VNets
Spoke VNet 1: 10.200.0.0/16
Location: Central India

VNet Peering
Peer both Spoke VNets with the Hub VNet

Create 2 VNet Gateways
VNet Gateway 1: In on-premises vnet
VNet Gateway 2: In hubvnet

Create 2 Local Network Gateways
Local Network Gateway 1: Represents Azure hub on the on-prem side
Local Network Gateway 2: Represents on-prem on the Azure hub side

Create 2 VPN Connections
Connection 1: From onpremvnet → hubvnet
Connection 2: From hubvnet → onpremvnet

Step1:
Create a Resource Group for hub, spoke, and on-prem as shown in the screenshot below.

Step2:
Create a VNet corresponding to the resource group that we have already created. Please refer to the screenshot below for reference.
Don’t forget—you need to create three VNets, each corresponding to the resource group. You can create both spoke VNETs in a single spoke resource group

Step 3:
Create a Virtual Network Gateway and a Local Network Gateway for the on-prem VNet and the hub VNet, as shown in the screenshot below.
You can choose any VPN SKU based on your requirements. For this experiment, I’m going to use VPNGW1. Also, disable the active-active mode for the sake of the lab

Local Network Gateway Creation on ONPREM

The local network gateway is a specific object deployed to Azure that represents your on-premises location (the site) for routing purposes.

We have created the on-prem virtual network gateway on the on-prem VNet, so you must enter its public IP address when creating the local network gateway.

In the address space field, I used the full range of the hub/spoke network, so I entered 10.0.0.0/8. You can also enter specific hub network address range, such as 10.100.0.0/16.

For the Sake of the lab, leave the BGP setting as it is

Please, repeat the same step for the Hub Network as well.

Step 4:
Create a connection profile between the on-prem network and the Azure hub network, and vice versa(bidirectional), and check the connection status

Need to establish the connection from the hub to the on-prem network, as shown in the screenshot below. Repeat the same step for on-prem to hub.

Please keep in mind that when you create a connection between the on-prem network and the hub, you need to set a shared key. Just enter a combination of letters and numbers. You’ll also need to use the same value when creating the connection on the other side.

As you can see in the screenshot below, the connection has been successfully established between both networks.

The next step is we are going to create a Jump host in the spoke VNet to check the connection.

Click the link below to complete the remaining setup

https://dev.to/rajeshwaranm/site-to-site-vpn-check-the-connection-using-the-jump-host-4h27