存储规划:图库与原始文件
照片目录结构
部署 Immich 之后,照片会以什么形态躺在硬盘上,这件事在用之前搞清楚,后面扩容、备份、迁移都会从容很多。默认情况下,上传的照片按拍摄日期组织成层级目录,每一天一个目录。这样的结构好处是肉眼可读、按时间段备份方便、和大多数传统相册目录习惯一致。如果你用外部库功能引用已有目录,那么结构完全由你原来的组织方式决定,Immich 只是读取者。两种方式可以并存:比如默认上传目录放新照片,外部库挂上旧的年度归档目录。
目录结构之外还有一个决定:要不要让 Immich 对存储模板启用基于时间的动态分段。简单说就是照片太集中时(比如一次性导入一个旅行包),目录结构会按时间再细分,避免单目录文件数过多影响机械盘的读取体验。这个选项对大盘用户影响不大,习惯按年归档的人可以按需开启。

| 目录方案 | 结构 | 谁在维护 | 适合场景 |
|---|---|---|---|
| 默认上传 | 按日期层级 | Immich 自动 | 从零开始 |
| 外部库 | 你原来的结构 | 你自己 | 存量照片多 |
| 并存 | 两套目录 | 分工明确 | 新旧都有 |
照片、缩略图、缓存各占多大
存储规划不能只算照片本体。以一万张照片、平均每张 4MB 为例,原图约 40GB;Immich 还会为每张图生成几个尺寸的缩略图,体积通常在原图的一成以内;机器学习的向量数据小到可以忽略,但模型文件本身有数百 MB。再加上 postgres 的数据库与备份,一套图库总占用大致是原图的一点一倍。
缩略图的数量和照片张数成正比,和照片体积无关。这意味着大量小文件(比如屏幕截图和连拍)会以文件数的形式消耗索引性能,占空间虽小,但不代表不给系统添麻烦。定期清理无用截图既省空间又让扫描更快,这件事在运维的去重一章还会展开。
| 组成 | 大致体积 | 存放位置建议 |
|---|---|---|
| 原图与视频 | 占绝对大头 | 单独的照片目录,放大盘 |
| 缩略图 | 原图的一成内 | 建议固态盘提升滑动 |
| 数据库 | 数百 MB 到 GB 级 | 固态盘,单独卷 |
| 模型文件 | 数百 MB | 容器内部即可 |
| 备份快照 | 看备份策略 | 另一块盘或异地 |
缩略图放固态盘的收益最容易被忽略。机械盘也能生成和读取缩略图,但滑动时间线时那种一卡一顿的迹象会让体验掉一个档次。系统盘和数据分开放的经典组合在这里依然成立。容量上,固态盘不需要太大——装下缩略图、数据库、系统就够,小容量的固态盘往往比大容量的机械盘对体验的提升更明显。

视频要单独算账
照片的存储账好算,视频才是真正吃空间的变量。一段几分钟的手机视频动辄几百MB,一次旅行下来视频占的容量常常超过照片总和。视频是真正吃空间的变量。规划空间时建议按视频占总容量的一半以上来估算,这个比例对有孩子的家庭只会更高。拍照的频率有上限,录孩子学走路、生日聚会、旅行片段的视频是没有节制的增长源——每段几分钟的手机视频动辄几百 MB,一次旅行下来视频占的容量常常超过照片总和。
视频还带来另一个隐性成本:转码与播放。网页端播放某些编码的视频时服务器需要实时转码,CPU 占用会短暂飙升;手机 App 播放通常直接走原始流。如果视频特别多,CPU 的预算要相应往上抬一些。日常使用层面,把视频备份策略设为仅充电且仅在 Wi-Fi 下,能兼顾流量和电池。
HEVC 格式是近年来绕不开的话题。新手机默认输出 HEVC 照片与视频,体积省一半,代价是网页端和部分老设备播放时需要转码。Immich 的转码设置里可以对触发的格式做限制,避免每次看视频都让服务器满负载。转码文件会额外占空间,但比起每个视频手动转一次,自动处理省下的是你的时间。
| 媒体类型 | 单个体积 | 年增量估算 | 备注 |
|---|---|---|---|
| 照片 | 数 MB | 随拍摄量 | 主要存储消耗 |
| 视频 | 数百 MB | 可达总体积一半 | 规划时重点考虑 |
| 实况与连拍 | 批量小文件 | 占据文件数 | 影响扫描时间 |
| 屏幕截图 | 一两 MB | 可观 | 建议单独剔出 |
单盘还是多盘:冗余的底线
照片是丢不得的数据,存储规划的第一原则是假设硬盘会坏。单盘裸奔意味着一次故障带走全部回忆,这在相册场景里是不可接受的基线。最低限度是两块盘做镜像,这是 NAS 的基本操作;更稳妥的是 RAID 之外的冷备份——一块移动硬盘定期同步,平时断电收在柜子里。
镜像和冷备份的分工不同:镜像解决的是硬盘突然坏了的实时切换,冷备份解决的是误操作、勒索软件、系统升级翻车这类逻辑灾难。两者都需要,不能互相替代。关于raid级别怎么选、如何按预算搭配硬盘,《自建 NAS 完全指南》 里有完整的展开。
| 方案 | 防什么 | 成本 | 推荐度 |
|---|---|---|---|
| 单盘裸奔 | 无 | 低 | 不推荐 |
| 双盘镜像 | 硬盘故障 | 一块盘 | 基线 |
| 镜像加冷备份 | 加逻辑灾难 | 加移动硬盘 | 推荐 |
| 异地多副本 | 灾难性事件 | 更高 | 视预算 |
还有一个方案介于中间:把照片目录里最重要的部分(比如孩子的成长记录)单独再同步一份到网盘。它不算严格的异地备份,但应对整机会故障的场景足够,而且成本几乎为零。照片和视频体积巨大全量上传网盘不现实,挑核心部分同步是务实的折中。
扩容路径要提前想
照片只会越来越多,存储规划要给未来留路。常见的扩容路径有三种:加硬盘到现有阵列、升级到更大盘位的主机、把历史照片归档到外置设备。每条路对应不同的前期决策:如果打算未来加盘,现在就别把位置占死;如果打算换更大容量的机器,数据目录的组织最好与机器解耦,也就是照片目录不绑定某个系统路径。
外部库在扩容这件事上特别有用——新盘挂到某个目录、把外部库路径指过去,索引自动跟上,不需要重新导入。这是它比默认上传目录灵活的地方,也是大量老 NAS 用户最终切到外部库的原因。反过来说,默认上传目录同样有它的优势:结构由软件保证一致、元数据完整、迁移整目录时拖一个文件夹就走,适合从零开始、没有历史包袱的新用户。

值得注意的是,外部库和默认上传目录的选择并非终身绑定。先用默认上传的新用户,几年后想接外部库随时可以挂上,两边的索引都在同一个时间线里呈现。选型压力没有想象中大,真正重要的是照片目录所在的那块盘要留足余量。外部库的经典用法是挂载一个按年份组织的现有归档目录,把家人多年攒下的照片一次性接入索引——文件不动、空间不涨,当晚就能搜索十年前的照片。
另一个值得提前知道的细节:外部库默认不接管你目录里的删除权限,在 Immich 里删照片时它不会真的删除外部文件,除非你明确开启相应设置。这个设计是保护性的——避免误操作把原始归档删没;但也意味着空间不会因为你在界面里删了照片就释放。理解了这层语义,外部库的日常使用就不会出现预期偏差。
定期巡检清单
存储规划不是一次性的决策,需要定期回头看。建议每几个月跑一次这套清单:硬盘健康度、剩余空间、缩略图目录是否膨胀、备份是否如期完成。巡检不需要很复杂,看一眼面板就够,难的是养成习惯。剩下空间低于两成的时候最危险——那时候再规划扩容,留给你的余地已经不多了,照片增长不会因为你忙而暂停。
| 巡检项 | 频率 | 看什么 |
|---|---|---|
| 硬盘健康 | 每月 | 智能检测状态 |
| 剩余空间 | 每月 | 是否低于两成 |
| 备份记录 | 每月 | 快照是否成功 |
| 重复照片 | 每年 | 用去重功能清一遍 |
| 归档策略 | 每年 | 历史照片是否外置 |
这套清单可以和家庭其他数字卫生一起做:同一个周末顺手看看路由器、NAS、相册的状态,变成一个习惯之后就不需要额外自律。自动化监控当然是更优雅的解法,群晖等系统自带的通知就能覆盖硬盘健康这一项,具体配置可以参考《群晖 DSM 实用指南》 的通知章节。自建主机则可以在系统中配置邮件告警,脚本检测到异常自动发消息。
小结
存储规划的核心是三句话:目录结构要在部署前定稿;照片本体之外还要给缩略图和数据库留位置;冗余的底线是加一份冷备份。头开好了,后面几年的扩容和备份都不会手忙脚乱。
延伸阅读
- 上一章《Docker Compose 全家桶解读》:卷映射让这里的规划落地。
- 《自建 NAS 完全指南》:阵列级别选择与硬盘搭配。
- 《群晖 DSM 实用指南》:存储空间与共享目录的划分建议。
