Windows Server / Basic: platform and service foundations / Lesson 3

Storage layers, volumes, and filesystems

Separate physical storage, pools, virtual disks, partitions, volumes, and filesystems. Review capacity, resiliency, compatibility, and recoverability without touching a real disk.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Trace the storage stack and ownership boundaries.
Compare NTFS and ReFS under actual workload requirements.
Model thin-provisioning commitments and recovery limits.

A drive letter hides several layers

An application path can depend on physical disks, a storage controller or fabric, a pool, virtual-disk layout, partitioning, a volume, filesystem, mount path, and permissions. Identify which layer owns redundancy and which layer reports free space. Storage Spaces and other supported technologies have specific hardware and configuration requirements; a diagram is not proof that a proposed topology is supported. Never initialize, format, resize, or repair a real disk as part of reading this course. A destructive operation can target the wrong object when a display label is mistaken for a stable identity.

Choose filesystem behavior from the application contract

NTFS and ReFS offer different capability and compatibility sets that vary by Windows Server release and workload. Review features such as application support, integrity behavior, quotas, encryption requirements, backup integration, and virtualization use before selecting. Do not assume every NTFS feature exists in ReFS or that an integrity feature replaces backup. The synthetic decision model below records verification questions rather than selecting a universally superior filesystem. Edition, hardware, role, and storage configuration can affect what is available. Keep the exact Microsoft support matrix with a future implementation proposal, especially for shared or highly available storage.

json A synthetic filesystem requirements record

{
  "model": "filesystem-decision-only",
  "workload": "synthetic-file-and-VM-data",
  "candidates": [
    "NTFS",
    "ReFS"
  ],
  "verify": [
    "application-support",
    "backup-integration",
    "required-features",
    "release-and-edition",
    "storage-topology"
  ]
}

Expected output

filesystem selection remains conditional; no disk or volume is changed

The model is neither a formatting command nor evidence of support for a particular storage device or role.

Logical commitments can exceed available physical space

Thin provisioning can present logical capacity that is not fully allocated yet. In the invented example, physical capacity is five hundred units, logical commitments total seven hundred, and current allocation is two hundred fifty. There are two hundred fifty units physically unallocated under the simplified model, but simultaneous growth to the promises would exceed capacity by two hundred. This is not a Windows sizing formula: metadata, resiliency layout, reserves, snapshots, and other consumers are omitted. Capacity alerts must consider trends and commitments, not only the free space shown inside one guest or filesystem.

python Offline allocation and commitment arithmetic

physical = 500
logical_commitments = [400, 300]
allocated = 250
print(physical - allocated)
print(max(0, sum(logical_commitments) - physical))

Expected output

250
200

The units are synthetic and no storage inventory, pool, disk, volume, or performance counter is queried.

Redundancy and backup protect different failures

A resilient disk layout can tolerate specified component failures but may faithfully preserve accidental deletion, corruption, ransomware changes, or an application mistake. Backup needs independent retention, access, consistency, and restoration evidence. Replication is also not automatically historical recovery. Plan the failure domain: a second volume on the same failing storage may not provide independent protection. Review rebuild time, degraded performance, replacement procedure, and remaining capacity before calling a layout resilient. Encryption and key recovery introduce additional dependencies. A storage health indicator alone cannot prove the application’s files, metadata, or business invariants are correct.

Storage change needs identity, evidence, and recovery planning

Before an authorized storage change, identify the exact object, dependents, current protection, supported operation, outage requirements, and rollback limits. Moving a mount path or changing a filesystem can affect shares, services, backup jobs, and virtual machines. Preserve safe event and capacity evidence before proposing repair. Test restored synthetic data and application access in an isolated Windows environment when implementation is authorized. This course performs no disk, filesystem, pool, snapshot, repair, backup, or host operation. Its offline models support reasoning only and must never be described as successful Windows storage validation.

Common errors and fixes

ReFS is assumed to support every NTFS behavior

Why it happens: Filesystem names replace a capability review.
How to fix it: Check the exact release/workload feature requirements.
Prevent it next time: Record application and backup compatibility before choosing.

Guest free space is treated as physical headroom

Why it happens: Logical and physical allocation layers are conflated.
How to fix it: Review pool capacity, commitments, and all consumers.
Prevent it next time: Monitor growth and reserve requirements across layers.

A redundant layout is called a backup

Why it happens: Availability and recoverable history are conflated.
How to fix it: Design independent retention and tested restoration.
Prevent it next time: Include deletion, corruption, and key-loss scenarios.

Check your understanding

1. What do 250 free physical units and 700 logical commitments mean in the model?

Show worked solution

Current modeled allocation leaves 250 physical units, but promised growth exceeds the 500-unit physical total by 200. Neither value proves real usable capacity because layout, reserves, and other consumers are excluded. Review both present allocation and future commitments rather than relying on one guest’s free-space display.

2. Why does a healthy mirror not prove recoverability after deletion?