How WindowsArea Builds a ZimaBoard 2 Mini Homelab With RAID 1

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Special thanks to WindowsArea for documenting a complete first build with ZimaBoard 2 in ZimaBoard 2: First Impression of the Mini Homelab. The video does more than open the box: it assembles a compact multi-drive frame, boots ZimaOS, detects two 4TB hard drives, creates RAID 1 storage, and installs self-hosted services including Immich and Jellyfin.

That sequence makes the video useful for anyone wondering where ZimaBoard 2 Mini Home Server fits between a bare single-board computer and a conventional NAS appliance. The hardware is small and server-oriented, while ZimaOS turns the first storage and application decisions into a browser-managed workflow.

The result is a genuine mini homelab, but not a magic one-click cloud. WindowsArea still has to assemble the hardware, connect the drives, initialize storage, wait for RAID synchronization, and decide which applications should use the new pool. That balance between accessibility and owner responsibility is the most important part of the test.

Watch WindowsArea’s full setup: The original German video follows the project from the shipping box and four-drive frame to the ZimaOS dashboard, RAID 1 storage, file management, Immich, and Jellyfin.

Source note: This article reorganizes the assembly process, interface observations, and application tests shown in WindowsArea’s video. ZimaOS screens, application versions, storage behavior, synchronization time, hardware accessories, and supported drive configurations can change after publication. RAID protects availability after a drive failure; it does not replace an independent backup.

The central finding is that ZimaBoard 2 can turn a collection of standard components into an approachable local storage and self-hosting platform. Its value comes from the combination of x86 compatibility, direct storage connections, an expandable physical design, and a graphical operating environment—not from eliminating the need to understand storage and recovery.

WindowsArea begins unboxing ZimaBoard 2 and a multi-drive mini homelab kit

WindowsArea begins with the ZimaBoard 2 hardware, drive components, and the frame that will turn the board into a compact storage server.

Why ZimaBoard 2 Makes Sense as a Mini Homelab

A homelab is not defined by a server rack. It is an environment where the owner can learn storage, networking, containers, backup, and application hosting on hardware under personal control.

ZimaBoard 2 condenses several server-oriented features into a small x86 platform:

  • An Intel N150 quad-core processor
  • 8GB or 16GB of LPDDR5 memory, depending on model
  • 32GB or 64GB of onboard eMMC storage
  • Two native SATA 3.0 connections
  • Two 2.5GbE Ethernet ports
  • USB 3.1 and Mini DisplayPort connectivity
  • An exposed PCIe 3.0 expansion interface
  • A fanless aluminum chassis designed to act as the heatsink

The ZimaOS dashboard in WindowsArea’s test reports approximately 7.51GB of usable memory, identifying the system as the 8GB-class ZimaBoard 2 832 rather than the 16GB 1664 model. That is enough for the storage workflow and selected Docker applications shown in the video, but capacity planning becomes important as more services are added.

Unlike an ARM development board, the x86 platform supports a broad selection of familiar server operating systems and container images. Unlike many sealed mini PCs, it exposes native SATA and PCIe connections so that storage and networking can be expanded without relying entirely on USB adapters.

-15% OFF
Single board computer zimaboard2

The Physical Build Is More Modular Than a Conventional NAS

WindowsArea lays the components across the workbench before assembly. The kit includes the ZimaBoard 2, a metal drive frame, brackets, drive cables, a small cooling component, and space for several hard drives.

ZimaBoard 2, hard drives, cables and frame parts prepared for homelab assembly

The open workbench shows how the board, drive frame, cables, cooling hardware, and standard hard drives become one modular system.

This approach differs from a closed two-bay NAS. The components remain visible and replaceable, and the frame can physically hold more drives than the two detected in the initial ZimaOS storage test. Additional positions create room for future projects, but physical capacity does not automatically create electrical connectivity. Every added drive still needs a data path, sufficient power, mounting support, and an intentional storage role.

Native SATA provides the simplest path for the first two drives. Expanding beyond those connections may require a compatible PCIe storage controller and suitable cabling. The PCIe card, connected drives, and any fan also add power and cooling requirements that should be planned before the server is placed into continuous use.

Assembling the Frame Turns the Board Into a Storage Appliance

By the middle of the video, WindowsArea has mounted ZimaBoard 2 above the drive frame and installed the hard drives below it. The finished structure remains far smaller than a rack server while keeping the board and storage accessible.

WindowsArea completes a compact ZimaBoard 2 frame with multiple hard drives

The assembled frame places ZimaBoard 2 above a multi-drive cage, producing a compact and serviceable mini-homelab layout.

The open design has several practical advantages:

  • Drives can be replaced without dismantling a sealed enclosure.
  • Cable paths and indicator lights remain visible during troubleshooting.
  • The PCIe slot stays accessible for a storage or network expansion card.
  • Air can move around the drives and the board’s passive heatsink.

It also requires more care than a finished NAS. The server needs a stable surface, strain relief for power and SATA cables, clearance around the heatsink, and protection from accidental contact. Mechanical hard drives should be mounted securely and kept away from repeated vibration or impacts.

The First ZimaOS Boot Reveals the Actual Test Configuration

WindowsArea opens ZimaOS through the board’s local IP address in a web browser. The dashboard combines system status, storage, network activity, applications, files, backup, virtual machines, and remote-access options in one interface.

At the captured moment, the system reports approximately 2% CPU use, 9% memory use, around 2.4 watts of processor power, and a temperature near 33°C. These are idle or light-load observations rather than long-term power and thermal benchmarks, but they show how the dashboard makes basic system health visible to a beginner.

More importantly, ZimaOS announces that it has found two new ST4000VN006 drives, each with 4TB of raw capacity. These are the two drives used for the storage pool demonstrated later in the video.

ZimaOS detects two new 4TB hard drives in the WindowsArea mini homelab

ZimaOS detects both 4TB drives and presents a direct management path before the storage pool is created.

The correct order is important. The owner should confirm model numbers and capacity before initializing anything. Selecting the wrong drive can destroy existing data, so any reused disk must be backed up before it is added to a new storage pool.

The official ZimaBoard 2 getting-started guide explains the initial power, network, storage, device-discovery, and ZimaOS sign-in process.

Two 4TB Drives Become a 4TB RAID 1 Pool

WindowsArea combines the two detected 4TB disks into a RAID 1 safe-storage pool. RAID 1 writes matching data to both drives, so the usable capacity is approximately the size of one drive rather than the combined 8TB raw total.

This tradeoff provides continuity after a single-drive failure. If one member of the mirror stops working, the data should remain available from the surviving disk while the failed drive is replaced and the mirror is rebuilt.

ZimaOS synchronizes a 4TB RAID 1 safe-storage pool across two hard drives

The ZimaOS storage panel shows approximately 4TB of available RAID 1 capacity while the mirror synchronizes.

Initial synchronization can take hours because every part of the mirror must be prepared. During that period, the owner should keep the server powered, avoid disconnecting a drive, and allow adequate airflow around the disks.

The synchronization indicator is also a reminder that a storage pool has state. A “healthy” label, degraded warning, rebuilding status, or drive error needs attention. RAID should not be treated as something configured once and then ignored indefinitely.

RAID 1 Protects Availability, Not the Entire Data History

A mirrored pool protects against one disk failing. It does not protect against every event that can remove data:

  • Accidental deletion is mirrored to both drives.
  • Ransomware or application corruption can affect both copies.
  • Electrical damage may reach the entire server.
  • Theft, fire, or water damage can remove both drives together.
  • A mistaken administrator action can alter the complete pool.

A complete plan therefore adds an independent backup with version history. The widely used 3-2-1 approach keeps at least three copies, uses two storage types, and places one copy away from the primary server.

The official ZimaOS 3-2-1 backup guide covers local, LAN, USB, Zima, and selected cloud destinations, along with scheduling and retained versions.

A related community build, ZimaBoard 2 RAID 1 and Home Assistant Private Cloud, shows how another creator combines mirrored storage with self-hosted services while preserving a separate backup plan.

ZimaOS Makes the Storage Useful to Applications

Creating RAID is infrastructure work. The server becomes useful when files and applications have a deliberate place on that storage.

ZimaOS provides a graphical Files application and an App Store for Docker-based services. That removes much of the initial container configuration, but it does not remove the need to understand persistent data. Each application should be mapped to a known folder on the storage pool so that its database, settings, thumbnails, and user content can be backed up and migrated.

Before installing many services, the owner should document:

  • Where each application stores persistent data
  • Which folders contain replaceable cache and which contain originals
  • Which ports and accounts expose the service
  • How the application is updated
  • How its data would be restored on a clean installation

The beginner-oriented structure seen in WindowsArea’s walkthrough resembles the workflow described in How SjslTech Tests ZimaOS as a Beginner-Friendly Home Server OS: storage comes before applications, and local operation should be verified before remote access is added.

Immich Turns the RAID Pool Into a Private Photo Service

WindowsArea opens Immich near the end of the video. Immich is a self-hosted photo and video platform that can organize a personal library and receive uploads from supported mobile clients.

Immich welcome screen runs on the WindowsArea ZimaBoard 2 mini homelab

The Immich welcome screen confirms that the photo service is running locally on the new ZimaBoard 2 storage platform.

Reaching the welcome screen proves that the application has launched. It does not yet prove the complete photo workflow. Before trusting it with a large library, the owner should create the administrator account, confirm the upload location, test a small set of original files, review mobile background behavior, and include both the photo originals and Immich database in the backup plan.

For a complete photo-focused workflow, see How Just Jean Builds a Private Photo Cloud With ZimaBoard 2.

Jellyfin Adds a Different Kind of Storage Workload

The browser tabs in WindowsArea’s application test also show Jellyfin. While Immich organizes personal photos and videos, Jellyfin turns folders of films, television, music, and other media into a streamable library.

The storage requirements differ:

  • Immich depends on original uploads, thumbnails, metadata, and its application database.
  • Jellyfin depends on correctly mapped media folders, metadata, client compatibility, and codec support.
  • Direct play mainly uses storage and network throughput.
  • Transcoding can place a much heavier load on the Intel N150 and integrated graphics.

A useful first test is one local client with media that can direct play. Importing a large library before checking paths, permissions, and playback behavior makes later troubleshooting more difficult.

What WindowsArea’s Build Proves—and What It Does Not

Stage What the Video Demonstrates What Still Needs Long-Term Testing
Physical assembly ZimaBoard 2 and several drives can fit into a compact, modular frame. Cable strain, vibration, sustained temperatures, and power behavior.
Drive detection ZimaOS identifies the two connected 4TB drives and offers a graphical management path. Long-term SMART health, error reporting, and replacement workflow.
RAID 1 Two 4TB drives create approximately 4TB of mirrored safe storage. Degraded-mode operation, rebuild time, and tested recovery after failure.
Immich The self-hosted photo application launches on the local server. Large-library indexing, mobile backup reliability, database recovery, and multi-user use.
Jellyfin The same ZimaOS system can host a private media service. Codec compatibility, concurrent streams, subtitles, and transcoding capacity.

Who Should Build a ZimaBoard 2 Mini Homelab?

WindowsArea’s configuration is best suited to someone who wants more control than a sealed NAS offers without beginning with a large rack server.

  • Homelab beginners can learn storage, RAID, Docker applications, and local networking through a graphical interface.
  • Privacy-conscious households can create local destinations for photos, files, and media.
  • Creators can separate active media libraries from cloud-only storage.
  • Self-hosting enthusiasts can run several services on a compact x86 platform.
  • Developers and administrators can use the board as an experimental node, edge server, or virtualization platform.

The 8GB model used in the video is a sensible starting point for selected services. Users planning many concurrent containers, larger databases, virtual machines, or heavier multitasking should evaluate the 16GB configuration and the CPU requirements of the complete workload.

WindowsArea’s Build Shows the Real First-Homelab Sequence

The strongest part of WindowsArea’s first impression is the order of operations. The project begins with hardware and drive mounting, then confirms that ZimaOS can see the disks, creates a mirrored pool, waits for synchronization, and only then starts turning storage into photo and media services.

That sequence is more valuable than a list of possible apps. A dependable homelab starts with known hardware, intentional storage, and visible recovery boundaries. Applications come afterward.

ZimaBoard 2 makes the process compact and approachable, while the open frame, standard drives, x86 architecture, and PCIe expansion preserve room for future experimentation. ZimaOS reduces setup friction, but the owner remains responsible for backup, accounts, updates, remote access, and testing how the server behaves when something fails.

Watch WindowsArea’s complete ZimaBoard 2 mini-homelab video for the original German assembly and software walkthrough. If you are building a ZimaBoard storage server, configuring RAID, or choosing apps for your first homelab, join the ZimaSpace community to ask questions and share your setup.

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.