Capacity explained
A new 32TB drive will not normally appear as “32.00 TiB” inside an operating system or recorder. The difference starts with decimal terabytes versus binary tebibytes and can grow slightly after partitions, filesystems and recorder reserves are applied.
Quick answer
32TB of manufacturer capacity equals about 29.10TiB before filesystem overhead. That is a unit-conversion difference, not evidence that the drive has lost nearly 3TB.
Exact models in this guide
Seagate SkyHawk AI
ST32000VE000AI-enabled NVR and edge video analytics
Interactive planner
32TB usable-capacity calculator
TB and TiB use different units
Drive makers define one terabyte as 1,000,000,000,000 bytes. Many operating systems calculate storage in powers of two, where one tebibyte equals 1,099,511,627,776 bytes.
Dividing the same 32 trillion bytes by the larger TiB unit produces a number around 29.10.
You can verify the conversion yourself by dividing the manufacturer byte count by 1,099,511,627,776. That simple calculation is more useful than memorizing a percentage because it works for 24TB, 26TB, 32TB and future capacities. It also makes clear that no physical sectors disappeared; only the reporting unit changed.
Why the label still says 32TB
The drive is sold using the decimal storage convention used across HDD and SSD marketing. That convention is consistent across capacities, so the difference becomes more visually obvious as drives get larger.
Nothing needs to be repaired simply because the operating system shows a lower binary number.
The decimal convention is not unique to Seagate. It is the standard way storage manufacturers state drive capacity, which allows different brands and models to be compared consistently on the package. Confusion arises because operating-system interfaces historically use binary calculations while sometimes displaying labels that look like decimal units.
Formatting takes additional space
Partition tables, filesystems and recorder databases require their own space. The visible usable capacity can therefore be slightly below the raw binary conversion.
Different recorders can report different final numbers because they reserve storage differently.
Filesystem overhead is usually much smaller than the roughly 9-percent decimal-to-binary display difference. If the system reports far below the expected binary value, look beyond formatting. Check partitions, controller limits, RAID configuration, reserved space and whether the host has recognized the full physical drive.
Recorder reserve is intentional
Surveillance appliances may hold back capacity for indexes, metadata, event databases, thumbnails and healthy overwrite behavior. This reserve protects system operation.
A user-visible recording pool therefore may not equal the maximum block capacity of the disk.
Recorder-reserved space may not be presented as a separate partition. The appliance can simply expose a smaller recording pool. That is why two recorders can show different usable numbers from the same drive. Use the recorder’s own storage documentation when a precise final value matters for a retention guarantee.
RAID changes the number again
If several 32TB drives are combined with RAID, usable capacity is reduced by parity or mirroring. Four 32TB drives in RAID 6 do not provide 128TB of usable protected storage.
Use the RAID calculator on the dedicated guide before ordering the final drive count.
RAID math should be performed before decimal-to-binary display conversion or consistently in bytes. For example, parity can remove one or two whole drive-equivalents from raw capacity. Converting only after that step prevents accidental double counting and makes the relationship between raw, protected and formatted capacity easier to explain.
Do not confuse TB loss with a bad drive
A decimal-to-binary display difference is predictable and consistent. A failing drive is diagnosed with SMART/health information, errors and manufacturer diagnostics, not by expecting the OS to display exactly 32TiB.
If the system shows dramatically less than the expected conversion, then investigate partitioning, controller limits and recorder compatibility.
A healthy capacity check compares the recognized model, total bytes and expected logical volume. Do not use a single UI label as the only diagnostic. SeaTools, the recorder storage page and the operating system can describe the same device with different unit labels while agreeing on the underlying byte count.
Large-volume addressing matters
A host must support modern partitioning and sufficiently large logical block addressing. Very old systems can show truncated volumes when they do not understand large disks.
This is one reason 32TB compatibility should be verified at the recorder model and firmware level.
Large-volume addressing problems often reveal themselves as suspicious round limits such as 2TB. That pattern is fundamentally different from seeing about 29.1TiB from a 32TB disk. If the number is truncated to an old addressing boundary, investigate firmware, controller and partition style before assuming the disk is faulty.
Capacity after snapshots or filesystem features
General-purpose servers may consume extra space for copy-on-write metadata, snapshots, checksums or reserved blocks. Surveillance appliances have their own overhead patterns.
Treat 29.10TiB as a raw conversion starting point, not a promise of final filesystem free space.
Snapshot and copy-on-write systems can reserve or consume capacity dynamically, so “free space” may change even without new video files. Surveillance appliances tend to hide those implementation details, while general servers expose them. Capacity planning should use the storage pool available to the recording application, not a generic raw-disk figure.
Why Windows and Linux may look different
Some tools label binary values as TB even when they are calculating TiB, while others use the units more precisely. The number can therefore appear inconsistent even when the byte count is identical.
When comparing systems, check the actual bytes or understand the unit each interface uses.
Unit labels can be inconsistent across tools, so compare values in bytes when troubleshooting. A tool that says 29.1 “TB” may actually be reporting binary TiB under a familiar label. The difference is semantic, not physical. Recording software ultimately allocates blocks, not marketing-unit labels.
Planning retention from usable capacity
Use the capacity actually available to recordings after reserve rather than multiplying from the package label. The recording-time calculator accepts a reserve percentage for this reason.
This produces a safer retention estimate for real deployments.
For retention planning, take the recorder-visible usable capacity after reserve and filesystem setup. This is the number that should feed the recording-time formula. Using 32TB directly will slightly overstate how much footage can be retained because it ignores both binary display and operational reserve.
Checking a suspiciously small volume
If a 32TB drive appears as 2TB, 4TB or another obviously truncated size, do not treat that as normal TB-versus-TiB conversion. Check controller firmware, partition style, enclosure limits and recorder support.
A host compatibility problem can look like missing capacity.
A severely undersized volume deserves immediate investigation before recording begins. Repartitioning a populated recorder can destroy footage, so validate full capacity during commissioning. Confirm that the host sees the intended drive size, creates a modern large volume and can write/read across it before relying on the system for evidence.
Practical takeaway
Expect about 29.10TiB before filesystem overhead from a 32TB decimal drive. Then subtract the capacity the recorder or filesystem reserves.
Use the calculator below to convert any marketed TB value and apply your own reserve percentage.
Keep the distinction simple in documentation: 32TB is the manufacturer decimal capacity; about 29.10TiB is the binary equivalent before overhead; the recorder-visible pool can be smaller again. Stating all three layers prevents future technicians from treating a normal unit conversion as a drive defect.
Current exact-model offers
Live buying options for the models above
Only listings containing the exact model number can appear. Generic capacity-only matches, accessories, systems and mixed-model listings are excluded.
Current manufacturer references
Exact models, warranty terms and product specifications can change. These links are included so you can verify the current manufacturer record before purchase or deployment.
Questions people ask
Frequently asked questions
How many TiB is 32TB?
About 29.10TiB before filesystem overhead.
Is the missing capacity defective?
No. Most of the difference is decimal TB versus binary TiB.
Why does my recorder show less than 29.1TiB?
Formatting, metadata and reserved operating space can reduce the available recording pool.
Does RAID reduce usable capacity?
Yes. Mirroring and parity consume raw drive capacity.
Why would a 32TB drive show only 2TB?
That is not normal unit conversion; investigate host, controller, partition and firmware limits.
Does Windows use TiB?
Many Windows interfaces calculate binary capacity but may label it using TB-style wording.
Does formatting destroy several terabytes?
No. Most of the apparent drop is unit conversion; formatting adds a smaller overhead.
Should retention calculations use 32TB or 29.1TiB?
Use actual bytes or the post-reserve usable recording capacity for the most realistic estimate.
Can I recover the decimal/binary difference?
No. It is not lost space; it is the same bytes expressed in different units.
Is 32TB still 32 trillion bytes?
Yes, manufacturer decimal capacity is approximately 32 trillion bytes.