You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Azure Site Recovery supports two types of failover depending on the disaster scenario. A Planned Failover is used for maintenance or drills and ensures zero data loss by synchronizing all data before shutting down the source virtual machine. An Unplanned Failover occurs during a sudden outage when the primary site is unavailable, focusing on restoring service as quickly as possible. Understanding these differences helps administrators choose the right strategy for business continuity.
When executing a failover, selecting the correct recovery point is vital for meeting specific business needs. Different options provide trade-offs between how current the data is and how fast the system recovers:
To ensure maximum data integrity, administrators should select the option to Shut-down machine before beginning failover. This process attempts to synchronize the final changes from the source virtual machine to the target region before the transition occurs. If the source region is completely inaccessible, Site Recovery will proceed using the latest available processed data. For Windows environments, Volume Shadow Copy Service (VSS) is used to create app-consistent points, though this may slightly impact performance during high-workload periods.
Once the failover is complete, the virtual machine must be validated in the secondary region to ensure all services are running correctly. If the initial results are unsatisfactory, you can use the Change recovery point feature to select a different snapshot. After the transition is verified, the Commit action must be performed, which permanently deletes all other available recovery points for that session. To return to the original region later, you must initiate Reprotect to begin replicating data back to the primary site.
Managing complex applications requires a Recovery Plan to sequence the failover of different tiers, such as web, application, and database. These plans ensure that multi-tier dependencies are respected during a regional transition to prevent application errors. Key components of this orchestration include:
Azure Site Recovery is a service that ensures business continuity by keeping your applications running during outages. It replicates workloads from a primary site to a secondary location. To set up failover policies, you need to configure the VSS Provider service, which is crucial for creating application consistency snapshots. Ensure that the VSS Provider service is installed and set to Automatic. If the service is disabled, you will encounter errors such as Error 2147943458. To resolve this, restart the VSS service, Azure Site Recovery VSS Provider, and VDS service.
Performing test failovers is essential to validate your configurations. This process involves simulating a failover to ensure that your applications and services can be successfully recovered in the secondary region. If you encounter issues like Error 2147754756, it may indicate that the VSS Provider is not registered. To fix this, reinstall the VSS Provider using the provided commands and restart the necessary services.
To ensure successful recovery, you must update the TenantId and ClientId manually in the source machine if you face a no Mobility Service heartbeat error due to an expired tenant. Use the GET Protected item API to retrieve the necessary values and update the RCMInfo.conf file on the source machine. Restart the relevant services to apply the changes.
After a failover occurs, the virtual machine runs in the secondary region but is not yet finalized. The Commit process is the final step to confirm the failover and make the secondary virtual machine the permanent primary. Once a failover is committed, all other available recovery points are deleted, meaning you can no longer switch to a different point in time. This action ensures that the workload is stable before moving to the next phase of disaster recovery.
Once the failover is committed, the virtual machine is in an unprotected state because it is no longer replicating data. To fix this, administrators must initiate reprotection, which sets up reverse replication from the secondary region back to the original primary region. Reprotection is a mandatory prerequisite for failback, as it ensures the primary site has the most recent data. This process involves selecting the target direction from secondary to primary, verifying the health and availability of the primary region, and ensuring the primary resources are ready to receive data. During reprotection, Azure Site Recovery performs a delta replication to synchronize data. Instead of copying the entire disk, the system calculates a checksum to identify only the changes made while the virtual machine was running in the secondary region. This method significantly reduces the time and bandwidth required to prepare for a return to the primary site. If the original source virtual machine was deleted or corrupted, a full initial replication may be required instead.
Successful reprotection requires careful evaluation of resource mapping and network settings. Administrators must ensure that the target virtual network, resource groups, and availability sets in the primary region are correctly configured to receive the workload. Incorrect network mapping can lead to major connectivity issues once the workload eventually moves back. Key items to verify include:
The final goal of managing post-failover tasks is to perform a successful failback. This is a planned failover that moves the workload from the secondary region back to the primary region once the original site is healthy. The source virtual machine must be shut down during this process to ensure data consistency and prevent synchronization conflicts. After the failback is complete, the cycle repeats by enabling replication from the primary to the secondary region once again.
Prepare and test your skills
Prepare and test your skills
A planned failover is used for scheduled maintenance or drills and guarantees zero data loss by synchronizing all data before shutting down the source virtual machine. An unplanned failover is triggered by an unexpected outage when the primary site is unavailable, focusing on restoring service as quickly as possible.
Committing a failover confirms the transition and designates the secondary virtual machine as the permanent primary workload. Once committed, all other available recovery points for that session are permanently deleted, which prevents the administrator from switching to a different point in time.
Reprotection is required because a failed-over virtual machine is in an unprotected state and no longer actively replicating data. Initiating reprotection sets up reverse replication from the secondary region back to the primary region using delta checksums, which is a mandatory prerequisite for performing a failback.
The Latest recovery point provides the lowest Recovery Point Objective (RPO) by processing all data sent to the service before initiating failover. The Latest Processed point delivers a lower Recovery Time Objective (RTO) by immediately using data already processed in Azure, while the Latest App-consistent point captures memory-resident data and pending transactions to preserve database integrity.
StudyCerts
StudyCerts