Build a Compact 4-SSD NAS With Raspberry Pi 4 and Radxa SATA HAT

I wanted a NAS.

Not a powerful home server, not a machine for running dozens of containers, and not another expensive commercial box with features I would never use.

I wanted something much simpler: a small machine that could sit quietly on my network, hold four SATA SSDs, and store my media and backups.

I already had a Raspberry Pi 4. So instead of buying a NAS, I decided to build one.

The result was a compact four-drive NAS based on a Raspberry Pi 4, a Radxa SATA HAT, and four 2 TB SATA SSDs. But the interesting part of this project wasn't installing Linux or creating RAID arrays.

It was designing the machine itself.

I wanted the SSDs to be individually removable, all important ports to remain accessible, the critical components to get enough airflow, and the whole thing to stay reasonably compact.

That meant designing my own enclosure.

This Instructable shows how the NAS came together, what hardware I used, how I designed the enclosure, and what I learned while turning a pile of boards and SSDs into an actual appliance.

If you're interested in the longer story behind the hardware design and the decisions that led to it, I also documented the project on my blog:

Read: Raspberry Pi Custom NAS: Hardware Design

Main Hardware

1. Raspberry Pi 4
2. Radxa ROCK Pi Dual/Quad SATA HAT
3. 4 × Verbatim Vi550 S3 2 TB SATA SSD
4. Power supplies for the Raspberry Pi and SATA HAT
5. Ethernet cable
6. Fasteners for the enclosure
7. 3D-printed enclosure parts
8. Noctua NF-A4x10 FLX 5V

Storage Layout

The four SSDs are divided into two RAID1 arrays:

1. 2 × SSD for media
2. 2 × SSD for backups

This means I sacrifice half of the raw capacity for redundancy, which is exactly the trade-off I wanted for this machine.

Software

The NAS runs Debian and uses standard Linux components rather than a dedicated NAS distribution.

The important pieces are:

1. Debian
2. mdadm
3. Samba
4. standard Linux monitoring tools

I deliberately wanted the storage layer to remain simple and understandable.

Before opening Fusion 360, I wrote down what I actually wanted from the machine.

The requirements were fairly simple:

1. four 2.5-inch SATA SSDs
2. small overall footprint
3. reasonable cooling
4. access to the Raspberry Pi and HAT ports
5. individually removable SSDs
6. no need to disassemble the entire NAS to replace one drive
7. easy access for maintenance

The last two requirements turned out to have the biggest influence on the design.

It would have been easy to create a box containing a Raspberry Pi and four SSDs.

But a box isn't necessarily a good enclosure.

If replacing a failed SSD requires removing several panels, disconnecting other drives and partially dismantling the computer, the design becomes annoying the first time something goes wrong.

So I decided that every SSD should have its own removable tray.

I already owned the Raspberry Pi 4, which made it the obvious starting point.

At the time I considered moving to a Raspberry Pi 5, but this was still an experiment. Buying another board before I knew whether the whole idea would work didn't make much sense.

The Raspberry Pi 4 also had more than enough performance for what I actually needed.

This NAS wasn't supposed to run virtual machines or become a homelab compute server. Its job was storage.

The more interesting problem was connecting four real SATA drives. For that I used a Radxa SATA HAT. The HAT provided the bridge between the Raspberry Pi and the four SATA SSDs and allowed the project to behave much more like a conventional multi-drive NAS than a collection of random USB disks.

There is an important trade-off here: the SATA bridge is a shared component. If it resets or fails, multiple disks can disappear at once.

For my use case that was acceptable, but it is worth understanding the limitation rather than pretending that a Raspberry Pi NAS has the same architecture as a server with independent SATA controllers.

A standard 2.5-inch SSD is already a wonderfully compact object.

Four of them aren't particularly large either.

The challenge is everything around them: airflow, the Raspberry Pi, the SATA HAT, mounting points and enough space to actually get your fingers inside the machine.

My first layouts therefore started with the SSDs rather than the Raspberry Pi. I arranged the drives as a compact storage block and designed individual trays around them. Each SSD can be removed separately.

This was one of those features that seemed slightly excessive while I was designing it, but made the finished NAS feel much more like an actual appliance.

A failed disk shouldn't turn into an evening project. Pull out the tray, replace the SSD, reconnect it and rebuild the array. The SSD trays became one of the central parts of the enclosure.

Instead of mounting all four drives directly to the chassis, each drive gets its own carrier.

The tray has two jobs:

1. Keep the SSD securely positioned.
2. Allow the drive to slide out without dismantling the rest of the NAS.

The surrounding enclosure provides the guides that keep each tray aligned. This also made the design easier to iterate.

I could change the enclosure without redesigning how the SSD itself was mounted, and I could print individual trays again if one needed adjustment.

This modularity wasn't something I planned as a grand engineering principle. It simply made the machine much easier to work on.

With the storage section defined, I could design the rest of the enclosure around the Raspberry Pi and Radxa board.

The important thing here was not just making the boards physically fit.

The connectors still needed to be usable.

It is surprisingly easy when designing a compact enclosure in CAD to create something that looks perfect on screen and becomes impossible to assemble in the real world.

A connector needs space in front of it.

A cable needs room to bend.

A screw needs enough clearance for a screwdriver.

And eventually you need to get the thing apart again.

Several iterations of the enclosure were essentially about discovering these small realities.

SSDs don't generate enormous amounts of heat, but putting four of them together with a Raspberry Pi and SATA controller inside a compact enclosure still creates warm spots.

So cooling was part of the enclosure design rather than something added after everything else.

The goal wasn't aggressive cooling.

It was simply to move enough air through the critical areas that heat couldn't accumulate inside the enclosure.

This is especially important around the Raspberry Pi and SATA hardware.

The final layout leaves a defined path for air through the machine while keeping the SSD section compact.

And because this NAS runs continuously, I prefer a slow, predictable airflow over trying to make the enclosure completely passive.

The first printed version wasn't the final NAS. Neither was the second. That is probably the most important part of designing your own enclosure.

CAD gives you confidence that everything fits. The printer tells you whether you were right.

Small issues appear immediately:

1. cable needs more clearance
2. connector is difficult to reach
3. tray is slightly too tight
4. screw is awkward to install
5. two parts technically fit but can't actually be assembled in that order

I went back and forth between Fusion 360 and the physical parts several times. With each iteration the enclosure became less like a 3D model and more like something I could actually live with.

Eventually I reached the point where I could remove a drive, access the electronics and work on the NAS without dismantling half of it. That was my definition of finished.

Once the enclosure design stabilized, the final assembly was straightforward.

The Raspberry Pi and SATA hardware went into their mounting positions, followed by the four SSD trays and cabling.

[IMAGE: final internal assembly]

The finished storage configuration is:

1. SSD 1 + SSD 2 → RAID1 media array
2. SSD 3 + SSD 4 → RAID1 backup array

Each pair therefore contains mirrored data.

With four 2 TB SSDs, the machine has 8 TB of raw flash storage and approximately 4 TB of usable mirrored capacity before filesystem overhead.

That may look inefficient if maximum capacity is the goal.

Maximum capacity wasn't my goal.

I wanted a small storage appliance where the failure of a single SSD wouldn't immediately mean restoring everything from another machine.

I chose Debian rather than a specialized NAS operating system.

There wasn't a particularly sophisticated reason for this.

I know Debian, I know how it behaves, and I wanted the NAS to remain a normal Linux machine.

The two mirrored arrays are managed with mdadm.

Conceptually the layout is simply:

The arrays are then mounted normally and exported over the network using Samba.

I won't reproduce a generic Debian/mdadm installation guide here because the interesting part of this project is the hardware rather than a particular set of shell commands.

More importantly, storage commands should always be adapted to the actual device names and filesystem layout of the machine being built.

RAID isn't backup. That sentence has been repeated so often that it has almost become background noise, but it matters particularly with a DIY NAS. RAID1 protects me from single SSD failure.

It doesn't protect me from accidental deletion, filesystem corruption, software mistakes or losing the entire machine. So the NAS is monitored and the important data is backed up separately.

I also monitor the machine itself rather than treating it as a black box.

At minimum, a storage server should make it obvious when:

1. an array is degraded
2. a disk disappears
3. storage is getting full
4. temperatures become abnormal
5. a backup stops working

A NAS that silently fails for six months isn't particularly useful redundancy.

The final machine is exactly what I originally wanted. It is small. It is quiet. It has four real SATA SSDs. The drives are mirrored.

Individual SSDs can be removed without taking the entire enclosure apart. And, perhaps most importantly, I understand every part of it.

There is no proprietary storage format and no mystery box between me and the data. If something breaks, I can open the enclosure, replace the component and change the design if necessary.

That was one of the unexpected benefits of building the NAS myself. I didn't just end up with storage. I ended up with a machine I can continue changing.

This NAS has been running long enough for me to see both the good parts and the limitations of the original design.

The Raspberry Pi 4 was a perfectly reasonable platform for the experiment, and the Radxa SATA HAT made a four-drive Pi NAS possible without turning it into a pile of USB adapters.

But the bridge is also one of the architectural limitations of the machine.

If I were designing a new NAS today, I would look much more closely at native PCIe/SATA connectivity and at making the storage subsystem less dependent on a single bridge.

And that is exactly what eventually happened.

The NAS kept evolving.

But I don't regret building this version first.

It solved the problem I actually had, taught me much more than buying a finished NAS would have, and gave me a working design that I could improve later.