Homelab搭建实录（一）——需求分析及对应解决方案

本文含有大量表格，建议在PC端进行阅读。

前言

“前言”部分与本文主题无关，且含有部分作者的负能量宣泄。
如您是奔着技术和对应思考来的，请直接从需求分析开始阅读。

最近或许实在是对未来有些焦虑，一连更新了好几期关于人生、未来、职场的碎碎念（还有几期在草稿箱里，但暂时有点疲倦，不想再写这类主题的内容了）。本着保持持续更新和换换脑子的想法，决定提前开设新专栏：Homelab搭建实录。

按原计划，站长准备将全自动加密备份方案落地后，再创建这一专栏进行分享。但近期，现实生活中的职场失意、亲密关系建立不畅、获得感缺失、Overwhelming等等因素，让站长忍不住想提笔分享些新的文章，来减轻下心底的恐慌和迷茫。

需求分析

本部分的隔离、分级方案，与现实生活中的“等保”等成熟方案没有对应关系，纯粹笔者DIY。
后续笔者更系统化学习后，可能会再次优化迭代。

从较为宏观的角度看，站长对Homelab的需求可以用以下表格概述：

需求	描述	重要性
网络存储	应通过中心化的设备和系统集中管理存储，并允许共享存储至网络中的其他服务	5
隐私安全	依据所运行服务重要性分区隔离；任何备份到外部非可信存储的数据应进行加密	5
数据安全	应为相关数据全面配置两地三中心的备份策略，将数据定期同步备份到外部存储	5
存算分离	为提高稳定性，存储设备和系统不应提供除基础网络存储服务外的任何服务	4
灾难恢复	相应的设备和系统应能在断电等极端情况结束后，自行重启并恢复	3
服务监测	应具备监控各重点服务的能力，在监测到故障时及时发送告警并尝试自行恢复	3

针对重要性≥4的重点需求，可以拆分为以下更具体的细项需求：

网络存储

网络存储，首先要选定传输协议。常用的网络协议有Samba/CIFS、NFS、WebDav等，不同的网络协议有不同的优劣点。例如，针对NFS协议，如需实现较为复杂的鉴权或数据流加密，需要使用NFSv4+Kerberos，其配置相比Samba/CIFS会复杂许多。其次，主板、网卡等硬件尽量选择有更多驱动支持的版本（可以参考网上玩“黑群晖”的文章，一般其中列出的支持性都会比较广泛），配备ECC内存以便提高数据稳定性，以及选用合适的交换机、配置合理的网络拓扑，以防大量的数据交换使一些羸弱的设备带宽被占满，影响服务运行。最后，如硬件较新，操作系统尽量选用现代化操作系统（如基于Debian修改而来的Truenas Scale），而非FreeBSD内核的稳定系统，以便实现良好的兼容性。

网络存储	子需求描述	重要性
协议支持	支持鉴权、加密的的文件共享协议	5
硬件保障	广泛驱动支持的主板；ECC内存；选用交换机、配备高速网口的主板保障带宽	5
操作系统	应具有良好的驱动支持，以及带有Web UI，以便管理共享存储服务	4

隐私安全

保障数据的隐私安全，需要先针对服务/数据进行保密等级划分。有了不同的保密等级后，进行网络隔离、硬件隔离、数据加密就有了对应的依据。例如，NAS的保密等级相较阿里云OSS的保密等级高，因此NAS中的数据备份到阿里云OSS时应进行数据加密。此外，为了进一步保障隐私安全，还应部署一套IDS系统用于分析出口流量，以便及时发现是否存在可疑服务外连。

隐私安全	子需求描述	重要性
数据加密	从高保密等级流转到低保密程度的数据应加密处理	5
网络隔离	不同保密等级的服务应通过VLAN、反向代理等方式进行联通和隔离	5
硬件隔离	极高保密等级设备/信息载体应独立放置，使用时通过唯一入口与内网联通	5
流量分析	应流量镜像抽样分析出口流量，检查是否存在可疑外联服务	4

数据安全

数据安全，主要需注意三个方面：备份、校验、快照。对于备份，应遵守最基本的两地三中心规则，副本越多越不容易丢失。即使搭建了一套专用于存储备份的NAS，若各类数据只留有一份，则风险仍然是巨大的。对于校验，应作为数据备份完毕后的必要操作。若数据在备份途中出现错误，无法通过完整性校验，则还能及时拯救；若配置了自动备份脚本，却不清楚备份脚本存在权限问题导致写入数据不完整，备份无法还原，相当于白备份，还容易因认为已有了一套备份，降低平时对敏感操作的警惕心、敬畏心，引发更严重的事故。对于快照，应尽量选用底层支持写时复制等方式的文件系统，以便快速创建快照且减少占用的空间。

最后，硬件上的冗余也非常重要。最直接的，存储设备所装载的磁盘应组成RAID，减少因硬盘损坏导致相应数据完全丢失的可能性。如使用Ceph等分布式文件系统，则更应在网络链路上、集群节点上做好冗余，避免因故障导致数据不一致，只能强制回滚。

数据安全	子需求描述	重要性
自动备份	从高保密等级流转到低保密程度的数据应加密处理	5
数据校验	极高保密等级设备/信息载体应独立放置，使用时通过唯一入口与内网联通	5
数据快照	不同保密等级的服务应通过VLAN、反向代理等方式进行联通和隔离	5
硬件冗余	NAS所装载的硬盘应组成RAID阵列，网络/集群节点等也应留有足够冗余	4

存算分离

站长的Homelab并不会集中于一台设备（ALL IN BOOM）。总的来说，站长将需求划分为存储、计算、网络三块，且争取降低彼此间的耦合程度。

计算服务应是其中依赖程度最低的，只需通过为不同重要程度的计算服务配置隔离，保障计算服务崩溃不会牵一发而动全身，减少对其他服务的影响。对于存储服务，为便于进行数据备份和管理，需要统一存储后端；同时，存储后端应尽量满足极端情况下文件的完整性。最后，网络服务是重中之重，因为存储、计算是相互分隔的，而网络服务就是打通以上两者的桥梁。为此，站长需要通过一台相对独立的设备配置路由服务，并在其上配置堡垒机、内网穿透和VPN通道，以便在存储、计算出现问题时能及时接入内网进行修复。

此外，由于存算分离，服务需要向远程存储后端申请空间，因此选定一个兼容相应服务的传输协议也是必需的。例如，在采用Samba/CIFS协议进行传输时，若未配置nobrl参数，则以Sqlite为数据存储方式的服务会报以下异常：SQLITE_BUSY: database is locked。

存算分离	子需求描述	重要性
文件完整	应尽可能保障在网络崩溃等极端情况下文件的完整性，避免文件损坏	5
独立网络	路由服务应部署在独立设备上，以便调整配置或修复问题	5
协议支持	与远程挂载服务相兼容的的文件共享协议	5
服务隔离	不同重要程度的计算服务应相互隔离，减小异常崩溃影响面	4
统一存储	应尽可能统一整个Homelab的存储后端，以便进行数据备份和管理	4

解决方案（拟）

以上需求，比较偏理论化。即使做了一轮细化，也是相对抽象的。

因此，接下来站长会对需求、需求之下暗藏的子需求、考虑现实环境后发掘的新需求，进一步拆解为实际需要的参数和解决方案。（注：交换机、网线、硬盘、路由器等硬件选用差异不大，不再叙述，依据自己的设备数和存储容量找靠谱店铺购买即可）

拓普龙 & 永擎E3C246D4U2

首先解决存储服务器的硬件配置。站长并没有一个地下室专门拿来放存储设备，没有19英寸标准机柜，也没有用来安置运营商的一体化机柜的上海院子。由此，一个相对较小且具备一定拓展性的方案是比较合适的。

相对较小+具备一定拓展性，市面上最容易找到的应是各类基于mATX主板的方案。前文站长列出的各项需求，细化到主板可以写成：①高速网口（≥2.5G）；②具备IPMI或类似功能；③应支持ECC内存；④出品方应为中大厂；⑤原生具有较多SATA口或PCIE拓展位。

基于此搜索发现，可能只有超微或华擎的工作站主板比较合适。搜索过程中，根据帖子[主板] 9700K搭建ESXI，求推荐带IPMI主板，越小越好叙述，永擎C246系列的特点恰好满足站长的需求，由此就选定了永擎E3C246D4U2作为Homelab系列中存储服务器的主板。（注：实际使用过程中，出现过开机异常缓慢、掉NVMe等奇怪的问题。可能还是超微的工作站主板更好一些）

解决完主板，站长就开始摸索合适的机箱。经过一轮筛选，经典HP GEN8、拓普龙、宝藏盒，新出的见方M，3D打印的QNAS系列机箱进入决赛圈（其中最喜欢的是QNAS。但后面发现，QNAS机箱的各个版本均仅支持ITX主板，因此无奈放弃）。站长准备购买的时候，全新的宝藏盒网上现货很少，见方M刚上架比较担心品控，HP GEN盘位相对少一些，因此最终选择了拓普龙作为存储服务器的机箱。

TrueNAS Scale

对于存储服务器，由于其只需要提供网络存储服务，因此站长希望为其安装一套为NAS场景设计的操作系统。市面上比较流行的方案包括黑群晖、Unraid、OpenMediaVault、TrueNAS Core、Truenas Scale。那么，最后为什么站长选择了Truenas Scale？

黑群晖离不开“黑”，不确定是否会随着政策变化对黑群晖批量打击，不作考虑。
Unraid需商业授权且价格较高。尽管网络上有许多“开心版”，但考虑到数据稳定性，不作考虑。
OpenMediaVault功能相对来说较为简陋，ZFS等功能需通过安装插件才能启用，不作考虑。
TrueNAS Core底层为FreeBSD，对ACL权限支持有限；同时，维护团队已终止支持Truenas Core，不作考虑。

相比之下，Truenas Scale虽较为臃肿，具备k3s/docker、虚拟机等站长用不上的功能，但其在ZFS文件系统、快照管理、定期备份等方面的功能确能有效覆盖站长的需求。因此，最终站长选定Truenas Scale为Homelab的存储服务器操作系统。

Proxmox VE

为了对不同等级的数据、服务进行隔离，虚拟化是一个比较直接的做法。不同等级的服务运行在不同虚拟子网的虚拟机中，由此可以方便地实现隔离。同时，由于前文提到的“存算分离”，对于SLA要求不高的服务，可以将存储空间托管到存储后端，因此运行服务虚拟化的机器对存储空间的要求不大。

比较出名的虚拟化服务有ESXi、Hyper-V、Proxmox VE。对于ESXi，其对运行空间的要求比较高，在默认配置下将占用120G空间作为虚拟内存，且备份和迁移的方案比较“企业级”，难操作的同时还可能会被卡License；Hyper-V在个人计算机上简单运行虚拟机还是比较合适的，但作为一个虚拟化方案管理一系列服务，在互联网上能够直接找到的参考信息比较少；因此以上选项中，站长更偏向于使用Proxmox VE作为虚拟化方案。

在实际使用过程中，Proxmox VE还能够方便地搭载Samba/CIFS、NFS、iSCSI等多种形式的存储，支持自动使用ZSTD压缩并备份虚拟机文件到远程存储，支持简单的Linux Bridge甚至Open vSwitch，比较切合站长的需求。

Docker Volume & Samba/CIFS

利用虚拟化，可以安全、隔离、易于备份管理地运行各类服务（例如：Immich，Miniflux，Nocodb，Gitlab）。其中，社区常见的虚拟化方案可大概分成三派：虚拟机/Docker或k8s/k3s（尽管还能通过Proxmox VE的LXC进行隔离和部署，但可参考资料稀缺，且灵活性有限，因此不作描述）。

在简中社区，采用k8s/k3s方案对Homelab服务进行管理的朋友，据观察多是Truenas Scale（因为旧版Truenas Scale服务底层采用k3s方案，而非docker）的用户，采用Talos VM部署服务的用户比较稀少。

以前，站长也曾尝试过使用旧版Truenas Scale搭建一套ALL IN ONE的Homelab，并参考社区额外引入TrueCharts源来拓展可用的应用。因此，某种程度上站长也对k3s有一定的了解。那为什么，站长放弃了k3s转投了Docker怀抱？

更为复杂的配置。k8s/k3s面向的更多是一个集群，其使用声明式API对集群中的状态进行说明，规格项很多且对于Homelab这类单点服务的情景用处不大。
社区支持程度有限。许多开源社区的服务会提供已经打包好的Docker镜像或Dockerfile，但同时提供k8s/k3s的配置文件的服务较少。
Debug更简单。k8s/k3s的服务类型比较复杂（例如： Deployment、Service），且资源类型灵活丰富，出现问题时定位比较困难。

由此，站长更偏好于使用Docker对服务进行编排和管理。

前文提到，运行类似Miniflux，Nocodb等SLA要求不高的服务时，可以将存储空间托管到存储后端。选用Docker，还有一个重要原因是使用Docker Volume挂载远程存储非常方便。后面实际测试中，站长认为未针对存储后端进行适配的官方原版Docker，可供选择的较合适的方案应只有Samba/CIFS和NFS。

测试时，站长浏览的一些帖子中指出，NFS的性能相较Samba/CIFS会更优。

那么，选择NFS会更合适吗？

于站长而言，不是。两者在兼容性上都还可以，但站长更偏向于使用Samba/CIFS，因为其能提供数据流加密以及较为复杂的鉴权，为内网场景提供更高的安全性。针对NFS协议，如需实现同样目标，需配置NFSv4+Kerberos，相比Samba/CIFS会复杂许多。

最后，讲一下站长的惯用做法。站长比较喜欢是在docker-compose.yml文件中定义Samba/CIFS的挂载路径以及使用的账户，并在同一个文件中映射用户ID与组ID，避免权限不足。后期，为了实现更方便的操作，站长利用Gitlab CI/CD简单写了个流程，在提交更新的docker-compose.yml文件后会自动前往对应文件夹停止服务、更新配置文件、重新启用服务。

Restic & Rclone

为了实现数据安全、隐私安全，或是更具体的两地三中心的备份策略、备份到外部非可信存储的数据应进行加密，个人认为主要需要做两方面的筛选：①可以连接到各存储后端的方案；②一套利用安全的加密方式备份文件的方案（该方案不应像Veracrypt一样，牵一发而动全身，否则将带来非常大的上传下载压力）。前者，经过站长的搜索筛选，具有51.1k star的Rclone可以说是最佳方案，只需找到一套底层为Rclone的远程存储后端管理软件即可（注：Alist近期陷入负面舆情，本文不再做推荐）。后者，Restic/Kopir/Borg都是比较经典的方案。经过站长比较，最终选择了Restic进行尝试。

其一，是因为Restic具备加密备份文件的能力。最终形成的存储库在Rabin指纹技术的作用下，由一系列相近大小的（默认条件下~16M）文件组成的。实测中，这样的算法寻找配置小文件时效率较高，只需下载需要的文件就能将小文件提取出来。其二，Restic能够快速安全地配置多套仓库密钥。这将减少因极端情况失去密钥导致失去全部数据的可能性。其三，具备版本控制/快照功能。用户能够快速地下载某一版本下的数据，且能够快速地配置保留的版本数量。其四，Restic有一个第三方的备份方案Backrest，自带WebUI，支持计划任务，支持通过参数配置Rclone连接远程存储后端，使用起来很方便。

综上，Restic是一个成熟的、且较为切合站长需求的方案。

但是，经过一段时间的使用，站长发现Restic亦不能完全满足需求。具体不足有两方面：

①备份Proxmox VE硬盘文件时，Restic的压缩率很低。最初，站长猜测原因是Proxmox VE备份硬盘文件时会先进行zstd压缩，导致尽管不同时间段硬盘文件相似，Restic也很难再次进行压缩。但后续，站长取消了zstd压缩，改为原格式存储，发现Restic的压缩率仍很低，未达预期。

②近期，Attack on content-defined chunking algorithm used by Restic #5291中提到使用Restic可能存在数据安全风险。针对这一攻击方式，维护者表示需修改存储库格式，这需要一定时间。尽管评论区中维护者还给出了一些缓解措施，但在未稳定下来前，使用Restic需担一定的风险。

因此，站长的加密压缩备份方案还未最终确定下来，需要再去探索一下。

RouterOS

针对网络服务，站长主要有两方面要求：①稳定性。作为网络基础服务，不能随意崩溃，否则会影响Homelab内所有使用远程存储的服务。②支持流量镜像。站长希望将NAT前的含原始IP的流量镜像到自建IDS便于分析，以便发现可疑流量。

以上要求，OpenWrt、pfSense、RouterOS都能实现。但是，OpenWrt稳定性相对较弱，pfSense的中文参考资料较少，因此最终还是选择了具有多年经验的RouterOS。

不过，不知是不是配置有误，RouterOS在流量镜像时，若不使用Packet Sniffer进行流量镜像，而是使用社区、论坛中提到的设置PREROUTING、POSTROUTING 、FORWARD的相关防火墙规则实现流量重定向，会导致流向IDS的数据包出现解析不完整的情况（包括但不限于数据包中srcIP均为NAT后IP、数据包均已加密无法解析、无法正常上网）。但是，Packet Sniffer是临时的流量镜像方案，长时间运行后会自动退出，不宜作为IDS流量分析的前置服务。因此，后续还需就此继续迭代配置。

至于“回家”，存在多种方案，没有必要在路由系统中ALL IN ONE。对此，站长认为最方便的方案是VPN。只需在内网创建Wireguard、Frp的实例，就能通过具有公有IP的云服务器对流量进行中转，随时回家。由于需要采购云服务器进行流量中转，成本相对较高，且“回家”带宽受限于云服务器的带宽限制（特别是在中国大陆地区，带宽很贵，大家都在给运营商打工），多数时比不上打洞带来的效果。

但，确实比较稳定，不用担心打洞失败怎么办。

下一步计划

在整个流程中，大部分问题都已被我进行筛选、处理。但在软件服务配置上，还有较多的欠缺之处。