与 NAS 的衔接：媒体放哪里

Jellyfin 是播放与管理系统，媒体文件本身总得有个落脚点。对大多数家庭玩家来说，这个落脚点就是 NAS。存储方案选得对，后面扩容、备份、多设备访问都会顺很多；选得不对，媒体库还没攒满就要推倒重来。

一、存储媒体的三种典型姿势

媒体库的存储可以概括为三种方案。第一种是成品 NAS：群晖、威联通这类设备功耗低、有现成的阵列与快照体系，套件生态成熟，适合不想折腾的玩家，代价是整机的单位容量成本偏高。第二种是自组主机：用旧电脑或多盘位机箱装大盘，灵活且单位容量成本最低，想怎么配就怎么配，但硬盘管理、风扇噪音与数据安全全要自己操心。第三种最简单——把媒体直接放在运行 Jellyfin 的那台主机上，结构最清晰，适合刚入门、媒体量还不大的场景，缺点是日后再想迁移要搬动数据。三种方案之间没有高下，只有匹配度，这一点在动手之前比品牌参数更值得先想清楚。自建影音库的第一笔钱花在哪、花多少，很大程度上由这个选择决定，而后面的所有扩展都建立在它之上。

Jellyfin 与存储位置的关系也顺带说明一下：服务端并不挑文件存放在哪里，只要能通过本地目录或网络共享读到就可以。因此常见的组合中，NAS 负责存储与冗余，小主机负责解码与转码，两者各司其职，哪一侧升级都不影响另一侧。这种解耦结构让自建影音库特别适合“边用边升级”，不必一次性配齐所有硬件。反过来，如果一切都压在一台设备上，任何升级都要先停服务、移动数据，谨慎很多。

选择时可以先问自己两个问题：媒体总量预期有多大？家里有几口人会用？预期几个 TB、只有自己看，服务端本地硬盘足够；上了十几个 TB、全家共享，成品 NAS 或自组多盘位主机更合适。预算紧的话，旧电脑改造是很好的起点，硬件成本归零，等库攒大了再认真规划存储也不迟——这也是自建与订阅的本质区别之一：方案可以随库成长，沉没成本很低。

再补一类常见纠结：单盘还是阵列。媒体库容量很大时，组 RAID 是不是必须？结论并非绝对。电影剧集这类可重新获取的内容，单盘存放、重要数据另做冷备份，是成本最低的组合；自己拍摄的视频则应组镜像或至少留两份不同介质的副本。盲目给整个媒体库组阵列既费空间也压写入寿命，不如把预算花在更大容量和一块专用备份盘上。阵列能换来的是可用性而非备份，这两个概念在实践中经常被混为一谈，值得在此先分开：阵列让坏了一块盘还能继续读，备份让你哪怕整个库没了也能找回来。

二、目录结构一开始就要想好

媒体库有个特点：只进不出，且持续增长。今天觉得 8TB 够用，两年后可能就要到处找空间。因此目录结构要按“可迁移”的原则设计：媒体文件集中放在一个独立的共享目录下，电影、剧集、音乐各自分离，不要与系统盘或其他数据混在一起。

这样设计的好处是，Jellyfin 通过 Docker 以只读或读写方式挂载这一个目录即可，将来换 NAS、加硬盘、拆分媒体库，只需要重新指向挂载点，元数据与播放进度都不受影响。中英文目录名都可以，刮削器主要认二级命名规范，但混用时容易给维护添麻烦，建议整套库统一一种语言。命名规范的具体写法是刮削能否识别的关键，会在第二章展开。

有一点新手容易踩坑：媒体目录的权限。Docker 容器以特定用户身份运行，宿主机上的共享目录如果权限不匹配，容器会读不到文件，或者能读但写入刮削元数据失败。这类问题表现为海报墙出不来、配置保存不上，排查起来绕一大圈，其实根源在权限。具体写法在部署一章会有示例。

同样的道理也适用于挂载路径的一致性：容器里看到的媒体路径一旦定下，之后所有刮削、播放列表与外部工具的配置都认这条路径。中途更改容器挂载点会让本地缓存与元数据对不上，所以第一次就规划好比事后改容易得多。养成一个习惯：凡是涉及路径的设定先写下来，改一处之前先全局搜一遍，能避免绝大多数“改了这里坏了那里”的连锁故障。

三、网络与挂载的连接方式

如果媒体与服务端不在同一台机器上，就需要通过网络文件系统连接。局域网内常用的是 SMB 与 NFS：SMB 兼容性最好，几乎所有设备都支持，群晖等成品 NAS 也默认用它；NFS 效率更高、开销更小，适合 Linux 服务端之间长期挂载。无论哪种，千兆有线是影音库的底线——播放原盘文件时千兆已经跑满，再低的带宽就只能靠转码压缩画质来迁就网络了。因此核心区域尽量走有线交换机，无线只作为移动设备的补充。

家中的网络拓扑如果还没理顺，先解决网段混乱或交换机带宽不足的问题，否则后面的排查会非常痛苦。网络规划的具体做法，可以参考 《软路由指南》 与 《OpenWrt 必备》 中的组网章节。

顺带提一下无线：不少人家里的路由器放在弱电箱里，客厅电视只能连 Wi-Fi。无线对高码率原盘是硬伤，受信道和邻居干扰波动很大。如果电视位置实在拉不了网线，可以考虑电力猫或 Mesh 子节点做有线中继，稳定性都比纯无线好得多。

五、媒体库之外的联动

NAS 一旦就位，能做的远不止影音库。相册同步、下载工具、家庭网盘这些功能都可以在同一台设备上共存，Jellyfin 只是其中最“显眼”的那一个。规划目录时提前留出这些模块的位置，比如顶层分出 media、photo、download 等并列目录，而不是把媒体目录放在根下深埋。

具体的联动玩法本书最后一章会展开：下载工具、相册库、家庭录像库都共享同一套存储规划。本章的任务是先确立存储这一层的骨架：选好方案、规划好目录、留足扩展空间，剩下的功能都能在这个骨架上逐步长出来。

最后用一句话收束本章：媒体放哪里，决定了后半本书顺不顺。目录结构与挂载方式是自建影音库里最贴近“基础设施”的部分，全部篇幅才这么一章，但日后每一次扩容、备份、排障都会反复用到这里的决定。

给重视流程的读者再补一张落地顺序图。这张图的作用是把抽象的“规划”变成可勾选的清单。

每一步都做到位，后面 Jellyfin 的部署就是“走流程”而不是“查故障”。这套顺序也是本书第二至四章的展开顺序：先存储、再部署、然后刮削与客户端、最后运维与扩展。把存储这一层想透还有一个隐性好处：将来你大概率会忍不住把媒体库分享给父母家，一台 NAS、一个统一的媒体根目录，比到处散落的数据要好管理得多。

四、容量规划与备份策略

容量规划的经验法则很简单：估算你一年会新增多少，然后乘以五。一部蓝光原盘四五十 GB，一个剧集季上百 GB，家庭照片视频更是年年累积，囤积速度远超预期。硬盘建议留出至少两成余量，既是性能考虑，也给文件系统留出整理空间。硬盘临近写满时，文件碎片的读取延迟会明显上升，体验下降早于空间耗尽。

具体到选盘，媒体库属于典型的“写得少读得多”场景，不必追求企业级高耐久盘，垂直记录的家用盘是性价比主流；叠瓦盘价格便宜但长时间写入与碎片的随机读取表现较差，尽量避开。监控盘也在社区流行，性价比介于两者之间。

更重要但常被忽略的是备份。很多人把媒体库当成下载来的消耗品，坏了重下就是；但自己拍摄的家庭录像、孩子成长记录这类不可再生内容，一定要有第二份副本，最好是放在不同位置的冷备份。异地或冷备份的成本远低于数据丢失的代价。群晖用户可以利用自带的快照与备份套件，具体操作见 《群晖 DSM 指南》；自组方案则在 《NAS 自建指南》 中有硬盘阵列的完整讨论。

延伸阅读

• 部署时媒体目录的挂载写法见第二章 Docker Compose 部署一篇；
• 刮削对命名的要求见第二章命名规范一篇；
• 配置与媒体库的备份策略见第四章备份一篇。