Volume (Storage)

The Wikipedia volume documentation captures the canonical definition: “In computer data storage, a volume or logical drive is a distinctly-addressable storage area with a single file system. Storage can be designed and configured in many different and complex ways yet all include the volume concept.”¹ The volume is the abstraction that the operating system presents to applications and users: a single, unified storage container with a known file system, accessible through a single addressing mechanism (drive letter, mount point, or path).

The single file system rule

The defining property of a volume is that it has exactly one file system. A volume might be NTFS, ext4, APFS, FAT32, or any other file system, but it has only one. This is what differentiates a volume from the underlying physical hardware: a single physical disk can hold multiple volumes (each with its own file system) or one volume that spans multiple disks (with a single file system layered over the combined capacity). The volume is the unit of file system organization; everything below the volume is hardware abstraction, and everything above is file and directory operation.

How volumes appear to users

The volume’s user-facing manifestation depends on the operating system:

• Windows: volumes typically appear as drive letters (C:, D:, E:) in File Explorer and command prompts. Volumes can also be mounted at directory paths within other volumes (e.g., C:\Music for a music volume mounted there).
• Linux: volumes are mounted at directory paths within a single unified hierarchy (root /, /home, /var, /Volumes/External). The /etc/fstab file describes which volumes mount where automatically.
• macOS: volumes appear in /Volumes (e.g., /Volumes/Macintosh HD, /Volumes/External) and in the Finder’s sidebar. APFS containers can hold multiple volumes that share underlying storage space.

The “office building” analogy

The Pure Storage volume vs partition explainer uses an accessible analogy: “To help illustrate the difference between a partition and a volume, imagine an office building partitioned into individual offices. When a company moves in, maybe they group their departments by floor (payroll on the first floor, IT on the second floor, management on the third floor, etc.).” The partitions are the architectural divisions of the building; the volumes are how the company logically uses spaces (some volumes might span floors, some might use a single office). The hardware partition layout is fixed once the building is built; the company’s logical use of space is more flexible.

Volumes that aren’t partitions

The Wikipedia documentation describes the broader applicability: “The concept of volume applies to any type of storage medium. But, for historical reasons, the term disk is often used even for non-disk media.” Several non-traditional cases:

• Floppy disks and small media: too small to partition meaningfully; the entire device is one volume.
• Volumes packed in files: ISO 9660 disc images (.iso files), Apple Disk Images (.dmg files), and VHD/VHDX virtual hard disks are volumes contained in files. The Wikipedia documentation notes: “A volume can be packed in a single file. Examples include the ISO9660 disc image (CD/DVD image, commonly called ‘ISO’), and the installer volume for Mac OS X (Apple Disk Image).”
• Network volumes: SMB shares, NFS exports, iSCSI LUNs all present as volumes despite being remote.
• Cloud volumes: AWS EBS volumes, Azure managed disks, Google Compute Engine persistent disks present as block storage volumes attached to virtual machines.

Volume labels and serial numbers

Each volume has identifying metadata. The Wikipedia documentation describes the conventions: “It is stored as an entry within a disk’s root directory with a special volume-label attribute bit set, and also copied to an 11-byte field within the Extended BIOS Parameter Block of the disk’s boot sector. The label is stored as uppercase in FAT and VFAT, and cannot contain special characters that are also disallowed for regular filenames. In the NTFS filesystem, the length of its volume label is restricted to 32 characters, and can include lowercase characters and even Unicode. In exFAT, the length is restricted to 11 characters.” The volume serial number is a separate identifier “generally both unique and not editable by the user,” assigned at format time and used for various system-level identification purposes.

The volume vs partition distinction is one of the most consistently confused concepts in storage. Different operating systems use the terms differently, and the conceptual relationship isn’t strictly hierarchical.²

The full storage hierarchy

The Pure Storage explainer describes the complete stack: “The hierarchy flows from physical hardware (the actual disk drive) → partition table (MBR or GPT) → partition (a logical section) → file system (the formatting) → volume (the accessible storage).” Each level abstracts the one below:

1. Physical hardware: the actual disk drive(s).
2. Partition table: MBR or GPT structure describing how the disk is divided.
3. Partition: a logical section of one disk, defined by the partition table.
4. File system: the structure (NTFS, ext4, etc.) imposed on a partition or combination of partitions.
5. Volume: the accessible storage container the OS presents based on the file system.

The not-quite-hierarchy relationship

The Pure Storage documentation cautions: “Volumes and partitions don’t have a perfect hierarchical relationship.” A partition is bound to a single physical disk; a volume is more flexible. Several relationships are possible:

• 1 partition = 1 volume: the most common case. Format a partition with a file system and it becomes a volume.
• 1 partition = 0 volumes: an unformatted partition exists but isn’t usable as a volume yet.
• Multiple partitions = 1 volume: spanned, striped, or mirrored configurations.
• 1 disk (no partitions) = 1 volume: some media (floppy disks, some flash drives) skip partitioning entirely.

The “partition without volume” case

The Wikipedia documentation captures an interesting edge case: “An operating system (OS) can potentially recognize a partition without recognizing a volume associated with it, as when a partition has not been formatted for a file system or is using a file system that the OS does not support. This occurs, for example, when Windows encounters a non-native partition, such as the ext4 filesystem commonly used with Linux.” The partition exists; the OS sees it; but the OS can’t access it as a volume because it doesn’t understand the file system. Recovery tools must understand the file system to access the volume; cross-platform recovery requires tools that understand foreign file systems.

The “all volumes are logical drives” terminology

The HelpDeskGeek explainer captures a terminology nuance: “Strictly speaking, all volumes are logical since they are not necessarily linked to a single or entire physical drive. Still, it seems more common for the term ‘logical volume’ to refer to a volume that spans multiple drives.”³ The term “logical drive” is used differently in different contexts: in MBR partitioning, “logical drive” specifically means a partition within an extended partition; in volume management generally, “logical volume” means a volume that’s been abstracted from underlying physical storage.

Server 2008 and the terminology shift

The Wikipedia documentation notes a Microsoft terminology change: “In Windows Server 2008 and onward, the term ‘volume’ is used as a superset that includes ‘partition’.” Modern Microsoft documentation often uses “volume” as the umbrella term, with “partition” being a specific kind of volume. This represents a simplification compared to earlier Windows documentation that distinguished the terms more carefully. Recovery tools and forensic analysis often still maintain the distinction because the underlying technical structures differ even when the terms are used interchangeably.

Cross-volume vs within-volume operations

The Wikipedia documentation describes a practical implication: “Generally, a file in a volume can be moved to any other path within that volume by simply changing filesystem metadata rather than copying file content. However, if a file is moved to a path that is on a different volume, then the file content is copied to the target and deleted from the source volume (which takes significantly longer to complete).” This is why moving a 10 GB file between folders on the same drive is instant, but moving the same file to a different drive takes minutes.

Modern operating systems support five main volume types, each with different capacity, performance, and redundancy characteristics. The choice depends on the workload and the importance of data on the volume.⁴

Simple volumes

A simple volume is the most basic type: one partition on one physical disk, formatted with a single file system. The Wikipedia documentation describes the configuration: “A simple volume describes the most basic configuration: a volume on one storage medium with no redundancy or striping.” Simple volumes are what most desktop and laptop computers use; they’re the easiest to manage and the easiest to recover from. The disadvantage is that simple volumes have no redundancy; if the disk fails, the data is gone.

Spanned volumes

The TheWindowsClub volume types documentation describes spanned volumes: combining free space from two or more disks into one logical volume. A spanned volume can have larger capacity than any single disk, but provides no redundancy or performance benefit. Data is filled into one disk first, then spills onto the next when the first is full. If any of the underlying disks fails, the entire spanned volume’s data is lost; this makes spanned volumes one of the riskier configurations and they’re rarely used in modern deployments.

Striped volumes (RAID 0)

Striped volumes interleave data across two or more disks for performance. Data is divided into stripes (typically 64 KB or 128 KB chunks) and written across all disks in parallel; reads and writes can use the combined throughput of all disks. Total capacity equals the sum of disk sizes (minus a small overhead). The TheWindowsClub documentation captures the trade-off: “Such volume types are not fault-tolerant. That means, if a disk that contains the strip data fails, then the entire striped volume is failed.” Striped volumes provide the best performance but the worst reliability; they’re appropriate for scratch space, render farms, and other high-throughput scenarios where data is reproducible.

Mirrored volumes (RAID 1)

Mirrored volumes store identical copies of data on two physical disks. The TheWindowsClub documentation describes the redundancy: “Even if one physical disk fails or corrupts, the mirrored data present on the second disk can be used by the system.” Usable capacity is half the total physical capacity; performance is similar to a single disk for writes and can be slightly better for reads (the system can read from either disk). Mirrored volumes provide the best protection against disk failure for critical data; the cost is the doubled storage requirement.

RAID 5 volumes (striped with parity)

RAID 5 volumes use striping with distributed parity across three or more disks. Data is striped like RAID 0 for performance, but each stripe set includes a parity block calculated from the data blocks; if any single disk fails, its contents can be reconstructed from the remaining data and parity blocks. The TheWindowsClub documentation captures the recovery property: “If a part of a hard disk fails and the data present in that portion is gone, then the same data can be re-created from the remaining data.” Usable capacity is (N-1) × disk size for N disks; RAID 5 represents a middle ground between mirroring (high redundancy, low capacity efficiency) and striping (high capacity efficiency, no redundancy).

Volume type comparison

Type	Min disks	Capacity efficiency	Redundancy	Performance
Simple	1	100%	None	Single disk
Spanned	2	100%	None	Single disk per spill
Striped (RAID 0)	2	100%	None	N × single disk
Mirrored (RAID 1)	2	50%	Survives 1 disk failure	1× write, 2× read potential
RAID 5	3	(N-1)/N	Survives 1 disk failure	Good read, slower write

Logical Volume Management (LVM) is a layer above traditional partitioning that abstracts physical disks into flexible storage pools. Linux uses LVM; Windows has the equivalent Storage Spaces feature.

The LVM hierarchy

The Red Hat LVM documentation describes the three-level abstraction: “Storage space is managed by combining or pooling the capacity of the available drives. With traditional storage, three 1 TB disks are handled individually. With LVM, those same three disks are considered to be 3 TB of aggregated storage capacity. This is accomplished by designating the storage disks as Physical Volumes (PV), or storage capacity useable by LVM. The PVs are then added to one or more Volume Groups (VGs). The VGs are carved into one or more Logical Volumes (LVs), which then are treated as traditional partitions.”⁵

• Physical Volume (PV): a disk or partition designated for use by LVM.
• Volume Group (VG): a pool of storage created from one or more PVs.
• Logical Volume (LV): a usable volume carved from a VG, formatted with a file system.

LVM advantages over traditional partitioning

LVM provides operational flexibility that traditional partitioning lacks:

• Online resize: volumes can grow without unmounting (most file systems) or shrink with appropriate procedures.
• Adding capacity: new physical disks can be added to a Volume Group, expanding the available pool.
• Snapshots: point-in-time copies of LVs for backup or testing.
• Migration: data can be moved between physical disks transparently to running applications.
• Striping and mirroring: LVM can implement RAID-like configurations at the volume management layer.
• Thin provisioning: volumes can be allocated more space than physically available, with actual blocks allocated on demand.

Storage Spaces (Windows)

Storage Spaces is Microsoft’s equivalent of LVM, introduced in Windows 8 and Windows Server 2012. The architecture is similar:

• Physical disks: raw disks added to a storage pool.
• Storage Pool: aggregated capacity from one or more physical disks.
• Storage Spaces (virtual disks): virtual disks carved from the pool with specified resiliency (Simple, Two-way Mirror, Three-way Mirror, Parity).
• Volumes: standard volumes formatted on the Storage Spaces.

Storage Spaces supports tiering (mixing SSDs and HDDs in the same pool with hot data on SSDs), cluster-level resilience, and integration with ReFS for additional features like integrity streams.

Recovery implications of LVM

LVM and Storage Spaces add complexity to recovery scenarios. The recovery work must consider:

• LVM metadata: the PV, VG, and LV definitions stored at known locations on the physical disks.
• File system within LV: standard file system recovery applies once the LV is identified.
• Multi-disk dependencies: if a Volume Group spans multiple disks, recovery requires all member disks (or rebuilding from backup PVs).
• Snapshot complications: LVM snapshots are stored as overlays on the original LV; recovery needs to handle both correctly.

When LVM helps

LVM is generally preferred over traditional partitioning for servers and workstations where storage requirements may evolve. Home users and dedicated single-purpose machines often don’t benefit from LVM’s flexibility. The trade-off is between flexibility (LVM wins) and simplicity (traditional partitioning wins); for most server deployments, the flexibility outweighs the complexity, but for typical desktop use, traditional partitioning is fine.

The volume is the basic unit of file system recovery. Recovery operations target volumes (not the underlying physical disks); when a volume becomes inaccessible, recovery work focuses on whatever level of the storage hierarchy is damaged.

Volume failure scenarios

Volumes can fail at multiple levels:

• Boot sector damage: the volume’s boot sector is corrupted, making the volume unrecognizable. The data is intact; only the entry point metadata is damaged.
• Partition table damage: MBR or GPT corruption removes the volume from the OS’s view despite the volume’s contents being intact.
• File system metadata damage: the MFT or inode tables are damaged; the volume is recognized but contents are partially or fully inaccessible.
• Cluster-level damage: bad sectors damaged specific clusters within the volume; affected files are unreadable but other files work.
• RAID member failure: for RAID volumes, the underlying disk(s) failed but the array can be rebuilt from parity or mirror.
• LVM metadata corruption: the LVM definitions are damaged; the underlying file systems may still be intact but unreachable through normal mounts.

Volume-level recovery tools

Different tools address different volume failure modes:

• TestDisk: partition table and boot sector recovery, GPT-aware.
• R-Studio, EaseUS Data Recovery: file system metadata recovery and file extraction.
• Linux mdadm + LVM tools: RAID array recovery and LVM metadata reconstruction.
• Windows Disk Management + diskpart: volume and partition manipulation.
• ddrescue / HDDSuperClone: sector-level imaging when physical damage is involved.
• PC-3000 (professional): firmware-level access for severe scenarios.

RAID volume recovery

RAID volume recovery has its own considerations:

• RAID 0 (striped): if any disk fails, recovery requires either the failed disk to be repaired or all stripes to be reassembled by professional services. Data loss is common.
• RAID 1 (mirrored): if one disk fails, the surviving disk can be read directly. The mirror provides a complete copy of the data.
• RAID 5: single-disk failure is recoverable from parity. Multi-disk failure usually means significant data loss; specialized tools can sometimes recover partial data.
• RAID 10 (1+0): can survive multiple disk failures depending on which disks fail. More resilient than RAID 5 to multi-disk failure.
• Hardware RAID controllers: add complexity because the controller’s metadata must be intact for the array to be recognized. Controller failure can make otherwise-healthy RAID drives appear damaged.

LVM recovery scenarios

LVM-specific recovery work involves understanding the LVM metadata layout. LVM stores its configuration in a header at the start of each PV plus optional backup copies. Recovery from corrupted LVM metadata involves:

1. Identifying which physical disks were members of the affected Volume Group.
2. Reading the LVM headers from each PV to find the most recent valid metadata.
3. If the primary metadata is damaged, falling back to /etc/lvm/backup config files (if available).
4. Rebuilding the LVM definitions and reactivating the Volume Group.
5. Mounting the Logical Volumes and recovering files normally.

The /etc/lvm/backup directory is a critical recovery resource for LVM systems; Linux automatically backs up LVM metadata there before each major change.

When to involve professionals

Volume recovery becomes professional-territory when:

• Multiple disks in a RAID array have failed.
• LVM metadata corruption affects multiple PVs.
• Encryption keys for full-disk-encrypted volumes are lost.
• Hardware RAID controller has failed and replacement controllers don’t recognize the array.
• Physical damage to multiple drives in a RAID array.
• Corruption affects both primary and backup metadata locations.

Professional services with PC-3000 SSD/HDD or equivalent tools can address scenarios that consumer software can’t reach. Cleanroom recovery applies when physical platter or NAND damage is involved; logical-only damage doesn’t require cleanroom.