On- prem to Azure DR setup

Hello Penumarthi Dora Krishna,

Thank you for reaching out to the Microsoft Q&A forum.

It looks like you want to protect three Linux‐based workloads (a virtual appliance, a DB2 server and an LDAP server) from on-prem to Azure with an RTO around 4 hrs and an RPO between 15 mins–1 hr. The most turnkey way to achieve that is Azure Site Recovery (ASR), which can replicate VMware or physical machines (including RHEL) into Azure near-real time.

Here’s a high-level approach:

Plan and size

• Use the Deployment Planner (for VMware) or do manual capacity planning (for physical servers) to estimate CPU, memory, network and storage needs in Azure.

• Gather disk sizes, change rates and monthly data growth for each server—this drives storage costs and bandwidth usage.

Prepare Azure

• Create a Recovery Services vault in your target Azure region.

• Make sure you have sufficient quotas for cores, storage accounts and networking (NSGs, VPN/ExpressRoute).

Deploy ASR on-prem components

• Install the ASR configuration server and process server on-prem (these handle replication, caching and compression).

• Open required outbound ports (443, 9443) to Azure (see network URLs in docs).

Enable replication

• In the vault, select “Enable replication,” choose your on-prem environment (VMware or physical), point to your config server, then select the machines: – Virtual Appliance (10.0.2.4) – RHEL 7.9 host running DB2 11.5.9.0 – RHEL 7.9 host running LDAP 6.4.0.25

• Configure replication settings to target your desired RPO (ASR can get down to 30 sec–5 min RPO for most workloads).

Test and validate

• Do a non-disruptive test failover to confirm machine boot, networking and application health in Azure.

• Tweak VM size, managed disk type (Standard SSD or Premium), and network settings as needed.

Failover and failback

• During an outage, you can orchestrate a planned or unplanned failover via ASR (RTO well under 4 hrs).

• When on-prem is back, you can fail back with minimal data loss.

Cost considerations

• ASR instance fee: ~$25 USD per protected instance per month.

• Azure storage for replicated disks: cost per GB/month (Standard LRS or Premium).

• Compute cost for DR VMs during an actual failover (you only pay compute when VMs are running).

• Network egress/storage replication traffic is free within Azure but you may incur on-prem bandwidth costs.

• Optionally, incremental snapshots + cross-region copy could lower costs if you only need hourly RPO—but won’t meet a 15 min RPO.

Rough ballpark (example): – 3 instances × $25 = $75/mo for ASR licensing – If each server has 1 TB of data on Premium SSD P10 ($100/TB/mo) → ~$300/mo – Total ~ $375/mo + any network costs + surge compute during failover

Hope this gives you a solid starting point!

Reference list

1. Best practices for VMware/physical machines with Azure Site Recovery https://docs.microsoft.com/azure/site-recovery/vmware-physical-large-deployment
2. Set up disaster recovery to Azure for on-premises physical servers https://docs.microsoft.com/azure/site-recovery/physical-azure-disaster-recovery
3. Enable VM replication with Azure Site Recovery https://docs.microsoft.com/azure/site-recovery/
4. Backup and data recovery for Azure Stack with the Infrastructure Backup Service https://docs.microsoft.com/azure-stack/operator/azure-stack-backup-infrastructure-backup

 Let me know if you have any questions?

For the stated RTO (4 hours) and RPO (15–60 minutes) from on-premises to Azure, a DR design must cover all three components (VA, DB2 server, LDAP server) and the surrounding infrastructure.

A suitable high-level approach on Azure, based on the provided material, is:

1. Define and validate business requirements
   • Confirm that all three systems (VA, DB2, LDAP) are part of the same business process and must fail over together.
   • Explicitly document RTO/RPO per component and for the end-to-end service, as recommended for DR planning: identify which services are critical and their RPO/RTO, and map all integration points (for example, applications that depend on DB2/LDAP, external consumers, and admin access paths).
2. Choose Azure region and DR topology
   • Select an Azure region that meets regulatory and distance requirements between on-premises and Azure. Larger distances increase network latency and can push RPO higher; this must be considered against the 15–60 minute RPO target.
   • If the DR site is entirely in Azure (single region), use that region as the DR region for the on-premises environment. If later extending to Azure-to-Azure DR, apply the same region-pair and availability zone guidance used for SAP and other workloads.
3. Use Azure-native DR building blocks
   • For non-database workloads (VA and LDAP server) running on RHEL VMs, use Azure Site Recovery (ASR) to replicate the on-premises VMs to Azure. ASR is explicitly called out as a core DR technology for IaaS workloads and for improving HA/DR when migrating from on-premises UNIX-like systems.
   • For the DB2 server, use a combination of:
     • Azure Site Recovery for VM-level replication to achieve an RTO typically under 15 minutes and an RPO in the 5–60 minute range (depending on configuration), similar to SQL Server guidance.
     • Optionally, DB2-native replication or log shipping (if available in the environment) to further tighten RPO if needed, following the pattern used for other databases (for example, Oracle Data Guard or SQL Server technologies in the references).
4. Network and connectivity design
   • Establish secure connectivity between on-premises and Azure. The Oracle DR example shows two patterns: direct connections with open TCP ports and a site-to-site VPN. The recommended approach is a site-to-site VPN between on-premises and an Azure virtual network, with:
     • Separate subnets for application/VA, DB2, LDAP, and VPN gateway.
     • Network Security Groups (NSGs) on application and database subnets to restrict access.
   • Ensure that after failover, clients and administrators can reach the DR VMs in Azure (DNS changes, routing updates, jumpbox/bastion access, and firewall rules must be part of the runbook).
5. RTO/RPO alignment
   • Azure Site Recovery for IaaS workloads is documented with:
     • Typical RTO < 15 minutes for protected VMs.
     • RPO around 5 minutes for crash-consistent recovery points and up to 1 hour for application-consistent points.
   • These values align with the requested RTO of 4 hours and RPO of 15–60 minutes, provided replication is configured correctly and bandwidth is sufficient.
   • For workloads where RPO must be closer to 15 minutes, configure more frequent recovery points and validate that the network and storage throughput support the data change rate.
6. End-to-end DR plan and runbooks
   • Follow the general DR planning guidance used for SAP and Databricks workloads and apply it to this stack:
     • Identify all failover triggers (site outage, application outage, security incident).
     • Document detailed runbooks for failover and failback, including:
       • Order of bringing up VA, DB2, and LDAP in Azure.
       • Network/DNS changes.
       • Validation steps (application health checks, DB2/LDAP connectivity).
     • Plan and schedule regular DR tests to meet compliance and to validate that RTO/RPO targets are met.
7. Cost estimation approach
   The provided context does not include specific pricing, but the cost model for this design is driven by:
   • Azure Site Recovery protection for each on-premises VM (VA, DB2, LDAP).
   • Azure storage for replicated disks (managed disks in the DR region).
   • Azure compute for DR VMs:
     • Minimal or no compute cost if using a “cold” DR pattern where VMs are only started during tests or actual failover.
     • Ongoing compute cost if using a “warm” DR pattern with continuously running VMs.
   • Networking costs for site-to-site VPN and data egress from on-premises to Azure.
   • Optional additional services (backup, monitoring, log analytics).
     A detailed estimate requires: VM sizes and disk sizes for VA, DB2, and LDAP; expected data change rate (for ASR replication); chosen Azure region; and whether DR VMs remain powered off until failover.
8. Migration and improvement path
   • Over time, consider modernizing the environment (for example, moving from legacy UNIX to Linux on Azure, as in the AIX-to-RHEL scenario) to take fuller advantage of Azure HA/DR capabilities and potentially reduce RTO further.

References:

• Disaster recovery overview and infrastructure guidelines for SAP workload
• Disaster recovery for an Oracle Database 12c database in an Azure environment
• Disaster recovery
• Set up disaster recovery for SQL Server
• AIX UNIX on-premises to Azure Linux migration