VM Disaster Recovery

Hello @TBFG Azure Admin ,

Thanks for reaching out Microsoft Q&A and sharing the details.

1. Your current protection what you actually have two complementary things running, and that's a good combination:

• Azure VM backup (Recovery Services vault) – nightly snapshots that create recovery points containing the OS disk + both 1 TB data disks together. These recovery points live in two tiers: a Snapshot tier (stored with the disks, used for fast "Instant Restore") and a Vault tier (copied into the vault for longer retention).
• SQL Server (in Azure VM) workload backup – Azure Backup uses the SQL native APIs (VDI) to take full, differential, and transaction-log backups of your databases directly, streaming them to the vault. This gives you point-in-time restore down to the second and an RPO as low as 15 minutes, independent of the VM-level snapshot.

So the "VM Recovery Points (includes the two disks)" your crash/app-consistent VM image, and the "SQL Protected Databases" screenshot is your granular, point-in-time SQL recovery path. They serve different purposes keep both.

2. Is your 3-step recovery plan correct?

Your idea to create a new VM from the image → restore last snapshot → change IPs — is close, but it's not quite how Azure Backup actually works. You don't need to pre-build a VM and then "apply" a snapshot to it.

Azure Backup gives you the following restore options directly from a recovery point:

So the correct DR flow after a total loss is really just:

1. Go to the Recovery Services vault → Backup item → Restore VM → "Create new virtual machine" (or "Restore disks" if you want to customize).
2. Restore the SQL databases separately from the SQL in Azure VM backup item to the newly restored VM, choosing the exact point in time (up to the second) you need.
3. Update IP/DNS/bindings for your websites as needed.
4. Answering your specific "unknowns"

• Operating System + installed programs? Yes.

The VM recovery point contains the OS disk, so Windows Server 2022, IIS, SQL binaries, drivers, roles, features, and any installed applications come back exactly as they were at the snapshot time.

• Will SQL Server operate as normal? Yes.

The SQL Server instance is on the OS disk and is restored with the VM. But the database files you should actually rely on come from the SQL workload backups restore those to bring the databases to your desired point-in-time (transaction-log-level granularity, not just the nightly snapshot).

• Does the new VM have both data disks? Yes.

A VM recovery point captures all disks attached at backup time, so both 1 TB data disks are restored and attached to the new VM automatically.

4. Realistic RTO – is 2–3 hours achievable?

It's usually feasible, but it depends on:

• Restore tier: Snapshot-tier (Instant Restore) is much faster than Vault-tier because the data doesn't need to be copied out of the vault first.
• Disk size: 2 × 1 TB data disks + OS disk take real time to hydrate.
• Post-restore work: SQL DB restore, IP/DNS/binding changes, app validation.

If you need a guaranteed low RTO/RPO with a hot standby, that's where ASR comes in below.

5. Where Azure Site Recovery (ASR) fits and how it's different:

Azure Backup and Azure Site Recovery solve different problems:

• Azure Backup = protects against data loss / corruption / accidental deletion / ransomware.

Recovery is a restore operation and takes time proportional to disk size.

• Azure Site Recovery = protects against major disaster / regional outage. It continuously replicates the VM (OS + data disks) to another region (or zone). During a disaster you failover and a new VM is created in the target location within minutes, using the latest processed recovery point for the lowest RPO. You can also run non-disruptive DR drills to test.

So to answer your question yes, when you enable ASR on the VM, it will replicate the VM and its disks to your chosen target region/zone, and on failover it creates a new VM with new disks (and you can pre-configure the target VNet/subnet/IP for it).

Recommendation: For a business-critical Windows 2022 + SQL workload, the ideal setup is both:

• Azure Backup (what you have) for operational recovery, SQL point-in-time, ransomware protection, long-term retention.
• Azure Site Recovery for regional/zone disaster recovery with minutes-level RTO.

6. Suggested DRP procedure:
7. Keep nightly VM backups + SQL log backups every 15 minutes in the Recovery Services vault (GRS enabled, Cross Region Restore turned on).
8. Enable Azure Site Recovery to a secondary region/zone and run a test failover every quarter no impact on production.
9. Document your runbook: (a) failover via ASR or (b) restore VM from vault + restore SQL DBs to the point-in-time you need.
10. After failover/restore, update DNS/IP/website bindings as needed.

References:

• How to restore Azure VM data in Azure portal
• About the Azure Virtual Machine restore process (OLR/ALR, Snapshot vs. Vault tier)
• Backup and restore options for virtual machines in Azure (Backup vs. ASR)
• Back up SQL Server databases on Azure VMs
• Restore SQL Server databases on an Azure VM

Hope this clarifies.

Thanks,
Suchitra.

Your plan can recover the server, but independent disk snapshots are not a coordinated VM recovery point. Create managed disks from the OS and two data-disk snapshots, create the VM from the restored OS disk, then attach the restored data disks in original LUN order. The OS snapshot contains Windows and installed programs; each data snapshot contains that disk. Recreating from the marketplace image first would produce a clean OS, so skip that step.

SQL Server is the main risk. Snapshots taken while the VM runs can be crash-consistent, and separately timed disks may not form a transactionally consistent set. Protect the full VM with Azure Backup using application-consistent recovery points, and configure SQL Server database backups for your required recovery point. For a dependable two-to-three-hour target, test the restore regularly or use Azure Site Recovery. Expect to recreate or reassign networking, DNS, RBAC, and static IP settings.