DR setup using Azure ASR

Hello @Penumarthi Dora Krishna@Penumarthi Dora Krishna Thank you for posting your query on Microsoft Q&A platform.

• ASR is OS‑level replication, not application‑aware for DB2.
• DB2 consistency is achieved by crash‑consistent or file‑system–consistent recovery points.
• DB2 does NOT need any special plugin for ASR.
• Recommended: Combine ASR with DB2 native backups / HADR for strict RPO/RTO.

STEP 1: Verify Prerequisites (CRITICAL)

1.1 Supported OS

• RHEL 8.x is supported for Physical Server → Azure replication.

1.2 Disk & File System

• No unsupported disk formats
• LVM and XFS are supported
• No custom kernel (must use Red Hat stock kernel)

1.3 Network

Allow outbound HTTPS (443) from on‑prem server to Azure:

• *.blob.core.windows.net
• *.hypervrecoverymanager.windowsazure.com
• login.microsoftonline.com
• *.servicebus.windows.net

STEP 2: Prepare Azure Environment:

2.1 Create Recovery Services Vault

Azure Portal →

• Create Resource
• Backup and Site Recovery
• Choose same region where DR VM will be created

2.2 Create Azure VNet

• Create VNet + Subnet
• Used by failed‑over DB2 VM

2.3 Assign Required Roles

User enabling replication must have:

• Virtual Machine Contributor
• Site Recovery Contributor

STEP 3: Deploy Configuration Server (On‑prem): Required for physical server replication

3.1 Download Configuration Server

Recovery Services Vault → Site Recovery → Prepare Infrastructure

3.2 Install Configuration Server

• Deploy on a dedicated Windows Server
• Register with Recovery Services Vault
• This also acts as Process Server

STEP 4: Install Mobility Service on DB2 RHEL Server

4.1 Download RHEL 8 Mobility Agent

From Configuration Server repository:

Microsoft-ASR_UA_version_OL8-64_GA_release.tar.gz

4.2 Install Agent on RHEL:

tar -xvf Microsoft-ASR_UA_*.tar.gz
sudo ./install

• Provide Configuration Server IP
• Enter passphrase
• Confirm service is running

STEP 5: Enable Replication

Azure Portal → Recovery Services Vault → Site Recovery → Enable Replication

5.1 Source

• Source type: Physical
• Configuration Server: Select deployed server

5.2 Target

• Target: Azure
• Subscription, Resource Group
• VNet, Subnet
• VM size (match DB2 workload)

5.3 Replication Policy

• Frequency: Continuous
• Retention: Based on RPO

5.4 Disk Selection

• Include:
  • OS disk
  • DB2 data disks
  • Log disks

ASR replicates block‑level changes

STEP 6: DB2‑Specific Best Practices (MANDATORY)

6.1 Put DB2 in Backup Mode (Recommended)

Before first sync:

db2 force applications all
db2 backup db <DBNAME> online

Reason:

• Ensures clean crash‑consistent state

6.2 Disable DB2 Autostart on Boot

systemctl disable db2

Prevent DB2 from auto‑starting during test failover.

STEP 7: Test Failover (NO IMPACT)

Azure Portal → Recovery Services Vault → Replicated Items → Test Failover

• Choose latest recovery point
• Select test VNet

Validate on Azure VM

lsblk
mount | grep db2
db2start

DB2 should start successfully

STEP 8: Planned / Unplanned Failover

Planned

• Shutdown DB2 cleanly
• Trigger Planned Failover

Unplanned

• Trigger Failover
• DB2 recovery will run automatically

STEP 9: Post‑Failover Actions

• Update DB2 hostname references
• Update licensing if required
• Validate application connectivity

Recommended Enhancements

• Use DB2 native backups to Azure Blob
• For near‑zero RPO → DB2 HADR + ASR
• Use Recovery Plans for automation

Please have a look into below references:

• Physical Server → Azure DR https://dori-uw-1.kuma-moon.com/azure/site-recovery/physical-azure-disaster-recovery
• Mobility Service (Linux) https://dori-uw-1.kuma-moon.com/azure/site-recovery/vmware-physical-mobility-service-overview
• Failover Process https://dori-uw-1.kuma-moon.com/azure/site-recovery/site-recovery-failover

Azure Site Recovery officially supports DR of on‑premises RHEL 8.x servers (including DB2 workloads) to Azure. ASR works at the OS and disk level and does not provide DB2‑specific application‑consistent recovery points.

Thanks,

Suchitra.

Azure Site Recovery (ASR) can replicate and fail over the entire RHEL VM that hosts Db2, but the provided context only contains a generic ASR implementation checklist and Db2-on-Azure HA guidance, not a Db2‑specific ASR runbook. The following steps combine that generic ASR checklist with the Db2 RHEL guidance from the context.

1. Prepare and plan the Db2 environment

• Ensure the on-premises RHEL 8.10 VM with Db2 11.5.9 is stable and in production shape (proper storage layout, network, and performance).
• If high availability is also required in Azure (not only DR), plan for Db2 HADR and Pacemaker on Azure VMs as described in the Db2 HA guidance. For pure DR via ASR, the minimum is a single replicated VM.
• Plan Azure resources for the DR target:
  • Resource group(s) for VMs, virtual network, and load balancer (if later using HADR in Azure).
  • Virtual network and subnet where the replicated Db2 VM will be created.
  • VM size and storage layout appropriate for Db2 workload.
  • Name resolution (DNS) strategy for Db2 virtual hostname.

2. Configure VMs for disaster recovery (ASR prerequisites) From the ASR implementation checklist:

• For VMware or physical machines (typical for on-prem RHEL):
  • Configure the ASR protection server, configuration server, and target servers.
  • Ensure the ASR mobility service is installed on the RHEL Db2 VM so it can be replicated.
• For Hyper‑V (if the RHEL VM runs on Hyper‑V):
  • Download and install the Microsoft Azure Site Recovery Provider on the VMM server or Hyper‑V host.
  • Download and install the Microsoft Azure Recovery Services agent on the Hyper‑V host.
• Verify that the RHEL kernel is supported by the ASR mobility agent; if a newer kernel is in use, apply any ASR mobility-agent hotfixes required for that kernel (as illustrated in the Debian example in the context).

3. Prepare Azure resources for the Db2 DR target

• Create or select an Azure Storage account as required by ASR for replicated data.
• Create or select a Recovery Services vault and configure it for replication from the on-prem site.
• Create or select the Azure virtual network and subnet that will host the failed-over Db2 VM.
• If planning to later convert to an Azure-native Db2 HADR cluster, also plan:
  • Virtual host name and virtual IP for Db2.
  • Standard Azure Load Balancer and probe port (for example, 62500 as recommended in the Db2 HA guidance).

4. Enable protection for the Db2 RHEL VM

• In the Recovery Services vault, enable protection for the on-premises RHEL Db2 VM:
  • Select the on-premises site (VMM cloud, Hyper‑V site, or VMware site) that contains the Db2 VM.
  • Enable replication to Azure for that VM.
  • Choose the target resource group, Azure VNet/subnet, and target storage.
• Wait for initial replication to complete and verify that the VM shows as “Protected” in the vault.

5. Validate Db2 consistency considerations

• ASR replicates the VM at the OS level; Db2 crash-consistent recovery is typically used unless application-consistent snapshots are integrated.
• Ensure Db2 logging and recovery configuration is appropriate so that Db2 can recover cleanly after a crash-consistent failover.
• For SAP-on-Db2 scenarios, follow the SAP/Db2 installation guidance for HADR and Pacemaker on Azure if converting to a full HA setup after failover.

6. Design the recovery plan From the ASR checklist:

• Map on-premises networks to Azure VNets so that the failed-over Db2 VM can communicate with required services (for example, SAP application servers, Active Directory, DNS).
• Create a recovery plan that includes:
  • The Db2 RHEL VM as a protected item.
  • Any dependency VMs (for example, SAP application servers) if they are also being replicated.
  • Boot order and any manual steps (for example, Db2 start commands, SAP-specific steps) as scripted or documented actions.

7. Test failover (DR drill – non-disruptive)

• Run a test failover from the Recovery Services vault using the recovery plan:
  • Use a test network in Azure so production traffic is not affected.
  • Verify that the Db2 VM boots successfully in Azure.
  • Log in to the test VM, check Db2 instance status, and confirm that Db2 can be started and the database opens.
  • For SAP environments, verify that SAP application servers can connect to Db2 using the planned virtual hostname/IP.
• Validate that all required resources (for example, DNS, Active Directory if used) are reachable from the failed-over VM.

8. Run a full disaster recovery drill

• Perform planned and unplanned failover drills as described in the ASR checklist:
  • Planned failover: shut down Db2 cleanly on-premises, then trigger failover to Azure.
  • Unplanned failover: simulate a site outage and trigger failover without clean shutdown.
• After failover, verify:
  • The Db2 RHEL VM is running in Azure with expected size and storage.
  • Db2 instance and databases start and recover successfully.
  • Application connectivity (for example, SAP) works as expected.

9. (Optional) Convert to Azure-native Db2 HA with HADR and Pacemaker If the long-term goal is not only DR but also HA within Azure, follow the Db2 HA guidance for RHEL on Azure VMs:

• Plan and deploy additional Azure VMs for a Db2 HADR secondary.
• Install and configure Pacemaker on RHEL.
• Configure shared storage (for example, Azure NetApp Files or GlusterFS) if required by the broader SAP landscape.
• Configure Db2 HADR between primary and secondary Azure VMs.
• Configure a Standard Azure Load Balancer with a probe port (for example, 62500) and virtual IP/hostname for Db2.
• Perform failover and takeover tests at the Db2/HADR level.

This sequence uses ASR to provide VM-level DR from on-premises to Azure and, if desired, extends to a full Db2 HADR/Pacemaker HA design once in Azure.

---

References:

• Set up disaster recovery for RDS using Azure Site Recovery
• High availability of IBM Db2 LUW on Azure VMs on Red Hat Enterprise Linux Server