家里那台老笔记本的硬盘第三次报红时我终于不想再把照片和片子往移动硬盘里东塞一块、西塞一块了。手机里三年攒了两万多张照片和一堆短视频工作资料、家人合影、下载的影视资源全混在一起找一张两年前的合影要翻三个网盘和两块硬盘。这套自己攒的个人NAS系统我给它起了个名字叫光影猫——光管照片和影像影管影视库猫代表它能安安静静蹲在角落干活。它能干的事其实很朴素把全家的照片自动收拢成一条时间线、把影视资源整理成一个能直接播放的库、把重要文件做多份冗余顺便让家里几台设备共享一个目录。适合谁看手上有一台闲置小主机或者愿意花一两千块攒台机器的朋友愿意动手但不想天天修系统的人还有被网盘年费和数据归属问题困扰过的人。这篇就把我从裸机到日常使用的完整过程摊开讲包括选型时的取舍、参数怎么算、踩过的坑以及那些文档里不会写的细节。1. 先想清楚光影猫到底要装什么1.1 三类数据的真实体量与增长速度动手之前我干的第一件事不是下单硬件而是拿出纸笔算容量。很多人装机失败不是技术问题是买完才发现盘不够用或者买了四块盘结果只用得上两块。我把自己要存的东西分成三类每类都按现在多少、三年后多少来估。照片和家庭录像增长最快。一部手机一年拍三千到六千张是常态单张按 3MB 算一年就是 10GB 到 18GB加上随手拍的短视频一分钟 4K 素材大约 350MB 到 400MB一年下来照片视频合计 40GB 到 80GB 很轻松。如果家里三个人都有这个量五年就是 600GB 到 1.2TB还要算上整理时产生的重复文件和编辑后的成品。影视资源是体积大户。一部压缩过的 1080P 电影 8GB 到 15GB一部剧一季 30GB 到 60GB如果收原盘那单部就是 30GB 到 60GB。我当时的预期是常驻 300 部电影加 20 部剧按平均 12GB 估大概 4TB 出头。这里有个经验影视库的体积永远是你以为的两倍因为你会不断收新片而且舍不得删。工作文件和设备备份属于量小但要命。虚拟机镜像单个 20GB 到 60GB设计稿、代码仓库、文档加起来不到 500GB但这些数据丢了最麻烦。三类加起来五年口径的规划容量我按 6TB 到 8TB 算再留 30% 余量决定了存储池至少要做到 10TB 可用。这个数字直接决定了后面盘位和阵列方式的选择。1.2 自建、成品和网盘我为什么选自己攒这一步很容易被忽略但它决定了你后面三年的折腾程度。我把四条路摊在桌上对比过下面这张表是我当时真实权衡的结果不是事后总结。方案初期成本扩展性影音转码能力长期折腾度数据归属成品双盘位中等偏高含系统授权差盘位锁死弱低端型号靠软件转码低自己自建四盘位中等一次性好换盘加盘灵活取决于处理器可选硬解中前期配置多自己大容量网盘会员每年续费越用越贵无上限但有单文件限制需下载后播放低平台旧电脑改造最低看机箱通常两盘位老处理器转码吃力高功耗噪音不可控自己选自建的核心原因有三点。第一是容量单价四盘位机器用大容量硬盘做池化每 TB 成本能压到成品方案的一半以下而且三年后加盘不用换整机。第二是转码影音库绕不开转码手机、平板、电视盒子解码能力差别很大一颗带核显的低功耗处理器能把这活干得很轻松成品入门型号往往在这块缩水。第三是可控性系统是我自己装的出了问题我知道去哪里看日志不会被厂商的固件更新牵着走。旧电脑改造这条我建议新手先别碰。看着省钱实际上老机器的电源效率低、机箱装不下三块盘、风扇噪音大最后往往是省了两百块多花两个周末。我第一版就是用一台退役小主机改的两块盘悬空固定在机箱里跑了半年因为共振把一块盘的螺丝震松了那之后我就老老实实买了个正经机箱。2. 硬件与系统选型钱该花在哪2.1 盘位、功耗和噪音的三角权衡四盘位是我认为的甜点。两盘位做镜像只剩一半容量扩展性差六盘位以上机箱价格陡增而且功耗和噪音控制难度上来了。四盘位刚好能走三块数据盘加一块校验盘或者两块镜像加两块冷备的组合。处理器方面我选的是低功耗 x86 平台带核显。理由很直接影音库需要硬件转码ARM 平台虽然省电但在转码和多容器并行上容易卡。整机待机功耗实测在 15W 到 18W跑一次转码峰值到 35W 左右。算笔账按平均 20W 全天运行一年耗电 20×24×365÷1000 ≈ 175 度按每度 0.55 元算不到 100 块这个成本完全可以接受不用为了省几瓦去买更贵的低功耗方案。内存我起步给到 16GB。很多人觉得 NAS 只要 4GB 就够那是纯文件共享的用法。你要跑容器、要开照片索引、要做影视刮削8GB 是底线16GB 才不难受。照片索引尤其吃内存两万张照片首次建库的时候8GB 机器会持续把内存吃到 90% 以上索引速度明显变慢。硬盘选择上有个必须说的点认准 CMR 记录方式避开 SMR。SMR 盘在大量随机写入时会掉速到几十兆重建阵列时可能要跑好几天。容量上我建议直接上大容量四块 8TB 比八块 4TB 更省电、更省盘位、故障率统计上也更优。二手企业盘价格诱人但要有心理准备通电时间可能上万小时没有质保到手必须完整跑一遍全盘读写和 SMART 检查。我买过四块二手盘其中一块在第七天出现重映射扇区直接退了所以二手盘只适合做冷备不适合进主阵列。2.2 系统层怎么选三条路的差别系统这块我纠结了最久最后选了通用 Linux 加容器编排。下面把三条路的真实体验讲清楚。第一条是开源 NAS 发行版网页界面友好点点鼠标就能建共享、装插件上手最快。缺点是它的插件生态和底层系统版本绑得比较紧你想跑的某个服务如果没被收录就得自己想办法绕过限制折腾起来反而更麻烦。第二条是通用 Linux 发行版从零配 SMB 共享、配容器。前期确实慢但每一层都是你自己搭的出问题看日志一目了然迁移的时候也简单——把配置文件拷走就行。我最终选这条原因就是可迁移性。第三条是虚拟化平台打底上面跑一个 NAS 系统加若干虚拟机。灵活度最高适合还想在同一台机器上跑软路由、跑测试环境的人。代价是多一层虚拟化硬盘直通要配置功耗也略高。提示如果你完全没有 Linux 命令行经验第一条路更省心如果你打算长期用、后续还想加服务第二条路的前期投入会在半年内回本。2.3 存储方案与容量计算别被标称容量骗了这是最容易算错的地方。硬盘厂商标的是十进制容量8TB 就是 8,000,000,000,000 字节系统显示的是二进制1TiB 1024GiB。换算下来一块 8TB 盘在系统里只有约 7.28TiB。我做了三组计算来选阵列方式单盘直用4 块盘 4 × 7.28 29.1TiB 可用但任何一块盘挂了那块盘上的数据全没。两两镜像可用 2 × 7.28 14.6TiB允许挂任意一块重建速度快风险最低。三数据加一校验可用 3 × 7.28 ≈ 21.8TiB允许挂一块但重建时其余三块要全盘参与读取重建期间如果第二块盘也出问题整个池就没了。我最终选了第三种理由是我的数据里影视资源占了七成这部分丢了可以重新收真正不能丢的照片和工作文件我另外做了镜像和异地备份。如果你的数据全是不可再生的比如全家唯一的照片库我建议老老实实两两镜像别为了那 7TiB 容量去赌重建窗口。还有一个细节留出 10% 到 15% 的池空间不要塞满。池子满了以后写入性能会断崖式下跌快照和索引也会失败。我给自己定的红线是使用率不超过 85%超过就开始清理或者加盘。3. 光影猫的落地过程从裸机到能用下文的 MediaHub、PhotoNest、FileVault 是我给自己部署的三类服务起的代称分别对应影视服务、照片服务和文件同步服务实际部署时换成你选用的同类服务即可参数逻辑和目录结构是完全通用的。3.1 装系统与网络固定系统盘我用了两块小容量固态做镜像和四块数据盘物理分开。这个做法多花一点钱但好处是数据盘可以整组迁移重装系统不影响数据。装系统的过程本身没什么好说写盘工具做一个启动盘按提示走完。真正需要花心思的是装完之后的五件事我列成清单每一步都有明确目的设固定 IP。NAS 的地址必须固定否则手机备份和播放器连不上。在路由器里做 DHCP 地址保留比在系统里手动写静态地址更不容易冲突。开启 SSH 密钥登录关闭密码登录。后面所有配置都在命令行做密钥登录省去反复输密码。校准时间。时区和时间同步必须对否则照片按时间排序会乱日志时间也对不上。关闭不用的服务。装完先关掉一切用不上的东西暴露面越小越省心。建一个普通账号日常用root 只在需要时切换。注意很多人装完系统就直接把管理端口暴露到公网上这是最危险的操作。管理界面永远只在内网访问需要外部访问时走官方账号通道或点对点加密连接不要图省事开公网端口。3.2 存储池与共享目录规划建池之前先把目录结构想清楚改起来很痛苦。我的规划是这样的目录用途权限是否进快照/Media/Movies电影全家人只读否/Media/TV剧集全家人只读否/Photos照片与家庭录像各自账号读写自己的是每天/Files工作与文档按账号隔离是每6小时/Backup设备备份与镜像仅管理员是每周/Docker容器配置与数据仅管理员是每天把影视库排除在快照之外是个关键决定。快照占用的是池空间影视文件动辄几个 TB全拍进去池子很快就满了。照片和工作文档体积小、价值高才值得高频快照。共享协议我用 SMB 给家里 Windows 和 Mac 设备NFS 给播放器和虚拟机。SMB 配置里有个参数值得调把最小协议版本限制在较新的版本关闭过时的兼容模式能明显提升小文件传输速度。实测同一批一万个小文件调整前写入要 12 分钟调整后 5 分钟出头。3.3 容器化部署影音与照片服务所有服务都用容器跑好处是配置文件和依赖打包在一起迁移的时候整个目录拷走就能在新机器上起来。下面是我实际用的编排文件结构参数含义在表里说明。services: mediahub: image: 影视服务镜像 container_name: mediahub restart: unless-stopped network_mode: host environment: - PUID1000 - PGID1000 - TZAsia/Shanghai - HWACCELvaapi devices: - /dev/dri:/dev/dri volumes: - /Docker/mediahub/config:/config - /Media:/media:ro photonest: image: 照片服务镜像 container_name: photonest restart: unless-stopped ports: - 2283:2283 environment: - TZAsia/Shanghai - DB_HOSTphoto-db volumes: - /Photos:/photos - /Docker/photonest/data:/data photo-db: image: 数据库镜像 container_name: photo-db restart: unless-stopped environment: - POSTGRES_PASSWORD自定义密码 volumes: - /Docker/photonest/db:/var/lib/postgresql/data几个参数的选择理由PUID和PGID指定容器内进程的运行身份不设的话容器默认以 root 跑生成的文件属主是 root后面用普通账号访问会权限报错。devices: /dev/dri把核显透给容器硬件转码靠它。没有这一行转码会全部落到 CPU 上一集 4K 转下来风扇直接起飞。/Media挂载加了:ro只读防止某个服务抽风删库。照片服务和数据库分两个容器好处是数据库升级和照片索引互不影响。部署命令很简单cd /Docker docker compose up -d docker compose logs -f --tail100起来之后先看日志有没有报错再去网页端口访问。第一次启动照片服务会比较慢它要扫描全库建索引两万张照片在我的机器上大约跑了 40 分钟。3.4 手机相册自动备份让照片自己回家这一步是光影猫日常使用率最高的功能。手机装对应客户端登录局域网地址开启相册自动上传设置成只在 Wi-Fi 下、只在充电时上传一晚上就把存量传完了。这里有两个坑必须提前说。第一是重复文件手机换了、重装应用、换账号都可能触发重复上传两年下来相册里多几千张一模一样的图。解决办法是在服务端开启去重按文件内容哈希判断而不是按文件名。第二是 HEIC 格式兼容。苹果手机默认拍 HEIC部分播放器和老设备打不开。我的做法是保留原图不转只在需要分享时单独导出 JPEG这样既不损失画质也不占用额外空间。照片服务的核心价值是时间线。目录层面我不用它自动分而是自己按/Photos/年/年-月组织好处是不依赖任何软件就算以后换服务目录结构还是人能看懂的。软链接和自动整理规则都不要用一旦断链照片就散了。3.5 账号权限与家庭多用户隔离一个人用怎么都好说家里三个人一起用权限不分就是灾难。我建了三个账号管理员账号只用来做配置另外两个是家人账号各自有独立的照片目录互相看不到。具体做法是每个人一个主目录组权限设置为同一个家庭组共享目录走组权限私人目录走用户权限。SMB 那边给影视库只读挂载避免谁手滑删了片子。做完之后一定要用每个账号实际登录一次上传、删除、播放各试一遍——我在这一步发现家人账号能删影视库文件原因是只读权限只设在共享层底层目录还是可写的。3.6 定时任务快照、校验与异地同步自动化是这个系统能不能长期存活的关键。我配了四类定时任务每天凌晨两点给照片和文档目录拍快照保留最近 30 个超过自动滚动删除。每周日做一次池数据校验只读扫描所有数据块发现静默损坏就报告。这个任务很吃 IO必须放在深夜。每周一从主池同步一份加密压缩包到第二台设备只同步照片和文档影视不同步。每月一次把最核心的 200GB照片加工作文档同步到一块离线冷备盘同步完拔掉。# 每日快照示例实际按所用系统的快照命令替换 0 2 * * * /usr/local/bin/snapshot-create /Photos /var/log/snapshot.log 21 # 每周校验 0 3 * * 0 /usr/local/bin/pool-scrub /var/log/scrub.log 21冷备盘那块我要强调离线盘是最后一道防线。勒索软件、误删、池损坏这几种情况在线备份都救不了你只有拔下来的那块盘能救。4. 影音库七成功夫在命名和刮削4.1 目录与命名规范决定刮削成败影视服务能不能认出你的片子几乎完全取决于文件名。我踩过的最大的坑就是前期随手命名几十部片子全被识别成未知影片手动改了两晚上。电影的标准结构是/Media/Movies/影片中文名 (年份)/影片中文名 (年份).mkv。年份必须有因为同名翻拍太多了没有年份刮削器只能瞎猜。剧集的标准结构是/Media/TV/剧名 (首播年份)/Season 01/剧名 S01E01 单集标题.mkv。层级必须清楚Season 目录一定要有单集编号必须是两位数。命名方式刮削成功率我的实测主要问题剧名 S01E01.mkv高无剧名 第1集.mkv中部分集数识别错位剧名01.mkv低常被识别成电影剧名 EP01 1080P.mkv低编号解析失败乱名 无目录结构几乎为零全靠手动4.2 刮削失败的三个真实原因第一是网络问题。刮削服务要访问外部信息源如果名称里有特殊符号、或者信息源本身收录不全就会失败。我的做法是先确认信息源里确实有这部片子再改本地文件名去对齐它而不是反过来。第二是文件权限。容器里跑的服务如果读不到文件表现出来的就是识别了但没封面。查日志能看到 permission denied把媒体目录设成组可读就好了。第三是同名冲突。比如一部电影有剧场版和加长版文件名一样刮削器会反复覆盖。解决办法是在文件名里加版本标识并在服务里配置成两个独立条目。4.3 转码策略什么时候该转什么时候别转直通播放永远优于转码。转码只有在三种情况下才必要播放端不支持视频编码、带宽不够、字幕需要烧录进画面。我的设置是按播放端能力分流。客厅电视盒子支持主流编码直接直通画质无损、CPU 占用接近零手机在外网看走转码码率压到 4Mbps老平板只支持某种老编码转码但保留原分辨率。核显转码的实测数据一集 4K 转 1080P纯 CPU 转码占用 300% 以上风扇噪音明显开启核显后占用降到 40% 左右速度还快了三倍。这个差别就是选带核显处理器的意义所在。提示转码缓存目录一定要放在固态或者数据盘之外的临时目录放在系统盘上一晚上能写满。5. 踩坑实录与常见问题速查5.1 硬盘与阵列的坑第一个坑是硬盘休眠。很多人为了让硬盘休息开启了自动休眠结果硬盘一天启停十几次。频繁启停对机械盘的伤害比持续转动大得多我的一块盘就是这么提前出现坏道的。后来我把休眠关了改成让盘一直转年电费多几十块但寿命有保障。第二个坑是重建期间断电。阵列重建要跑十几个小时这段时间是最脆弱的。我给机器配了一台小容量不间断电源只求断电时能自动关机实测能撑 15 分钟足够体面地关掉。第三个坑是混用不同批次的盘。四块盘一起买、一起用坏的时候往往一起坏。我现在的做法是新盘入池时故意留一块容量相同但批次不同的盘做备件价格一样风险分散。5.2 网络访问的坑局域网内访问很顺出门在外的访问才是难点。我不开公网端口原因是管理界面和服务端口直接暴露在外网被扫描和撞库是迟早的事。我的方案是优先用服务自带的远程通道这类通道一般走官方服务器做账号校验再建立点对点加密连接不需要你在路由器上开口子。外网看片的实际体验要提前打预期家里上行带宽通常只有 30Mbps 到 50Mbps一部码率 20Mbps 的片子勉强够多设备同时看就会卡。我的设置是外网默认走 4Mbps 转码画质妥协换流畅。还有一个容易被忽略的点家里宽带重新拨号后外部地址会变。如果你的方案依赖地址访问务必配上动态域名解析否则一次重拨全家断联。我因为这个在出差时打不开照片库折腾了半小时才反应过来。5.3 功耗、噪音与散热的实测场景整机功耗噪音1米处备注待机盘空转15W 到 18W几乎听不见夜间放在客厅可接受文件传输25W 到 30W轻微硬盘声机械盘寻道声明显硬件转码30W 到 35W风扇可闻放书房会分心全盘校验35W 到 40W明显必须安排在深夜噪音主要来自三处机箱风扇、硬盘共振、电源风扇。解决顺序是先治共振——硬盘架加橡胶垫螺丝不要拧死再换大风压低转速的机箱风扇电源选低负载下风扇不转的型号。这三步做完待机状态基本听不到。5.4 常见问题速查现象最可能原因排查动作照片上传中断手机后台被杀改为前台保持应用或设白名单影视无封面文件名不带年份重命名后重新扫描播放卡顿上行带宽不足检查是否走了转码、降低外网码率共享目录看不到协议版本不匹配调整最小协议版本池使用率涨得飞快快照没设保留数检查快照策略清理旧快照硬盘间歇性掉线供电不足或线材换数据线检查电源功率余量容器反复重启权限或端口冲突看日志检查 UID 和端口占用6. 长期运维让它三年不折腾的习惯6.1 只盯五个指标就够了监控不用做得很复杂我只盯五个数池使用率、硬盘温度、SMART 里的重映射扇区数、容器健康状态、最近一次备份是否成功。前四个用系统自带的告警邮件推送到手机第五个靠备份脚本写完日志后发一条通知没收到通知就说明出问题了。池使用率警戒线设在 85%硬盘温度警戒线设在 50 度。重映射扇区只要不是零就重点关注出现增长立刻换盘不要等它彻底坏。这几个数字是我两年下来觉得最有效的组合其他指标看了也做不了什么决定。6.2 备份的三层结构第一层是快照解决误删和误改恢复只要几分钟。第二层是同步到第二台设备解决整机故障和池损坏恢复要几小时。第三层是离线冷备盘解决勒索软件和灾难性事故恢复要一天以上。三层缺一不可很多人只做第一层觉得有快照就够了实际上池一坏快照和数据一起没。备份必须定期演练恢复。我第一次真去恢复一个目录时发现压缩包里的文件权限全变了原因是打包参数没加保留权限的选项。这种问题不演练根本发现不了。6.3 升级和迁移要提前留好路所有服务的配置目录统一放在/Docker/服务名下面每个服务一个目录配置和数据都在里面。迁移时把整个目录拷到新机器改一下挂载路径就能起来这一条习惯能省下大量时间。系统盘和数据盘分离也是为迁移服务。三年后换机器四块数据盘直接拔下来插到新机器池能直接识别系统重装也不影响数据。我现在这台机器已经换过一次主板数据盘没动一个小时就恢复了全部服务。最后分享一个我自己用着很顺的小习惯给每个目录写一个纯文本说明文件写清楚这个目录放什么、由哪个服务写入、能不能删。半年后你回头看自己的系统这份说明比任何文档都管用。