Design solutions for backup and disaster recovery
Azure Backup protects data by creating recovery points for virtual machines, databases, and file shares. The backup policy defines how often a backup runs (frequency) and how long each recovery point is kept (retention). Recovery points are stored in a Recovery Services vault, which is a container that also holds backup configuration and encryption keys. When a failure occurs, you restore from the most recent valid recovery point, and the time needed to return to normal is defined by your recovery time objective (RTO); the amount of data you can afford to lose is your recovery point objective (RPO). Choosing the right backup policy means balancing cost (more frequent backups cost more) against your RPO requirement.
Azure Site Recovery (ASR) handles disaster recovery by replicating workloads from a primary region to a secondary region. The replication engine continuously copies changes to the target region, so the RPO can be as low as a few seconds. During a declared disaster you run a failover, which brings up the workloads in the secondary region using the replicated data. After the primary region recovers you can fail back to return to normal operation. The relationship between backup and disaster recovery is complementary: backup protects against data corruption or accidental deletion with long-term retention, while disaster recovery protects against a full-region outage with fast failover. You plan for both by deciding which workloads need only backup, which need full replication, and which need a combination of the two.
Design for high availability
High availability keeps an application running even when individual components fail. Availability zones protect against a datacenter failure by placing resources in physically separate zones within the same region. For example, you deploy virtual machines across two or three zones, and a Standard Load Balancer distributes traffic to healthy instances in any zone. If one zone fails, the other zones continue to serve traffic. The design tradeoff is that cross-zone traffic adds a small amount of latency, and zonal resources cost more than single‑zone ones.
Availability sets protect against hardware failure within a single datacenter. An availability set places virtual machines into different update domains (so Azure reboots only one domain at a time during planned maintenance) and different fault domains (so VMs run on separate racks with independent power and network). Availability sets do not protect against a zone or region failure, so they are used when you cannot use zones or when lower cost is the priority. For stateful workloads, you must also decouple the application layer from the storage layer: use Azure Storage with geo‑redundancy to keep data accessible if the compute tier fails, or use a database with built‑in high availability like Azure SQL Database’s zone‑redundant configuration. The overall design decision depends on the workload’s criticality: mission‑critical applications use zones plus disaster recovery, while less critical ones may rely only on availability sets and backup.
StudyCerts
StudyCerts