NAS Build Compatibility Checklist

The short answer

A compatible NAS build starts with the workload and drive count—not the motherboard or CPU. Before buying parts, confirm that the case has enough usable bays, the motherboard and controller expose enough storage ports, the CPU and RAM suit services such as Plex or surveillance, the PCIe slots have the required lanes, and the PSU and cooling can handle startup and sustained load.

Use this sequence:

1. Define the number and type of drives.
2. Estimate usable capacity and redundancy.
3. Match the CPU and RAM to the workload.
4. Count SATA, NVMe, USB, and networking ports.
5. Check PCIe lanes and slot clearance.
6. Confirm case, backplane, PSU, and cooling compatibility.
7. Plan backup, expansion, and noise limits.
8. Test the final parts list before ordering.

1. Start with drive count and workload

Write down the actual workloads before selecting hardware. A file server for documents has different requirements from a NAS running virtual machines, Plex, photo indexing, containers, and camera recording simultaneously.

Identify the drives

Separate storage by role:

• Data drives: HDDs or SSDs used for the main storage pool.
• Boot drive: A separate device for the operating system, if the chosen platform requires or benefits from one.
• Cache or special-purpose SSDs: Devices used for metadata, read/write caching, applications, or a dedicated high-speed pool.
• Surveillance drives: Drives receiving continuous camera recordings may have a different endurance and workload profile from general-purpose storage.
• Backup drives: External or removable drives are not part of the primary NAS array, even if they have similar capacities.

Then record:

• Number of initial drives
• Drive interface: SATA, SAS, or NVMe
• Drive form factor: 3.5-inch, 2.5-inch, or M.2
• Capacity and sector format
• HDD versus SSD
• Planned expansion drives
• Required redundancy level

Do not assume that an M.2 slot is automatically available for storage. Some M.2 slots support only NVMe, some only SATA, and some share bandwidth or disable motherboard SATA ports when populated. Check the motherboard manual.

Define the workload

Classify the NAS by its heaviest expected task:

Workload	Main compatibility concerns
File sharing and backups	Drive capacity, redundancy, networking, backup destination
Media serving	Network speed, client playback support, CPU capability if transcoding is required
Plex or other media servers	Direct play versus transcoding, hardware acceleration support, RAM, application storage
Surveillance	Camera count and recording bitrate, continuous-write capacity, retention period, monitoring support
Containers	RAM, SSD responsiveness, CPU threads, application isolation
Virtual machines	RAM capacity, CPU virtualization features, storage latency, networking
ZFS storage	Adequate RAM, reliable storage devices, controller mode, pool layout, backup plan
High-speed editing or multiple users	Network speed, PCIe expansion, switch and client compatibility, storage throughput

A NAS that can store video files may not be suitable for several simultaneous transcodes. Likewise, a system with many CPU cores may still be limited by a single network port, insufficient RAM, or an unsuitable drive layout.

2. Calculate capacity before selecting the case

Raw capacity is not usable capacity

A simple raw-capacity estimate is:

Raw capacity = number of drives × capacity of each drive

Redundancy changes the usable result. For similarly sized drives, simplified planning formulas are:

• Mirror: usable capacity is approximately the capacity of one drive per mirror pair.
• Single-parity layout: usable capacity is approximately (number of drives - 1) × smallest drive capacity.
• Dual-parity layout: usable capacity is approximately (number of drives - 2) × smallest drive capacity.
• No redundancy: usable capacity is approximately the sum of all drives, but a drive failure can destroy the affected pool or array.

These are planning estimates. Filesystem overhead, reserved space, metadata, snapshots, and mixed drive sizes reduce the space available to users.

Worked example

Suppose a build starts with four drives of 12 TB each:

Raw capacity = 4 × 12 TB = 48 TB

A simplified single-parity estimate is:

Usable before overhead ≈ (4 - 1) × 12 TB = 36 TB

A simplified dual-parity estimate is:

Usable before overhead ≈ (4 - 2) × 12 TB = 24 TB

The final usable figure will be lower, and the pool still needs free space for normal operation, snapshots, replacement procedures, and future growth.

Account for growth

Do not fill every bay on day one unless there is a clear reason. Empty bays can be valuable for:

• Replacing failed drives without immediately removing data
• Expanding a pool, where the storage platform supports the required expansion method
• Adding a separate backup or surveillance pool
• Moving from a mirror layout to a larger redundant layout
• Separating high-activity applications from bulk media

Check the storage platform’s expansion rules before choosing a small initial array. Some systems expand one drive at a time; others require a larger migration or a new vdev, group, or array. A case with extra bays does not guarantee that the software can use them in the way you expect.

3. Match the CPU to the workload

CPU selection should follow the services that must run concurrently.

File serving and backups

Basic file serving usually does not require a high-end processor. More important factors may include:

• A supported operating system
• Sufficient RAM
• Reliable network connectivity
• Enough storage ports
• Efficient idle power use
• Hardware support for the chosen filesystem and applications

Plex and media workloads

For Plex or another media server, distinguish between:

• Direct play: The client can play the stored file format without conversion.
• Remuxing: The server repackages the stream without fully converting the video.
• Transcoding: The server converts video or audio to a different format, resolution, bitrate, or subtitle mode.

Transcoding requirements depend on the media format, client devices, subtitle handling, concurrent streams, and whether hardware acceleration is supported and configured. Do not buy a CPU based only on a generic “number of streams” claim unless it applies to your exact codecs, resolutions, clients, and software configuration.

Check:

• Whether the CPU includes the required media engine
• Whether the operating system and application can access it
• Whether hardware acceleration requires additional configuration
• Whether the chosen motherboard exposes the necessary display or media-related functionality
• Whether the workload falls back to CPU transcoding

Surveillance

For surveillance, estimate recording load:

Total recording bitrate = cameras × bitrate per camera

Then convert to storage usage:

Storage per day in bytes = total bitrate in bits per second × 86,400 / 8

A practical estimate should also account for variable bitrate, audio, overhead, motion-only recording, retention policy, and camera settings. Surveillance systems can create sustained writes, so drive selection, cooling, and pool layout matter as much as CPU performance.

Virtual machines and containers

Virtual machines generally need more RAM and storage responsiveness than ordinary file sharing. Check:

• Hardware virtualization support
• Number of simultaneous guests
• Guest operating-system requirements
• RAM reserved for the host
• Storage latency and IOPS needs
• Network interfaces for isolated or high-throughput workloads

Containers are often lighter than full virtual machines, but multiple applications can still consume substantial RAM and create background disk activity.

4. Size and verify RAM

RAM compatibility has two parts: whether the modules physically and electrically work, and whether the capacity is sufficient for the workload.

Check the motherboard or NAS platform for:

• Supported memory type
• Maximum capacity
• Number of memory slots
• Supported module configurations
• ECC support, if required
• Registered or unbuffered memory requirements
• Firmware restrictions
• Whether mixed modules are supported

ECC is a platform feature, not just a property of a memory stick. The CPU, motherboard, firmware, and operating system must support and use error correction for it to provide its intended benefit.

RAM planning

Reserve memory for:

• The operating system
• Filesystem caching
• Containers and virtual machines
• Plex or media-server indexing
• Photo and document indexing
• Surveillance software
• File-system snapshots and background tasks

ZFS benefits from RAM for caching and metadata, but there is no universal capacity rule that makes every ZFS system compatible or incompatible. A small home file server and a virtualisation host have very different requirements. Confirm the platform’s documented memory guidance and size RAM for the services you will actually run.

Avoid treating an SSD cache as a substitute for insufficient RAM. A cache can change access patterns, but it does not solve a memory shortage, add redundancy, or replace a backup.

5. Count storage ports and PCIe lanes

Port count is not the same as usable storage connectivity.

SATA and SAS

Count every planned device:

Required storage connections = data drives + boot devices + cache devices + future devices

Then verify:

• Native motherboard SATA ports
• HBA or RAID-controller ports
• Backplane connectors
• Power connectors for each drive
• Whether the controller supports the chosen drive type
• Whether the controller can operate in the mode required by the filesystem
• Whether cables reach without sharp bends or obstructed airflow

A hardware RAID controller may not be appropriate for a ZFS pool that expects direct disk access or HBA mode. Confirm the storage software’s controller requirements before selecting an HBA or RAID card.

SAS controllers and backplanes may support SATA drives, but compatibility depends on the specific hardware and cabling. Do not infer support from connector shape alone.

PCIe lane planning

List every expansion card:

• Network interface card
• HBA or storage controller
• GPU or media-acceleration card
• NVMe adapter
• Additional USB or other I/O card

For each card, record:

• Physical slot size
• Electrical lane requirement
• Generation requirement
• Required bandwidth
• Slot position and clearance
• Cooling needs
• Whether another device shares the slot or lanes

A physically full-length PCIe slot may be electrically connected with fewer lanes. Likewise, populating an M.2 slot or a second PCIe slot may disable SATA ports or reduce another slot’s available lanes.

Create a lane map before buying:

Device	Physical slot	Electrical requirement	Lane or port sharing to verify
HBA	Appropriate PCIe slot	Confirm from controller documentation	Shared lanes, chipset uplink, slot bifurcation
Network card	Appropriate PCIe slot	Confirm interface and lane requirement	Slot bandwidth and neighboring clearance
NVMe adapter	PCIe slot	Confirm drive count and bifurcation support	CPU/chipset lanes and M.2 sharing
GPU	Appropriate PCIe slot	Confirm power, clearance, and software support	Slot spacing and airflow

For multiple NVMe drives on one adapter, check whether the motherboard supports PCIe bifurcation in the required arrangement. An adapter that physically holds several drives may not make all of them visible without the correct lane configuration.

6. Verify networking end to end

Network speed is limited by the slowest important link:

Effective link speed = minimum(NAS port, switch port, cable, client port, storage capability)

A faster NAS port does not automatically make every client faster. Verify:

• NAS network interface
• Switch port
• Client network interface
• Cable category and installation quality
• Link aggregation requirements, if applicable
• SMB, NFS, or other protocol settings
• Whether the storage pool can sustain the intended workload

For a rough theoretical conversion:

Bandwidth (Gbps) / 8 = theoretical GB/s

For megabytes:

Bandwidth (Gbps) × 1,000 / 8 = theoretical MB/s

Real throughput is lower because of protocol overhead, filesystem behavior, encryption, small files, simultaneous users, drive limits, and network configuration.

Link aggregation can provide more total traffic across multiple clients, but it does not necessarily make one file transfer use the sum of all links. Confirm the switch, NAS operating system, and clients support the selected aggregation mode.

7. Check the case, bays, and backplane

Drive-bay compatibility

Confirm that the case supports the required:

• Number of 3.5-inch bays
• Number of 2.5-inch bays
• M.2 positions
• Hot-swap or fixed-mount arrangement
• Drive thickness
• Backplane connector type
• Drive trays and mounting hardware
• Cable routing
• Vibration isolation

A case advertised with many bays may count positions that are inaccessible after installing a long GPU, radiator, power supply, or expansion card. Measure the complete assembly, not just the empty chassis.

Backplane and cabling

A backplane can simplify installation, but verify:

• How the backplane connects to the motherboard or HBA
• Whether it requires separate power
• Whether it supports SATA, SAS, or both
• Whether an expander is present
• Whether the controller supports that topology
• Whether activity and fault LEDs are supported by the software

Do not assume that a backplane’s connector count equals the number of independently supported drives.

Internal clearance

Measure for:

• CPU cooler height
• GPU length and thickness
• HBA and network-card heatsinks
• Power-supply length
• Radiator and fan placement
• Drive trays and cable bends
• PCIe retention brackets
• Front-to-back airflow paths

A build can be technically compatible yet impractical if installing one part blocks another part’s airflow or prevents drive removal.

8. Size the PSU for startup and sustained load

The PSU must support both peak demand and the required connectors.

List:

• Motherboard connector
• CPU power connector
• Drive power connectors
• HBA or controller power
• GPU power, if applicable
• Fans, pumps, and accessories
• Any future drives or expansion cards

Hard drives can draw more power during startup than during normal operation. A system that appears fine at idle may become unstable when many drives spin up together.

A basic planning model is:

Required PSU capacity > peak system load × design margin

Use the actual power requirements of the selected CPU, drives, cards, fans, and motherboard where available. If exact figures are unknown, say so and avoid presenting a precise wattage as guaranteed.

Also check:

• PSU efficiency and low-load behavior
• Number and type of native connectors
• Cable length
• Modular cable compatibility
• PSU physical length
• Warranty and operating environment

Never mix modular cables from different PSU models unless the manufacturer explicitly confirms compatibility.

9. Plan cooling, noise, and power together

NAS systems often run continuously, so cooling is not only a performance issue. It affects drive health, noise, dust buildup, and electricity use.

Airflow checklist

A sensible airflow path usually includes:

• Cool air entering near the drive bays
• Air passing through the drives
• CPU and expansion-card cooling
• Warm air leaving the rear or top
• Unblocked fan intakes and exhausts
• Filters that can be cleaned without dismantling the system

Check fan sizes, control methods, connector types, and firmware support. A quiet fan profile may allow temperatures to rise during sustained writes or parity operations.

Noise trade-offs

The main noise sources are:

• Hard-drive vibration and seeking
• Small, high-speed fans
• HBA or GPU cooling
• PSU fan behavior
• Resonance from the case or drive trays

Reducing noise can mean lower fan speeds, quieter drives, vibration isolation, or a larger case with better airflow. These choices may increase cost, reduce peak cooling capacity, or make drive temperatures more sensitive to ambient conditions.

Power trade-offs

Compare the consequences of:

• More low-capacity drives versus fewer high-capacity drives
• HDD bulk storage versus an SSD pool
• A low-power CPU versus a higher-performance CPU
• A dedicated GPU versus integrated media acceleration
• Always-on services versus scheduled workloads
• More expansion headroom versus lower idle consumption

Do not assume that adding SSD cache reduces total energy use. It may improve responsiveness for a specific workload, but it also adds devices, consumes power, and introduces configuration complexity.

10. Decide between an appliance and a DIY NAS

Appliance advantages

A prebuilt NAS can provide:

• A validated CPU, board, case, and power combination
• Drive trays and backplane integration
• Vendor-supported firmware and operating system
• Simpler setup and monitoring
• Lower compatibility risk
• A documented upgrade path

The trade-off is less freedom to replace the CPU, add arbitrary PCIe cards, change the operating system, or reuse unusual hardware.

DIY advantages

A DIY NAS can provide:

• Choice of case and drive layout
• Flexible CPU and RAM selection
• More control over PCIe, networking, and storage controllers
• Reuse of existing components
• Greater freedom to run a preferred operating system
• Potentially easier expansion in selected areas

The trade-off is that you are responsible for validating every interface, firmware combination, cooling solution, and replacement part. Vendor support may be split among the case, motherboard, controller, operating system, and drive manufacturers.

If convenience and predictable support are more important than customization, compare appliance options in Browse NAS. For server-oriented systems, review NAS & storage servers.

11. RAID, ZFS, and backup are separate decisions

RAID is not backup

RAID or a redundant filesystem layout can help keep data available after certain drive failures. It does not protect against:

• Accidental deletion
• Ransomware
• Corruption propagated to redundant copies
• Theft or fire
• Failed updates
• A damaged NAS
• User mistakes
• Loss of the entire array

Maintain a separate backup with a tested restore process. Ideally, at least one backup copy should be disconnected or otherwise protected from the NAS during normal operation.

Validate the storage layout

Before finalizing the build, document:

• Expected usable capacity
• Number of drive failures the layout can tolerate
• Whether mixed drive sizes are supported efficiently
• Expansion procedure
• Rebuild or resilver implications
• Snapshot and retention policy
• Backup destination
• Restore procedure

For ZFS, check that the controller exposes drives correctly, the pool layout matches the expansion plan, and the system has sufficient RAM and cooling for the workload. ZFS redundancy improves availability; it does not eliminate the need for backups.

Final NAS build checklist

Drives and capacity

• [ ] Drive count matches the initial workload.
• [ ] Drive type and interface match the NAS, backplane, or controller.
• [ ] Usable capacity was calculated after redundancy and expected overhead.
• [ ] Free space and future growth were included.
• [ ] Surveillance, cache, boot, and backup drives have defined roles.
• [ ] The expansion method is documented.

CPU and software

• [ ] The CPU supports the selected operating system.
• [ ] Plex or media workloads were evaluated for direct play and transcoding.
• [ ] Hardware acceleration support was verified where needed.
• [ ] Virtualization features are available if required.
• [ ] The CPU’s integrated graphics or media engine is supported by the software.

RAM

• [ ] Memory type and maximum capacity match the motherboard or NAS platform.
• [ ] ECC requirements were checked across CPU, board, firmware, and operating system.
• [ ] Enough RAM remains for the host, filesystem, applications, and virtual machines.
• [ ] Module configuration is supported.
• [ ] SSD cache is not being used as a substitute for adequate RAM.

Ports and PCIe

• [ ] Every drive has a data connection and power connection.
• [ ] SATA, SAS, and NVMe compatibility was verified.
• [ ] HBA or RAID-controller mode matches the storage software.
• [ ] PCIe slot size and electrical lanes were checked.
• [ ] M.2 and PCIe lane sharing was reviewed.
• [ ] PCIe bifurcation support was confirmed for multi-drive adapters.
• [ ] Expansion cards have adequate clearance and cooling.

Case and cooling

• [ ] All drive bays are physically accessible.
• [ ] Drive thickness, trays, and backplane connectors match.
• [ ] CPU cooler, GPU, HBA, PSU, and radiator clearances were measured.
• [ ] Airflow reaches the drive bays.
• [ ] Fan connectors and control support were verified.
• [ ] Noise and vibration are acceptable for the installation location.

Power and networking

• [ ] PSU capacity covers startup and sustained peak demand with margin.
• [ ] The PSU has the required connectors and physical clearance.
• [ ] Modular cables are compatible with the exact PSU.
• [ ] NAS, switch, clients, and cabling support the intended network speed.
• [ ] The storage pool can sustain the expected network workload.
• [ ] Link aggregation is not being confused with faster single-client transfers.

Reliability and recovery

• [ ] RAID or ZFS redundancy is documented.
• [ ] A separate backup exists.
• [ ] Backup restoration has been tested.
• [ ] Drive replacement and rebuild procedures are understood.
• [ ] Firmware, operating-system, and application update plans exist.
• [ ] The system has monitoring for drive health, temperatures, pool status, and backup failures.