机器到手，硬盘插上，手机相册一键推进去。看着进度条跑完，你顺手把手机里的原图删了——空间回来了，照片躺在自己家，完美。
有个人也是这么干的。后来他想做份冷备，把群晖里的 `/volume1/photos` 整个拷到移动硬盘。打开一看：照片一张不少，标签没了，相册分类全乱了。不是硬盘的问题，是他只搬了一半。小红书
相册是两半的
一半是文件。JPG、MP4，躺在你看得见、能直接拖走的目录里。另一半是数据库。谁是谁的脸、这张属于哪个相册、你手动打的标签、时间线顺序、家里有几个账号——全在里面，一个字节都不在照片身上。
Immich 把这条界线写得很直白：媒体文件在 `UPLOAD_LOCATION`，账户、相册关系、任务状态和媒体元数据在 PostgreSQL——只备份数据库，照片恢复不出来；只复制媒体目录，相册关系和账户也恢复不出来。群晖那边同理，做过大盘换小盘无损迁移的人，会专门把套件那套 PostgreSQL 挪到双盘 RAID1 上，理由只有一句：数据库是整套系统的命根子。知乎知乎知乎
两半都要拿，怎么拿
这事不只发生在某一家身上。有位管着 35 万张照片、6TB 素材的用户，换相册软件时把容器路径来回改，玩崩过好几次，每次都靠备份的数据库文件救回来。小红书
群晖：Hyper Backup 里勾 Synology Photos 这个应用，别勾文件夹。勾应用，照片数据库、人脸信息、标签、相册分类、套件配置会一起打包走；勾文件夹，你拿到的就只有那一半文件。小红书
Immich：网页端 账号 → 系统管理 → 设置 → 数据库导出，默认保留 14 天，导出文件落在 `library/backups`。这份要和 `library` 媒体目录一起备，缺一个都不算完。知乎
都适用：别直接 `cp` 正在运行的 postgres 目录当备份。没走过一次完整恢复的备份，不算备份。知乎
顺手三个坑，DIY 的尤其要看
一、旧电脑改 NAS 的，先查 CPU。 更硬的一道门槛是指令集：Immich v3 的机器学习容器在 amd64 平台上要求支持 x86-64-v2，太老的 U 直接起不来。内存只有 4G 也能跑，代价是关掉机器学习，人脸识别和智能搜索一起没；官方给出的硬件基线是最低 2 核 6G、推荐 4 核 8G。知乎知乎小红书
二、8G 内存的真实边界。 有人拿 2014 款 Mac mini（8G）实测：空闲时 immich-server 占 412M、postgres 356M、机器学习容器 168M；一上传 500 张照片，机器学习容器就从 168M 涨到 1.1G，整机内存峰值到过 6.3G，swap 用掉 400M。半年里 Immich 相关容器被 OOM 杀掉 4 次，全是几个吃内存的任务撞在了一起。最狠的一刀是关掉 CLIP 智能搜索：机器学习容器从 700M 降到 168M，人脸识别留着。知乎
三、时区。 容器里不挂 `/etc/localtime`、`.env` 里不写 `TZ=Asia/Shanghai`，所有照片显示成 UTC 时间，时间线错位八小时。知乎
还有个更隐蔽的
从 Mac 或移动硬盘导入时，macOS 会顺手生成一堆 `._` 开头的伴生文件，只有 4096 字节，压根不是 JPEG。Immich 照单全收，时间线上就冒出一排“加载图片时出错”的灰块。知乎
这时候千万别去文件夹里 `rm`——数据库里还记着这条资产，直接删文件会让数据库和文件系统对不上。正确做法是在 Immich 网页里搜 `._`，选中删资产，再清回收站。知乎
最后
上传成功 ≠ 备份完成。iOS 的后台任务由系统调度，开“仅前台备份”更稳。第一次传 84G、三万两千张，局域网约 2 小时；走家宽 30M 上行，约 8 小时。真要删手机原图之前，先拿一小批照片把“备份—恢复”完整走一遍。知乎
Immich 官方 README 自己就写着：别把它当照片的唯一存放处，按 3-2-1 来。知乎小红书
硬盘都涨成这样了，机器也装起来了，别让半个相册躺在没备份的数据库里。
