📖 Chapter 07 — When to Upgrade

The signs, the math, the timing. How to know it's time to invest in more.

Learning Objectives

• Recognize the signs that the storage pyramid is straining
• Decide which upgrade to make first (capacity vs performance vs reliability)
• Plan the upgrade without disrupting the family
• Avoid the most common upgrade mistake (buying capacity you don't need)

Introduction

The NAS is built. The family uses it. The creator uses it. Years pass. At some point, something starts to feel constrained:

• The archive is filling up
• The network feels slow
• The apps are sluggish
• The drives are getting old

This chapter is about recognizing the signs, deciding which upgrade to make first, and doing it without disrupting the family system.

The four kinds of "needs more"

There are four kinds of constraints a NAS hits. Each has a different solution.

1. Capacity

The pool is filling up. Snapshots are eating space. The "used" column is above 80%.

Solution: add drives. Either expand the existing vdev (add drives to the RAIDZ2 array) or add a new vdev (a separate set of drives, joined to the pool).

2. Performance

The network is slow. Editing from the NAS lags. The apps are sluggish. The pool is healthy but the throughput is the bottleneck.

Solution: upgrade the network (1 GbE → 10 GbE), add an SSD cache (SLOG, L2ARC), or add a dedicated SSD pool for performance-sensitive data.

3. Reliability

The drives are aging. SMART errors are appearing. The pool has been resilvered once already.

Solution: replace drives proactively. Plan for a full drive replacement cycle every 5-7 years.

4. Capability

You want to do something the current setup can't do. Run a new app that needs more RAM. Add a VM. Add a second pool with different properties.

Solution: hardware upgrade (more RAM, faster CPU, additional storage controller, GPU for transcoding).

Sign 1: The pool is filling up

The most common constraint. ZFS works best when the pool is below 80% full; above that, performance degrades. Above 90%, you have a real problem.

Check: Storage → Manage Devices in TrueNAS. Look at "Used" vs "Size".

Solutions, in order of complexity:

1. Delete things you don't need. Old snapshots, large files you forgot about, duplicates. The conversation's first recommendation: clean before buying.
2. Reduce snapshot retention. If you have 5 years of yearly snapshots, you can probably drop the oldest. If you have hourly snapshots going back 48 hours, you can probably drop to 24 hours.
3. Move cold data to the external drive backup. The 3-2-1 rotation (Chapter 05) means the external drive is a recent copy of the archive. If the archive has stuff you don't need on the NAS, move it to the external drive only.
4. Add a new vdev. Buy 6 more drives, configure them as a second RAIDZ2 vdev, add to the pool. The new vdev adds capacity AND performance (writes are striped across vdevs).
5. Replace all drives with larger ones. Replace 6×12TB with 6×20TB, one at a time, each drive resilvers into the larger replacement. The result is a 6×20TB pool. This is the right answer when the existing drives are aging anyway.

The conversation was explicit: clean before buying. The first three options are free; the last two cost real money.

Sign 2: The network is slow

Symptoms: editing from the NAS stutters. Streaming 4K to multiple TVs buffers. The SMB share feels sluggish. The app web UIs load slowly.

The first thing to check: is the network actually the bottleneck, or is it the disks? TrueNAS shows per-disk and per-vdev throughput in the dashboard. If the disks are saturated, more network won't help.

Assuming the network is the bottleneck:

1. Check the cables. Cat 5e supports 1 GbE. Cat 6 supports 10 GbE. Older cables might be limiting.
2. Upgrade to 10 GbE. A 10 GbE NIC for the NAS is $50-100. A 10 GbE NIC for the laptop is $50-100. A 10 GbE switch is $100-300. The total is $200-500, but the throughput goes from 125 MB/s to 1.25 GB/s — a 10x improvement.
3. Add an SSD SLOG. A Separate Intent Log (SLOG) is a small SSD that accelerates synchronous writes. Useful for SMB, less so for editing.
4. Add an L2ARC. A Level 2 Adaptive Replacement Cache is a larger SSD that caches reads. Useful for repeated reads of the same data (like an NLE re-reading the same source clips).

For most home creators, the 10 GbE upgrade is the right first move. SLOG and L2ARC are advanced topics; only pursue them after 10 GbE is in place.

Sign 3: Drives are aging

SMART tests are showing errors. The pool has been resilvered. A drive is making new noises. The drives are 5+ years old.

HDDs have a typical service life of 5-7 years in NAS use. After that, failure rates increase. Plan the replacement:

1. Order replacement drives (same model or larger).
2. Replace one drive at a time. Let each replacement resilver before doing the next.
3. Keep the replaced drives as immediate backups (or destroy them if you're confident the new ones are good).

For a 6-drive RAIDZ2, replacing all 6 drives takes 1-2 weeks (because each resilver takes 12-24 hours). During the replacement, the pool is degraded but functional. The replacement can be done one drive at a time over weekends.

The conversation was clear: plan the replacement before drives fail. Reactive replacement (after a drive fails and the pool is degraded) is stressful and error-prone. Proactive replacement is calm.

Sign 4: You want to do something new

You want to run Plex instead of Jellyfin and it needs more RAM. You want to add a VM for development. You want hardware-accelerated transcoding for 4K HDR.

The conversation's recommendation for new capability: buy the next machine, don't replace this one.

Specifically:

• For more RAM: check if the current NAS's motherboard can take more. Many can go to 64 or 128 GB.
• For more CPU: usually, the answer is "wait for the next NAS build." CPUs in NAS are typically not upgradeable.
• For a GPU: add a low-profile GPU to the existing NAS. Most consumer GPUs work; check the case's physical constraints.
• For a VM: a second machine (an older desktop, a NUC, a used workstation) is the right answer. The NAS is for storage; the VM is for compute.

The "expand the vdev" trap

One trap to avoid: the idea that you can "just add a 7th drive to the 6-drive pool." You can't. ZFS vdevs are fixed-size once created. You can add a 7th drive as a new vdev (a 1-drive stripe), but that's a terrible idea — the 1-drive vdev has no redundancy, and losing that 1 drive takes the whole pool down.

To add capacity, you either:

• Replace all drives in the vdev with larger ones (one at a time), or
• Add a new vdev (a full set of drives, configured the same way as the original)

The conversation covered this in detail in Volume 1, Chapter 03. The principle: plan capacity for the lifetime of the NAS, not for the next year.

The cost of upgrading vs. building a second NAS

For TK's conversation: the question came up about whether to add a second NAS. The factors:

• Pro of second NAS: physical separation (one can fail without affecting the other); different performance characteristics (one HDD pool for archive, one SSD pool for performance); replication between them is a built-in backup.
• Con of second NAS: cost (a second machine, drives, network); power (a second machine running 24/7); complexity (more to maintain).

For most home creators, a second NAS is overkill until the archive exceeds 50-100 TB. The conversation's recommendation: expand the existing NAS first, build a second one when you have a real reason.

The upgrade plan

For a planned upgrade, the steps:

1. Identify the constraint (capacity, performance, reliability, capability).
2. Identify the minimum-viable upgrade that addresses it.
3. Verify the upgrade won't break anything. (Adding a 10 GbE NIC doesn't affect data. Adding a vdev increases the pool's capacity but doesn't change existing data.)
4. Order the parts.
5. Schedule the upgrade for a low-traffic time (a weekend, a holiday).
6. Do the upgrade.
7. Verify everything still works (pool is online, shares are accessible, apps are running).

For TK's build, the most likely first upgrade is either a drive replacement (5+ years in) or a 10 GbE NIC (for editing performance). Both are well-understood and low-risk.

When to do the next NAS build

The current NAS will reach end-of-life in 5-7 years for the hardware, longer for the data. At that point:

1. Build the new NAS.
2. Migrate the data. ZFS replication (send/receive) is the right tool. The new NAS receives the data from the old one.
3. Reconfigure the apps on the new NAS.
4. Update the family on the new connection details (the name might change, the IP might change).
5. Decommission the old NAS (or repurpose it as a backup target).

The conversation's principle: the data is permanent, the hardware is temporary. The 5-7 year cycle is the hardware's life. The data persists through multiple hardware generations.

Engineering Note

Summary

Four kinds of constraints: capacity, performance, reliability, capability. Each has a different upgrade path. The order is: clean before buying, plan before reacting, replace drives before they fail. For most home creators, expand the existing NAS first; build a second one when you have a real reason. The data is permanent; the hardware is temporary. Plan for the next build as part of this one.

Checklist

• ⬜ Check pool capacity monthly. Clean before adding drives.
• ⬜ Check network throughput when something feels slow. It might be the disks, not the network.
• ⬜ Set a calendar reminder for drive replacement (5 years after the build date).
• ⬜ Budget for the next upgrade. Save a small amount monthly; spend it on the upgrade when the time comes.

Volume 3 is complete

The pyramid, the archive, the scratch, the renders, the backups, the collaborators, the upgrade path. The creator's NAS is now a long-term tool, not a 3-year project. Volume 4 takes the next step: turning the NAS into a home lab. Docker, VMs, self-hosted services, the developer/admin's NAS.

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