📖 Chapter 04 — Capacity Planning

Predicting when you'll need more. The math, the signs, the timing.

Learning Objectives

• Forecast capacity needs from historical growth
• Recognize the signs that capacity is becoming constrained
• Decide between cleaning, expanding, and rebuilding
• Plan the upgrade to happen before the constraint bites

Introduction

Capacity isn't infinite. The pool fills up. The snapshots take more space. The drives age. The question is not "will it run out" but "when, and what do I do about it."

This chapter covers the discipline of capacity planning: forecasting growth, recognizing the signs, and acting before the constraint forces an emergency.

The capacity sources

For a NAS, the capacity sources that need to be planned:

• Pool capacity: the total size of the array. Grows when you add drives or replace with larger drives.
• Snapshot space: the space consumed by snapshots. Depends on data churn and retention policy.
• Performance: the throughput of the array. Affected by drive speed, RAID level, network.
• RAM: the memory for ARC (ZFS read cache) and applications.
• Network: the bandwidth for clients. Often the bottleneck for video editing or large file copies.

Each has different signs of strain and different solutions. This chapter focuses on pool capacity (the most common constraint) but mentions the others where relevant.

Forecasting growth

From historical data, you can forecast when the pool will fill up. The math:

1. Look at the pool's growth over the last 6-12 months. (TrueNAS shows a graph.)
2. Calculate the average growth per month.
3. Divide the free space by the growth rate. The result is the months until the pool is full.

Example: the pool is at 60% used (40% free = 17 TB on a 44 TB pool). Growth is 500 GB/month. The pool will be full in 34 months (about 3 years).

If 3 years is too soon, plan an upgrade. If 3 years is fine, set a calendar reminder for 2.5 years to start the upgrade process.

The signs of strain

For pool capacity:

• Used > 80%: ZFS performance starts to degrade above 80% used. The system feels slower.
• Used > 90%: performance is significantly degraded. Snapshots can fail to create.
• Used > 95%: the pool is in danger. The next scrub or resilver might not have enough space.

For performance:

• Disk I/O wait is high. The drives are the bottleneck. Tasks take longer than expected.
• Network throughput is saturated. Large file copies are limited by the network, not the disks.

For RAM:

• ARC is evicting frequently. The cache is too small for the working set.
• Applications are using swap. There's not enough RAM for the active workloads.

The options

When the pool is filling up, three options (in order):

1. Clean up. Delete what you don't need. Old snapshots. Forgotten files. Duplicates.
2. Reduce retention. Snapshots that are kept longer than necessary. Backups that have aged out of usefulness.
3. Add capacity. New drives, larger drives, a new vdev.

The principle: clean before you buy. The cost of an hour of cleanup is much less than the cost of new drives.

Cleanup patterns

Common sources of wasted space:

• Old snapshots. Snapshots accumulate. A monthly snapshot policy that's been running for 5 years has 60 snapshots. Many are no longer needed.
• Duplicate files. The same file in multiple places. A dedup tool (or just fdupes) can find them.
• Large forgotten files. The 50 GB backup of a laptop that's been replaced. The 20 GB video file from a project that's been deleted. The temporary download directory that has files from 3 years ago.
• App data. Old versions of Immich's library, the Paperless consume folder that's been processed, the Jellyfin cache that grew to 10 GB.

For TrueNAS, the dashboard shows where the space is going. Start with the largest directories, then the largest files. The 30 minutes of cleanup often finds 100+ GB to reclaim.

Reducing snapshot retention

From Volume 1, Chapter 9, the snapshot policy. As the data grows, the snapshot space grows. Reasonable reductions:

• Hourly retention: 48h → 24h (cuts snapshot space in half for hourly)
• Daily retention: 30 → 14 (cuts daily space in half)
• Monthly retention: 12 → 6 (cuts monthly space in half)

The trade-off: less recovery granularity. With hourly for 48h, you can recover to any hour in the last 2 days. With hourly for 24h, only the last day. For most family use, 24h is plenty.

Adding capacity

When cleanup isn't enough, add capacity. The options:

• Replace drives with larger ones. One at a time, let each resilver, repeat. The result is a larger pool.
• Add a new vdev. A full set of drives (e.g., 6 more drives in RAIDZ2). The new vdev adds capacity to the pool.
• Build a second pool. A separate pool with its own drives. Used when the workloads have different requirements (e.g., an SSD pool for VMs).

For most home labs, the right answer is "replace drives with larger ones" when the existing drives are aging anyway. The cost is the new drives; the benefit is more capacity and a refresh of the aging hardware.

The "can't add a 7th drive" gotcha

From Volume 1, Chapter 3: ZFS vdevs are fixed-size once created. You can't add a single drive to a RAIDZ2 vdev to make it 7-wide. The options are:

• Add a 7th drive as a single-drive stripe (a new vdev). This is a terrible idea — a single point of failure for the whole pool.
• Add a 7th, 8th, 9th, 10th, 11th, 12th drive as a new RAIDZ2 vdev. The right answer; adds 6 more drives' worth of capacity.

The conversation was clear: plan for capacity upfront. A 6-drive RAIDZ2 in 2026 with 12 TB drives gives 44 TB usable. If you think you'll need more, plan for 8 or 12 drives upfront, or plan for replacement with larger drives later.

The replacement cycle

Drives don't last forever. NAS drives typically last 5-7 years before failure rates increase. Plan the replacement cycle:

1. At year 3-4: order replacement drives (the same model, or the next generation).
2. At year 5-7: replace drives one at a time. Each replacement takes 12-24 hours (resilver).
3. After all replacements: the pool is at full capacity with new drives. Set the cycle reminder for another 5-7 years.

Reactive replacement (after a drive fails and the pool is degraded) is stressful. Proactive replacement is calm. The discipline: plan the replacement before drives fail.

The "should I go bigger" decision

When replacing drives, the question is: same size or bigger?

Same size: cheaper, simpler. The pool is the same capacity.

Bigger: more expensive, more future-proof. The pool grows by the percentage increase (12 TB → 20 TB is a 67% increase; the usable space grows from 44 TB to 80 TB on a 6-drive RAIDZ2).

For most home labs, the right answer is: go bigger. The marginal cost of the larger drives is small compared to the cost of another replacement cycle. A 20 TB drive in 2026 costs about 50% more than a 12 TB; the capacity is 67% more.

Forecasting performance needs

For performance (not capacity), the question is: will the workloads outgrow the hardware?

For most home labs, the answer is: no, not for years. A modern NAS with SSDs for the boot drive and HDDs for the data can handle 4K streaming, simultaneous family use, and a few VMs. The performance bottlenecks are usually the network (1 GbE is saturated by a single 4K stream) or the application (a slow algorithm in a Jupyter notebook).

The exception: heavy video editing or AI/ML. For these, the 10 GbE upgrade (Volume 3, Chapter 7) or a GPU server (Volume 4, Chapter 9) is the right answer.

Forecasting RAM needs

For RAM, the rule of thumb from Volume 1: 1 GB per TB of storage (for the ARC) plus 8-16 GB for the applications and VMs. For TK's 44 TB pool, that's 44 + 16 = 60 GB, rounded to 64 GB.

If you add many VMs (each takes 4-8 GB), the application RAM grows. If you add an SSD L2ARC (an SSD cache), the ARC pressure decreases, but the L2ARC uses some RAM for its metadata.

The plan: monitor the ARC hit rate. If it's below 90%, the ARC is too small. Either add RAM or add an L2ARC.

Engineering Note

Summary

Forecast growth from history. Recognize the signs (80%, 90%, 95%). Clean before you buy. Reduce retention if needed. Add capacity by replacing drives or adding a vdev. Plan the replacement cycle (5-7 years). Go bigger when replacing. The 30 minutes of planning quarterly is the price of never being surprised by capacity.

Checklist

• ⬜ Quarterly: check pool capacity and forecast the next 12 months
• ⬜ When used > 80%: clean up, reduce retention
• ⬜ When used > 90%: plan a capacity upgrade in the next 3 months
• ⬜ At year 3-4: order replacement drives
• ⬜ At year 5-7: replace drives one at a time, with larger drives if appropriate
• ⬜ Document the capacity plan in the runbook (Chapter 7)

Looking Ahead

Chapter 05 is disaster recovery. What to do when the worst happens: a pool dies, a drive fails catastrophically, a ransomware attack encrypts the data, the house burns down. The playbooks, the practice, the recovery. The chapter that turns "I have backups" into "I can recover."

Ch 04 · v0.1 · drafted from the original ChatGPT conversation, July 2026