宿舍 NAS 后续：真正长期运行后，我发现哪些设计是错的
最开始搭这台宿舍 NAS 的时候，我关心的问题很简单：能不能跑起来，能不能在宿舍局域网里访问，能不能把手机和电脑的数据备份进去，能不能用尽量低的成本，把这一套东西拼出来。
那时候我觉得，一台 NAS 只要能装上系统、识别硬盘、跑 Docker、挂 WebDAV、做相册备份和影视管理，就算基本完成了。
但真正长期运行之后，我才发现自己一开始想错了。
NAS 真正难的不是搭建，而是长期稳定、无人值守、可迁移、可恢复地运行下去。
尤其是当我把它从宿舍搬回家，而自己人在外地工作以后，这个问题变得非常具体：机器坏了，谁去看？硬盘报错，我能不能及时知道？系统盘坏了，配置能不能恢复？几万张照片迁移时，元数据会不会出问题？路由器、交换机、网线、硬盘、系统里到底是哪一个环节炸了，我人在外地又怎么判断？
最后它确实坏了。
故事到此为止。
还好，数据我备份了。
所以这篇不是重新写一遍“宿舍 NAS 怎么搭”，也不是回过头来嘲笑当初的自己。相反，我依然觉得那几个月的认真折腾很值。它让我学到了 Linux、组网、存储、备份、Docker、WebDAV，也让我第一次真正把“数据”当成一种需要长期维护的资产。
只是现在回头看，很多当初看似合理的设计，放到长期运行的场景里，其实是错的。
准确一点说，不是技术细节错了，而是设计前提错了。
一、当初我以为 NAS 的难点是搭建
最早搭这台 NAS 的时候，它的定位很明确：宿舍校园网环境下的本地网络存储。
硬件也很符合“捡垃圾折腾”的思路：H81 主板、E3 1225 v3、8G DDR3、60G SSD 系统盘，再加 500G、500G、1T 的机械硬盘。网络部分是 2.5G 网卡、千兆交换机、TP-Link 300M 路由器。各种线材、网卡、硬盘支架、电源、散热、机箱、工具加在一起，最后总花费 872.75 元。
以当时的目标来看，它其实是成功的。
它便宜，能跑，能折腾，能让我在宿舍里实现文件共享、手机备份、电脑备份、本地游戏文件传输，也让我对网络设备之间的关系有了很直观的理解。
那时候的成就感来自“把它搭起来”。
一台旧主板，一块老 E3，几块二手硬盘，一堆便宜配件，最后真的组成了一台能用的 NAS。这个过程本身就很快乐。
但长期运行之后，我慢慢意识到：搭建成功只是第一阶段。
一台 NAS 不是一次性项目，而是一台长期在线的基础设施。它不是今天装好了、明天能访问，就算真正完成。它要面对的是几个月、一年、两年之后的硬盘老化、系统更新、数据增长、网络变化、异地维护、硬件故障和迁移需求。
短期折腾看功能。
长期运行看恢复。
这个认知转变，是后面所有问题的起点。
二、错误一：把“能跑起来”当成了“能长期运行”
刚开始玩 NAS 的时候，很容易被功能带着走。
能装系统，很爽。
能识别硬盘，很爽。
能跑 Docker，很爽。
能挂网盘，很爽。
能有影视墙、相册、备份、外网访问，更爽。
但是这些都只是在证明一件事：它能跑起来。
而长期运行需要证明的是另一件事：它坏的时候，系统还能不能恢复，数据还能不能保住，人不在旁边还能不能处理。
这两件事不是一个层面的能力。
我最开始设计这台 NAS 时，更多是在想“怎么让它实现更多功能”。后来才发现，长期 NAS 更需要的是少出问题、出了问题能定位、定位之后能恢复、恢复不了也不能影响数据安全。
比如：
硬盘报警有没有通知？
系统盘坏了能不能重装？
Docker 配置有没有备份？
应用数据目录是否清楚？
断电后能不能自动开机？
断网后能不能自动恢复？
路由器坏了、交换机坏了、网线坏了，要怎么判断？
人不在旁边时，家里人能不能帮忙做最基础的重启和拍照反馈？
这些问题，我当初没有认真想。
因为那时候 NAS 就在宿舍，人就在机器旁边。出了问题，大不了接显示器、插键盘、拔线、换盘、重启。
人在旁边时，很多问题都不是问题。
但 NAS 一旦进入长期无人值守状态，问题就不一样了。
我当初设计的是一台“人在旁边时很好用的 NAS”，而不是一台“人不在旁边也能自救的 NAS”。
这就是第一个错误。
三、错误二：为了低成本堆了太多二手和拼装变量
我不反对捡垃圾。
甚至可以说，如果没有这次捡垃圾，我不可能这么快理解主板、CPU、内存、网卡、交换机、路由器、硬盘、SATA 线、电源线、系统盘之间的关系。
学习阶段，低成本二手硬件非常合适。
因为它便宜，坏了不心疼，折腾空间大，也能逼着人去理解很多原本不会接触的东西。
但长期运行之后，我才意识到：二手硬件不是不能用，而是不确定性太多。
二手硬盘不知道前史。
老主板不知道还能稳定多久。
旧电源、廉价转接线、SATA 线、网线、USB 网卡、硬盘支架，每一个东西单独看都很便宜，但它们组合在一起之后，故障点就会变得非常多。
NAS 这种设备最怕的不是性能不够，而是问题不好排查。
硬盘掉线，到底是硬盘坏了，还是线的问题？
SMART 报错，到底是盘本身的问题，还是供电和接口的问题？
系统卡住，到底是系统问题、内存问题、硬盘问题，还是某个 Docker 容器把 I/O 打满了？
当初我以为省钱是这套方案最大的优点。
后来才发现，省下来的硬件成本，可能会在功耗、维护、排查、迁移和不确定性里慢慢补回来。
这不是说低成本方案错了。
它适合作为学习项目，适合作为宿舍折腾，适合作为阶段性尝试。
但如果目标是长期保存重要数据，甚至在人不在旁边的情况下连续运行，那它就不应该只按“能不能便宜搭起来”来设计。
学习系统可以便宜。
长期数据系统要算总成本。
四、错误三：没有一开始就把“人不在旁边”作为设计前提
这可能是我后来感受最深的一点。
在宿舍时，我默认自己随时能摸到机器。
网断了，我可以过去看路由器。
硬盘报错了，我可以拆机换线。
系统进不去了，我可以接显示器。
风扇声音不对，我可以当场判断。
但是 NAS 放回家以后，我人在外地工作，这个前提就消失了。
设备还在家里，数据还在里面，问题也真的发生了，但我不在现场。
这个时候，很多过去很简单的操作都会变得很困难。
比如重启。
人在旁边时，重启只是按一下按钮。
人在外地时，重启就变成了：家里人能不能找到那台机器？知不知道哪个是电源？敢不敢按？按了之后有没有反应？路由器、交换机、NAS、光猫分别在哪里？哪个灯应该亮，哪个灯不亮代表异常？
再比如排查网络。
人在旁边时，我可以很快判断是校园网认证、路由器、交换机还是 NAS 自己的问题。
人在外地时，我只能靠远程连接失败这个结果去猜。
如果所有远程通道都依赖同一套网络，那么网络一断，管理能力也一起消失了。
这就是无人值守系统最残酷的地方：真正需要远程管理的时候，往往也是远程管理最容易失效的时候。
如果重新设计，我会从第一天就把“人不在旁边”作为前提。
至少要考虑：
来电自启。
断电恢复。
远程 SSH。
健康监控推送。
硬盘 SMART 报警。
系统异常通知。
路由器和 NAS 的独立恢复方式。
家里人能执行的简单故障处理说明。
而不是像当初那样，默认“坏了我过去看一眼”。
长期 NAS 不能依赖“我刚好在旁边”。
五、错误四：低估了校园网认证对 NAS 的杀伤力
宿舍环境下搭 NAS，最绕不开的不是硬件，而是网络。
我一开始以为，网络问题总能靠设备解决。
加交换机。
换路由器。
插网卡。
做内网穿透。
想办法绕校园网认证。
但后来发现，有些限制不是设备不够，而是环境本身就不适合。
需要认证的校园网，直接把 NAS 的很多远程能力打残了。
飞牛 OS 虽然有自带的免费内网穿透，但在校园网认证环境下，远程访问管理并不顺畅。我本来还想用它搭一个 WebDAV 小文件备份服务，但没有外网访问是一方面，本地局域网 WebDAV 备份还会出现不明原因的无法访问错误，最后也只能开摆。
这件事给我的教训是：不要把一个天然不稳定、不完全受自己控制的网络环境，设计成长周期服务的基础。
宿舍校园网下的 NAS，更适合做这些事：
本地文件共享。
手机和电脑的局域网备份。
临时游戏文件传输。
影视和资料缓存。
折腾学习。
但它不适合从一开始就被设计成稳定的远程服务中心。
这不是技术能力问题，而是场景判断问题。
如果网络环境本身就不适合，就不要硬把系统目标设成长期外网访问。
六、错误五：没有做好数据冷热分层
这台 NAS 后来让我很早意识到一个问题：硬盘不是只看容量。
刚开始规划硬盘时，我的想法很简单：固态盘放系统，机械盘放数据。空间够不够，是我最关心的事情。
但真正跑起来以后，我才发现“数据”其实也分很多种。
有些数据是冷的，比如影视、归档文件、历史备份、大体积资料。
有些数据是热的，比如 Docker 容器、应用配置、数据库、日志、缓存、缩略图、索引文件。
这两类数据不应该随便混在一起。
我当时就遇到过一个很典型的问题：Docker 和应用中心的软件如果安装在 HDD 存储空间中，会导致所有 HDD 都不会休眠，待机温度上升。
这件事看起来只是一个软件安装位置的问题，但长期看影响很大。
机械硬盘适合存大文件、冷数据、低频访问的数据。
它不适合长期被一堆小文件、日志、数据库、缓存反复唤醒。
如果应用和数据混在一起，NAS 表面上功能很多，但背后是机械盘长期不能休眠，温度上升，噪音增加，寿命压力也增加。
后来我才意识到，长期 NAS 应该按访问频率来设计存储，而不是只按容量来设计。
更合理的方式应该是：
系统放 SSD。
Docker、应用、日志、数据库、缓存放 SSD。
影视、归档、冷备份放 HDD。
相册原图可以放 HDD，但数据库、缩略图、索引最好不要和冷数据混在一起。
重要创作数据则必须本地和云端多副本。
我当时更多是在问：“这个盘还有多少空间？”
后来才知道，更重要的问题是：“这个数据会不会频繁读写？它坏了影响什么？它迁移时麻不麻烦？”
容量只是存储设计里最表层的问题。
长期运行之后，冷热分层才是真正影响体验和寿命的地方。
七、错误六：没有一开始就把硬盘故障当成必然事件
硬盘不是会不会坏，而是什么时候坏。
这句话以前看起来像废话，直到硬盘真的开始报错。
我这台 NAS 中间出现过 ID199 奇偶校验错误，当时大概率判断是线的问题，所以换线。后来又有一块 500G 机械硬盘 SMART 报错，查了一下之后，为了数据安全，不再继续使用。
这些经历让我意识到，NAS 的故障不一定来自硬盘本身。
线材会出问题。
供电会出问题。
接口会出问题。
系统会出问题。
温度也可能成为问题。
如果整个系统都是二手配件、廉价线材、老平台、拼装供电，那么排查起来就更麻烦。
而硬盘故障最可怕的地方，不是盘坏了本身，而是你突然发现自己没有足够的空间去迁移数据。
我之前就遇到过类似情况：有一块盘坏了，数据有 1.7TB，但手头没有存储介质可以完成备份。这个时候就会非常狼狈。
所以后来我对备份的理解变了。
RAID 不是备份。
存储池不是备份。
NAS 本身也不是备份。
如果重要数据只在 NAS 上有一份，那它就不是安全的。
后来我逐渐形成了自己的策略：生产力数据和个人创作数据至少三份备份，两份上云，一份在本地 NAS。涉及个人隐私、照片、敏感信息的数据，不会完全上云，但也不能只有本地单点。
真正让我从“存储爱好者”变成“备份强迫症”的，不是哪篇教程，而是硬盘真的开始报错。
硬盘故障必须被当成必然事件设计。
不是为了让硬盘永远不坏，而是为了让硬盘坏的时候，数据系统不要跟着一起崩。
八、错误七：一开始没有划清 NAS 和云盘的边界
这台 NAS 跑到后面，我对本地存储的需求其实发生了变化。
一开始我想的是：我要有一台自己的 NAS，把数据都放在本地，尽量自己掌控。
但后来 123 云盘、WebDAV、rclone、多平台备份这些东西逐渐用起来以后，我发现很多数据其实更适合上云。
特别是当我充了 123 云盘 VIP 以后，很多备份和上传任务变得简单了很多。再加上飞牛 OS 的网盘挂载，可以直接挂着转存，不影响使用。后来我顶着不足百兆的上传，把大部分数据都上云了，个人网盘数据迁移量达到了 10TB。
上云以后，我对本地存储的需求明显降低了。
但这并不意味着 NAS 没用了。
相反，我只是更清楚 NAS 该做什么了。
云盘适合做异地备份、大体积冷数据归档、多端同步、不敏感资料存储，以及跨平台的 rclone 流水线。
NAS 更适合做本地高速访问、隐私数据保存、原图相册和元数据管理、局域网服务入口、创作资料本地副本，以及一些需要本地执行的自动化任务。
也就是说，NAS 不应该承担一切，云盘也不应该替代一切。
真正合理的是分工。
当初我把 NAS 想成一个中心。
后来我更愿意把它看成整个数据体系中的一个节点。
它可以很重要，但不能是唯一。
它可以坏，但数据不能跟着一起死。
九、错误八：把 NAS 当成万能中心，而不是数据系统中的节点
长期运行之后，我反而更能判断哪些 NAS 功能是有价值的。
比如 bililive 录播项目。
NAS 作为我的 bililive 录播项目运行了很久。Docker 部署好项目之后，在飞牛里挂载 123 的 WebDAV 网络存储，再设置每日凌晨自动备份任务，这个流程确实很好用。
再比如影视。
飞牛影视支持网络存储挂载和 302，海报墙体验也不错，看电影的时候用起来很舒服。
相册功能也有价值。
特别是整个相册分享给朋友看瀑布流图片，这种体验确实比普通文件夹分享舒服很多。
所以我并不想把这篇写成“NAS 没用”。
NAS 当然有用。
但它不应该被设计成万能中心。
它更适合承担这些角色：
本地服务入口。
数据缓存节点。
隐私数据节点。
局域网高速访问节点。
自动化任务执行节点。
云盘和本地之间的中转节点。
问题在于，它不能成为唯一节点。
如果录播项目挂了，可以重跑。
如果影视墙没了，可以重建。
如果相册服务挂了，只要原图和元数据还在，就还有恢复空间。
但如果所有数据只在 NAS 上，而 NAS 一坏，整个数据体系就跟着崩了，那这套设计就是危险的。
NAS 可以是系统的一部分。
但它不应该成为系统的全部。
十、错误九：没有提前设计迁移路径
很多系统装的时候很爽，迁移的时候才知道痛苦。
这句话放在 NAS 上尤其准确。
刚开始使用时，我关心的是怎么把数据放进去。
手机照片怎么同步进去？
电脑文件怎么备份进去？
Docker 应用怎么跑起来？
影视资源怎么管理？
网盘怎么挂载？
但后来真正麻烦的是：怎么把数据安全地拿出来。
尤其是相册。
我的飞牛相册里有几万张图片，部分图片甚至只有 NAS 上有。我又很在意图片元数据信息，比如拍摄时间、文件时间、整理顺序。飞牛没有提供让我满意的相册和其他软件存储空间迁移方式，所以我一直不敢轻易动手。
因为我不知道迁移之后会不会改变元数据。
不知道应用数据库和原始文件之间的关系会不会出问题。
不知道换盘、换系统、换机器之后，相册还能不能恢复成原来的样子。
这个问题比“硬盘容量够不够”更折磨人。
容量不够，可以加盘。
迁移路径不清楚，就会让人不敢动。
后来我才意识到，长期系统从第一天开始就应该考虑迁移。
Docker volume 在哪里？
应用配置在哪里？
数据库在哪里？
原始文件在哪里？
元数据有没有备份？
能不能一键导出？
换系统后能不能恢复？
迁移前后能不能校验？
如果这些问题一开始不想，等数据越来越多以后，每一步都会变得很重。
当初我考虑的是怎么把数据放进去。
后来真正麻烦的是怎么把数据安全地拿出来。
十一、错误十：没有把功耗当成长期成本
装机的时候，我很自然地会算硬件价格。
主板多少钱。
CPU 多少钱。
内存多少钱。
硬盘多少钱。
网卡多少钱。
交换机多少钱。
线材多少钱。
最后合计多少钱。
但长期运行以后，我才发现 NAS 是 24 小时设备，功耗不是小事。
E3 洋垃圾性能当然够用。
甚至对很多 NAS 场景来说，性能是过剩的。
但问题是它不够省电。
老平台的能效、发热、噪音和稳定性，都不适合被简单忽略。尤其是配上较高的市电价格以后，硬件买得便宜，不代表长期真的便宜。
NAS 大多数时候并不缺性能。
它更缺低功耗、低噪音、低温度、低维护和高稳定。
如果只是短期折腾，老平台很合适。
如果是 24 小时长期运行，功耗就会变成每天都在发生的成本。
当初我算的是装机成本。
后来我才开始算长期成本。
这也是为什么到最后，我会觉得现在的市场环境下，不一定适合继续 DIY 这套 NAS。
不是 DIY 没意义，而是如果目标从“折腾学习”变成“长期可靠的数据系统”，那评价标准就完全不一样了。
十二、哪些设计后来证明是对的
写到这里，好像前面一直在说错。
但我并不后悔搭这台 NAS。
甚至我觉得，这台 NAS 对我最大的价值，不是它作为硬件运行了多久，而是它把我推向了更成熟的数据观。
有些设计后来证明是对的。
第一个，是开始重视备份。
如果没有这台 NAS，我可能不会这么早认真思考生产力数据、个人创作数据、照片、隐私数据和冷备份之间的区别。
以前我会觉得，文件在硬盘里就是安全的。
后来我才知道，文件只有一份，就永远不安全。
第二个，是把云盘和 NAS 做分工。
不是所有东西都适合上云，也不是所有东西都适合留在本地。
隐私数据、原图相册、元数据完整性、本地高速访问，这些仍然是 NAS 的价值。
异地备份、大体积冷数据、多端同步、自动化上传，这些交给云盘反而更合适。
第三个，是把 NAS 用作本地任务节点。
bililive 录播、影视管理、相册分享、WebDAV 挂载、自动备份，这些功能都让我真切感受到 NAS 的便利。
第四个，是最终真的把重要数据迁出去了。
机器坏了以后，最重要的问题不是机器还能不能修，而是数据还在不在。
我能写出“还好数据我备份了”，就说明这台 NAS 最后至少完成了它最重要的教育意义：它让我在真正出问题之前，把数据安全放到了更高的位置。
十三、如果重来一次，我会怎么设计
如果再来一次，我不会把目标设成“最低成本搭一台 NAS”。
我会把目标改成：设计一套坏一部分也能继续活着的数据系统。
这两个目标差别很大。
如果只是最低成本搭 NAS，我会继续找便宜主板、便宜 CPU、二手硬盘、低价线材，然后想办法把功能跑起来。
但如果目标是长期数据系统，我会先想这些问题：
重要数据有几份？
哪一份在本地？
哪一份在云端？
哪一份是离线或异地？
系统盘坏了怎么恢复？
Docker 配置怎么备份？
相册元数据怎么迁移？
硬盘报错时有没有通知？
人不在旁边时谁能处理？
这台 NAS 坏了以后，数据体系还能不能继续运转？
硬件上，我会优先考虑低功耗、低噪音、低温度、少变量。
存储上，我会明确区分系统盘、应用盘、缓存盘和数据盘。
备份上，我会先设计三份数据，再考虑本地容量。
网络上，我不会把校园网这种不稳定环境作为长期远程服务的基础。
应用上，我会尽量选择数据目录清楚、迁移路径明确、可以导出和恢复的方案。
最重要的是，我不会再把 NAS 当成唯一中心。
NAS 应该只是数据系统中的一个节点。
它可以承担很多任务，但它必须可以被替换。
它可以坏，但数据不能跟着一起坏。
结语：能跑起来只是开始
这台宿舍 NAS 最开始给我的快乐，是“我居然真的把它搭起来了”。
后来它给我的教训，是“搭起来远远不够”。
一台 NAS 真正难的地方，不在于装系统、插硬盘、跑 Docker、挂网盘。
这些都只是开始。
真正难的是长期运行后，面对硬盘老化、网络变化、系统更新、数据迁移、人机分离和突发故障时，整个数据系统还能不能保持从容。
我不后悔折腾这台 NAS。
它让我学会了很多东西，也让我真正理解了数据的价值。
只是如果再来一次，我不会再单纯追求低成本、功能多、能跑起来。
我会更在意它坏的时候会发生什么。
因为一台 NAS 运行时有多酷，并不是最重要的。
坏了以后数据还在，才算真正设计对了。