存储规划:图库与原始文件

照片目录结构

部署 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 实用指南》 的通知章节。自建主机则可以在系统中配置邮件告警,脚本检测到异常自动发消息。

小结

存储规划的核心是三句话:目录结构要在部署前定稿;照片本体之外还要给缩略图和数据库留位置;冗余的底线是加一份冷备份。头开好了,后面几年的扩容和备份都不会手忙脚乱。

延伸阅读