{"id":2710,"date":"2026-10-08T15:11:12","date_gmt":"2026-10-08T15:11:12","guid":{"rendered":"https:\/\/www.exam-topics.info\/blog\/microsoft-az-104-backup-and-site-recovery\/"},"modified":"2026-10-08T15:11:12","modified_gmt":"2026-10-08T15:11:12","slug":"microsoft-az-104-backup-and-site-recovery","status":"publish","type":"post","link":"https:\/\/www.exam-topics.info\/blog\/microsoft-az-104-backup-and-site-recovery\/","title":{"rendered":"Microsoft AZ-104: Backup and Site Recovery"},"content":{"rendered":"

Backup and disaster recovery are often grouped together because both deal with failure, but they protect different outcomes. Azure Backup creates recoverable copies and recovery points. Azure Site Recovery replicates workloads so they can be failed over when the primary environment becomes unavailable. The AZ-104 exam<\/a> expects administrators to understand when each service is appropriate and how vault, policy, replication and recovery decisions fit together.<\/p>\n

The most useful starting point is business impact. How much data can the organization afford to lose? How quickly must the workload return? Is the failure a deleted file, a corrupted VM, an unavailable datacenter or a regional disaster? Those questions determine whether the solution needs backup, replication, high availability, or a combination.<\/p>\n

Recovery objectives turn business needs into technical targets<\/h2>\n

Recovery point objective describes the maximum acceptable amount of data loss measured in time. Recovery time objective describes how long the service can remain unavailable before recovery must be complete. A workload with a short RPO needs frequent or continuous protection. A short RTO requires a recovery method that can restore service quickly.<\/p>\n

These terms are broader than Azure. The site’s explanation of RTO and RPO<\/a> provides the conceptual foundation, while AZ-104 focuses on implementing Azure services that can meet the selected targets.<\/p>\n

Administrators should avoid promising an RPO or RTO based only on a product feature. Recovery time depends on data size, application dependencies, automation, network readiness and testing. The objective is a business requirement; the Azure design must be validated against it.<\/p>\n

Recovery Services vaults organize protection operations<\/h2>\n

A Recovery Services vault is a management entity used for backup recovery points and, for supported scenarios, Site Recovery replication data and operations. Administrators use vaults to define policies, initiate backups, perform restores and manage protected items.<\/p>\n

Azure also uses Backup vaults for newer workload types. The exam scenario should guide which vault type applies. Do not assume the word \u201cvault\u201d refers to only one service model, and do not confuse backup vaults with Azure Key Vault, which solves a completely different secrets and key-management problem.<\/p>\n

The wider Microsoft Azure infrastructure certifications<\/a> path includes resilience because infrastructure is not complete when it can only be deployed; it must also be recoverable after operational mistakes and larger failures.<\/p>\n

Backup policy defines when recovery points are created and retained<\/h2>\n

A backup policy determines the protection schedule and retention behavior for supported workloads. The correct policy reflects both the required RPO and how long different recovery points must remain available. Short-term operational recovery and long-term retention may have different needs.<\/p>\n

Retention should be intentional. Keeping every recovery point forever increases cost and can complicate governance, while aggressive deletion may violate business or compliance requirements. Administrators should understand daily, weekly, monthly or other retention concepts in terms of the organization’s recovery history rather than treating them as arbitrary values.<\/p>\n

Backup policy is also only useful if jobs succeed. Monitoring backup health and investigating repeated failures is part of normal operations. A policy assigned to a VM is not proof that recoverable data exists.<\/p>\n

Restore design matters as much as backup configuration<\/h2>\n

A backup has value only if the organization can restore what it needs. Recovery may involve an entire VM, disks, files or application data depending on the protected workload and service capabilities. Administrators should know where restored resources will be placed and whether networking, identity and application dependencies also need reconstruction.<\/p>\n

Testing restores is critical. A successful backup job proves that Azure created recovery data; it does not prove that the full application can be returned to service within the required time. Regular recovery exercises expose missing dependencies and outdated documentation before a real incident.<\/p>\n

Restore testing should be isolated carefully so that a test does not overwrite production data or create conflicting network identities. Recovery procedures are operational workflows, not merely buttons in the vault.<\/p>\n

Site Recovery protects workload continuity through replication<\/h2>\n

Azure Site Recovery replicates supported machines and orchestrates failover to a recovery location. Rather than rebuilding a VM from an older backup, the service maintains replicated state intended to support disaster recovery with a different recovery profile.<\/p>\n

This does not eliminate the need for backup. Replication can carry unwanted logical changes, corruption or malware to the recovery side. Backup supplies historical recovery points, while replication supplies an alternate execution location. Many important workloads use both because the failure modes differ.<\/p>\n

Site Recovery also requires planning for networks, target resources and application dependencies. A replicated VM that starts successfully is not enough if it cannot reach databases, identity services or users after failover.<\/p>\n

Recovery plans coordinate multi-tier failover<\/h2>\n

Applications often contain several machines that should start in a particular sequence. A database or identity dependency may need to become available before the application tier, followed by web or presentation components. Site Recovery recovery plans can help organize that sequence and include automation or manual checkpoints.<\/p>\n

This is where disaster recovery becomes application recovery rather than VM recovery. Administrators need to understand which components are independent, which require ordering and what external steps are needed for traffic redirection or validation.<\/p>\n

Runbooks and scripts can reduce manual work, but automation should be tested. An untested recovery script can turn a planned failover into a new incident.<\/p>\n

Test failover is different from planned and unplanned failover<\/h2>\n

A test failover validates the recovery process without committing to a production cutover. It should use an isolated network where possible so that test machines do not conflict with the live environment. The purpose is to prove that replication, startup and application validation work.<\/p>\n

A planned failover is used when the primary environment is available and the organization can coordinate the transition. An unplanned failover addresses an outage where normal synchronization or shutdown may not be possible. These states have different operational implications and should not be treated as interchangeable terms.<\/p>\n

Failback also needs planning. Returning service to the original location after the incident can be as complex as the initial failover, especially if data changed while the recovery site was active.<\/p>\n

Vault security protects the recovery system itself<\/h2>\n

Recovery data is a high-value target. An attacker who compromises production and can also delete backups removes one of the organization’s strongest recovery options. Azure Backup therefore includes security controls around vault operations, access, soft-delete-style protections and other safeguards depending on workload and configuration.<\/p>\n

RBAC should limit who can change policies, stop protection or delete recovery data. Administrative identities used for recovery should be protected strongly, and critical operations should be monitored. The backup system should not share every weakness of the workload it is meant to rescue.<\/p>\n

This principle connects resilience to security. The broader cloud architecture certification<\/a> view treats recoverability as part of risk management, not merely storage administration.<\/p>\n

High availability, backup and disaster recovery are separate layers<\/h2>\n

Availability zones and scale sets help workloads continue through selected infrastructure failures. Backup helps recover older data or resources after deletion, corruption or other loss. Site Recovery helps bring supported workloads online in a recovery location. None of these is a complete substitute for the others.<\/p>\n

An administrator should map each requirement to its failure mode. \u201cKeep serving through one datacenter outage\u201d points toward high availability. \u201cRestore yesterday’s uncorrupted data\u201d points toward backup. \u201cRun the VM in another location after a disaster\u201d points toward replication and failover.<\/p>\n

The Azure administrator role<\/a> sits at the operational intersection of those controls, making sure the configured protection actually produces usable recovery outcomes.<\/p>\n

For AZ-104, study the recovery workflow end to end<\/h2>\n

Identify the workload and required RPO\/RTO. Choose the appropriate vault and backup policy. Understand how restores are performed and monitored. For disaster recovery, configure replication, target resources, networking and recovery plans. Test failover without disrupting production, then know how planned, unplanned and failback scenarios differ.<\/p>\n

The exam is less about memorizing every wizard screen than about recognizing the correct protection model. A good administrator knows whether the problem requires another copy, another recovery point, another running location or all three.<\/p>\n

Recovery procedures should include dependencies outside the VM<\/h2>\n

A virtual machine rarely represents the whole application. DNS records, load balancers, private endpoints, identities, certificates, databases and external integrations may all need to work after a restore or failover. A disaster-recovery plan that validates only whether the VM powers on can therefore give a false sense of readiness.<\/p>\n

Administrators should document which dependencies are recreated, which remain shared with the primary environment and which must be redirected during failover. Network address ranges need to avoid conflicts. Security rules and route tables must support the recovery path. Monitoring and backup should also continue after the workload is running in the recovery location.<\/p>\n

Recovery testing is the time to discover these dependencies, not the middle of a real outage. A test should verify application transactions, authentication, connectivity and operational monitoring in addition to machine startup. This end-to-end view also explains why recovery plans and automation are valuable: they turn a collection of protected VMs into an ordered application-recovery process.<\/p>\n

Regular exercises also keep recovery documentation current, expose ownership gaps and give operations teams practical experience before a real emergency forces them to work under pressure.<\/p>\n","protected":false},"excerpt":{"rendered":"

Backup and disaster recovery are often grouped together because both deal with failure, but they protect different outcomes. Azure Backup creates recoverable copies and recovery […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-2710","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/2710","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/comments?post=2710"}],"version-history":[{"count":0,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/posts\/2710\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/media?parent=2710"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/categories?post=2710"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.exam-topics.info\/blog\/wp-json\/wp\/v2\/tags?post=2710"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}