Resize of SQL Virtual Machine loses all settings

Question

Resize of SQL Virtual Machine loses all settings

TBFG Azure Admin 0

I create a SQL VM using the sql2022-ws2022 image and started to setup. Machine is D8ds_v4

This image setup

C Drive with the operating system
D Drive (temp drive including the SQL Temp Database)
E Drive (1 GB Drive for SQL Data Files)
F Drive (1 GB Drive for SQL Log Files

I then installed IIS on the C Drive and setup web sites that were located on the E Drive, and FTP for this site.

I also setup SSH for SFTP, created accounts

Everything was setup and working

Because this is a new setup and I hadn't done too much work (though a few days worth) I decided to Resize the VM to determine how that works and what the outcome is.

I resized to E8bds_v5 which seemed the next logical step up for us.

The Resize resulted in

SQL Server Settings being lost
- Temp Database no longer on the Temp Drive
- the 5 Database no longer attached
- All SQL Users were no longer setup
IIS was not installed at all
SSHOpen was not installed
All users setup in Windows Admin were no longer there

Basically I had to set everything up again.

What am I missing here?

Luckily I didn't wait for the need to resize to find all of this out, our system is in about 800 venues around Australia and 2-3 hour downtime is not a desired outcome after resizing.

Any guidance before I set everything up again would be appreciated.

Thanks in Advance

Wayne

Ankit Yadav 13,135 Reputation points Microsoft External Staff Moderator

2026-04-09T13:11:28.4133333+00:00
Hello TBFG Azure Admin,

Based on general known behavior, a normal VM resize should restart the VM and may require deallocation, but it should not remove your OS disk or managed data disks. https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/sizes/resize-vm. Given that you observed OS-level changes disappearing (IIS removed, local Windows users gone, SSH tooling removed, SQL configuration/users gone), that outcome is most consistent with the VM being reprovisioned back to the original image state, which can occur only if the VM was created with an ephemeral OS disk.

For VMs using an ephemeral OS disk, Microsoft documents that resizing to a new VM size deletes data on the OS disk and reprovisions the OS. https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/ephemeral-os-disks

On the other hand (and regardless of OS disk type), the Windows temporary disk (commonly D:) is not persistent. Microsoft tells that data on the temporary disk can be lost during events such as VM redeploy/move/stop, and guidance is to avoid storing data there that must be preserved. https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/managed-disks-overview, https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/windows/change-drive-letter

Guidance to keep to avoid running into these issues in future:

->Confirm whether the OS disk is ephemeral or persistent (managed)

If the VM is using an ephemeral OS disk, the behavior you saw after resizing is expected per documentation, because the OS disk state is not preserved across a resize-to-new-size operation. In that case, for a stateful server (SQL, IIS, local accounts), you should use a persistent (managed) OS disk design rather than an ephemeral OS disk.

If the OS disk is a persistent managed disk, then losing installed roles/software and local users is not described as expected behavior for a resize. A resize remains disruptive (restart and sometimes deallocation), but the OS and data disks are documented as not being affected. In that scenario, it would be important to review what operation occurred (for example, whether the VM was redeployed or reimaged rather than only resized).

->Keep all durable content on managed data disks, not on the temporary disk:

Store SQL user databases (data and log files) and IIS site content on managed data disks (for example E: and F: if those are attached managed disks). Microsoft’s guidance is that the temporary disk is intended for short-term, non-critical data (pagefile, swap, tempdb), and it can be lost during certain VM lifecycle events. [Overview o...soft Learn | dori-uw-1.kuma-moon.com], [dori-uw-1.kuma-moon.com]

Tempdb on D: is supported as an optimization, but it must be re-prepared on startup Microsoft documents that local SSD ephemeral storage is recreated when the VM is deallocated or moved (including during resizing). This is why tempdb on ephemeral storage is described as low risk (tempdb is recreated on SQL Server restart), but you must ensure the tempdb folders and permissions exist again on each startup. (https://dori-uw-1.kuma-moon.com/en-us/azure/azure-sql/virtual-machines/windows/tempdb-ephemeral-storage?view=azuresql)

Microsoft documents that resizing a running VM causes a restart and can be disruptive for stateful workloads. Planning a maintenance window and ensuring all durable components are on persistent disks is the supported way to minimize risk and downtime.

References:

https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/sizes/resize-vm

https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/ephemeral-os-disks

https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/managed-disks-overview

https://dori-uw-1.kuma-moon.com/en-us/azure/virtual-machines/windows/change-drive-letter

https://dori-uw-1.kuma-moon.com/en-us/azure/azure-sql/virtual-machines/windows/tempdb-ephemeral-storage?view=azuresql

Hope this gives you the guidance to avoid running into same issue again!

1 answer

Your answer

Answer 1

Resizing the SQL Server VM changed the underlying VM SKU and storage layout, which in this case effectively redeployed the SQL image and its configuration rather than performing an in‑place resize of the existing OS and data disks. As a result, the VM came back as if it were a fresh SQL image deployment, and anything that was not on a persistent data disk that survived the operation was lost or reset.

Key points relevant to this scenario:

Ephemeral/temporary disks are not persistent
- The D: drive in Azure Windows VMs is a temporary disk. It is explicitly not supported for storing data that must survive host moves or redeployments.
- When the VM is moved to different hardware (which can happen on resize), the temporary disk is recreated and its contents are lost. This includes anything stored there, such as tempdb or any other files.
- Official guidance is not to use the temporary disk for persistent data: “Don't use the temporary disk to store data. It is only temporary storage, so you would risk losing data that can't be recovered. Data loss can occur when the virtual machine moves to a different host. Resizing a virtual machine, updating the host, or a hardware failure on the host are some of the reasons a virtual machine might move.”
SQL Server image + certain VM SKUs can reconfigure storage
- Some newer VM sizes (those with uninitialized ephemeral NVMe storage, often indicated by a lowercase d in the SKU name) change how the temporary disk is presented.
- SQL Server on Azure VM images are tightly integrated with the VM size and storage layout. Moving between certain SKUs (for example, between generations or to SKUs with different ephemeral disk behavior like Ddsv6, Ebdsv6, FXmdsv2, etc.) can cause SQL deployment or configuration issues if tempdb or system databases are tied to ephemeral storage.
- There is explicit guidance to avoid impacted SKUs or to choose SKUs without the lowercase d when using SQL images, or to reconfigure tempdb away from ephemeral storage.
Correct pattern for persistent SQL and app configuration
- System and user databases, IIS content, and configuration that must persist across resizes and host moves should be on:
  - The OS disk (C:) for OS and installed roles/features, or
  - Dedicated data/log managed disks attached to the VM (for example, E:, F: created as data disks), not on the temporary disk.
- For SQL Server VMs, use the SQL Server settings → Storage configuration blade at deployment time to:
  - Place system and user databases on persistent data disks.
  - Configure tempdb appropriately. If using local SSD, ensure it is understood as non‑persistent and that the SQL IaaS Agent extension manages re‑provisioning, or choose a non‑ephemeral drive for tempdb.
How to avoid this outcome on future resizes
- Do not store any required data or configuration on the temporary disk (D: by default).
- When choosing VM sizes for SQL Server on Azure VMs:
  - Prefer SKUs recommended in the SQL VM performance best practices.
  - Avoid impacted SKUs that deploy an uninitialized ephemeral drive unless tempdb is explicitly moved off that storage.
- Before resizing:
  - Ensure SQL data/log files, IIS content, and any configuration that must persist are on managed data disks.
  - Take a full backup or create a managed image/snapshot of the VM and disks.
If using impacted VM sizes
- If a desired SKU is on the impacted list (for example Ddsv6, Ebdsv6, FXmdsv2, Dadsv6, etc.), use the non‑d variant where possible (for example FXmsv2 instead of FXmdsv2) so that tempdb is placed on the same persistent storage as data files.
- Alternatively, deploy a Windows‑only VM with the desired SKU, manually install SQL Server, and configure tempdb and data/log locations explicitly on persistent disks.

In practice, to rebuild this environment safely:

Recreate the VM using a supported SQL Server image and a non‑impacted SKU (or the non‑d variant of the SKU family).
On the SQL Server settings → Storage configuration page:
- Place system and user databases on dedicated data/log managed disks.
- Configure tempdb on either the local SSD with SQL IaaS Agent management or on a persistent data disk.
Install IIS and SSH on the OS disk and keep web content and SFTP data on persistent data disks (not D:).
Document and script configuration (ARM/Bicep/Terraform, PowerShell, or Azure CLI) so that a resize or redeploy can be recovered quickly.

References:

Share via

Resize of SQL Virtual Machine loses all settings

1 answer

Your answer