Azure Virtual Machines come with an operating system disk by default, but that disk is designed to host the operating system and its associated files rather than application data, databases, or large file storage. Data disks are separate managed disk resources that attach to a virtual machine specifically to provide additional storage capacity for workloads that require dedicated, persistent storage independent of the OS disk. The separation between OS disks and data disks is not merely organizational — it reflects a deliberate architectural principle that improves manageability, performance isolation, and recovery flexibility across the lifetime of a virtual machine.
When an application running on a virtual machine generates data that must survive reboots, scaling events, and even the deletion and recreation of the VM itself, that data belongs on a data disk rather than the temporary disk that Azure also provides. The temporary disk, sometimes called the ephemeral disk or the D drive on Windows VMs, is physically located on the host server and does not persist when a VM is deallocated or moved to different hardware. Misunderstanding the difference between temporary storage and persistent data disk storage is one of the most common and costly mistakes made by teams new to Azure virtual machine management, and clarifying this distinction early prevents data loss scenarios that are entirely avoidable.
The Different Managed Disk Types Available in Azure
Azure offers several managed disk types, each designed to balance performance and cost for different workload categories. Standard HDD disks use spinning magnetic storage and are suitable for workloads where cost minimization is the primary concern and latency is not critical — development and test environments, infrequently accessed archives, and backup storage are typical use cases. Standard SSD disks offer more consistent performance than HDD at a modest cost increase and are appropriate for lightly loaded web servers, small databases, and workloads that need predictable performance without the premium cost of higher-tier options.
Premium SSD disks deliver high throughput and low latency backed by solid-state storage and are designed for production workloads including enterprise databases, high-traffic web applications, and any scenario where IO performance directly affects application responsiveness. Ultra Disk is the highest-performance tier, offering configurable IOPS and throughput that can be adjusted independently of disk size, making it appropriate for the most demanding workloads such as SAP HANA, top-tier SQL Server deployments, and transaction-intensive applications. Choosing the right disk type requires matching the performance characteristics of the disk to the IO profile of the workload it will serve — over-provisioning wastes money while under-provisioning creates performance bottlenecks that are often difficult to diagnose without understanding the storage layer.
Attaching a New Data Disk to a Running Virtual Machine
One of the practical advantages of Azure managed disks is that new data disks can be attached to a running virtual machine without requiring a restart in most cases. Through the Azure portal, this process involves navigating to the virtual machine resource, selecting the Disks section under the Settings menu, and choosing the option to add a new data disk. At this point you specify the disk name, type, size, and whether the disk should be created fresh or sourced from an existing snapshot or disk resource. Once the configuration is confirmed and saved, Azure attaches the disk to the virtual machine within seconds.
Attaching the disk through the portal or through Azure CLI and PowerShell makes the disk visible to the operating system, but the disk is not immediately ready for use. On a Windows VM, the newly attached disk appears in Disk Management as an uninitialized disk that must be initialized, partitioned, and formatted before it can store data. On a Linux VM, the disk appears as a new block device that must be partitioned using a tool like fdisk or parted, formatted with a file system such as ext4 or xfs, and mounted to a directory in the file system hierarchy. Completing these operating system level steps is a required part of the data disk setup process that is separate from the Azure-level attachment operation.
Initializing and Formatting Data Disks on Windows Virtual Machines
After a data disk is attached to a Windows Azure virtual machine, the Disk Management console is the primary graphical tool for preparing it for use. Opening Disk Management reveals the new disk listed as unknown and uninitialized. Right-clicking the disk and selecting Initialize Disk prompts a choice between MBR and GPT partition styles. For data disks larger than two terabytes or in environments that will eventually scale beyond that threshold, GPT is the correct choice. For smaller disks in environments with no anticipated size growth, either partition style works, but GPT has become the standard recommendation for most modern deployments.
After initialization, the disk appears as unallocated space and must be partitioned and formatted. Right-clicking the unallocated space and selecting New Simple Volume launches a wizard that guides through partition size selection, drive letter assignment, and file system formatting. NTFS is the appropriate file system for Windows data disks in the vast majority of scenarios. The allocation unit size can be left at the default for general-purpose storage or adjusted to larger values for specific workloads like SQL Server databases, where larger allocation units improve IO efficiency. Once formatting completes, the drive letter appears in Windows Explorer and the disk is ready to receive data from applications and services running on the VM.
Preparing and Mounting Data Disks on Linux Virtual Machines
Preparing a newly attached data disk on a Linux Azure virtual machine requires working in the terminal using command-line disk management tools. The first step is identifying the device name assigned to the new disk, which can be done using the lsblk command to list all block devices currently visible to the operating system. The new disk typically appears as sdc or the next available device name in sequence after the OS disk and any previously attached disks. Confirming the correct device before partitioning is important because operating on the wrong device can cause data loss on existing disks.
Creating a partition on the new device using fdisk or parted, then formatting it with a command like mkfs.ext4 pointing to the new partition, prepares the disk for mounting. Creating a mount point directory and mounting the partition to that directory makes the storage accessible. However, this manual mount is not persistent — it is lost when the virtual machine reboots. Making the mount persistent requires adding an entry to the /etc/fstab file that specifies the device, mount point, file system type, and mount options. Using the disk’s UUID rather than its device name in the fstab entry is the recommended practice because device names can change between reboots while UUIDs remain stable, preventing the mount failures that occur when a device name shifts unexpectedly.
Resizing Data Disks Without Downtime in Azure
One of the significant operational advantages of Azure managed disks is the ability to increase disk size without taking the virtual machine offline in most configurations. Through the Azure portal, CLI, or PowerShell, you can increase the size of a managed data disk by navigating to the disk resource and specifying a larger size. Disk size can only be increased, not decreased, so planning initial sizes with growth in mind while avoiding excessive over-provisioning is an important consideration. The disk tier can also be changed during a resize operation, allowing a simultaneous upgrade from Standard SSD to Premium SSD if performance requirements have grown.
After the disk size is increased at the Azure level, the additional space is not automatically available to the operating system. On Windows, Disk Management shows the additional space as unallocated, and extending the existing volume using the Extend Volume option incorporates the new space into the existing partition. On Linux, the partition must be resized using parted or fdisk to extend it to the new disk boundary, and then the file system must be extended using a command like resize2fs for ext4 file systems or xfs_growfs for xfs file systems. Both Windows and Linux extension operations can typically be performed on a mounted, live file system without interrupting applications that are actively using the disk, making online resize a practical option for production environments.
Detaching Data Disks Safely and Avoiding Data Corruption
Detaching a data disk from an Azure virtual machine is a straightforward operation at the Azure level but requires care at the operating system level to avoid corrupting data on the disk. Detaching a disk while the operating system still has open file handles to it, or while write operations are in progress, can leave the file system in an inconsistent state that requires repair tools to resolve before the disk can be safely used again. Following a proper detachment sequence prevents these issues and ensures the disk remains in a healthy state for reattachment to the same or a different virtual machine.
On Windows, the correct preparation for detachment involves taking the disk offline through Disk Management before initiating the detach operation in Azure. This signals to the operating system that the disk is no longer available and ensures all pending writes are flushed and file handles are closed. On Linux, unmounting the file system using the umount command achieves the same result. After the operating system has been prepared, the detach operation in the Azure portal, CLI, or PowerShell removes the disk from the VM’s configuration. The disk resource itself remains in Azure storage and can be reattached to the same VM, attached to a different VM, used to create a snapshot, or retained as a standalone resource for future use.
Using Disk Snapshots for Backup and Point-in-Time Recovery
Azure disk snapshots capture the state of a managed disk at a specific moment in time and store that state as an independent resource that can be used to restore the disk or create new disks from a known good state. Snapshots are incremental after the first full snapshot, meaning each subsequent snapshot only stores the changes made since the previous one, which reduces storage costs significantly for disks that change gradually rather than completely between snapshot intervals. Creating regular snapshots of data disks is a foundational backup practice for Azure virtual machine workloads that complements but does not replace more comprehensive backup solutions.
Creating a snapshot through the Azure portal involves navigating to the disk resource, selecting the Create Snapshot option, specifying a name and resource group, and choosing between locally redundant storage and zone-redundant storage for the snapshot itself. For application-consistent snapshots — where the data on the disk is in a state that the application considers consistent, rather than potentially mid-transaction — applications should be quiesced or write operations should be paused momentarily before the snapshot is taken. Azure Backup provides automated, application-consistent snapshot scheduling for virtual machines and is the recommended approach for production workloads where manual snapshot management would be impractical or unreliable.
Implementing Disk Encryption to Protect Data at Rest
Protecting data stored on Azure data disks from unauthorized access requires encryption, and Azure provides multiple encryption mechanisms that can be applied depending on the security requirements of the workload. Azure Storage Service Encryption, also called server-side encryption, is enabled by default on all managed disks and encrypts data at rest using platform-managed keys without requiring any configuration from the customer. This default encryption protects against unauthorized access at the physical storage level and satisfies baseline compliance requirements for many regulatory frameworks.
For workloads requiring customer control over encryption keys, Azure Disk Encryption uses BitLocker on Windows VMs and DM-Crypt on Linux VMs to perform volume-level encryption within the operating system, with encryption keys stored in Azure Key Vault. This approach provides an additional layer of protection because data is encrypted before it leaves the virtual machine rather than only at the storage layer. Customer-managed keys in Key Vault give security teams control over key rotation, access policies, and key lifecycle management. Organizations subject to strict compliance requirements around key custody — including certain financial services, healthcare, and government workloads — typically implement customer-managed key encryption to satisfy auditors and regulatory frameworks that require demonstrable control over encryption key management.
Performance Tuning and IOPS Considerations for Data Disk Configurations
Getting the expected performance from Azure data disks requires attention to several factors beyond simply choosing the right disk tier. Each virtual machine size in Azure has a maximum uncached disk throughput and IOPS limit that applies regardless of how many high-performance disks are attached. If the combined IO demand of all attached disks exceeds the VM size’s throughput ceiling, performance is throttled at the VM level rather than the disk level. Selecting a VM size whose IO limits comfortably accommodate the expected disk workload is as important as selecting the right disk tier.
Disk caching settings also affect performance significantly and should be configured deliberately based on the read and write patterns of the workload. The ReadOnly cache setting stores recently read data in the host server’s memory, accelerating repeated reads of the same data — useful for read-heavy workloads like reporting databases and media servers. The ReadWrite cache setting additionally caches write operations before they are committed to disk, improving write performance at the cost of a small data loss window if the host fails before cached writes are persisted. For databases with their own write-ahead logging or other durability mechanisms, disabling caching entirely on data and log disks is often recommended to avoid conflicts between the application’s own durability guarantees and the disk cache behavior.
Striping Multiple Disks for Higher Throughput Requirements
When a single data disk cannot provide sufficient throughput or IOPS for a demanding workload, striping multiple disks together using a software RAID configuration distributes IO operations across several disks simultaneously, multiplying effective throughput and IOPS proportionally with the number of disks in the stripe set. On Windows Azure VMs, Storage Spaces provides a built-in mechanism for combining multiple data disks into a single logical volume with striping. On Linux VMs, mdadm or LVM striping achieves the same result, with LVM being the more flexible option for environments where volume management beyond simple striping is anticipated.
The number of disks in a stripe set, combined with the per-disk IOPS and throughput limits of the chosen disk tier, determines the aggregate performance of the striped volume. A stripe set of four Premium SSD P30 disks, each providing 5000 IOPS, can theoretically deliver up to 20000 aggregate IOPS, subject to the VM-level IO ceiling. Planning stripe configurations requires calculating both the individual disk limits and the VM ceiling to identify which constraint will bind first under the expected workload. For the most IO-intensive workloads, Ultra Disk often provides a simpler alternative to multi-disk striping because its configurable IOPS and throughput can be set to match workload requirements without the complexity of managing a stripe set.
Monitoring Disk Performance and Identifying Storage Bottlenecks
Effective management of data disks in production environments requires ongoing monitoring of disk performance metrics to identify bottlenecks before they cause application degradation. Azure Monitor collects metrics for managed disks including read and write IOPS, read and write throughput in bytes per second, disk queue depth, and latency per operation. These metrics can be viewed in the Azure portal, used to trigger alerts when thresholds are exceeded, and exported to Log Analytics workspaces for long-term trend analysis and capacity planning.
Disk throttling is a particularly important condition to monitor and detect promptly. When a disk or VM consistently reaches its IO limits, Azure throttles additional IO requests, introducing latency spikes that manifest as application slowdowns, query timeouts, or increased error rates. The Disk Throttled IOPS and Disk Throttled Bytes Per Second metrics in Azure Monitor reveal when throttling is occurring. Persistent throttling indicates that either the disk tier needs to be upgraded, the VM size needs to be scaled to provide higher IO limits, or the workload needs to be distributed across additional resources. Catching throttling conditions early through proactive monitoring is considerably less disruptive than diagnosing them reactively after application performance complaints have already reached users and stakeholders.
Conclusion
Managing data disks effectively on Azure virtual machines is a discipline that spans initial design decisions, day-to-day operational tasks, security implementation, performance optimization, and ongoing monitoring. Each dimension covered in this guide contributes to a complete approach that protects data, maximizes performance, controls costs, and maintains the operational flexibility that cloud infrastructure is designed to provide. Organizations that treat disk management as an afterthought — attaching whatever disk type is convenient, skipping encryption, neglecting monitoring, and ignoring performance boundaries — consistently encounter avoidable problems that proper planning and practice prevent entirely.
The foundation of good disk management begins with choosing the right disk type for the workload at hand. A mismatch between disk tier and workload IO profile is one of the most common sources of performance issues in Azure VM environments, and it is also one of the most straightforward to avoid through upfront workload analysis. Beyond tier selection, structuring the OS disk and data disk separation correctly, configuring caching settings deliberately, and planning for growth through appropriately sized initial allocations all reduce the operational friction that teams encounter as workloads evolve over time.
Security should never be treated as optional in data disk management. Default server-side encryption provides a baseline, but workloads handling sensitive data deserve the additional protection of customer-managed keys and Azure Disk Encryption, both of which are well-documented and straightforward to implement with modest planning effort. Similarly, snapshot and backup practices should be established from the beginning of a VM deployment rather than added later in response to a data loss incident. The Azure tools available for backup, snapshot management, and recovery are capable and accessible, and the cost of implementing them proactively is a fraction of the cost of recovering from a preventable data loss event. Teams that build these practices into their standard VM deployment procedures, treat monitoring as a continuous operational responsibility, and review disk configurations regularly as workloads grow will find that Azure data disk management becomes a reliable and well-controlled aspect of their cloud operations rather than a recurring source of unpleasant surprises.
