Azure Backup and Recovery Services vaults
Azure Backup stores backup data in a Recovery Services vault, a storage entity that holds both Azure Backup and Azure Site Recovery data. Creating a vault in a specific region and subscription is the first step before protecting any resource. The vault stores backup copies and applies backup policies that define the schedule and retention.
Backup policies define two things: how often to back up (hourly, daily, weekly) and how long to retain each backup (daily points for 7 days, weekly points for 4 weeks, monthly points for 12 months, yearly points for N years). Longer retention requires more storage. You can apply different policies to different VMs within the same vault depending on their recovery point objective requirements. Azure Backup supports Azure VMs, SQL Server in Azure VMs, SAP HANA in Azure VMs, Azure Files shares, blobs, and on-premises workloads via the MARS agent.
Soft delete in Azure Backup retains deleted backup data for an additional 14 days after you stop protecting a workload and delete its backup. During those 14 days, the backup data appears as soft-deleted and can be recovered. This protects against scenarios where ransomware or a malicious actor deletes backups to prevent recovery. Soft delete is enabled by default on Recovery Services vaults and should not be disabled in production environments.
Azure Site Recovery and disaster recovery concepts
Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time: if your RPO is 1 hour, you can tolerate losing up to 1 hour of transactions. Recovery Time Objective (RTO) is the maximum acceptable downtime: if your RTO is 4 hours, your business can tolerate being down for up to 4 hours during a disaster. These two metrics drive every disaster recovery design decision: a lower RPO requires more frequent replication, and a lower RTO requires more pre-provisioned infrastructure at the recovery site.
Azure Site Recovery replicates VMs from a primary location to a secondary location continuously. For Azure-to-Azure scenarios (replicating VMs from one region to another), ASR replicates disk changes in near-real-time, maintaining a crash-consistent recovery point every 5 minutes and an application-consistent recovery point hourly. When you initiate a failover, ASR starts the VM replicas in the target region using the latest recovery point. Failover can be planned (graceful, no data loss) or unplanned (immediate, possible minimal data loss based on replication lag).
Failback brings workloads back to the primary region after the disaster is resolved. ASR supports failback for Azure-to-Azure replication. Recovery plans in ASR define the order in which VMs are started during failover, with the ability to add manual steps, custom scripts, and Azure Automation runbooks between VM groups. A recovery plan ensures that database servers start before application servers, which start before web servers.
How to choose the correct answer
Recovery Services vault: required for both Azure Backup and Azure Site Recovery data. Region-specific.
Backup policy: frequency (hourly/daily) and retention (daily, weekly, monthly, yearly points).
Soft delete: 14-day retention of deleted backup data. Protects against accidental or malicious deletion.
RPO: maximum data loss tolerance in time. ASR provides 5-minute crash-consistent recovery points for Azure VMs.
RTO: maximum acceptable downtime. Lower RTO requires pre-staged infrastructure in the secondary region.
ASR failover types: planned (no data loss, graceful), unplanned (immediate, small possible loss).
Recovery plan: ordered multi-VM failover with scripted steps. Ensures correct startup sequence.
MARS agent: backs up on-premises Windows machines to Azure Recovery Services vault.