外观
安全更新容器并保留回滚能力
容器更新容易，应用回滚未必容易。新版本第一次启动可能修改数据库，旧镜像即使能下载，也不一定读得懂新格式。可靠的更新方案应同时回答：用哪个版本、备份在哪、失败后恢复哪一组文件。
更新前必须准备恢复副本
下面命令在 NAS 的应用项目目录执行，会重建该项目容器。先停止写入并保存数据库、上传文件、配置和加密密钥的一致备份。数据库迁移后不要直接启动旧镜像写入新数据库；恢复必须使用升级前备份和匹配版本，先在隔离目录验证。
一次只更新一个应用
阅读该应用发布说明，确认是否需要跨中间版本、数据库升级或新增环境变量。记录当前 Compose 文件、.env、镜像标签和摘要，以及备份时间。多容器应用如 Immich 要把官方 Compose、环境变量和依赖镜像作为整套版本管理，不能只改主容器。
选择有空检查结果的时间窗口。为应用暂停上传、同步任务或定时工作流；数据库仍在写入时直接复制数据目录不是可靠备份。小型 SQLite 服务可以停止容器后备份整个数据目录；PostgreSQL 应使用数据库导出或其官方支持的一致备份方法。
更新步骤
将 .env 中镜像标签改为已经核对的目标版本，在应用目录执行：
sh
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=150pull 本身不替换运行中的容器；up -d 才会按配置重建需要变化的服务。这里没有 down --volumes，因为更新不需要删除数据卷。首次启动可能进行迁移，按日志和项目文档等待，避免在迁移过程中反复强制重启。
验收要检查真正的业务
用普通用户登录，读取旧内容，写入一条测试记录，再读取附件。照片应用检查缩略图和原图，密码库检查客户端同步，媒体服务检查播放和转码，自动化服务使用不会发邮件或改生产数据的测试流程。监控连续观察一段时间，确认没有循环重启、权限错误或持续堆积任务。
保留升级前备份直到验收完成并经过自己的观察窗口。回收旧镜像可以晚些做；“清理未使用数据卷”不能作为例行更新步骤。
失败后怎么做
如果只是配置变量写错，修复变量后重建，保留日志。若涉及不兼容的数据迁移，停止新版本，将备份恢复到新目录，使用原镜像启动验证。确认旧数据完整后再切换服务地址。不要覆盖唯一失败现场，也不要让新旧容器同时写同一个数据目录。
恢复到升级前备份意味着丢失备份之后的新写入，需要提前向使用者说明。在家庭环境也要考虑手机新上传的照片、密码变化与自动化任务产生的外部效果，后者不一定能用本地数据库恢复撤销。
要不要自动更新
Watchtower 等工具可以自动拉取并重建容器，但无法理解照片数据库是否完成备份，也无法判断旧客户端是否兼容。先为无状态、可随时重建的测试服务尝试；数据库、密码库、相册和 NAS 管理组件优先人工安排更新。安装前核对工具当前维护状态与 Docker API 兼容性，不把历史热门项目默认当成持续维护。
监测新版本和执行更新是两件事。优先获取更新通知，再经备份、阅读说明、更新、验收完成一轮。即使使用自动化，也必须保留排除关键应用、暂停任务和报警的能力。