Guide

NAS Capacity Planning Checklist

Updated 2026-09-02

Calculate the usable NAS capacity you actually need after RAID, filesystem overhead, snapshots, and free-space headroom. This checklist also covers growth, backups, drives, networking, Plex, and surveillance.

The short answer: size for usable capacity, not raw drive capacity

Your NAS needs enough usable capacity for:

Current data
Expected growth
Filesystem and RAID overhead
Snapshots and recycle-bin retention
A deliberate amount of free space
Temporary workloads such as Plex transcoding or surveillance recording

A simple planning formula is:

Required usable capacity = (Current data × (1 + growth allowance)) / (1 - free-space target)

This gives you the usable capacity required inside the NAS before accounting for a separate backup system.

For most planning exercises, do not treat every advertised terabyte as available storage. Start with raw drive capacity, subtract RAID or parity capacity, allow for filesystem overhead, and keep free space available for normal operation and future changes.

The five capacity numbers to keep separate

1. Raw capacity

Raw capacity is the sum of the advertised capacities of all installed drives.

Raw capacity = Number of drives × Drive capacity

For example, six 12 TB drives provide:

6 × 12 TB = 72 TB raw capacity

Drive manufacturers normally advertise decimal terabytes. Operating systems may display capacity using tebibytes, or may label binary values as TB. This can make the displayed number look smaller even before RAID or filesystem overhead is considered.

2. RAID or parity capacity

RAID uses some capacity for mirroring or parity. The amount depends on the layout:

RAID 1 or a two-drive mirror: roughly one drive's capacity is usable, before overhead.
RAID 10: roughly half of the raw capacity is usable, before overhead.
RAID 5: roughly one drive's capacity is used for parity.
RAID 6: roughly two drives' capacity is used for parity.
RAID-Z: usable capacity depends on the number of disks, vdev layout, record settings, and implementation. Do not assume it behaves exactly like every conventional RAID calculator.
Single-disk or JBOD layouts: may expose more raw capacity, but they do not provide the same redundancy as mirrored or parity layouts.

A simplified parity estimate is:

RAID 5 nominal capacity ≈ (Number of drives - 1) × Smallest drive capacity

RAID 6 nominal capacity ≈ (Number of drives - 2) × Smallest drive capacity

These are planning estimates, not guarantees of the final space shown by the NAS. Mixed drive sizes, storage-pool rules, hot spares, and the NAS operating system can change the result.

RAID improves availability after a drive failure. It is not a backup and does not protect against accidental deletion, ransomware, theft, fire, or a damaged NAS.

3. Filesystem and storage-pool overhead

The filesystem and storage-pool manager consume some space for metadata and internal structures. The exact amount varies by platform, filesystem, pool layout, block or record settings, deduplication, compression, and snapshot implementation.

Treat the capacity shown by a vendor's calculator as an estimate unless it explicitly describes the configuration you will use. Leave additional room rather than planning to fill the pool to its displayed maximum.

4. Snapshots, recycle bins, and version history

Snapshots are space-efficient when files do not change, but changed blocks must be retained while older snapshots still reference them. Snapshot consumption therefore depends on:

How often snapshots are taken
How long they are retained
How frequently files change
Whether large files are rewritten
Whether a recycle bin or version history is also enabled

A NAS with frequent snapshots and a long retention period needs more headroom than a NAS used only for current files. Capacity planning should include a snapshot reserve instead of assuming snapshots are free.

5. Free-space headroom

Free space is not wasted capacity. It provides room for:

Filesystem housekeeping
Snapshots and metadata
Large file transfers
Temporary files
Pool balancing or reshaping
Drive replacement and RAID rebuild operations
Future growth before the next expansion

Choose a free-space target based on your filesystem, workload, snapshot policy, and vendor guidance. If you do not have a tested target, use a conservative planning allowance rather than designing for a nearly full pool.

Worked capacity-planning example

Assume the following requirements:

Current data: 18 TB
Expected growth over the planning period: 30%
Desired free-space headroom: 20%
Two-drive parity protection
Snapshots required
Backups stored on a separate system

First, estimate the data after growth:

18 TB × 1.30 = 23.4 TB

Next, account for the desired 20% free space:

23.4 TB / (1 - 0.20) = 29.25 TB

The NAS therefore needs approximately 29.25 TB of usable space before filesystem-specific overhead and snapshot consumption. Because the result is close to the limit, the practical target should be higher.

Consider a pool of five 12 TB drives using a two-drive parity layout:

5 × 12 TB = 60 TB raw capacity

Simplified nominal capacity:

(5 - 2) × 12 TB = 36 TB

That 36 TB is not the final space available to users. Filesystem overhead, snapshots, display-unit differences, and any reserved capacity must still be considered. Even so, this configuration provides more planning margin than a four-drive, two-parity pool:

(4 - 2) × 12 TB = 24 TB nominal capacity

The four-drive example would not meet a 29.25 TB target. The five-drive example may meet it, but confirm the NAS's actual calculator and leave room for snapshots and operational headroom.

If the 18 TB figure includes only primary data and excludes backup copies, do not assume the NAS also has enough space to hold a local backup. Backup capacity must be planned separately.

Account for growth before choosing the drive count

Estimate growth by category instead of applying one optimistic percentage to everything:

Data category	Current size	Growth pattern to consider
Documents and projects	Measure it	New users, projects, and retained versions
Photos and video	Measure it	Cameras, resolutions, and import frequency
Media library	Measure it	New purchases, remuxes, and duplicate formats
Surveillance recordings	Calculate it	Camera count, bitrate, motion, and retention
Backups	Calculate it separately	Number of devices, versions, and retention
Snapshots	Reserve capacity	Change rate and retention duration

A useful planning period is the time until you expect to add drives, replace the NAS, or change the storage layout. Choose the period based on your budget and expansion options rather than assuming an upgrade will always be easy.

Also check whether the selected NAS can expand the pool you intend to create. Expansion may require adding drives in a particular number, replacing every drive with a larger model, creating a new pool, or migrating data. Do not buy a small initial array based only on the claim that it can be expanded later.

Plan backups as a separate capacity problem

RAID is redundancy, not backup.

A practical backup plan should account for:

The data that must be recoverable
How many historical versions are retained
Whether the backup is on another NAS, external drives, or cloud storage
Whether the backup location is physically separate
How often backups run
Whether backups are encrypted and tested
How much additional space is needed as the primary dataset grows

A second NAS used for backup needs enough usable capacity for its own backup policy, not merely the current size of the primary NAS. Versioned backups can require substantially more capacity than a single mirror copy.

External USB drives can be useful for rotating offline copies. Cloud backup can provide geographic separation, but upload time, restore time, provider limits, and recurring costs should be checked before relying on it.

Test a restore. A backup that has never been restored is an assumption, not a verified recovery plan.

Include snapshots without confusing them with backups

Snapshots are valuable for recovering from accidental edits, deleted files, and some ransomware incidents. They remain on the same storage system, however, so they do not replace an independent backup.

When sizing for snapshots:

Identify which shares or datasets need protection.
Choose hourly, daily, or other snapshot intervals.
Set retention rules for recent and older snapshots.
Estimate how much data changes during the retention period.
Set alerts before the pool becomes full.
Include snapshot use in the free-space target.

Snapshots may also affect replication and backup capacity. If you replicate snapshots to another system, plan capacity on both systems.

Check Plex and other media workloads

For Plex or another media server, separate these storage needs:

Original media files
Alternate versions and remuxes
Metadata and artwork
Download or staging folders
Temporary transcoding space
Backups of the media database and configuration

Transcoding space is usually temporary, but it still needs room during concurrent sessions. The required amount depends on the source files, output settings, number of simultaneous sessions, and whether transcoding uses the NAS's CPU, GPU, or another device. Do not size the main storage pool solely from the media library's current size.

If Plex will run on the NAS, check CPU, memory, hardware-transcoding support, and application compatibility separately from capacity. A large array does not guarantee smooth transcoding.

Check surveillance retention mathematically

Surveillance storage depends on camera bitrate and retention, not just camera count.

A rough estimate is:

Daily storage = Total bitrate (Mbps) × 86,400 seconds / 8 / 1,000,000

This produces an approximate decimal terabyte calculation when the result is extended over the required number of days. A simpler practical approach is to use the camera or surveillance software's storage calculator, then add headroom.

Retention also changes with:

Continuous recording versus motion recording
Resolution and frame rate
Codec and bitrate
Number of cameras
Audio recording
Event clips and protected recordings
Whether recordings are duplicated or backed up

Surveillance workloads can write continuously and may benefit from drives and storage layouts intended for that workload. Confirm the NAS's supported camera count and licensing separately; capacity alone does not determine compatibility.

Decide whether SSD cache belongs in the plan

SSD cache is not a substitute for more hard-drive capacity. It may help particular workloads, but benefits depend on the access pattern, cache policy, working-set size, and NAS implementation.

Before budgeting for cache, ask:

Is the workload random and frequently reused?
Is the bottleneck storage latency, network speed, CPU, or application behavior?
Does the NAS require one SSD, a mirrored cache, or a particular SSD type?
What happens if a cache SSD fails?
Does the cache consume bays needed for future hard drives?
Will the cache improve the specific applications you use?

For a home media library dominated by sequential reads, adding hard-drive capacity or improving the network may matter more than cache. For databases, virtual machines, containers, or metadata-heavy applications, SSD storage may be more appropriate than a cache layered over a hard-drive pool.

Do not assume SSD cache is safe for write operations unless the NAS documentation explains the protection and failure behavior.

Consider networking and expansion alongside capacity

More usable storage does not automatically mean faster file transfers. Network planning should include:

The NAS link speed
Switch and router capabilities
Client network adapters
Link aggregation support and limitations
SMB, NFS, or other protocol overhead
Concurrent users and workloads
Whether the NAS can saturate the available network

A faster network can improve large transfers, but it cannot remove hard-drive seek limits, CPU constraints, encryption overhead, or application bottlenecks.

Expansion planning should cover:

Empty bays available after the initial build
Supported drive sizes and types
Whether mixing drive capacities is allowed
Expansion rules for the selected RAID or ZFS layout
Backup and migration requirements
Power and cooling for additional drives
The point at which replacing the NAS is more practical than expanding it

For ZFS, plan the vdev structure before buying drives. Adding a disk to a pool is not universally equivalent to adding capacity to a conventional RAID group, and vdev choices can affect redundancy, performance, and future expansion.