背景
苦于国内各大流媒体平台长期以来的分辨率、码率不达标导致观影体验不够完美，一直以来有保存高质量的(eg:4K HEVC 10bit)电影以供收藏和回放的需求，于是衍生出了大容量的存储需求。
阶段1：外接机械硬盘
在媒体这类侧重于连续读写性能的冷数据存储上，我选择了更低成本的机械硬盘方案，由于自用的itx主机没有加装3.5寸机械硬盘的空间，于是采用了外接硬盘盒的方案；初期使用的硬盘容量为4TB，选用的硬盘是经典的希捷vx007垂直盘
阶段2：突遭飞来横祸
阶段1中的方案在愉快自然的运作了一年后，在一场意外中戛然而止：
我的硬盘盒因为我的飞起一脚，在运行过程中惨遭荼毒；Windows当场无法读盘，重新通电后，硬盘发出了磁头敲打的声音；我4TB的高清大片儿们，也随它一起消失在了这个世界上
在惨痛的故事发生之后，咱也没有沉湎在悲痛中无法自拔而一蹶不振，在利用Jellyfin缓存的元数据列表获取到了所有影片的tmdb id(tmdb: https://www.themoviedb.org/)后，连夜写了一套磁力爬虫来获取所有已经逝去的伙计们
阶段3：保障数据安全
算上下载的耗时，为此我花费了2-3天的时间，也只是堪堪抢救回 不到40% 的数据
事情已经发生了，我们能做的只有不让这件事重演
很自然的，我想到了需要考虑数据安全
有别于常规意义上的
信息安全，这里更多是为了避免软硬件的错误而导致设备故障或数据异常的安全
目前，在数据安全方面，我们可以做的只有两种思路：
- 硬件备份：将数据重复存储在不同的设备上
- Raid方案：使用算法来实现冗余和性能提升
对于前者而言，直接购买硬件，创建定时任务是很容易实现的方案；
而对于后者而言，则更多侧重于软件层面的保障(详细的Raid解析可以参考什么是Raid)
在一系列方案的比选之下，ZFS的Raid-Z脱颖而出，针对Raid-Z和ZFS我们可以简单的做一个概括：
ZFS是一个典型的Copy-On-Write(即写时复制)的文件系统，基于这个特性，其为我们提供了非常强大的快照功能和先进的数据保护机制，激进的内存缓存策略(通常1TB<==>1GB)也使得其拥有良好的热文件读写性能
Raid-Z是ZFS提供的一种类似Raid5的软Raid，在存储池中包含一个校验驱动器，以4块4TB的硬盘为例，组成Raid-Z后将拥有3x4TB的容量和同一时间允许一块硬盘损坏/离线的冗余能力
阶段4：TrueNas Scale
幸运的是，我们不需要手动的与命令行频繁的交互，开源的存储系统开发商TrueNas为我们提供了一套完整的ZFS系统交互组件和WebUI，考虑到Linux更加普遍的适应性，我们最终选择了基于Debian的TrueNas Scale作为Nas的OS；
TrueNas Scale提供了完整的Debian环境，同时附带了一套完整的k3s环境，允许我们在轻量化的环境下使用容器化技术构建我们的服务，这一特性让TrueNas Scale在Nas系统的基础上衍生出了非常广的拓展能力：
随着对TrueNas Scale的了解逐渐深入，一个Home Lab的计划逐渐在我的脑海里成型了
这样的一台Home Lab将可以承担起非常多的任务，并高效的执行一些自动化的工作；之前部署的开黑啦机器人、本机运行的Jellyfin影音服务器、局域网内的全局代理服务…
软件上的计划已经开始成型：
- TrueNas Scale作为家庭服务器系统
- 轻量云服务器作为内网服务穿透的公网节点
- ZFS-RAIDZ构建高可用的存储阵列
那么接下来要做的就是准备硬件了: HomeLab搭建日记（二）