A VM that receives 500 GB of disk space does not necessarily require 500 GB of physical storage. Similarly, a 2 TB database may require much more usable capacity when copies, snapshots, logs, retention, and projected growth are considered. Understanding how to calculate storage capacity helps avoid two costly data center problems: purchasing an undersized solution or tying up budget in unused capacity.
Proper sizing does not start by adding up the space used by current files. It begins by identifying workloads, growth patterns, data protection technology, and the expected level of availability. In enterprise environments, capacity, performance, and resilience are interdependent decisions.
How to calculate storage capacity in practice
The initial calculation is simple: determine the volume of production data, apply the growth projection, and add operational requirements. However, the result must be converted from logical capacity to usable capacity and, finally, to raw disk capacity.
An initial formula can be presented as follows:
Required capacity = current data x projected growth + operational copies + technical reserve
Suppose an environment with 20 TB of production data and 25% annual growth. For a three-year horizon, a compound calculation is more appropriate than a fixed margin:
20 TB x 1.25³ = 39.06 TB
This is only the projected production volume at the end of the period. If the environment maintains a local copy for fast restoration, frequent snapshots, and a 20% operational reserve, the 39 TB may exceed 70 TB of required usable capacity. Raw capacity will depend on RAID, deduplication technology, compression, and the chosen layout.
Distinguish between raw, usable, and logical capacity
Raw capacity is the nominal sum of all installed disks. A shelf with twelve 12 TB disks provides 144 TB of raw capacity. This number does not represent the space available for applications.
Usable capacity is the space remaining after RAID protection or equivalent fault-tolerance schemes. In a RAID 6 group, for example, the equivalent of two disks' capacity is used for parity. With twelve 12 TB units, the simplified reference would be 10 x 12 TB, or 120 TB of usable capacity before other system reserves.
Logical capacity is the volume presented to hosts, virtualization clusters, or applications. Thin provisioning allows, for example, 100 TB of logical capacity to be presented even when the physical pool has less space. It is efficient, but requires strict monitoring: the initial savings do not eliminate the need for expansion before the pool reaches critical levels.
It is also advisable to standardize units. Disk manufacturers normally report TB in decimal base, while operating systems may display TiB in binary base. A 12 TB disk appears as close to 10.9 TiB. In projects with dozens of disks, this difference must be included in the calculation.
RAID changes the available capacity
RAID is not just a protection choice. It determines how much of the raw capacity will be converted into usable space and directly influences disk rebuild times, write performance, and array availability.
RAID 10 uses mirroring and data striping. In practice, about 50% of the raw capacity is available, but the arrangement tends to offer low latency and high performance for transactional databases, intensive virtualization, and workloads with many random writes.
RAID 5 consumes the equivalent of one disk for parity. It can make better use of capacity in smaller groups, but requires careful analysis on large-capacity disks, as rebuilding after a failure can be lengthy and create additional pressure on the array.
RAID 6 reserves the equivalent of two disks for parity and supports the simultaneous failure of two units in the same group. It is a recurring choice when the goal is to balance capacity and protection in pools with higher-capacity SAS or NL-SAS HDDs. The cost is higher write overhead and lower usable capacity compared to RAID 5.
In enterprise storage, mechanisms may vary by manufacturer and platform. Some arrays use distributed protection, erasure coding, or dynamic pools without the classic structure of fixed RAID groups. The rule remains: use the actual efficiency reported for the intended model and configuration, not a generic estimate.
Include snapshots, copies, and retention in the calculation
Snapshots do not necessarily occupy the full size of the volume at the time of creation. They record blocks changed after the restore point. Even so, in environments with a high rate of change, their consumption can grow rapidly.
A 2 TB VM with a daily snapshot and seven-day retention does not automatically require an additional 14 TB. If 10% of the blocks change per day, the initial reference would be an additional 1.4 TB. But this rate changes according to the workload profile: file servers, databases, email repositories, and development environments exhibit very different behaviors.
The same applies to local copies. If the policy requires an internal replica or clones for testing, size each purpose separately. Deduplication and compression can reduce consumption, especially in VDI, similar virtual machines, and systems with repetitive data. On the other hand, encrypted data, media files, and already compressed backups usually generate little to no reduction. Do not use optimistic reduction rates as a capacity guarantee.
Capacity without IOPS can be a design error
Two arrays with the same usable capacity can serve completely different scenarios. A set of high-capacity nearline disks is suitable for retention, files, and data with less frequent access. A virtualization cluster with hundreds of VMs may need SAS SSDs, NVMe SSDs, or hybrid tiers, even if the total volume is relatively small.
When calculating storage, associate the volume with performance metrics: read and write IOPS, average block size, acceptable latency, throughput, and random or sequential access patterns. An OLTP database, for example, usually prioritizes low latency and consistent writes. A video repository depends more on sequential throughput.
The architecture also changes the result. In a Fibre Channel or iSCSI SAN, evaluate the available ports, link speed, HBAs, switches, and path redundancy. For NAS, consider protocols, the number of users, concurrency, and file behavior. It is no use calculating the TB correctly if the controller, network, or disk layer becomes the bottleneck.
Define a realistic operational margin
Storage should not operate near 100% occupancy. Excessively full pools can suffer performance degradation, limitations for snapshots, and difficulty redistributing data during a unit replacement or expansion.
The recommended margin depends on the platform and workload, but reserving between 15% and 30% of the usable capacity is usually a prudent reference. All-flash arrays with internal garbage collection, wear leveling, and data protection mechanisms may require an even more conservative range, according to the manufacturer's guidance.
Also plan expansion in coherent blocks. A storage system may accept additional disks, expansion shelves, or extra nodes, but each path has compatibility rules, minimum disk quantities, firmware versions, and controller limits. Mixing SSDs, SAS, and SATA without observing the approved pools can compromise predictability and manufacturer support.
Sizing example for virtualization
Consider a company with 80 VMs that currently occupy 18 TB, a projected annual growth of 20%, and a three-year plan. The projected production volume will be approximately 31.1 TB.
The company maintains snapshots with an estimated consumption of 15% of the production volume, which adds 4.7 TB. There are also 6 TB for testing clones and an operational margin of 25% on the subtotal. The usable need is close to 52 TB:
31.1 TB + 4.7 TB + 6 TB = 41.8 TB
41.8 TB x 1.25 = 52.25 TB usable
If the solution uses RAID 6 with groups of ten 12 TB disks, each group delivers approximately 96 TB of usable capacity in the simplified calculation, as eight disks are available for data. There is enough capacity, but this is not the final decision. It is necessary to check if this composition delivers the IOPS required by the 80 VMs. If it does not deliver, it may be necessary to use more smaller disks, SSDs, or a hybrid architecture, even if the total capacity seems excessive.
Information that should be included in the quote
A consistent technical quote must state the current volume, expected growth, planning period, application type, IOPS and latency requirements, snapshot retention, copy policy, access protocol, and expansion need. It is also relevant to state whether the environment uses VMware, Hyper-V, Windows Server, Linux, databases, or proprietary applications, as these variables define the read and write profile.
With this data, it is possible to compare options with SAS, SATA, SSD, and NVMe disks, as well as controllers, HBAs, and Fibre Channel or Ethernet connectivity. I.T. Computers supports enterprise infrastructure quotes with configurations aligned with HPE ProLiant, Dell PowerEdge, and Lenovo ThinkSystem servers, storage systems, and compatible components.
The best sizing is not the one that delivers the most terabytes in the proposal. It is the one that maintains available space, predictable performance, and a clear path for expansion so that the storage keeps pace with the business without turning every new project into an emergency.