The SkyCore IT Disaster Recovery Guide: Building Resilient Azure Architectures

Step 1: Establish Your BCDR Strategy and Define Requirements

Before implementing any technology, a clear strategic foundation is paramount. Your Business Continuity and Disaster Recovery (BCDR) strategy must align with business objectives, identifying which applications are critical and what their tolerance for downtime (RTO) and data loss (RPO) truly is. NIST SP 800-34 Rev. 1, the Contingency Planning Guide for Federal Information Systems, emphasizes the initial stages of defining the scope and objectives for contingency planning, directly informing your BCDR strategy. Ready.gov further stresses the importance of making a comprehensive business continuity plan.

Start by categorizing your workloads:

• Tier 0/1 (Mission-Critical): < 1 hour RTO, < 15 minute RPO. Typically requires active-active setups or near-continuous replication.
• Tier 2 (Business-Critical): 1-4 hour RTO, 1-4 hour RPO. Can tolerate some downtime and minor data loss.
• Tier 3 (Important): 4-24 hour RTO, 4-24 hour RPO. Recoverable within a business day.

This definition drives the choice of DR solution. Azure Site Recovery provides continuous replication for Azure VMs and VMware VMs, with replication frequency as low as 30 seconds for Hyper-V, directly supporting aggressive RPOs.

# While no direct CLI command defines RTO/RPO, this step is about strategic documentation.
# You would typically store these definitions in a dedicated DR strategy document or a CMDB.
# Example: Document RTO/RPO for a critical application 'WebApp01'
# Application: WebApp01
# Criticality: Tier 1
# RTO: 30 minutes
# RPO: 5 minutes

Portal alternative: This step is primarily a business and architectural exercise, documented outside the Azure portal. However, you would later configure services within the portal to meet these defined objectives.

Confirmation: A formally documented BCDR strategy, endorsed by stakeholders, detailing RTO and RPO for all critical applications.

Step 2: Assess Risks and Identify Critical Workloads

A comprehensive risk assessment informs your disaster recovery planning. Identify potential threats (natural disasters, cyberattacks, human error, infrastructure failures) and analyze their likelihood and impact on your critical systems. The CISA Ransomware Guide emphasizes identifying critical assets and data, understanding your attack surface, and creating a security architecture that can prevent and recover from ransomware attacks. This step involves a deep dive into your current infrastructure, whether on-premises, hybrid, or cloud-native.

# This step involves documentation and assessment, not direct CLI commands.
# Example: Identify critical Azure VMs requiring DR protection.
# Get a list of all VMs in a specific resource group:
RESOURCE_GROUP_NAME="prod-app-rg"
az vm list --resource-group $RESOURCE_GROUP_NAME --output table

# Identify VMs running specific critical applications, e.g., SQL Server
az vm list -d --query "[?tags.Application=='SQLServer'].name" -o tsv

• `az vm list`: Lists virtual machines.
• `--resource-group`: Filters VMs by a specified resource group.
• `--output table`: Formats the output as a readable table.
• `-d`: Show instance details.
• `--query`: JMESPath query to filter and select specific properties.
• `-o tsv`: Formats output as tab-separated values.

Portal alternative: Navigate to 'Virtual machines' in the Azure portal, filter by resource group, tags, or other properties to identify critical VMs.

Confirmation: A prioritized list of critical applications and infrastructure components, along with their assessed risks and dependencies.

Step 3: Provision Azure Recovery Services Vaults

The Azure Recovery Services vault is the cornerstone of your BCDR strategy in Azure. It's a management entity that stores backup data and orchestrates disaster recovery for various workloads. Both Azure Backup and Azure Site Recovery services utilize this vault. You should create one per region where you intend to manage backups or DR, ensuring data residency and compliance.

# Create a Resource Group for your DR components if one doesn't exist
RESOURCE_GROUP_NAME="SkyCore-DR-RG"
LOCATION="eastus"
az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# Create the Recovery Services Vault
VAULT_NAME="SkyCoreRecoveryVaultEastUS"
az backup vault create --resource-group $RESOURCE_GROUP_NAME --name $VAULT_NAME --location $LOCATION

• `az group create`: Creates a new resource group.
• `--name`: Specifies the name of the resource group or vault.
• `--location`: Specifies the Azure region for the resource.
• `az backup vault create`: Creates a new Recovery Services vault.

Portal alternative: Search for 'Recovery Services vaults' -> 'Create' -> Fill in Subscription, Resource group, Vault name, and Region.

Confirmation: A new Recovery Services vault appears in the specified resource group and region. Verify its creation by listing vaults: `az backup vault list --resource-group SkyCore-DR-RG --output table`.

Step 4: Implement Azure Backup for Data Resilience

Azure Backup provides secure, cost-effective solutions for backing up and recovering data from the Microsoft Azure cloud. It's crucial for data resilience and recovery from accidental deletion, corruption, or ransomware. Azure Backup supports a wide array of sources, including Azure VMs, Managed Disks, Azure Files, SQL Server/SAP HANA in Azure VMs, and on-premises resources via the MARS agent or Azure Backup Server (MABS).

When configuring backup, consider the storage options: Locally Redundant Storage (LRS) for lowest cost within a datacenter, Geo-Redundant Storage (GRS) for higher durability across regions (default and recommended for disaster recovery), or Zone-Redundant Storage (ZRS) for resilience within Availability Zones in the same region, guaranteeing data residency and no downtime. NIST SP 800-34 highlights off-site storage of backups as a critical component of contingency planning.

# Set the Recovery Services Vault context
VAULT_NAME="SkyCoreRecoveryVaultEastUS"
RESOURCE_GROUP_NAME="SkyCore-DR-RG"
az backup vault set --name $VAULT_NAME --resource-group $RESOURCE_GROUP_NAME

# Create a backup policy for Azure VMs (daily backup, 30 days retention, GRS storage)
az backup policy create --vault-name $VAULT_NAME --resource-group $RESOURCE_GROUP_NAME \
    --name "DailyVMBackupPolicy" --backup-management-type AzureIaaSVM --policy "@daily_vm_policy.json"

# Example daily_vm_policy.json content:
# {
#   "properties": {
#     "backup": {
#       "frequency": {
#         "scheduleType": "Daily"
#       },
#       "hour": 23,
#       "minute": 0,
#       "timeZone": "UTC"
#     },
#     "retentionPolicy": {
#       "daily": {
#         "count": 30
#       }
#     }
#   },
#   "sku": {
#     "name": "Standard"
#   },
#   "replicationStrategy": "GeoRedundant"
# }

# Associate a VM with the backup policy (replace with your VM name and resource group)
VM_NAME="MyCriticalVM"
VM_RG="MyCriticalVM-RG"
az backup protection enable-for-vm --vault-name $VAULT_NAME --resource-group $RESOURCE_GROUP_NAME \
    --vm $VM_NAME --vm-resource-group $VM_RG --policy-name "DailyVMBackupPolicy"

• `az backup vault set`: Sets the default vault for subsequent backup commands.
• `az backup policy create`: Creates a new backup policy.
• `--backup-management-type`: Specifies the type of workload to protect (e.g., AzureIaaSVM).
• `--policy`: Specifies a JSON file containing the detailed policy definition (frequency, retention, timezone).
• `--replicationStrategy`: (For vault creation or modification, default is GRS) Defines the storage redundancy (LRS, GRS, ZRS).
• `az backup protection enable-for-vm`: Configures backup for an Azure VM using a specified policy.

Portal alternative: Navigate to your Recovery Services vault -> 'Backup' -> 'Backup goals' to configure backup, then 'Backup policies' to create and manage policies, and 'Backup items' to enable protection for specific resources.

Confirmation: Verify that the VM is listed under 'Backup items' within the vault and that the first scheduled backup completes successfully.

Step 5: Configure Azure Site Recovery for Application Continuity

While Azure Backup focuses on data recovery, Azure Site Recovery (ASR) is designed for application continuity, orchestrating replication, failover, and failback of entire workloads. ASR can replicate Azure VMs between regions, or on-premises Hyper-V, VMware VMs, and physical servers to Azure, eliminating the need for a secondary datacenter. It ensures business apps and workloads remain online during outages, with customizable recovery plans that include scripts and manual actions.

ASR provides continuous replication and supports application-consistent snapshots to ensure data integrity during failover, capturing disk data, memory, and in-process transactions. It's critical to configure ASR to meet your RTO targets, potentially integrating with Azure Traffic Manager for efficient network switchovers.

# Note: Full Azure Site Recovery setup involves multiple resources (Storage Account, Cache Storage, 
# and a detailed replication policy). The following commands illustrate enabling basic replication 
# for an Azure VM, assuming necessary resources are pre-configured or created via a separate process.

# Set the Recovery Services Vault context
VAULT_NAME="SkyCoreRecoveryVaultEastUS"
RESOURCE_GROUP_NAME="SkyCore-DR-RG"
az backup vault set --name $VAULT_NAME --resource-group $RESOURCE_GROUP_NAME

# Enable Azure-to-Azure replication for a VM
# This is a high-level command. In a real scenario, you'd define target resources (RG, VNET, Subnet, Storage)
# The source and target regions must be different.

# Example: Enable replication from 'eastus' to 'westus' for an existing VM
VM_NAME="MyCriticalWebAppVM"
SOURCE_RG="MyCriticalWebAppVM-RG"
TARGET_RG="SkyCore-DR-WestUS-RG"
TARGET_VNET_NAME="SkyCore-DR-WestUS-VNet"
TARGET_SUBNET_NAME="default"

az site-recovery replication-fabric create --name "Azure-Primary-EastUS" --location "eastus"
az site-recovery replication-protection-container create --name "EastUS-ProtectionContainer" --fabric-name "Azure-Primary-EastUS"

# The actual command to enable replication for an Azure VM is more complex and involves many parameters:
# az site-recovery replication-protected-item create \
#    --resource-group $SOURCE_RG \
#    --fabric-name "Azure-Primary-EastUS" \
#    --protection-container-name "EastUS-ProtectionContainer" \
#    --name "$VM_NAME-replication" \
#    --properties "@{providerSpecificDetails=@{instanceType='AzureToAzure';targetRegion='westus';targetResourceGroupId='/subscriptions//resourceGroups/$TARGET_RG';targetNetworkId='/subscriptions//resourceGroups/$TARGET_RG/providers/Microsoft.Network/virtualNetworks/$TARGET_VNET_NAME';...}}"

# Due to the complexity of ASR's Azure CLI setup (many parameters for target resources, caching, etc.),
# initial configuration for Azure VMs often involves a more guided approach or Azure portal usage.
# However, core management and failover operations can be triggered via CLI once replication is configured.

• `az site-recovery replication-fabric create`: Creates a replication fabric (representing the primary site).
• `az site-recovery replication-protection-container create`: Creates a protection container within the fabric.
• `az site-recovery replication-protected-item create`: Initiates replication for a specific item (VM). This command requires extensive JSON parameters detailing target resources (resource group, virtual network, subnet, storage account, availability sets, etc.) in the target region.

Portal alternative: Navigate to your Recovery Services vault -> 'Site Recovery' -> 'Enable Site Recovery' -> Select source (Azure, VMware, Hyper-V) and target environments. The portal provides a guided wizard for configuring replication with all necessary dependencies.

Confirmation: In the Recovery Services vault, under 'Site Recovery items', the protected VM should show a 'Protected' status, with a healthy replication state.

Step 6: Develop and Test Disaster Recovery Plans (DRPs)

Implementing technology is only half the battle; having a well-documented, regularly tested Disaster Recovery Plan (DRP) is the other. A DRP is a comprehensive document outlining the procedures to restore operations after a disaster. NIST SP 800-34 emphasizes the importance of developing a detailed plan, including roles, responsibilities, communication strategies, and step-by-step recovery procedures. Azure Site Recovery's 'Recovery Plans' are invaluable here, allowing you to group VMs, define boot order, add scripts (e.g., for application startup, load balancer configuration), and incorporate manual actions.

# Create an Azure Site Recovery Recovery Plan
# This command is conceptual as a full recovery plan JSON can be extensive.
# It typically defines groups of VMs, dependencies, and automation runbooks.

# Example of creating a placeholder recovery plan. Actual plan definition requires a JSON file.
RECOVERY_PLAN_NAME="WebAppTier1-DR-Plan"
TARGET_REGION="westus"
az site-recovery recovery-plan create --name $RECOVERY_PLAN_NAME --resource-group $RESOURCE_GROUP_NAME \
    --vault-name $VAULT_NAME --primary-zone "eastus" --recovery-zone $TARGET_REGION \
    --failover-deployment-model "ResourceManager" --groups "@recovery_plan_groups.json"

# Example recovery_plan_groups.json (simplified):
# [
#   {
#     "groupType": "Shutdown",
#     "replicationProtectedItems": []
#   },
#   {
#     "groupType": "Boot",
#     "replicationProtectedItems": [
#       {
#         "id": "/subscriptions//resourceGroups//providers/Microsoft.RecoveryServices/vaults//replicationFabrics//replicationProtectionContainers//replicationProtectedItems/MyCriticalWebAppVM-replication",
#         "virtualMachineType": "VirtualMachine"
#       }
#     ],
#     "name": "Group1",
#     "startGroupActions": [
#       {
#         "actionName": "StartSQLVM",
#         "actionType": "AutomationRunbook",
#         "customLocation": "/subscriptions//resourceGroups/SkyCore-Automation-RG/providers/Microsoft.Automation/automationAccounts/SkyCore-AutomationAccount",
#         "failoverDirections": [
#           "PrimaryToRecovery",
#           "RecoveryToPrimary"
#         ],
#         "timeout": "00:30:00"
#       }
#     ]
#   }
# ]

# Test the Recovery Plan (non-disruptive drill)
# This is crucial for validating your DRP without impacting production.
az site-recovery recovery-plan test-failover --name $RECOVERY_PLAN_NAME --resource-group $RESOURCE_GROUP_NAME \
    --vault-name $VAULT_NAME --direction PrimaryToRecovery --recovery-point-type LatestApplicationConsistent

• `az site-recovery recovery-plan create`: Creates a new recovery plan, defining the failover sequence.
• `--groups`: Specifies a JSON file detailing VM groups, boot order, and pre/post-failover actions.
• `az site-recovery recovery-plan test-failover`: Initiates a non-disruptive test failover of the recovery plan.
• `--direction`: Specifies the failover direction (e.g., `PrimaryToRecovery`).
• `--recovery-point-type`: Defines the type of recovery point to use (e.g., `LatestApplicationConsistent` or `Latest`).

Portal alternative: Navigate to your Recovery Services vault -> 'Site Recovery' -> 'Recovery plans' -> 'Create recovery plan'. After creation, select the plan and click 'Test Failover' to initiate a drill.

Confirmation: A successful test failover indicates that your applications can be brought online in the disaster recovery region as expected. Document the results and any lessons learned.

Step 7: Enhance Security and Ransomware Protection

In the current threat landscape, a robust IT disaster recovery guide must heavily emphasize security, particularly against ransomware. The CISA Ransomware Guide highlights key mitigation strategies. Your backups are the last line of defense, so their integrity and recoverability are paramount. Implement immutable backups, multi-factor authentication, and strict access controls on your Recovery Services vaults.

Azure Backup provides features like soft delete (retains deleted backups for 14 days), enabling a recovery even if a malicious actor deletes backups. Leverage Azure Security Center (now Defender for Cloud) to monitor your DR environment for vulnerabilities and threats.

# Enable Soft Delete for the Recovery Services Vault (default for new vaults, but verify)
# Soft delete protects against accidental or malicious deletion of backups.
VAULT_NAME="SkyCoreRecoveryVaultEastUS"
RESOURCE_GROUP_NAME="SkyCore-DR-RG"

az backup vault show --name $VAULT_NAME --resource-group $RESOURCE_GROUP_NAME --query "properties.softDeleteFeatureState"

# If soft delete is not enabled or needs adjustment (e.g. extending retention beyond 14 days):
# az backup vault update --name $VAULT_NAME --resource-group $RESOURCE_GROUP_NAME \
#   --soft-delete-state Enabled --soft-delete-retention-period 30 # Example: 30 days

# Implement Azure Key Vault for managing encryption keys if using customer-managed keys for Storage accounts.
KEY_VAULT_NAME="SkyCoreDRKeyVault"
KEY_VAULT_LOCATION="eastus"
az keyvault create --name $KEY_VAULT_NAME --resource-group $RESOURCE_GROUP_NAME --location $KEY_VAULT_LOCATION

# Enforce MFA and Conditional Access for administrative access to the Recovery Services Vault and related resources.
# These are typically configured via Azure Active Directory / Entra ID policies.
# Example: Assign a built-in role to a user for backup administration with MFA enforced by policy.
# az role assignment create --assignee "admin@skycore.com" --role "Backup Contributor" \
#   --scope "/subscriptions//resourceGroups/$RESOURCE_GROUP_NAME/providers/Microsoft.RecoveryServices/vaults/$VAULT_NAME"

• `az backup vault show`: Displays details of a Recovery Services vault.
• `--query`: Filters the output to show specific properties.
• `az backup vault update`: Modifies properties of a Recovery Services vault, including soft delete state and retention.
• `az keyvault create`: Creates a new Azure Key Vault for secure secret/key management.
• `az role assignment create`: Assigns an Azure RBAC role to a user, group, or service principal.

Portal alternative: For soft delete, navigate to your Recovery Services vault -> 'Properties' -> 'Security settings' -> 'Soft Delete'. For Key Vault, search for 'Key vaults' and create a new one. RBAC is managed via 'Access control (IAM)' on the vault or resource group. MFA and Conditional Access policies are configured in Microsoft Entra ID (formerly Azure Active Directory).

Confirmation: Verify soft delete is enabled for your vaults. Conduct regular security audits and penetration tests on your DR environment. Ensure all administrative access paths are secured with strong authentication and least privilege.

Step 8: Automate, Review, and Continuously Improve

A DRP is a living document, not a static artifact. It requires regular review, updates, and continuous testing to remain effective. Integrate automation where possible to reduce manual effort and human error. Azure Site Recovery can integrate with Azure Automation runbooks for advanced customization of recovery plans, triggering scripts before or after VM failover to configure applications or networks.

NIST SP 800-34 emphasizes the importance of exercising and maintaining the contingency plan. Establish a schedule for regular disaster recovery drills (at least annually, ideally more frequently for critical systems), review the plan after any major infrastructure change or incident, and update it to reflect lessons learned. Automation can include health checks, reporting on replication status, and automatic alerts for replication issues.

# Integrate Azure Automation for custom recovery plan actions
# First, create an Automation Account
AUTOMATION_ACCOUNT_NAME="SkyCoreAutomationAccount"
AUTOMATION_RG="SkyCore-Automation-RG"
LOCATION="eastus"
az group create --name $AUTOMATION_RG --location $LOCATION
az automation account create --name $AUTOMATION_ACCOUNT_NAME --resource-group $AUTOMATION_RG --location $LOCATION --sku Basic

# Create a sample PowerShell runbook (e.g., to configure a web server after failover)
# (Runbook content would be loaded from a .ps1 file and imported)
az automation runbook create --automation-account-name $AUTOMATION_ACCOUNT_NAME --resource-group $AUTOMATION_RG \
    --name "ConfigureWebServerAfterFailover" --type PowerShell --location $LOCATION

# Import actual runbook content (this typically involves 'az automation runbook replace-content')
# For example, a runbook that updates DNS records or starts a specific service.

# Then, update your Recovery Plan to include this runbook as a pre- or post-failover action.
# (This is done by modifying the 'recovery_plan_groups.json' and updating the recovery plan, 
# or directly via the Azure portal as mentioned in Step 6).

• `az automation account create`: Creates a new Azure Automation account.
• `az automation runbook create`: Creates a new runbook within the automation account.

Portal alternative: Navigate to 'Automation Accounts' -> 'Create'. Within an Automation Account, go to 'Runbooks' to create or import scripts. To integrate with Site Recovery, edit your recovery plan and add an 'Automation runbook' action to a group.

Confirmation: Your DRP is regularly reviewed and updated, and automation effectively streamlines recovery processes. Post-drill reports consistently show RTO/RPO targets are met or improved upon.

When to bring in a consultant

While this IT disaster recovery guide provides a comprehensive framework, implementing and managing a sophisticated DR strategy can be exceptionally complex, especially for hybrid environments, multi-tier applications with intricate dependencies, or organizations with stringent compliance requirements. DIY becomes risky when internal teams lack the deep expertise in Azure networking, advanced Site Recovery configurations, or the time for thorough, non-disruptive testing. If you're struggling with defining accurate RTO/RPO, ensuring application consistency, optimizing costs, or require validated compliance, engaging specialists ensures your DR plan is not just functional, but truly resilient and cost-effective, mitigating the risk of critical business impact. SkyCore Solutions has extensive experience in designing, implementing, and validating enterprise-grade disaster recovery solutions.