Azure Backup design is easy to underestimate because the first visible object is a vault and the first visible action is usually \u201cenable backup.\u201d In production, the harder work is deciding what the vault should protect, where it should live, which failure domains it must survive, who can administer it, and how restore expectations map to replication and retention. Those are administration decisions that fit directly into the operational scope of AZ-104<\/a>, but they also matter to architects who have to connect backup choices to broader resilience targets.<\/p>\n The useful mental model is to treat a Recovery Services vault as a protection boundary rather than a folder full of restore points. It becomes the place where backup policy, security controls, storage redundancy, recovery operations, and delegated administration meet. Microsoft\u2019s current Azure Backup guidance continues to center Recovery Services vaults for workloads such as Azure virtual machines, SQL Server and SAP HANA in Azure VMs, Azure Files vaulted backup, and supported on-premises protection. That makes vault topology a design decision, not an afterthought.<\/p>\n A Recovery Services vault stores backup recovery points and exposes the management surface used to configure protection, run on-demand backups, restore data, and apply policies. That sounds simple, but the boundary matters because backup operations are intentionally separated from the production resources they protect. A compromised VM should not automatically imply control over its protected recovery points. That separation is part of the reason a serious design starts with the vault and its administrative model rather than with a single VM\u2019s Backup button.<\/p>\n Think about the questions the vault must answer. Which team can change policy? Who can initiate a restore? Who can delete protected data? Does one business unit need administrative isolation from another? Do regulated workloads need a different retention policy? Must a regional outage be survivable? The answers determine whether one vault is enough or whether separate vaults are justified by region, business boundary, or operational ownership. A broad business continuity and disaster recovery plan<\/a> provides the context, while the vault turns part of that plan into an Azure operating model.<\/p>\n Do not confuse separation with needless sprawl. More vaults mean more policies, monitoring, role assignments, and operational objects to manage. The goal is to create boundaries where they correspond to real recovery, regional, or administrative requirements. A vault per VM is usually an anti-pattern; a vault per region or clearly separated workload boundary may be entirely reasonable.<\/p>\n Azure has both Recovery Services vaults and Backup vaults, and the right object depends on the workload being protected. Recovery Services vaults remain central for familiar enterprise backup scenarios, including Azure VMs and several workload-aware protections. Backup vaults support other newer Azure Backup scenarios. A design should therefore begin with the data source and protection capability, not with an assumption that every Azure Backup feature uses the same vault type.<\/p>\n For an administrator, this means inventorying the protection set first: virtual machines, file shares, database workloads, and any hybrid systems that depend on agents or backup servers. Then map each protection mechanism to the vault type and region it supports. This avoids a common design failure in which teams establish a naming standard and resource-group layout before confirming that the chosen vault supports the actual workload.<\/p>\n The same reasoning appears across Microsoft certification exams<\/a>: resource selection is rarely independent of service capability. If the organization is also standardizing architecture decisions across multiple Azure services, the broader design perspective associated with AZ-305<\/a> is useful. Backup is not simply \u201cdata protection\u201d; it interacts with platform topology, availability, security, and recovery objectives.<\/p>\n Vault placement should follow the protected workload and Azure Backup\u2019s regional support rules. For common workloads, the vault must be created in the same region as the data source it protects. That has immediate consequences for organizations that deploy the same application in multiple Azure regions: protection generally needs a regional vault strategy rather than a single global vault.<\/p>\n Region design should be explicit because recovery planning often starts with an imprecise phrase such as \u201cwe have backups in Azure.\u201d That does not tell you which region owns the control plane, where the backup data is replicated, or what happens if an entire region becomes unavailable. Azure regions and availability zones solve different failure problems; understanding Azure regions and availability zones<\/a> is therefore essential when deciding what protection a vault actually adds.<\/p>\n A regional vault also affects operations. Incident responders need to know which vault contains the relevant recovery points, which subscription and resource group hold it, and which team can access it during an outage. Good design makes those relationships predictable. Naming, tagging, and resource-group placement should reveal the protected environment and region without forcing an operator to reverse-engineer the topology in the middle of a restore.<\/p>\n Regional design should also account for resource moves and rebuilds. A protected workload that is redeployed into another region does not simply drag its old vault relationship with it. The recovery design must be revisited for the new regional boundary, and automation should create the required vault and policy association as part of the move. Treating backup topology as code helps prevent a migrated workload from silently losing the protection standard it had before the move.<\/p>\n Recovery Services vault storage redundancy is a resilience decision. Locally redundant storage is the least expensive option and keeps copies within a regional datacenter boundary. Zone-redundant storage distributes copies across availability zones in a supported region. Geo-redundant storage adds asynchronous replication to a paired secondary region. None of those labels should be chosen because one sounds \u201cmore enterprise.\u201d The right option depends on the failure the organization is paying to survive.<\/p>\n If the protected data can be recreated elsewhere and the primary goal is economical protection against local infrastructure failure, LRS can be appropriate. If zone failure within the primary region is a meaningful availability concern and the workload must remain region-resident, ZRS may fit better. If regional disaster recovery is a requirement, GRS becomes relevant because it creates a secondary regional copy and is the prerequisite for Cross Region Restore in supported scenarios.<\/p>\n This is where backup design intersects with availability targets<\/a>. Redundancy does not automatically create an application-level recovery plan. It protects backup data against specific infrastructure failures. You still need to understand restore time, dependency ordering, network recovery, identity availability, and application validation. More copies are useful only when they correspond to a recoverable operating model.<\/p>\n A vault becomes useful through policy. Backup frequency, retention, and recovery-point lifecycle should reflect how much data loss the organization can tolerate and how far back it may need to recover. Retaining a very large number of recovery points \u201cjust in case\u201d can increase cost and operational complexity without improving the ability to restore the right business state.<\/p>\n Start with the workload\u2019s recovery point objective and retention obligations. A system that changes constantly may need frequent recovery points; an archive-oriented service may not. A finance workload might require long-term retention for regulatory reasons, while a development environment may need only short retention because it can be rebuilt. The policy should encode those differences instead of forcing every resource into one universal schedule.<\/p>\nA Recovery Services vault is an operational control boundary<\/h3>\n
Start with workload support before choosing the vault pattern<\/h3>\n
Region placement is a hard boundary, not a cosmetic property<\/h3>\n
Choose LRS, ZRS, and GRS by failure model<\/h3>\n
Backup policy turns business requirements into recovery points<\/h3>\n