TrueNAS Sizing Guide: how much storage do I really need?

One of the first questions in every TrueNAS engagement is also the most misunderstood: “How much storage do we need?” And almost every time the answer is unrealistic. Either the current data volume is simply doubled — or a wish figure lands on the table that ignores snapshots, growth and RAID overhead. Both paths lead into the same dead end: the system either fills up after 18 months or was bought far larger than the real workload requires.

This sizing guide shows how to calculate honestly: from the usable baseline to the raw capacity, with every factor in between. No marketing numbers, no wishful thinking, no fixed price tables — hardware prices swing too much for reliable figures in a blog post.

Why the naive “we have 20 TB, we need 40 TB” formula does not work

The classic rule of thumb “current data times two” ignores four things that matter decisively on a ZFS-based system:

• Snapshots consume space — sometimes considerably, depending on change rate and retention.
• Compression saves space — sometimes considerably, but not guaranteed and not on every data type.
• Growth is not linear but cumulative. 25 percent per year is more than triple after five years.
• RAID overhead is not a feature, it is a math term. Depending on layout, between ten and over forty percent of raw capacity go to redundancy.

Separate these four factors and calculate them individually, and you arrive at a defensible target. Mix them together or ignore them, and you either undersize or seriously oversize the system.

Step 1: capture the usable baseline properly

The starting point is always the real, currently used data volume — not the capacity of the existing system, but what is actually occupied. And broken down by category:

• Active user data — file shares, databases, VM images, project data
• Backup data — snapshots, PBS targets, replication receivers
• Archive data — old projects, regulatory retention, cold volumes

This separation matters because the shares behave very differently. Active data grows linearly with the business. Backup data grows with retention and change rate. Archive data grows in jumps when projects close.

In practice this means: a data scan on the existing NAS or file server, split by these categories, plus a conversation with the departments about running and planned projects. Only then does an honest baseline emerge.

Step 2: estimate the snapshot overhead correctly

Snapshots are the killer feature of ZFS — and the most consistently underestimated space consumer. A snapshot initially uses little space but grows with every change to the referenced blocks. Run a 30-day retention on file server data and you quickly hit a double-digit percentage of extra consumption.

Realistic reference ranges from real projects:

• File server with office data — 10 to 25 percent overhead at 30 days retention
• VM storage with high change rate — 30 to 60 percent overhead at 14 days retention
• Databases with frequent writes — 40 to 80 percent overhead at 7 days retention
• Archive datasets — below 5 percent overhead due to minimal change

These are not laws of nature — the numbers depend on the actual change rate. If you want certainty, measure a week on an existing system and extrapolate. For sizing purposes these ranges work as a conservative assumption. We go into detail in our post on TrueNAS snapshot schedule best practices.

Step 3: apply an honest compression range

ZFS compression — usually LZ4 or ZSTD — is lossless and very fast. It saves significant space on many data types, almost none on others. Honest reference values:

• Text data, office documents, logs, databases — factor 1.5 to 2.5
• VM images with typical OS installs — factor 1.3 to 2.0
• Already compressed media — JPEG, MP4, ZIP, encrypted data — factor 1.0 to 1.05
• Mixed file server datasets — factor 1.4 to 1.8

Important: use compression as a buffer in the sizing calculation, not as a fixed number. Internally we plan conservatively with a factor of 1.4 for mixed environments — anything above is bonus. When entering an expected factor in the configurator, err on the low side. More technical background sits in ZFS compression: efficiency and performance.

Step 4: model growth realistically — 20 to 40 percent per year

The point that generates the most pushback in sizing discussions: data growth. Customers almost always underestimate their own growth. Studies and our own observation across years show: 20 to 40 percent per year is a realistic range for typical midmarket IT.

Example: at 30 percent growth per year, 10 TB of usable data today becomes not 25 TB in five years, but 37 TB. After seven years it is 62 TB. Compounding is merciless.

Practical consequence for sizing:

• Three-year horizon — multiplier 1.7 to 2.7 on the usable baseline
• Five-year horizon — multiplier 2.5 to 5.4
• Seven-year horizon — multiplier 3.6 to 10.5

Anyone buying a TrueNAS appliance with a five-year write-off must plan on at least the lower five-year multiplier. Anything less leads to premature expansion, which in the enterprise segment is almost always more expensive than a generous first design. Why this hits particularly hard on TrueNAS is discussed in TrueNAS for SMB.

Step 5: include RAID overhead and pool layout

The final step from net demand to raw capacity is RAID overhead. On ZFS this is not classic RAID but RAID-Z1, RAID-Z2, RAID-Z3 or mirrors — with markedly different effects on usable capacity and fault tolerance.

Rough overhead ranges for typical layouts:

• RAID-Z1 with 5 disks — around 20 percent overhead, suitable for non-critical workloads
• RAID-Z2 with 6 disks — around 33 percent overhead, standard for business storage
• RAID-Z2 with 8 disks — around 25 percent overhead, a good compromise
• RAID-Z3 with 8 disks — around 37 percent overhead, enterprise archive
• Mirror layout — 50 percent overhead, highest IOPS for VM storage

Important: RAID-Z1 on large HDDs is no longer state of the art. As soon as a disk fails and resilvering starts, the entire array is exposed to a second failure — and rebuild times on 12-terabyte disks are in the double-digit hours. For business storage, RAID-Z2 is the new baseline. Layout decisions are covered in RAID vs ZFS: why classic RAID still exists.

Additionally: ZFS reserves about 20 percent of the pool for performance and headroom. Run a pool over 80 percent utilisation and write performance drops noticeably. This slack belongs in the sizing calculation, not as reserve but as operational requirement.

Worked example: from 5 TB of usable data to raw design

Take a realistic SMB scenario: a law firm with 5 TB of active user data today, file server characteristic, moderate change rate, statutory retention obligations.

Baseline: 5 TB active user data Growth over five years (25 percent p.a.): factor 3.05 — yields 15.3 TB Snapshot overhead (20 percent): yields 18.3 TB Compression factor (1.5): reduces to 12.2 TB net pool demand RAID-Z2 overhead (33 percent): yields 18.3 TB raw capacity 80 percent slack (pool headroom): yields 22.9 TB raw capacity as target

The naive “5 TB times two” calculation would have given 10 TB — the realistic calculation lands at around 23 TB. That is the difference between a system full after two years and one that lasts the planned write-off period without expansion.

Where our configurator takes over the calculation

Exactly this calculation — baseline, snapshot, compression, growth, RAID — is embedded in the TrueNAS configurator. You enter your current usable data, your workload profile, a target horizon and an expected growth factor. The configurator computes the raw capacity and proposes a suitable TrueNAS model class — from the F-Series compact system through H-Series hybrid to M-Series with M30 or M40 for larger environments.

What the configurator deliberately does not do: reinforce wishful thinking. Enter 5 TB of usable data and configure a 200 TB raw system, and you get a warning. Oversizing costs money that belongs in a proper backup strategy or in HA. Obvious undersizing also triggers a warning.

You will not find fixed price tables in the configurator either — actual hardware prices swing too much to publish reliably. For firm numbers, configurations flow through our consulting as an individual quote. To place the system classes in context beforehand, Home Lab vs Enterprise TrueNAS provides the frame.

When sizing goes wrong — four typical mistakes from the field

Across dozens of projects we see four recurring sizing mistakes:

1. Growth treated as linear — 25 percent per year over five years is triple, not plus 125 percent.
2. Compression set too high — factor 3 on mixed datasets is wishful thinking, 1.4 to 1.8 is realistic.
3. Snapshots misunderstood as backup — retention set generously but overhead calculated small. Both must fit.
4. RAID-Z1 on large disks — looks cheap on the surface, is a risk at current HDD capacities.

If you are in the middle of a sizing process: check these four points before the purchase order goes out. Retroactive corrections are expensive.

Bottom line: honest math instead of gut feeling

TrueNAS sizing is not black magic, but it is not simple multiplication either. Separate baseline, snapshot overhead, compression range, growth rate and RAID overhead cleanly and calculate them individually, and you arrive at a defensible target — avoiding the two most expensive mistakes: expansion after 18 months or oversizing by a factor of three.

The TrueNAS configurator takes over the math and delivers a system class recommendation with realistic capacity planning. For individual advice we are available as a Gold-certified iXsystems partner in Bavaria and across Germany — through our IT service or directly through the configurator request.

FAQ

How precise does my usable baseline need to be?

For sizing purposes, +/- 10 percent is sufficient. More important than the exact number is the clean split by active data, backup and archive — these three categories grow at different rates.

How high is the snapshot overhead on VM storage really?

On VM storage with a high change rate, 30 to 60 percent overhead at a two-week retention is realistic. If you want certainty, measure a test dataset for a week and extrapolate. Internally we plan conservatively with the upper end.

Is compression on ZFS always worthwhile?

Yes. LZ4 is enabled by default and practically free — even when savings are minimal. ZSTD saves more but costs CPU. On already compressed media — JPEG, MP4, ZIP — compression brings almost nothing but does no harm. For sizing, set compression conservatively.

Why no more RAID-Z1 on large HDDs?

Because resilvering after a disk failure on 12- or 16-terabyte drives takes many hours to days — and during that window a second failure loses the entire array. RAID-Z2 provides a second redundancy level and is baseline for business storage today. Detail in the RAID vs ZFS post.

What happens when a ZFS pool gets too full?

Above roughly 80 percent utilisation, write performance drops noticeably because ZFS needs space for metadata and copy-on-write. Above 90 percent it becomes critical. The 20 percent slack belongs firmly in sizing — it is not reserve, it is operational requirement.

Which TrueNAS model class fits my sizing result?

As a rough guide: under 20 TB raw fits F-Series or small H-Series, 20 to 100 TB is the core range of H-Series and M30, above that the M40 is the typical choice. Large archives lean towards the X-Series. The configurator makes the mapping automatically and also accounts for network and HA requirements.