从一个念头开始的“悲劇”
为什么我会把这个项目叫做《悲劇物語》？说出来有点丢人。一开始的念头特别单纯，就是想把家里那些闲置的旧设备和硬盘利用起来。我家里的存储一直是老大难问题，数据散得到处都是，手机拍的照片、几百个G的电影资源，存得乱七八糟。
我当时的想法是：自己搭建一套能打通内外的私人云存储系统，取代那些收费又限速的公有云。多酷！
第一代“物語”的诞生与夭折
说干就干，我先是淘了一台二手的工控机，塞进两块8TB的盘，硬件算是到位了。软件方面，我选择了X-penology，也就是黑群晖，想着这套系统界面友功能又多。我摸索着把系统刷进去，分配好存储空间，又花了两个晚上解决了公网DDNS的解析问题，那会儿感觉自己就是个天才。
本地访问是真爽，速度杠杠的。问题是，当我决定引入异地备份机制，想把数据同步到我老家的另一台机器上时，悲剧就开始了。
我折腾了好几套同步方案，从自带的Synology Drive到Rsync，结果发现每次同步都卡在权限问题上。为了解决这个，我手动修改了底层文件的读写权限，改着改着，我犯了个大错：我把系统盘的一个关键目录权限给设错了。
第二天，系统直接崩了。登录界面都进不去，只剩下滴滴的报警声。我当时人都傻了，花了整整四天，尝试用各种急救U盘去修复，但都没成功。我不得不痛苦地承认，第一代“物語”彻底完蛋了，所有配置重头来过。
悲劇物語的更新日志：2.0的尝试
这回我学乖了，我意识到用黑群晖这种定制系统，一旦底层出问题，修复的难度太大。我决定彻底推翻重来，采用更纯粹的Linux发行版，然后用Docker一个个把服务叠上去。这个过程是真费劲，但起码每一步都掌控在自己手里。
我在新的Debian系统上搭建了第二代架构，主要调整了几个地方：
- 抛弃了图形化界面，只保留了SSH命令行，减少资源占用。
- 存储方案换成了更稳妥的Raid 1，避免了上次的权限混乱。
- 内网穿透服务从DDNS换成了NPS+Frp，流量控制更精细。
这个2.0版本跑起来之后，我又遇到了新的问题。虽然存储稳了，但外网访问视频时，转码卡顿得厉害。我怀疑是转码软件的硬件加速没调对，它总是调用CPU而不是核显。我连续查了好几天的文档，终于发现是驱动版本太老，和Docker容器里跑的Plex服务不兼容。
那段时间，我感觉自己不是在搞私人云，而是在修一台随时会爆炸的古董车。每次解决一个BUG，我就得庆幸半天。
现在的状态和下一步计划
悲劇物語2.5版本正在稳定运行，勉强达到了当初“随时随地访问”的目标。我成功解决了转码加速的问题，通过升级驱动和调整Docker容器的启动参数，现在4K视频流媒体访问流畅多了。
但新的隐患又来了：功耗！这台小机器24小时开着，电费蹭蹭往上涨。我开始研究怎么用脚本实现夜间低功耗待机，以及如何设定定时唤醒。这又是一个巨大的坑，我光是找合适的唤醒方法，就消耗了整整一个周末。
为什么我会这么执着于自己搞定一切？和我老婆说的一样，我买个成品NAS早就解决了。但是，这个过程让我彻底搞懂了存储、网络、容器化的所有细节。我就是想看看，一个普通人，在不花大价钱的前提下，能把这些技术玩到什么程度。
这回的更新日志就到这儿，等我把功耗优化搞定，我再来分享我的新一轮“悲劇”记录。