Cannot update disk encryption to Customer-Managed Key — "already has incremental restore point(s)" error

Yes. The error is expected and is caused by the presence of incremental restore points associated with the managed disk. Azure Managed Disks require a disk and its associated incremental snapshots or restore points to use the same Disk Encryption Set, which prevents changing the disk's encryption properties while those restore points exist. [learn.microsoft.com], [docs.azure.cn]

For your 1st question, I am not aware of any docuementd supported method that preserves the existing incr restore point chain while performing an in-place conversion of the source disk from SSE-PMK to SSE-CMK. The platform restriction effectively requires removal of the incremental restore-point dependency before the disk encryption settings can be changed. [learn.microsoft.com], [docs.azure.cn]

For production workloads, a practical sequencing approach is:

1. Take and validate a recent backup before making any changes.
2. Plan a maintenance window for the encryption transition.
3. Stop backup protection and ensure any restore points that are blocking the operation are removed.
4. Update the disk to use the target disk encryption Set (SSE-CMK).
5. Verify Disk Encryption Set access to the Key Vault and confirm the disk reports the expected encryption configuration.
6. Re-enable backup protection and create a new recovery point.
7. Perform a test restore or recovery point validation before closing the change.

The important consideration is that the backup history associated with the pre-conversion disk should be treated as part of the old protection chain. After the encryption change, Azure Backup establishes a new backup lineage for the CMK-encrypted disk rather than continuing the existing incremental chain. This means a short recovery-point gap during the transition should be expected and planned for.

Bottom line: Based on the documented managed disk encryption restrictions, there is no supported in-place approach that both preserves the existing incremental restore-point chain and changes the disk from SSE-PMK to SSE-CMK. The recommended approach is to perform the encryption transition in a controlled maintenance window and then establish a new backup chain afterward. [learn.microsoft.com], [docs.azure.cn]

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

Hi @Mohan Venkata Durgarao Y

1. You do not need to delete your recovery point history. The two stop options behave differently, and Manage Azure VM backups explains the difference. "Stop protection and retain backup data" stops future backup jobs but keeps the recovery points already stored in the vault. You can still restore the VM, and you can resume protection later. The other option, stop and delete backup data, is the one that removes the vault recovery points.

The part that does need to be cleared is the Instant Restore snapshot tier. This is separate from the vault and sits next to the disk. The Instant Restore documentation explains that for managed disks, snapshots are stored in a restore point collection resource in a designated resource group.

It helps to understand why the block exists. The disk encryption documentation states:

"A disk and all of its associated incremental snapshots must have the same disk encryption set."

Your existing snapshots were taken under platform-managed keys, so they cannot remain once the disk is moved to a disk encryption set. That is the rule the error is enforcing.

2. For sequencing, the order that follows from the above is: stop protection while retaining data, clear the incremental restore points, apply the encryption change, then resume backup. The only exposure is the window between stopping and resuming, because no new recovery points are created during that time while the existing ones remain restorable.

Plan for the first backup after you resume to be a full snapshot. Under the Enhanced policy, the Instant Restore documentation explains that the initial snapshot is a full copy of the disks and only later snapshots are incremental. Expect a longer first run and a larger snapshot after the change.

One thing the documentation does not state clearly is whether stopping protection with retain automatically clears the incremental restore points, or whether you need to delete the restore point collection yourself. Since nothing in the docs confirms either behaviour, check the restore point collection resource group after you stop protection and before you retry the encryption update.

Before you commit this on a production VM, be aware that it is close to a one-way door:

"If this feature is enabled for a disk with incremental snapshots, it can't be disabled on that disk or its snapshots."

The workaround the same page gives is to copy all data to a different managed disk that is not using customer-managed keys. Reversing later means creating a new disk, not flipping the setting back.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.