Unraid 8 讲解：从 2005 年的白牌硬盘，到底座系统的更换

2026年8月14日，unRAID 官方 YouTube 频道 The Uncast Show 放出了一期视频《unRAID 8 Explained: New Distro, Docker Compose, Backups and more | Uncast (Part 2 of 2)》，节目回顾了 unRAID 从诞生至今的发展历程，同时重点介绍了未来的发展方向。

其中最值得关注的是 unRAID 8 的规划：官方明确表示，unRAID 8 将更换底层系统，从 Slackware 转向 Fedora 生态中的 uCore。

关于这期节目：这是 The Uncast Show 关于 Unraid 20 年发展历程的第二期节目。上一期主要回顾了 Unraid 从诞生到今天的发展历程，而这一期在继续回顾历史的同时，将重点放在了 unRAID 8 的未来规划上。
节目中，Unraid 创始人 Tom 主要负责回顾 Unraid 从最初的个人 DIY 项目，到今天成为一家独立公司的发展过程；产品总监 Eli 则介绍了当前产品以及 unRAID 8 的设计方向。
因此，这一期节目比较特别：它既是一场对 Unraid 20 年历史的回顾，也可以看作是目前官方对 unRAID 8 未来方向的一次集中介绍。

以下正文是基于播客全文整理的内容，主要对节目中值得关注的部分进行简述，并加入一些必要的背景说明。

重点内容在第 6 章：6. unRAID 8 为何转向 Fedora 底座：不可变 Linux 与 Universal Blue（uCore）

1. 2005 年：Tom 当初要解决的问题

2000 年代初大屏高清电视（plasma TV，等离子电视）、DVD 光盘数字化与 HTPC 软件同时兴起，Tom 恰逢换工作的空档，把 DVD 收藏数字化到廉价白牌硬盘（white-label hard drives）时意识到：一块盘坏掉就等于白干上百小时，于是决定要做冗余。

白牌硬盘（white-label hard drives）指的是一种没有以正常制造商品牌形式销售的廉价硬盘。白牌硬盘不等同于翻新盘、二手盘、水货盘或 OEM 盘等，它与这些东西可能存在交集，但不是同义词，白牌硬盘主要描述的是品牌/标识。

2. 校验与冗余：第一个 unRAID 阵列

Tom 不想用 Linux MD 建 RAID 5 再把文件重搬一遍，于是修改 MD 驱动做出“数据盘各自独立 + 一块校验盘”的 unRAID 阵列。在儿子的建议下他开发了 unRAID 的前端界面 Web GUI，确立“把 Linux 藏起来”的理念，“tower”这个默认主机名也来自他儿子。

由于早期的 Unraid 只是 Tom 自己使用，完全没有前端界面，而是通过纯 Linux 命令行的形式进行维护，因此他的儿子建议他开发易于用户使用的前端界面。另外，如果大家有印象，unRAID 安装之后的初始名称就叫作“Tower”。

3. Web GUI、“Tower”与插件的诞生

unRAID 4 是首个对外版本：基础 Web GUI、缓存盘（应对千兆网速超过阵列单盘写入）和 User Shares（用户共享），定位纯 NAS。unRAID 5 引入 PHP 并带来正式插件机制，社区由此开发出沿用至今的 Dynamix Web GUI。

博主在《新手教程：unRAID 是如何存储文件的？》中讲解过什么是 User Shares（用户共享）。

4. 64 位、虚拟机与 Docker：通往 unRAID 6 之路

unRAID 6 迁移到 64 位，原计划用 KVM 实现“一个应用一个虚拟机”，Docker 出现后转向 Docker 方案，社区做出 Community Apps（简称为 CA，即应用市场，由后来加入公司的 Squid 维护至今），6 还加入了多存储池支持。随后谈到做 unRAID 7 的动机 —— 更多商业用户和进阶家庭用户，并点出 USB 启动授权这把双刃剑：方便但闪存易坏。

也是从 unRAID 7 开始，unRAID 正式从买断制过渡到订阅制，博主有专门文章介绍过 —— 《2024 unRAID 新付费制解读》。

5. ZFS 支持与 USB 镜像启动（unRAID 7）

unRAID 7 两大主线：应社区要求集成 ZFS，以及支持把启动迁移到镜像 ZFS 池（内部启动，internal boot）加 TPM 授权，让 U 盘启动不再是唯一选择。Tom 还指出 AI 时代安全漏洞雪崩，维护 Slackware （unRAID 系统底座）日益吃力，为转向 Fedora 埋下伏笔。

6. unRAID 8 为何转向 Fedora 底座：不可变 Linux 与 Universal Blue（uCore）

几乎每天雪崩式的安全更新正在挤占核心产品的研发精力，因此 unRAID 8 改用 Fedora 底座。Tom 强调 unRAID 本就是从 SquashFS 加载 root filesystem（根文件系统）的 immutable OS（不可变操作系统），这是选择 Fedora 的重要前提。

这里需要先解释一下视频中反复提到的 Immutable OS（不可变操作系统）。

“不可变”并不是说 unRAID 运行后什么都不能修改，而是指操作系统的基础部分采用了一种特殊的设计：系统启动时从 SquashFS 镜像加载根文件系统，而不是把这部分系统文件作为普通的可写 Linux 系统一直修改。

简单来说，可以把它理解成给操作系统保留了一份“干净的母版”。

用户在运行过程中可以对系统进行各种操作，即使误删或修改了部分系统文件，只要重新启动，unRAID 仍然可以从这份基础镜像重新加载一个干净的系统状态。

当然，这并不意味着用户的数据也会被还原。Array、存储池、Docker 数据、虚拟机磁盘以及其他用户数据并不会因为重启而恢复。这里的“不可变”主要针对的是操作系统本身。

这种设计其实并不是 unRAID 8 才出现的。Tom 介绍，unRAID 很早就采用了从 SquashFS 加载根文件系统的方式，因此即使用户把 root 下的系统文件破坏掉，重新启动后仍然可以恢复到一个干净的系统状态。Eli 也因此认为，Tom 很早就在 Slackware 上实现了类似今天 Immutable Linux 的设计。

那么问题来了：既然 unRAID 原本已经有这种设计，为什么 unRAID 8 还要更换底层系统？

原因之一，就是维护 Slackware 底座本身正在变得越来越困难。随着 Linux 软件包和安全漏洞不断增加，Lime Technology 需要花费越来越多的精力维护底层系统，而这些工作并不是 unRAID 核心产品本身。

因此，unRAID 8 希望转向 Fedora 生态，同时保留原有的不可变系统理念。最终选择的是由 Universal Blue 社区维护的 uCore，它本身就是 Fedora 的一个变体。

uCore 的一个重要特点就是支持不可变系统和分层（layering）。这意味着 unRAID 可以拥有一个相对固定、干净的基础系统，同时又能够在这个基础之上增加额外的软件包和驱动，而不必像过去一样完全依赖 unRAID 插件机制去解决所有问题。

Eli 在节目中举了一个很直观的例子：他自己的 Wi-Fi 网卡目前需要通过插件和自行构建的驱动包才能正常使用，而未来采用新的底层系统后，可以直接利用 Fedora 生态中的软件包和驱动，再将它们叠加到基础系统之上。

因此，unRAID 8 转向 Fedora 并不只是简单地“把 Slackware 换成 Fedora”。更准确地说，是希望借助 Fedora 及 Universal Blue 的生态，在保留 unRAID 原有不可变系统优势的同时，获得更加标准化的 Linux 软件包、驱动和硬件支持，并减少 unRAID 团队维护底层 Linux 发行版的负担。

7. 内核灵活性与更好的硬件支持

更大的底座换来更标准的内核与开箱即用的硬件支持，目标是装机体积控制在 4GB 以内。发行版与管理界面解耦后，用户可自行更新底座、更快拿到纯安全补丁，甚至选择运行最新内核而不必等官方的 LTS 节奏。

博主之前同样的《2024 unRAID 新付费制解读》文章中提到过 unRAID 官方关于安全方面更新方面的内容。我当时指出 unRAID 新的付费形式带会来安全更新方面的疑问，以及可能的安全更新形式发展方向。

如果更换了系统底座，那么上述相关的问题都可以得到很好的解决 —— 用户可以自行更新内核来实现安全更新，完全不需要像现在这样等待 unRAID 官方发布新版本才能解决安全上的问题。

8. 浑然一体的界面与数据自主

unRAID 8 将进行界面与 API 大改，让 Docker、VM、存储等各子系统体验一致 —— 会一个就会全部。目标是让任何人轻松上手、运行自己的云，帮大家把数据从云端拿回来。

9. 内置备份与原生 Docker Compose

unRAID 8 内置备份方案（可备到云端、S3、其他 unRAID 服务器，支持快照与完整恢复），并把 Docker Compose 原生融入现有模板体系、与 XML 模板并存。Eli 强调这一切以不丢失任何高级功能为前提，高级功能会在需要时主动浮现。

当前 7 版本并不支持原生的 Docker Compose，用户需要通过安装插件的形式来实现，并且 Docker Compose 也不与当前 unRAID 原生的 Docker XML 体系集成，使用 Docker Compose 会增加额外的维护成本（就比如我写下这篇文章时前段时间出现的 Docker Compose 图标不显示的问题）。当切换到 8 版本后，这个问题就可以完美解决。