This year, faced with ever-growing digital files, I embarked on a project to construct my very own home NAS server. This 32TB system is designed to securely store both my personal and business data, all powered by open-source software.
The hardware for the server itself came to $531, and adding four robust hard drives cost $732, bringing the total investment to $1,263. While this price is comparable to pre-built, off-the-shelf storage servers, the DIY approach offers significant advantages in terms of processing power and customization flexibility.
In this article, I’ll detail my journey of selecting components, share the missteps I encountered, and provide actionable recommendations for anyone considering building their own NAS server.
All components laid out in their original packaging ready for the NAS server build.
The finished DIY NAS server, compact and ready for operation.
For those who prefer visual learning, I have also created a video walkthrough of this build available on YouTube.
Understanding NAS Servers and the DIY Advantage
Why Choose a NAS Server?
NAS, or Network-Attached Storage, is fundamentally a dedicated server designed for one primary purpose: data storage and accessibility across your network. Unlike direct-attached storage, a NAS server operates independently, making files available to multiple devices simultaneously.
But why dedicate an entire server to data storage? Isn’t data storage already handled by every computer?
The key benefit lies in decoupling data storage from individual workstations. With a NAS server, data migration headaches during computer upgrades become largely a thing of the past. Whether I upgrade my main workstation or laptop every few years, my data remains centralized and accessible. Furthermore, a NAS server greatly simplifies file sharing between all devices on my network.
My personal need for a NAS server is also driven by the sheer volume of data I accumulate. As a self-confessed data hoarder, I meticulously archive every digital photograph, every email from the past two decades, and the source code for all personal projects. Currently, this collection occupies around 8.5 TB and continues to grow.
The largest contributor to my storage needs is my extensive DVD and Blu-ray collection. Concerned about the ephemeral nature of streaming services, I prefer owning physical media for content I value. As soon as a new disc arrives, I create a raw image and a streamable video file. The combination of ISO copies and MP4s for each disc can consume upwards of 60 GB of storage space.
Physical media collection, including hundreds of DVDs and Blu-rays, driving the need for substantial storage capacity on the NAS server.
Delving into the Homelab Concept
The term “homelab” has gained significant traction recently, referring to a dedicated space within your home for experimenting with IT hardware and software typically found in professional office or data center environments. A homelab can serve as a practical training ground for developing professional IT skills or simply a playground for exploring fascinating technologies. Building a NAS server often falls under the umbrella of homelab projects.
The DIY NAS Server Proposition
If you’re new to the homelab world or lack experience in PC building, starting with a DIY NAS server might not be the most straightforward path.
Pre-built, off-the-shelf NAS server solutions offer comparable functionality with a significantly shallower learning curve. These systems, like those from Synology or QNAP, are user-friendly and ready to go.
Prior to embarking on this DIY NAS server project, I relied on a 4-disk Synology DS412+ for seven years. My Synology unit was an excellent introduction to NAS servers, and for newcomers, I often recommend starting with such a system.
The Synology DS412+, a reliable off-the-shelf NAS server that served well for seven years and provided a gentle introduction to NAS technology.
However, a recent incident with my Synology – a boot failure accompanied by ominous clicking noises – highlighted a critical dependency on a single, proprietary device. Off-the-shelf NAS servers often lack user-repairability; component failures post-warranty necessitate complete server replacement. Furthermore, proprietary storage formats can lock your data into a specific vendor’s ecosystem, complicating data access outside of their systems.
While my Synology eventually recovered after cleaning and reseating the drives, this close call spurred me to transition to TrueNAS. TrueNAS offers an open-source operating system built upon open storage formats, providing greater control and flexibility.
TrueNAS and ZFS: The Foundation of the DIY NAS Server
TrueNAS (formerly FreeNAS) stands out as a leading open-source operating system specifically designed for NAS servers. With a development history spanning nearly two decades, TrueNAS has established itself as a robust and reliable choice for home and enterprise storage solutions.
At the heart of TrueNAS lies ZFS, a powerful filesystem engineered from the ground up for storage servers. Unlike traditional filesystems like NTFS or ext4, which operate atop a separate volume manager, ZFS integrates file system and volume management into a unified layer. This comprehensive control enables ZFS to deliver enhanced performance and advanced features.
Key advantages of ZFS include:
- Storage Pooling: Aggregating multiple physical disks into a single, manageable filesystem pool.
- Data Integrity: Automatic detection and repair of data corruption, ensuring data reliability.
- Snapshots: Creating point-in-time data snapshots, similar to Apple’s Time Machine, for easy data recovery.
- Data Security: Optional on-disk encryption and compression to protect and optimize storage.
Prior to this project, my experience with ZFS was non-existent, making this DIY NAS server build an exciting opportunity to explore its capabilities firsthand.
Planning Your NAS Server Storage Capacity
Estimating Storage Needs
When I initially purchased my Synology NAS server, I started with three 4TB drives, leaving one bay empty for future expansion. This configuration provided 7TB of usable storage with Synology Hybrid RAID. After three years, nearing capacity, I added a fourth drive, expanding usable storage to 10TB.
For this new DIY NAS server, I adopted a similar growth-oriented strategy. My goal was to achieve an initial usable storage capacity of 20TB, with the flexibility to expand up to 30TB by adding drives later.
Currently, ZFS does not natively support adding drives to an existing pool. However, this feature is under active development and expected to be implemented in future releases, hopefully simplifying storage expansion when needed.
Update (2025-01-25): The ability to add drives to ZFS pools is now available in the latest ZFS version, although I haven’t yet tested it within TrueNAS.
Balancing Disk Size and Quantity
ZFS’s data redundancy mechanisms, crucial for protecting against drive failures, impact usable storage capacity. ZFS employs data redundancy by storing data blocks across multiple disks, ensuring data survival even if a drive fails. Consequently, usable storage is not simply the sum of individual drive capacities.
ZFS organizes disks into “pools.” The efficiency of storage utilization within a ZFS pool is influenced by the number of disks. For instance, a two-disk pool using 10TB drives yields only half the total capacity as usable storage. Conversely, a five-disk pool using 4TB drives provides significantly more usable space—14TB in this example—even with the same total raw capacity. Utilizing more, smaller drives can yield a higher percentage of usable storage in ZFS configurations.
When designing a NAS server, the decision between fewer large drives and more small drives involves trade-offs. Smaller drives often offer a lower cost per terabyte but can increase operational expenses due to higher power consumption. Two 4TB drives consume twice the power of a single 8TB drive.
Prioritizing a compact server footprint, I opted for fewer, larger capacity drives for my NAS server build.
RAIDZ Configuration: Choosing Redundancy Level
ZFS offers different RAID-like configurations for data redundancy: raidz1, raidz2, and raidz3. These differ primarily in their fault tolerance—the number of simultaneous drive failures the array can withstand without data loss. Raidz1 tolerates a single drive failure, raidz2 tolerates two, and raidz3 tolerates up to three concurrent drive failures.
Increased redundancy comes at the cost of usable storage. Using five 4TB drives, the usable storage capacities for different raidz configurations are:
| ZFS type | Usable storage | % of total capacity |
|---|---|---|
| raidz1 | 15.4 TB | 77.2% |
| raidz2 | 11.4 TB | 57.2% |
| raidz3 | 7.7 TB | 38.6% |
I selected raidz1 for my NAS server. With a relatively small number of drives, the probability of multiple simultaneous drive failures is statistically low.
It’s crucial to remember that ZFS is not a substitute for a comprehensive backup strategy. While ZFS protects against hardware failure, it does not mitigate data loss from accidental deletion, malware, or physical theft. For robust data protection, I rely on restic to replicate critical data to encrypted cloud backups.
ZFS’s primary benefit is preventing data loss and downtime from single drive failures, minimizing the need to resort to cloud backups for routine drive replacements. While the risk of two drives failing simultaneously exists, the storage overhead of raidz2 (20% capacity reduction) seemed disproportionate for my home NAS server use case with a limited number of drives. For larger drive arrays (e.g., 20+ disks), raidz2 or raidz3 would become more prudent.
Mitigating Concurrent Drive Failures
While the probability of two drives failing at the same instant seems negligible, drives in close proximity, especially those from the same batch and workload, are not statistically independent. If one drive fails, its neighbors’ failure risk increases.
Furthermore, rebuilding a ZFS pool after a drive failure places considerable stress on the remaining drives. A drive nearing its end of life under normal operation might succumb to the additional workload of a pool rebuild.
To minimize the risk of concurrent drive failures in my NAS server, I implemented drive diversification. I chose two different drive models from separate manufacturers and purchased them from different vendors to reduce the likelihood of receiving drives from the same manufacturing batch. While the exact impact of this diversification is hard to quantify, it introduced minimal additional cost and seemed like a worthwhile precaution.
Purchasing Seagate IronWolf drives from different vendors to reduce the chance of receiving drives from the same manufacturing batch and mitigating potential batch-related failures in the NAS server.
Component Selection for the DIY NAS Server
Motherboard Choice
Motherboard size was the initial key decision. Appreciating the compact footprint of my Synology DS412+, I decided to explore a mini-ITX motherboard for this build, a form factor I hadn’t worked with before.
The ASUS Prime A320I-K motherboard was selected based on several criteria:
- Four SATA ports: Sufficient for directly connecting four hard drives.
- Integrated Radeon Graphics: Eliminating the need for a discrete graphics card.
- Affordability: Priced at a budget-friendly $98.
The ASUS Prime A320I-K mini-ITX motherboard chosen for the NAS server build, featuring integrated graphics and four SATA ports.
Important Note: In retrospect, the motherboard choice was a source of regret, as discussed later.
The B450 chipset motherboard was considered as an alternative, offering similar features but at nearly double the price. The primary advantage appeared to be enhanced overclocking capabilities, which were not relevant for a NAS server application.
CPU Selection
Based on my research, ZFS is not particularly CPU-intensive. A quick test installing TrueNAS on a spare Dell OptiPlex 7040 mini PC confirmed minimal CPU utilization, suggesting a low-power CPU would suffice.
My main CPU criterion was integrated Radeon graphics support to leverage the A320 motherboard’s HDMI output, avoiding a separate graphics card.
The AMD Athlon 3000G CPU selected for the NAS server, balancing cost and integrated graphics capability.
The AMD Athlon 3000G emerged as a suitable option. Priced at around $105, it offered good value, integrated Radeon graphics, and respectable CPU benchmarks.
Case Selection
For my previous VM server build, I used a Fractal Design case, a brand I greatly appreciated. For this NAS server, I returned to Fractal Design, selecting the Fractal Design Node 304 Black, a compact mini-ITX case. Its cube-like design and six 3.5″ drive bays were appealing, offering both initial storage capacity and future expandability.
The Fractal Design Node 304 Black mini-ITX case, providing a compact form factor with six drive bays for the NAS server.
Data Drive Selection
With six drive bays available, I decided to start with four 8TB drives, providing approximately 22.5TB of usable storage in a raidz1 configuration. Future expansion with a fifth and sixth drive would increase usable storage to 30.9TB and 37TB, respectively.
In the 8TB capacity range, most drives are 7200 RPM or higher. For a NAS server, speeds exceeding 7200 RPM offer negligible performance gains as network bandwidth becomes the primary bottleneck. Faster drives would increase noise and power consumption without practical benefits.
Initially, I consulted Backblaze’s hard drive stats to identify reliable drives, but their recommendations leaned towards pricier enterprise-grade options. While tempting to invest heavily in ultra-reliable drives with low failure rates, the cost premium seemed disproportionate for home use.
A critical consideration was avoiding Shingled Magnetic Recording (SMR) drives. ZFS performance degrades significantly on SMR drives. Therefore, selecting drives with Conventional Magnetic Recording (CMR) was essential.
I chose the Toshiba N300 and the Seagate IronWolf, both receiving positive reviews on TrueNAS forums and Reddit. Priced between $180-$190, they offered a good balance of capacity and value.
The Toshiba N300 8TB NAS hard drive selected for the NAS server.
The Seagate IronWolf 8TB NAS hard drive, the second drive model chosen for diversification in the NAS server build.
OS Drive Selection
TrueNAS requires a dedicated OS drive, but its demands are minimal. The OS itself needs at least 2GB of space, and disk activity is infrequent.
The Kingston A400 120GB M.2 SSD, a cost-effective and compact OS drive for the NAS server.
The Kingston A400 120GB M.2 SSD was chosen for its affordability (around $32) and compact M.2 form factor, eliminating the need for cables and occupying minimal space.
RAM Selection
During my research, the “rule” of 1GB of RAM per terabyte of storage for ZFS surfaced frequently. However, ZFS developer Richard Yao has debunked this as a myth. While RAM-intensive features like data deduplication exist, ZFS functions effectively even with limited RAM.
RAM shopping is often less engaging. Lacking definitive RAM benchmarks for NAS server applications, my selection process was pragmatic:
- Consult the ASUS A320I-K motherboard’s compatibility list.
- Filter for 32GB or 64GB kits using two sticks.
- Prioritize reputable brands (Corsair, Crucial, G.SKILL, Kingston, Samsung, Patriot, Mushkin, HyperX).
- Set a budget limit of $150.
This led to the CORSAIR Vengeance LPX 32GB CMK32GX4M2A2400C14 (2 x 16GB) kit, priced at $128.
The CORSAIR Vengeance LPX 32GB RAM kit, compatible with the chosen motherboard and offering sufficient memory for the NAS server.
Power Supply Unit (PSU) Selection
Power capacity requirements for the NAS server were minimal. PCPartPicker estimated a system power draw of only 218W. A 300-400W PSU would have sufficed, but semi-modular options were scarce at that wattage. The EVGA 110-BQ-0500-K1 500W PSU, a semi-modular unit, was selected.
The EVGA 110-BQ-0500-K1 500W semi-modular power supply unit, providing ample power for the NAS server components.
90-Degree SATA Cables
Holding a 90-degree SATA cable, a crucial component for space-constrained mini-ITX NAS server builds.
An unexpected necessity was 90-degree SATA cables. Standard SATA cables would not fit due to limited clearance between the motherboard SATA ports and the PSU in the mini-ITX case. Slim 90-degree SATA cables resolved this space constraint.
Close-up showing the tight fit of the 90-degree SATA cable between the motherboard SATA port and the power supply, highlighting the space constraints in the mini-ITX case.
Components Intentionally Omitted
Several components commonly found in NAS server builds were intentionally excluded from this project due to cost, complexity, or space limitations.
Graphics Card (GPU)
Given the space constraints and limited motherboard ports, a dedicated graphics card was omitted. The chosen motherboard and CPU combination provided integrated graphics capabilities, sufficient for NAS server operation.
Host Bus Adaptor (HBA)
Many NAS server builds incorporate a Host Bus Adaptor (HBA) to expand the number of supported drives beyond the motherboard’s native SATA ports. However, HBAs often require firmware flashing, a process deemed potentially complex. For initial needs, the ASUS A320I-K’s four SATA ports were sufficient, and a PCI slot was reserved for a future HBA if needed.
ECC RAM
Error-Correcting Code (ECC) RAM is often advocated for NAS servers to prevent data corruption. However, I opted for standard consumer-grade RAM. While ECC RAM offers enhanced data integrity, decades of personal computing experience without ECC RAM haven’t revealed noticeable data corruption issues. For a home NAS server, consumer-grade RAM seemed adequate, although ECC RAM might be considered for mission-critical enterprise deployments.
SLOG Disk
A Separate Intent Log (SLOG) disk, typically a dedicated SSD, is sometimes included in ZFS NAS server builds to accelerate write operations. However, due to port and drive bay limitations, a SLOG disk was omitted to prioritize storage capacity expansion.
NAS Server Parts List and Costs
| Category | Component | Cost |
|---|---|---|
| CPU | AMD Athlon 3000G | $105.13 |
| Motherboard | ASUS Prime A320I-K* | $97.99 |
| Graphics | Integrated (Motherboard) | $0 |
| Disk (OS) | Kingston A400 120GB | $31.90 |
| Memory | CORSAIR Vengeance LPX 32GB CMK32GX4M2A2400C14 (2 x 16GB) | $127.99 |
| Power | EVGA 110-BQ-0500-K1 500W 80+ Bronze Semi-Modular | $44.99 |
| Case | Fractal Design Node 304 Black | $99.99 |
| SATA cables | Silverstone Tek Ultra Thin Lateral 90 Degree SATA Cables (x2) | $22.30 |
| Subtotal (Server Hardware) | $530.29 | |
| Disk (Storage) | Toshiba N300 HDWG480XZSTA 8TB 7200 RPM (x2) | $372.79 |
| Disk (Storage) | Seagate IronWolf 8TB NAS Hard Drive 7200 RPM (x2) | $359.98 |
| Total (NAS Server with Storage) | $1,263.06 |
* Note: BIOS compatibility issues may exist with the ASUS Prime A320I-K motherboard and AMD Athlon 3000G CPU out-of-the-box, requiring a BIOS update. Further details are provided below.
DIY NAS Server vs. Off-the-Shelf Alternatives
To contextualize the cost and capabilities of this DIY NAS server, let’s compare it to similarly priced off-the-shelf options:
| Product | 2022 DIY Budget NAS | Synology DS920+ | QNAP TS-473A-8G-US |
|---|---|---|---|
| Disk bays | 6 | 4 | 4 |
| RAM | 32 GB | 4 GB | 4 GB |
| Max RAM | 32 GB | 8 GB | 8 GB |
| CPU Benchmark | 4479 | 3002 | 4588 |
| Price | $530.29 | $549.99 | $549 |
While the total cost is comparable, the DIY NAS server offers significantly more value in terms of RAM capacity (8x more) and avoids vendor lock-in associated with proprietary operating systems. The DIY approach provides greater control and customization at a similar price point.
NAS Server Build Log: Visual Journey
All components unboxed and ready for assembly.
The ASUS Prime A320I-K motherboard installed within the Fractal Design Node 304 case.
Kingston A400 M.2 SSD installed directly onto the motherboard, showcasing the clean and cable-free M.2 installation.
The EVGA power supply unit installed in the case, utilizing the case’s internal power extension cable.
90-degree SATA cables pre-installed on the motherboard SATA ports before PSU installation to manage space constraints.
Close-up illustrating the extremely tight clearance between the 90-degree SATA cables and the installed power supply.
Motherboard with CPU, RAM, and power cables connected, ready for final assembly.
The completed DIY NAS server build, a compact and functional home storage solution.
Remote Server Management with TinyPilot
For managing the server build process, I utilized TinyPilot, a Raspberry Pi-based KVM over IP device I developed. This build marked my third server deployment using TinyPilot and the first with the new TinyPilot Voyager 2.
TinyPilot Voyager 2 connected to the NAS server, enabling remote management and installation without direct keyboard, mouse, and monitor connections.
TinyPilot Voyager 2 streamlined the build process, eliminating the need for physical keyboard, mouse, and monitor connections. BIOS access, TrueNAS installation media mounting, and OS installation were all managed remotely through a web browser.
TinyPilot interface showing the TrueNAS installer ISO mounted remotely, simplifying the OS installation process.
One minor limitation encountered was BIOS updating. While TinyPilot handles .img and .iso disk images, direct file sharing for BIOS .CAP files was not yet supported. For the BIOS update, a temporary USB drive was used. Future TinyPilot updates aim to address this scenario for fully remote BIOS management.
BIOS Compatibility and Troubleshooting
Upon initial component assembly, the system powered on but lacked video output. Troubleshooting steps, including reseating RAM, CPU, and checking cables, yielded no improvement.
Online research revealed potential BIOS incompatibility between the ASUS Prime A320I-K motherboard and the Athlon 3000G CPU, requiring a BIOS update. A detail overlooked during parts selection, assuming BIOS updates would be straightforward. However, updating the BIOS without a compatible CPU presented a challenge.
Fortunately, the Ryzen 7 CPU and GPU from my older 2017 VM server were compatible with the ASUS Prime A320I-K. Borrowing these components allowed the new NAS server to boot, enabling the necessary BIOS update.
Screenshot of the ASUS BIOS interface, version 2203, after booting with borrowed components to facilitate the BIOS update.
Strangely, even after booting with borrowed parts, the BIOS version reported was 2203, which ASUS claimed was compatible with the Athlon 3000G. Nevertheless, an update to the latest BIOS (version 5862) was performed.
Screenshot from the ASUS Prime A320I-K CPU compatibility list, indicating Athlon 3000G support starting from BIOS version 2203.
Post-BIOS update to 5862, booting with the Athlon 3000G still failed. The eventual solution: realizing the HDMI cable was mistakenly plugged into the DisplayPort output.
Diagram highlighting the visual similarity between HDMI and DisplayPort connectors, illustrating the potential for misconnection.
The root cause remains ambiguous: user error (HDMI/DisplayPort confusion) or inaccurate ASUS BIOS compatibility information. Regardless, the NAS server eventually booted successfully with the Athlon 3000G after this troubleshooting process.
Screenshot capturing the moment of successful boot with the Athlon 3000G CPU, signaling the resolution of the BIOS compatibility issue.
NAS Server Performance Benchmarks
Benchmarking NAS server performance proved surprisingly challenging. While disk I/O benchmark tools exist, they don’t accurately reflect real-world network-based usage. Most NAS server operations occur over the network, making network bottlenecks the primary performance limiting factor.
A rudimentary benchmark was devised using robocopy to measure read and write speeds between my desktop and the NAS server. Two datasets were used: 20 GiB of 1 GiB files and 3 GiB of 1 MiB files. Averages of three trials were taken for both encrypted and unencrypted volumes, and compared against my old Synology DS412+.
Performance peaked around 111 MiB/s (931 Mbps), closely aligning with the 1 Gbps limit of my network hardware (switch, desktop, and NAS server all using 1 Gbps Ethernet). This indicated network infrastructure as the primary performance constraint.
Read Performance
Chart comparing read performance between the DIY NAS server and Synology DS412+ on unencrypted volumes.
On unencrypted volumes, surprisingly, the 7-year-old Synology outperformed the new DIY NAS server, exhibiting 31% faster small file reads and 10% faster large file reads.
Chart comparing read performance between the DIY NAS server and Synology DS412+ on encrypted volumes.
However, Synology’s performance drastically declined with encryption enabled, experiencing a 67-75% read speed reduction. In contrast, encryption had negligible impact on the DIY NAS server‘s read speeds. Consequently, on encrypted volumes, the DIY NAS server outperformed Synology by 2.3x for small files and 3x for large files, representing a more realistic performance comparison for my encrypted data usage.
Write Performance
Chart comparing write performance between the DIY NAS server and Synology DS412+ on unencrypted volumes.
For write performance, even on unencrypted volumes, the DIY NAS server surpassed Synology, achieving 77% faster small file writes, with comparable large file write speeds between the two systems.
Chart comparing write performance between the DIY NAS server and Synology DS412+ on encrypted volumes.
Enabling encryption severely hampered Synology’s write performance. With encryption, the DIY NAS server demonstrated 5.2x faster small file writes and 3.2x faster large file writes compared to the Synology unit.
Power Consumption
Power consumption measurements using a Kill A Watt meter revealed:
| System | Synology DS412+ | 2022 DIY NAS |
|---|---|---|
| Idle Power | 38 W | 60 W |
| Load Power | 43 W | 67 W |
The DIY NAS server consumed approximately 60% more power than the Synology. At a power cost of $0.17/kWh, the DIY NAS server‘s monthly operating cost is around $7.20. The higher power draw might be attributed to PSU inefficiency at low load levels, as the 500W PSU operates far below its capacity.
Final Reflections on the DIY NAS Server Build
Motherboard Considerations
The ASUS Prime A320I-K motherboard’s limited CPU compatibility and BIOS quirks were notable drawbacks. The BIOS update utility proved unreliable, requiring manual BIOS updates.
Screenshot of ASUS EZ Flash utility incorrectly reporting BIOS version 2203 as the latest available version.
Screenshot of the ASUS website clearly indicating the availability of BIOS version 5862, contradicting the EZ Flash utility.
The 32GB RAM limit was another limitation. While currently sufficient, future memory expansion is restricted.
Realtek Network Driver Fix
Network instability with the motherboard’s Realtek NIC was encountered under heavy load. A workaround involving loading the official Realtek FreeBSD driver resolved this issue:
-
Access TrueNAS web dashboard, navigate to System > Tunables.
-
Add the following tunables:
Variable Value Type if_re_loadYESloader if_re_name/boot/modules/if_re.koloader
Case Feedback
The Fractal Design Node 304 case, while aesthetically pleasing, proved less user-friendly than anticipated. Limited documentation and non-intuitive mechanisms made assembly somewhat cumbersome. Mini-ITX form factor constraints inherently introduce design compromises.
Component Performance and Suitability
The Athlon 3000G CPU proved significantly overpowered for NAS server duties, consistently idling at 99% CPU utilization. However, its integrated graphics fulfilled the requirement of avoiding a dedicated GPU.
TrueNAS CPU utilization graph showing consistently low CPU usage, indicating the Athlon 3000G is more than sufficient for the NAS server workload.
Data drives (Toshiba N300 and Seagate IronWolf) have performed reliably without noticeable noise. The Kingston A400 OS drive operates with minimal disk activity, confirming its suitability for the TrueNAS OS.
TrueNAS OS disk I/O graph showing minimal activity after system boot, highlighting the low demands on the OS drive.
The EVGA 500W PSU might be over-spec
