Azure VM Crash-Consistent Restore Points Preview for Premium SSD v2 and Ultra Disk: SCSI Limits

What the preview adds​

Azure VM restore points store a VM's configuration plus point-in-time snapshots of its managed disks. Instant Access, the fast-restore option, applies only to VMs with Premium SSD v2 or Ultra Disks as data disks. Until now, those high-performance disks could get application-consistent restore points. They could not get multi-disk crash-consistent ones.

A crash-consistent restore point captures a write-order-consistent snapshot of all the VM's disks. Microsoft describes the result as equivalent to the VM's state after a power outage or crash. It is not application-consistent. Application-consistent points use VSS writers on Windows, or pre/post scripts on Linux, to flush in-flight application data first. Crash-consistent points skip that step.

The preview extends the existing crash-consistent support to Premium SSD v2 and Ultra data disks. It is supported in public preview for SCSI VMs only, and it doesn't change existing support for Standard HDD, Standard SSD and Premium SSD disks.

Who can use it​

Before you plan a test, check these constraints:

• Controller: SCSI only. Multi-disk crash-consistent restore points aren't supported on VMs with NVMe disk controllers, whatever the disk type.
• Hardware: VMs running on Azure Boost hardware are not supported, even with a SCSI controller. A SCSI VM can still land on Azure Boost hardware and hit this error.
• Regions: The preview is available in all public regions except South Central US, West US 3 and East US 2.
• API version: Instant Access requires API version 2025-04-01 or later.
• Disk types: The VM needs Premium SSD v2 and/or Ultra disks as data disks. Managed disks only. Ephemeral OS disks and shared disks are not supported.
• Interfaces: Instant Access is currently supported through REST API, Azure SDK, CLI and ARM templates. The restore-point overview page says it is not supported in the portal.

"Preview" matters here. Azure's own status definitions describe preview features as meant for non-production use and testing. Treat this as a feature to evaluate, not as your only recovery path.

How to create one​

The documented flow has two steps:

1. Create a restore point collection with instantAccess set to true. The property defaults to false.
2. Create the restore point in that collection with consistencyMode set to CrashConsistent. If you omit consistencyMode, you get an application-consistent point.

You can also set instantAccessDurationMinutes on each restore point. The valid range is 60–300 minutes. The default is 300 minutes, which is five hours. Microsoft's CLI guidance says the Azure CLI command is az restore-point create, with --consistency-mode CrashConsistent. You can optionally exclude disks to reduce storage cost.

Disk restore points then report a state. Microsoft's documentation defines the VM-level instantAccessState values this way:

In practice, the Instant Access window is for restoring quickly, not for long-term retention. Plan your copy or download steps around the state transitions.

The Azure Boost catch​

This is the gotcha most likely to bite administrators. On newer-generation Azure Boost hardware in US regions, a SCSI VM with Premium SSD v2 or Ultra data disks can fail crash-consistent creation. The error is UserErrorCrashConsistentSnapshotNotSupportedForAzureBoostVms.

Microsoft's documented workaround for an existing VM is:

1. Stop the VM.
2. Apply the LegacyVMNVA tag.
3. Redeploy the VM so placement honors the tag and avoids Azure Boost hardware.
4. Retry creating the crash-consistent restore point.

Microsoft says to plan for downtime. Applying the tag alone doesn't move an already-running VM. If you're testing on a production-adjacent VM, schedule a maintenance window. Be aware that steering a VM away from newer hardware is a trade-off in its own right.

Limits and throttling​

• Crash-consistent restore points can be taken at most once per hour. Application-consistent ones have a three-hour minimum interval. Microsoft warns that going below the minimum causes failures.
• Microsoft's throttling table lists three create operations per hour per VM for each consistency type. Requests over the limit return HTTP 429, and you should retry after the interval in the response. That throttle doesn't override the one-hour minimum for crash-consistent points.
• A VM can retain at most 500 restore points, regardless of the number of collections or the consistency type.
• Concurrent restore-point creation for the same VM is not supported.
• There is a maximum of 50 concurrent Instant Access restore-point creations per subscription per region.
• Restore points are per VM. To cover an availability set or a Flexible-orchestration scale set, create them for each VM. Uniform-orchestration scale sets are not supported.
• Temporary disk contents are not captured.

Pricing​

Microsoft says Instant Access snapshots are billed on usage, with two charges. The first is storage for the changed data only. A new snapshot shares data with the source disk and incurs no storage cost at first. The second is a one-time restore fee, calculated from the disk's provisioned size at restore time. Microsoft's pricing pages have current rates.

Context and analysis​

Microsoft says the Azure Backup side is moving in parallel. According to the Azure Backup what's-new page, agentless multi-disk crash-consistent VM backups, built on these restore points, have reached general availability. That page also describes using Premium SSD v2 and Ultra Disks without disrupting existing backups. This new preview is a separate, lower-level feature: it covers the restore-point layer for the high-performance disk tiers.

Crash-consistent points are a reasonable fit for workloads that recover well from a crash. Transactional databases and journaling file systems usually do, but test that for your own workload. If you need guarantees that applications have flushed state, application-consistent points remain the better fit. Premium SSD v2 and Ultra Disks already support those.

This is my own assessment, not Microsoft guidance. The preview's value depends on how many of your VMs sit on SCSI controllers and avoid Azure Boost hardware. The restrictions are narrow, so check the VM's controller type, hardware placement and region before you commit to a test.

Pre-flight checklist​

• Confirm the VM is in a supported region (not South Central US, West US 3 or East US 2).
• Confirm the disk controller is SCSI.
• Confirm Premium SSD v2 and/or Ultra data disks.
• Use API version 2025-04-01 or later.
• Enable instantAccess on the collection and set consistencyMode to CrashConsistent.
• If you see the Azure Boost error, use the stop, tag, redeploy sequence above and budget for downtime.
• Don't rely on it as your only production recovery mechanism until it reaches general availability.