Azure Disaster Recovery Design and Testing
Karolis Vitkus
Reviewed and developed an Azure-based disaster recovery solution for a UK organisation operating critical services across an on-premises environment.
The engagement focused on improving the recoverability of workloads replicated to Microsoft Azure and ensuring that future disaster recovery tests would provide meaningful evidence of service availability, rather than simply confirming that individual virtual machines could be started.
Challenge
The existing disaster recovery environment replicated a limited number of servers, including core identity and file services. However, the original design did not provide users or supporting services with a complete method of accessing the recovered environment.
This created several concerns:
- Replicated servers could be started, but end-to-end service access had not been demonstrated
- The protected workloads did not fully represent the organisation’s priority business services
- Network dependencies and access paths required further definition
- Recovery objectives had not been clearly mapped to technical recovery activities
- Third-party application and connectivity dependencies needed to be understood
- Previous testing provided limited evidence of operational readiness
A successful virtual machine failover alone does not demonstrate that a business service has been recovered.
Responsibilities
My responsibilities included:
- Reviewing the existing disaster recovery design and replicated workloads
- Assessing whether the protected systems aligned with business priorities
- Identifying missing application, network, identity and access dependencies
- Reviewing Azure Site Recovery replication and recovery arrangements
- Developing an improved recovery topology
- Defining network isolation requirements for disaster recovery testing
- Planning user and administrator access to recovered services
- Identifying dependencies involving third-party suppliers
- Producing a structured disaster recovery design document
- Defining technical validation and business acceptance activities
- Establishing rollback and clean-up requirements following testing
- Coordinating discussions between technical teams, stakeholders and external providers
Technologies
- Microsoft Azure
- Azure Site Recovery
- Azure virtual networks
- Network security groups
- Azure VPN connectivity
- Microsoft Entra ID
- Windows Server
- Active Directory Domain Services
- DNS
- File services
- Firewall and routing policies
- Backup and recovery tooling
Design approach
The proposed approach separated disaster recovery testing from the production environment while still allowing controlled access to recovered services.
The design considered:
- A dedicated Azure recovery virtual network
- Recovery network address ranges and subnet allocation
- Controlled connectivity between users and recovered workloads
- DNS and Active Directory dependencies
- Firewall policies and network security groups
- Recovery sequencing for interdependent servers
- Test failover isolation
- Authentication and administrative access
- Application dependencies
- Monitoring during the recovery exercise
- Controlled clean-up after completing the test
This reduced the risk of a test failover affecting production services or creating duplicate systems on connected networks.
Recovery sequence
A proposed recovery sequence was developed around service dependencies:
- Confirm Azure connectivity and recovery network availability
- Start identity, DNS and supporting infrastructure
- Validate authentication and name resolution
- Recover application and file services
- Apply temporary test access controls where required
- Confirm administrator access
- Provide controlled access to nominated business testers
- Validate priority business processes
- Record results, issues and recovery timings
- Shut down and remove test resources in a controlled manner
The sequence was designed to test complete services rather than isolated servers.
Validation approach
Technical validation included:
- Virtual machine start-up and health
- Network routing and firewall connectivity
- DNS resolution
- Domain authentication
- Service account functionality
- File and application access
- Administrative access
- Logging and monitoring
- Replication health after the exercise
Business validation was intended to confirm that nominated users could access the recovered environment and complete agreed operational tasks.
Risk management
The recovery plan included controls intended to reduce operational risk:
- Test failovers performed within an isolated network
- No unrestricted connection to the production environment
- Predefined firewall and routing requirements
- Configuration and recovery checkpoints
- Named technical and business validation owners
- Documented decision points
- Agreed rollback and clean-up procedures
- Post-test review and issue tracking
Outcome
The review identified that successful replication did not, by itself, provide an effective disaster recovery capability.
The revised approach established a clearer path towards a meaningful recovery exercise by connecting technical recovery tasks with business service validation. It also highlighted where additional workloads, network paths and third-party dependencies required inclusion before the environment could meet the organisation’s recovery expectations.
Lessons learned
- Disaster recovery scope should be driven by business priorities, not only by server availability
- Recovery time objectives must include application and connectivity dependencies
- Identity, DNS and network services should be included in recovery sequencing
- Test environments must be isolated without becoming inaccessible
- Business representatives must validate recovered services
- Recovery documentation should include owners, dependencies, decision points and clean-up procedures
Security and confidentiality
The organisation, third-party providers, server names, IP addresses, recovery objectives and detailed network configuration have been intentionally omitted or generalised.