The 9U Silent Homelab: Raspberry Pi 5, Docker, and a Dead 8TB Drive

The typical homelab showcase on Reddit or YouTube often resembles an enterprise server closet. Enthusiasts rack decommissioned Dell PowerEdge towers, run dual redundant 10-gigabit fiber switches, and proudly display 42U cabinets that draw 800 watts at idle while heating an entire basement. That aesthetic is impressive, but it represents a specific hobbyist obsession. For my daily requirements, computing infrastructure should remain quiet, draw minimal electrical power, and perform its designated tasks without demanding a second full-time job in systems administration.

That philosophy led me to construct my current homelab around a compact 9U wall-mounted rack. Rather than stuffing it with loud, power-hungry servers, I built a structured physical network backbone powered by an 8GB Raspberry Pi 5 equipped with a 128GB NVMe drive. For months, this entire setup quietly orchestrated my personal services, consuming under 25 watts from the wall.

Last week, the mechanical reality of budget storage caught up with me. My 8TB external USB hard drive died.

The ensuing failure provided a real-world test of my physical and logical architecture. The post-mortem highlighted the strengths of a structured residential rack, the physical vulnerabilities of USB-attached storage, and the deliberate separation of concerns that prevented an inconvenient drive death from wiping out my entire digital life.

The Physical Backbone: 9U Wall-Mounted Architecture

A reliable homelab begins with clean physical containment and structured cabling. Instead of letting cables tangle behind furniture, I mounted a 9U server cabinet to centralize power, switching, and compute:

Power Distribution (U1): A Linkbasic 1U 6-way aluminium moulded rack-mount PDU (CAB-P06) sits at the top of the cabinet. It delivers clean, master-switched power with surge suppression, keeping power bricks and cables routed safely inside the chassis.
Structured Patching (U2): A Connect 1U 24-port CAT6 FTP shielded patch panel (C6PPFTP) terminates solid-core FTP cable runs from Netix shielded dual RJ45 wall boxes installed across my office and living areas. Terminating all permanent runs into a fixed patch panel protects the internal cabling from mechanical strain.
Switching Core (U3): A Cudy 24-Port Gigabit metal switch (GS1024) connects directly beneath the patch panel. Short 0.5-metre patch cords link the switch ports directly to the patch panel jacks above it, creating a tidy, high-throughput local switching fabric with 48Gbps backplane capacity.
Wireless & Routing (U5): A Cudy AX3000 Wi-Fi 6 mesh kit (M3000W) provides whole-home wireless coverage. The primary gateway node sits on a cantilever rack shelf, connected via wired backhaul to the switch, while a secondary satellite node extends wireless coverage across the house.
The Compute Shelf (U5): Sharing the cantilever equipment shelf alongside the router sits the primary compute engine: an 8GB Raspberry Pi 5 with an M.2 NVMe HAT.

This physical arrangement delivers the organization and aesthetic satisfaction of an enterprise rack cabinet while generating virtually zero noise and drawing negligible electrical current.

The Compute Anchor: Raspberry Pi 5 and NVMe Boot

Prior generations of the Raspberry Pi always suffered from a fundamental storage bottleneck. Booting a Linux system from a consumer microSD card meant accepting sluggish random write speeds and anticipating filesystem corruption caused by worn-out flash cells.

The Raspberry Pi 5 changed this dynamic by routing a single-lane PCIe 2.0 interface directly to an external connector. By attaching an M.2 HAT and installing a 128GB NVMe solid-state drive, the hardware platform sheds its educational toy heritage. Random I/O throughput jumps by orders of magnitude. Package installations, container image pulls, and local SQLite database queries run with desktop-grade responsiveness.

On top of this physical foundation, I run Raspberry Pi OS Lite 64-bit. Omitting the desktop display server and graphical user interface leaves a lean Debian baseline that consumes roughly 180MB of RAM after a cold boot. Paired with the official 27W USB-C power delivery adapter, the board supplies full current to all four USB ports without throttling or dropping voltage.

Docker CE runs as a managed systemd service, serving as the sole workload runtime. Everything on the machine executes inside isolated containers managed via modular Docker Compose files.

The Architectural Separation: State vs Blobs

From the day I provisioned the machine, I adhered to one strict storage rule: container configuration and operational state must never mix with bulk binary assets.

The 128GB NVMe drive hosts the operating system root, container images, local configuration volumes, and application databases. Paths under /opt/docker/ house every Compose file and persistent volume. When a container runs an embedded SQLite database or generates internal application state, those transactions execute exclusively on high-speed NVMe storage.

The 8TB external 3.5-inch mechanical drive existed solely for bulk media. It was formatted as an ext4 filesystem and mounted under /mnt/storage/media via a persistent /etc/fstab entry. It stored thousands of video files, television series archives, anime libraries, and an extensive collection of digital books and reference manuals.

Consider the practical implementation in a simplified Docker Compose definition:

services:
  jellyfin:
    image: jellyfin/jellyfin:latest
    container_name: jellyfin
    restart: unless-stopped
    volumes:
      # Application state on fast, reliable NVMe
      - /opt/docker/jellyfin/config:/config
      - /opt/docker/jellyfin/cache:/cache
      # Bulk media read from external storage
      - /mnt/storage/media/movies:/data/movies:ro
      - /mnt/storage/media/shows:/data/shows:ro
    ports:
      - "8096:8096"
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Africa/Johannesburg

By mounting the external drive’s directories as read-only volumes for consumer services, the application layer treated the external drive as a passive data repository. This explicit separation proved to be the saving grace of the entire homelab.

The Weakest Link: 8TB on a USB Controller

In a rack cabinet equipped with shielded patch panels, enterprise-grade steel switching, and solid-state silicon, a consumer USB external hard drive was an obvious outlier.

Hanging a single 8TB spinning hard drive off a single-board computer via USB 3.0 is a common pattern in the self-hosting community. It is affordable, straightforward to configure, and avoids the initial capital expenditure of an enterprise NAS. It is also an architectural house of cards.

Standard desktop external hard drives present three structural liabilities when run 24/7 in a rack enclosure:

The USB-SATA Bridge Controller: Enclosure manufacturers use cheap bridge chipsets (often ASMedia or JMicron) designed for intermittent desktop file transfers. They handle sustained server workloads poorly. When the operating system issues spindown commands, or when an aggressive kernel poll queries drive telemetry, the controller bridge can lock up or silently reset the USB bus.
Thermal Stress: Sealed external enclosures lack active cooling fans. Inside a cabinet under prolonged sequential read or write operations, internal drive temperatures easily climb past 50 degrees Celsius. Sustained heat accelerates mechanical wear on drive bearings and head actuators.
No Redundancy or Early Warning: A single drive offers zero parity. Furthermore, passing SMART diagnostics through generic USB bridge controllers is often unreliable or completely unsupported by consumer firmware. Drive health degrades silently; the disk simply drops off the bus when a critical sector fails.

The Incident: When the Drive Died

The collapse happened without fanfare on a Tuesday afternoon.

An automated script running an indexing task threw an unhandled I/O exception. When I logged into the host via SSH, running a routine ls /mnt/storage/media hung the terminal indefinitely. The kernel had encountered unrecoverable hardware errors on physical sectors and protected the integrity of the filesystem by remounting /mnt/storage/media into read-only mode.

A quick inspection of dmesg revealed the typical diagnostic death spiral:

[142859.102341] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_status=CHECK_CONDITION
[142859.102355] sd 0:0:0:0: [sda] tag#0 Sense Key : Medium Error [current] 
[142859.102364] sd 0:0:0:0: [sda] tag#0 Add. Sense: Unrecovered read error - auto reallocate failed
[142859.102375] blk_update_request: critical medium error, dev sda, sector 419430480 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[142859.105210] EXT4-fs error (device sda1): ext4_lookup:1824: inode #2621441: comm ls: I/O error
[142859.105230] EXT4-fs (sda1): Remounting filesystem read-only

Within ten minutes, even read-only access evaporated. The drive began the dreaded rhythmic mechanical sweep: a faint hum, an internal click as the head actuator failed to calibrate against the platter surface, followed by a quiet spindown. The USB controller dropped off the bus entirely. A subsequent check using lsblk confirmed the diagnosis: device sda had vanished.

The Blast Radius: What Survived and What Vanished

Assessing the damage brought both relief and frustration.

Because all service configurations, databases, and Docker definitions lived on the 128GB NVMe SSD, the homelab itself never crashed. The physical network remained unaffected: the Cudy switch, patch panel, Wi-Fi 6 mesh, and wall outlet connections continued operating at full line rate.

On the compute host, Jellyfin, Calibre-Web, Audiobookshelf, and my internal utility containers remained running without interruption. Web interfaces responded instantly. Application schemas, user accounts, watch markers, reading progress, and curated playlists were completely intact.

However, the media files backing those applications were gone.

The lost drive held eight terabytes of movies, television seasons, anime series, and an extensive digital library of books. None of this data was mission-critical personal information. There were no financial records, family photographs, proprietary code repositories, or personal databases on that drive. All irreplaceable personal assets reside in encrypted, multi-tier cloud backups following the 3-2-1 rule.

Even so, losing eight terabytes of curated media represents hours of bandwidth, sorting, and manual curation wiped out in a single afternoon. It was an earned reminder that data you can technically replace still carries an operational cost when you fail to protect it.

Architectural Lessons for Single-Board Computing

This failure clarified the operational boundaries of running a homelab on a single-board computer:

Decoupled Architecture Protects Operational Sanity: Keeping container state on the primary NVMe drive prevented a storage failure from becoming a total system rebuild. If I had followed the naive approach of running container configurations and databases directly from the external drive, this incident would have forced a full recovery from raw backups.
USB Protocols Were Never Designed for Server Storage Fabric: Using external USB enclosures for high-density storage in an always-on environment is an architectural compromise with an expiration date. USB controllers introduce latency jitter, mask diagnostic telemetry, and introduce fragile physical cables into an infrastructure stack.
Bulk Media Demands Mirroring or Parity: Backing up eight terabytes of media to cloud storage is often cost-prohibitive for hobbyist setups. The pragmatic answer is local redundancy. A two-bay storage pool running a simple mirror array would have absorbed this mechanical disk failure with zero downtime.

What Comes Next

The Raspberry Pi 5 and the 9U wall-mounted rack have proven themselves. The setup manages compute, networking, and container runtimes with outstanding thermal efficiency and near-silent operation. I have no intention of replacing the Pi with a loud enterprise rack server.

The storage layer, however, must evolve to match the quality of the surrounding network cabinet.

The path forward requires retiring single-disk USB enclosures entirely. My next iteration will introduce a dedicated storage architecture, either through a multi-bay Direct-Attached Storage (DAS) unit with hardware RAID and active cooling sitting on the lower rack shelf, or a dedicated, low-power Network-Attached Storage (NAS) appliance running TrueNAS with ZFS mirrors connected over gigabit ethernet.

Until that replacement hardware arrives, my Raspberry Pi 5 continues to run its container fleet from its silent NVMe drive inside the 9U cabinet. The media containers are currently empty, pointing to unpopulated mount points, waiting for reliable disks to return.

Component failures are unavoidable in any digital system. Sound homelab architecture ensures that when hardware inevitably breaks, the blast radius remains strictly localized, predictable, and simple to recover from.