群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家 群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家很多老用户是从 DSM 6.x 一路升级上来的，Docker 套件里跑着三五个容器：下载器、相册、密码库、监控面板，几年都没动过。升级到 DSM 7.2 后，Docker 套件被 Container Manager 接替，名字变了、界面变了，不少人第一反应是：直接升级会不会把容器弄丢？先给结论：DSM 7.2 的 Container Manager 就是 Docker 套件的改名续作，底层还是 Docker，容器和镜像可以平滑带过来。但“可以带过来”不等于“点一下升级就万事大吉”。旧版里一些写法、路径和权限，在新版里会踩坑。本文按真实迁移顺序讲：先盘点、再备份、再动手，迁移完逐项验证，万一翻车还能原路退回。提醒：站内 2022-2023 年写的群晖 Docker / DSM 6.x 旧文（旧版 Docker 套件界面与操作）已过时，请以本文 DSM 7.2 Container Manager 的流程为准，不要再按旧截图一步步点。一、迁移前先盘点：你到底跑着什么别急着点升级，先把家底列清楚。打开旧版 Docker（或已升级后的 Container Manager），逐个记下来：每个容器的名字、镜像名和版本标签（比如 latest 还是带版本号的 1.2.3）端口映射：宿主机端口对容器端口，例如 8080:80数据卷：哪些目录映射到了 /docker/xxx，哪些是匿名卷环境变量：时区 TZ=Asia/Shanghai、PUID/PGID、密码、域名等网络模式：bridge 还是 host，有没有用到 macvlan自动启动：是不是随 NAS 开机自启最容易丢的是两类东西：一是写在容器内部、没映射出来的数据（比如只存在容器里的数据库），二是 latest 标签——你以为还是原来那个版本，重新拉取后其实已经是大版本更新了。盘点表建议直接写成一张表，迁移后逐项打勾。还有一个常被忽略的点：DSM 7.2 要求 Container Manager 的项目文件和旧版 Docker 的存储位置不完全相同，升级向导一般会保留数据，但如果你之前把 Docker 目录改过位置，或者用了非默认的共享文件夹，升级前一定要先确认 /volume1/docker（或你自己的目录）里每个应用的文件夹都在。二、备份：三份东西，缺一不可迁移的底气全来自备份。动手前做好这三份：容器配置导出：在旧版 Docker 里把每个容器的设置导出，或者用 docker-compose.yml 重写一遍。推荐后者——一份 compose 文件就是一份可复现的部署说明书，比在界面里点来点去可靠得多。数据卷备份：把 /docker 下每个应用的配置和数据文件夹完整复制一份到另一个共享文件夹或外接硬盘。像 Vaultwarden 的数据文件、Immich 的上传目录、下载器的配置文件，丢了就得重头来。Hyper Backup 快照：如果 NAS 上开了 Hyper Backup 或快照，迁移前手动做一次快照。这一步是给“整个迁移翻车”准备的后悔药。备份完别只放在原地：验证一下备份文件能不能打开、大小是不是正常。备份没验证过，等于没备份。三、正式迁移：按这五步走第 1 步：停容器，记状态先把所有容器停掉，不要在运行中直接升级。停之前截一张运行状态图，或者把 docker ps 的输出存下来，方便迁移后对照：原来跑着几个、现在跑着几个，一眼就能看出来。第 2 步：升级 DSM 到 7.2，安装 Container Manager在控制面板里把 DSM 升级到 7.2（如果还没升），然后在套件中心安装 Container Manager。安装完成后，旧 Docker 套件会被替换，容器列表应该还在——如果列表空了，先别慌，也别马上重建，先看第 5 步的排查。第 3 步：核对镜像与容器逐个核对：容器名、镜像、端口、卷映射、环境变量是不是和盘点表一致。重点看三处：端口冲突：DSM 7.2 的系统服务占用端口有变化，原来能用的端口可能被系统占了，容器起不来就先查端口。权限变化：DSM 7.2 对共享文件夹权限更严格，容器用户读不到映射目录时，表现常常是“容器起来了但数据是空的”或“写不进文件”，这时要去检查文件夹权限和 PUID/PGID。网络模式：host 模式的容器在新版里行为基本一致；bridge 模式下如果原来用了自定义网桥，要确认网段没有冲突。第 4 步：逐个启动，别一键全开不要图省事把所有容器一次性全启动。一个一个起，起一个、看日志、打开网页确认能访问，再起下一个。日志里出现 permission denied 多半是权限问题；出现 port is already allocated 就是端口冲突；出现 no such file or directory 往往是卷路径写错了。特别提醒：数据库类容器（比如带 MariaDB/Postgres 的应用）启动要慢一些，等它初始化完成再判断，不要看到一时打不开就反复重启。第 5 步：全量验证按盘点表逐项验证：网页能打开、登录账号还在、历史数据都在、定时任务在跑、外部访问（域名或内网穿透）正常。验证通过的打勾，有问题的记下来集中处理，不要带着疑问过夜——迁移当天的问题，当天最容易定位。四、最常见的五个坑坑 1：以为升级会自动转 compose，旧容器变成“孤儿”旧版用界面建的容器，升级后可能没有对应的项目文件，界面里能看到但不好批量管理。办法：趁这次迁移，把重要容器逐个整理成 compose 项目，放到 Container Manager 的“项目”里统一管理，以后备份、迁移都是一份文件的事。坑 2：latest 一拉取，大版本变了迁移时顺手点了“更新镜像”，结果应用从 1.x 升到 2.x，配置格式不兼容。原则：迁移先求稳，镜像版本先保持原样；等迁移验证通过了，再单独安排一次升级，并且升级前再备份一次。坑 3：数据卷路径大小写或斜杠写错Linux 路径区分大小写，/docker/Vaultwarden 和 /docker/vaultwarden 是两个目录。迁移时复制路径要原样粘贴，不要手打。坑 4：时区和时间不对，定时任务全乱套新容器如果忘了设 TZ=Asia/Shanghai，定时签到、备份、清理任务的执行时间会差 8 小时。建容器时把时区写进环境变量，顺手检查一次。坑 5：没留回滚路，翻车只能干瞪眼回滚路其实很简单：旧数据文件夹的备份 + 旧 compose 文件 + 旧镜像版本号。只要这三样在，删掉新容器、按旧配置重建，十分钟就能回到迁移前。迁移当天不要删备份，确认稳定运行一周后再清理。五、迁移后顺手做的三件优化迁移只是开始，DSM 7.2 的 Container Manager 有几个值得顺手用起来的地方：用“项目”管理：把 compose 文件放进项目里，改配置不用再进容器详情页翻，改完一键重新部署。资源限制写清楚：给下载器、相册这类吃内存的应用设个内存上限，避免某个容器失控拖垮整台 NAS。日志轮转别忘开：容器日志默认一直涨，时间长了能吃掉不少空间。在 compose 里加上日志大小限制，或者定期清理。六、结尾：迁移清单，照着打勾[ ] 盘点表已列好：容器、镜像版本、端口、卷、环境变量、网络[ ] 数据卷已备份并验证能打开，Hyper Backup/快照已做[ ] 旧容器已停止，DSM 已升到 7.2，Container Manager 已安装[ ] 容器逐个启动、日志无报错、网页能访问[ ] 登录、历史数据、定时任务、外部访问逐项验证通过[ ] 重要容器已整理成 compose 项目，备份保留一周再清理DSM 7.2 的这次改名，表面是换了个名字，实际是把 Docker 管理收进了更规范的项目制里。迁移本身不难，难的是不做盘点、不做备份就直接动手。按本文的顺序走一遍，大多数人一个晚上就能平滑搬完，第二天早上起来，容器还是原来那几个，只是管理方式更顺手了。相关旧文群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好：https://www.yeyhome.com/2026/10/20/285.htmlDockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战：https://www.yeyhome.com/2026/10/17/276.htmlLucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：https://www.yeyhome.com/2026/10/14/268.htmlVaultwarden 自建密码库：Docker 一键部署 + 多端同步实测：https://www.yeyhome.com/2026/10/16/273.html