Venture into the world of Azure Infrastructure, where design meets functionality. Harness your skills and gain mastery over complex cloud structures to ace the AZ-305 Designing Microsoft Azure Infrastructure Solutions exam!
Gauge your current knowledge
Gauge your current knowledge
When planning recovery for SQL Server databases in Azure, several built-in technologies help keep data available during failures. Failover clustering automatically switches operations to a backup server when hardware or software fails, while Always On availability groups maintain multiple synchronized copies of a database across different servers. Database mirroring provides high-performance asynchronous replication, and log shipping periodically moves transaction logs to a secondary system for recovery. For geographic protection, active geo-replication copies databases across regions asynchronously, enabling near real-time failover when a whole data center experiences an outage. Auto-failover groups simplify the failover process by automating the switch between primary and secondary databases, reducing manual steps during an emergency.
Azure Site Recovery (ASR) works alongside these SQL Server business continuity and disaster recovery technologies to meet specific recovery targets. The recovery time objective (RTO) measures how long the system can be down, while the recovery point objective (RPO) defines how much data loss is acceptable. Pairing ASR with Always On availability groups provides minimal data loss through asynchronous replication, making it suitable for high-performance environments. Failover clustering using Always On Failover Cluster Instances shares storage between nodes and ensures zero data loss, though it requires more complex setup. Database mirroring and log shipping work well when the business can tolerate higher data lag, offering cost savings compared to synchronous replication options.
Azure Site Recovery creates recovery points using two types of snapshots. Crash-consistent snapshots capture the state of disks every five minutes but do not preserve data held in memory, making them suitable for most applications that can tolerate some data loss. App-consistent snapshots include in-memory data and pending transactions by using the Volume Shadow Copy Service on Windows systems, ensuring databases remain consistent after recovery. App-consistent snapshots are essential for database workloads but require more processing power and can temporarily slow down the system.
Once replication is configured, testing the recovery process ensures it works when needed. The failover step switches operations to the Azure virtual machine, while the commit failover step finalizes the switch and begins using the backup system. When the primary site is ready again, failback moves operations back, which requires setting up a temporary process server in Azure to handle the reverse replication. Testing these steps regularly helps identify issues before an actual disaster occurs.
Applications that span multiple virtual machines require coordinated recovery to maintain data integrity. Multi-VM replication groups ensure all related VMs share the same recovery point, keeping the application consistent across machines after failover. However, grouping VMs together can impact performance because the system must wait for all VMs to sync before creating a recovery point. This feature should only be enabled when application consistency is critical, such as for multi-tier applications where all components must recover to the same point in time.
Designing a resilient compute infrastructure in Azure requires a strategy that protects virtual machines from data loss and extended downtime. Architects must evaluate the capabilities of both Azure Backup and Azure Site Recovery to build a comprehensive backup and disaster recovery solution. This strategy must map directly to business requirements while defining clear operational boundaries and dependencies between primary and secondary environments.
To establish effective recovery point objectives and recovery time objectives, architects must first evaluate the business requirements of their workloads. This assessment focuses on three critical factors: the criticality of applications determines how vital each workload is to ongoing business operations and establishes its priority during a recovery event; the data change frequency monitors how often data updates within the applications, which directly dictates how frequently backups must run to avoid data loss; and the acceptable data loss establishes the maximum timeframe of lost data the business can tolerate during an unexpected outage. With these metrics established, architects can design backup schedules that align with the required RPO and recovery workflows that satisfy the target RTO.
Azure Backup protects compute workloads by storing backup copies in secure, isolated storage entities. Architects choose between a Recovery Services vault or a Backup vault depending on the specific workload type and security requirements. For maximum protection against regional disasters, the vault should use geo-redundant storage which replicates data to a secondary paired region. A backup policy is then applied to the vault, defining the backup frequency (such as hourly, daily, or weekly) and the retention duration for both short-term recovery and long-term compliance.
Configuring protection for a virtual machine involves a specific order of operations to ensure data is safely replicated. First, create a Recovery Services vault in the same Azure region as the virtual machine to minimize latency and avoid cross-region data transfer costs during backup ingestion. Next, verify the vault's storage replication settings to ensure geo-redundant storage is selected before any backups are performed, as this setting cannot be changed once backups begin. Finally, associate the target virtual machines with the appropriate backup policy to initiate the initial replication and establish the scheduled backup lifecycle.
Regular verification of the backup infrastructure is necessary to guarantee that virtual machines can be successfully recovered when a failure occurs. Disaster recovery teams must execute test restore procedures in isolated test environments to confirm that restored virtual machines function correctly without affecting production workloads. This process includes validating that the latest recovery points are consistently accessible, uncorrupted, and capable of meeting the target RTO. These routine recovery drills identify potential gaps in the restoration process before an actual outage occurs.
For workloads requiring near-zero RTO and RPO, Azure Site Recovery provides continuous replication and rapid failover capabilities. The configuration process begins by identifying the primary region hosting the active virtual machines and selecting a secondary Azure region to act as the disaster recovery target. Once replication is enabled, virtual machine data streams continuously to the secondary region, managed securely through a Recovery Services vault. Architects must conduct regular disaster recovery drills using test failovers to verify that the secondary environment can assume the workload seamlessly and that failback procedures can return operations to the primary region without data loss.
Integrating Azure Backup and Azure Site Recovery creates a layered defense-in-depth strategy for Azure compute resources. While Azure Backup provides long-term retention and protection against data corruption, Azure Site Recovery ensures business continuity during major regional outages. Together, these services allow organizations to meet stringent RPO and RTO requirements, protecting both the state of the data and the availability of the compute tier.
Azure databases use a combination of backup types to protect data. Full database backups occur weekly and capture the entire database. Differential backups run every 12 to 24 hours and record only the changes since the last full backup. Transaction log backups execute every 5 to 10 minutes, depending on database activity, and capture every individual change. The transaction log backups are what enable point-in-time restore, allowing you to recover to a specific moment before a failure. Together, these three backup types minimize data loss while keeping storage costs manageable.
Backup storage redundancy protects your data against hardware failures, power outages, or natural disasters. Azure offers several redundancy options. Locally Redundant Storage (LRS) stores three copies of your data within a single datacenter, protecting against local hardware failures. Zone-Redundant Storage (ZRS) distributes copies across multiple availability zones within an Azure region, protecting against an entire zone going down. Geo-Redundant Storage (GRS) replicates your backups to a secondary Azure region, so you can restore even if the primary region fails completely. GRS is the default for many services and is critical for disaster recovery scenarios.
Azure SQL Database and Azure SQL Managed Instance provide automated backup solutions that support long-term retention and geo-redundant storage. Long-term retention lets you keep full backups for up to 10 years to meet compliance requirements. All backup data is encrypted using strong encryption methods, both at rest and during transfer. Azure Database for MySQL supports automatic server backups with user-configured LRS or GRS and an adjustable retention period between 7 and 35 days. These backups are encrypted with AES 256-bit encryption, ensuring secure recovery processes. When designing a strategy, you must choose the retention period and redundancy level that match your organization's compliance policies and recovery objectives.
A Recovery Services Vault is the central management entity for backups in Azure. To create one, sign in to the Azure portal and navigate to the Business Continuity Center dashboard. Create a new vault, ensuring it is in the same region as the data source you want to protect. The vault stores backup data, manages backup policies, and orchestrates restore operations. You configure backup policies within the vault to define how often backups run, how long they are retained, and which redundancy option to use.
High availability keeps your database running with minimal disruption through redundant, fault-tolerant, or failover-protected components. For SAP applications, this means distributing application servers across multiple Azure VMs and subnets to avoid a single point of failure. In Azure Data Explorer, high availability involves a fault-tolerant persistence layer with default LRS, optional ZRS for zone failover, and high-availability configurations at the compute layer. Disaster recovery practices include enabling delete locks to prevent accidental deletion, using undo commands for recoverability, and taking snapshots for protection against accidental data loss. These measures ensure that even if a component fails, the system can continue operating or recover quickly.
Enabling Cross Region Restore in a Recovery Services Vault allows you to restore data in a secondary Azure region. This is essential for meeting compliance requirements and ensuring data availability during a regional disaster. Cross Region Restore is recommended for services configured with GRS storage, because GRS already replicates backups to the paired secondary region. When enabled, this feature provides a secondary Recovery Point Objective, meaning recovery points are replicated to the secondary paired region within 12 hours. This ensures you can recover your database even if the primary region is completely unavailable.
Azure Backup protects unstructured data stored in Blob Storage by creating copies that can be restored if data is lost. These copies guard against hardware failures, accidental deletion, and cyber threats like ransomware. When planning backup solutions, organizations set two key targets: Recovery Point Objective (RPO) defines how much data loss is acceptable, and Recovery Time Objective (RTO) defines how quickly systems must be restored after an incident.
Azure Backup supports three main backup approaches. Full backups capture all data in a single copy, providing the simplest restore process but using the most storage. Differential backups save only changes made since the last full backup, reducing storage needs while keeping restore straightforward. Incremental backups track changes since the last backup of any type, making them the most storage-efficient option because each new backup only stores what changed since the previous one. Organizations choose their approach based on how much data they can afford to lose versus how much storage cost they can bear.
Azure stores redundant copies of data to protect against different failure scenarios. Locally Redundant Storage (LRS) keeps three copies within a single data center, protecting against hardware failures but not against regional disasters. Zone-Redundant Storage (ZRS) replicates data across three separate availability zones in one region, protecting against zone-level failures while maintaining low latency. Geo-Redundant Storage (GRS) copies data asynchronously to a secondary region, guarding against entire region outages but with some data lag during the replication. Geo-Zone Redundant Storage (GZRS) combines the benefits of ZRS and GRS by synchronously replicating across zones in the primary region and asynchronously replicating to a secondary region.
Two built-in features strengthen data protection beyond traditional backups. Immutable blob policies lock data for a specified time period so it cannot be modified or deleted, which helps meet compliance requirements and protects against accidental or malicious changes. Soft-delete settings retain deleted blobs and their previous versions for a configurable window, allowing recovery of accidentally deleted files before they are permanently removed. These features work alongside point-in-time snapshots that create read-only copies of data at specific moments, enabling precise recovery to any desired state.
Designing backup solutions requires weighing storage costs against recovery needs. Higher redundancy levels like GRS and GZRS cost more but provide stronger protection for critical data. More frequent backups reduce RPO but increase storage consumption and management overhead. Organizations must regularly evaluate their backup frequency and redundancy choices to ensure they match current recovery requirements without overspending on protection that exceeds their actual needs.
Azure Backup protects unstructured data stored in Blob Storage by creating copies that can be restored if data is lost. These copies guard against hardware failures, accidental deletion, and c…
Azure Backup protects unstructured data stored in Blob Storage by creating copies that can be restored if data is lost. These copies guard against hardware failures, accidental deletion, and c…
Azure databases use a combination of backup types to protect data. Full database backups occur weekly and capture the entire database. Differential backups run every 12 to 24 hours and record …
Azure databases use a combination of backup types to protect data. Full database backups occur weekly and capture the entire database. Differential backups run every 12 to 24 hours and record …
When planning recovery for SQL Server databases in Azure, several built-in technologies help keep data available during failures. Failover clustering automatically switches operations to a backup …
When planning recovery for SQL Server databases in Azure, several built-in technologies help keep data available during failures. Failover clustering automatically switches operations to a backup …
Designing a resilient compute infrastructure in Azure requires a strategy that protects virtual machines from data loss and extended downtime. Architects must evaluate the capabilities of both **Azure…
Designing a resilient compute infrastructure in Azure requires a strategy that protects virtual machines from data loss and extended downtime. Architects must evaluate the capabilities of both **Azure…
StudyCerts
StudyCerts