北京
我用NAS存文档、跑备份、放Jellyfin影音库。装好之后，日常几乎不需要打开管理后台——电脑上能取文件，电视上能看片，后台在忙什么根本不用管。代价是：昨晚的备份到底跑完没有，得靠我自己记得去查。
于是我写了个小脚本，让NAS每天早晨给我发一封报告邮件。反正我本来就要看邮箱，把报告塞进收件箱，比再给自己增加一个要访问的仪表盘合理得多。到目前为止，它已经拦下过一次中断的备份，也发现过一块硬盘健康读数里值得警惕的变化——两次都发生在我还能正常访问文件的时候。
把总忘记的检查，塞进一封早邮件
脚本以计划任务的形式跑在NAS上，结果整理成一封简短的HTML邮件。它通过smartctl采集硬盘健康信息，检查可用存储空间，读取备份日志。这些检查我自己在后台和备份应用里也能做，所以整套东西谈不上复杂的监控系统。
硬盘健康这块，重点看温度和SMART读数里的异常变化。脚本会保留上一次的读数，方便对比。如果某块盘开始报告待映射扇区，把昨天的数值和今天的摆在一起，就能看出计数有没有增加。报告还会指明是哪块盘出了问题，省得我再去猜警告对应的是哪一块。
报告里还有一个备份区块，显示最近一次任务的结果，以及上一次成功完成备份的时间。我也把NAS和备份目标位置的可用空间放了进去——任何一边空间耗尽，整套备份策略都会崩掉。邮件里还带采集时间。另外，如果脚本读不到某块盘、或者取不到备份结果，对应条目会写明信息不可用。否则一次不完整的检查，可能给你一份看着安心、实际什么都没查的报告。
失败备份有多容易被漏掉，你根本想不到
报告在我这套配置里抓到的问题之一，是一次夜里跑不完的备份。邮件显示任务失败，并附上了最后一次成功运行的时间戳。当时我照样能打开文档、通过Jellyfin串流电影，日常使用中完全没察觉哪里不对。
问题出在备份目标位置空间耗尽。看到报告里的警告后，我在任务日志里找到了原因。NAS上的文件没事，旧备份也还在。受影响的是上次成功备份之后我新增或修改的内容——这些文件没能拿到我预期的那份独立副本。我调整了备份保留设置，腾出目标位置的空间，重新跑了一次任务，问题解决。
顺带一提，我把NAS备份到一家便宜的云服务Backblaze上，对我来说比把全部东西备份到另一块硬盘好管理得多。也更安全：放在同一地点的备份盘，依然面临物理损坏的风险，而把它放到别处又更费事。
在真正丢数据之前发现问题
另一份报告标记出我某块硬盘的待映射扇区计数上升。当时NAS仍可访问，打开文件也没遇到问题。看到邮件里的变化后，我去查了这块盘的SMART读数。
待映射扇区，是硬盘无法可靠读取、需要重新评估的扇区。这个计数给你一个去排查的由头，虽然它并不能告诉你硬盘什么时候会坏。报告里的上一次读数在这里帮了忙，因为我能看到数值确实涨了。即使SMART总体状态显示某块盘“通过”，我也把详细读数留在报告里。那个状态不代表每一条读数都可以忽略，扇区计数持续上升就值得查一查。
这封早邮件和NAS的即时存储通知是并存的。你不会想为了等一份定时报告，而错过紧急故障通知——有些硬盘失效前，并不会给出SMART预警。
这封早报，我打算一直留着
我在NAS和它的备份上投入了足够多的功夫，所以我想在某个环节停摆时第一时间知道，尤其是它装着我所有重要数据，而我又尽量避开云端。唯一要注意的是：发给自己的邮件必须短，整件事的意义就是拿到一份你真正需要知道的快照。如果把它做成一份塞满各种内容的长报告，这封邮件本身就会变成你想躲开的东西。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
