前几天知乎一篇帖子在NAS圈刷屏。作者盘点自己NAS上的Docker容器：24个，23个绿灯常亮。他打了个特别形象的比方——像养了24只猫，其中23只不认识，但每天还得喂。知乎
这就是很多DIY NAS玩家逃不掉的「容器囤积症」。
绿灯的满足感，填不满的坑
为什么会囤？因为爽。部署一个容器，绿灯一亮，成就感+1。影音库、下载器、去广告、智能家居、签到脚本……教程里推荐的全装上，仿佛装了就等于拥有了那种生活。
真实状态往往是：Plex、Emby、Jellyfin都试了一遍，三个服务扫同一批1400部电影，各建一套数据库，一起刮削时风扇狂转，三套播放进度互不同步，最后偶尔打开一次，只为确认它还活着。知乎
更扎心的是那些「不知道干嘛但不敢删」的容器——稳定运行、没出过问题，删了又怕整台机器塌方。
囤，是有代价的
先是内存。DIY NAS大多是N100这类低功耗芯片或二手老机器，内存本来就紧。容器每多一个，就多一份常驻开销，连装个监控面板都得精打细算——Netdata这类功能强的面板本身就吃资源，1、2G内存的小机器能被拖到卡顿甚至掉线，这也是为什么Glances WebUI这种轻量面板最近在低配玩家里流行起来。知乎
然后是磁盘。上面那位主角某天一查系统盘：镜像层和容器读写层（overlay2）占了78G，容器日志又占了34G。是的，Docker容器日志默认不轮转、不限量，一天天安静地长，直到某天系统盘爆满，所有服务集体报错。知乎
于是他重装了系统。规范化compose文件后又重装一次，一键重建，24个容器整整齐齐全起来了——然后发现数据全没了。因为他备份的是「怎么搭起来」，没备份「搭起来之后里面有什么」。知乎
三条减法动作
一、一个月没打开过的，删。 影音库三选一；签到脚本这种，不在乎积分就删。留下的容器在compose里加资源上限（mem_limit、cpus），谁失控也别想拖垮整机。
二、日志和镜像，从源头管住。 compose里加日志配置 max-size: 50m、max-file: 3；隔段时间跑一次 docker system prune，清掉废弃镜像和停止的容器，磁盘就不会被暗吃。
三、更新，别交给盲盒。 主角装了Watchtower自动更新全部容器，结果数据库格式变了、整台机器不兼容，只能回滚。核心服务要分批更新、更新前先备份数据；想省事可以用docker-updater这类可视化更新工具，点谁更新谁。知乎哔哩哔哩
最后说备份：compose文件只是菜谱，真正值钱的是数据卷。用Backrest这类跑在Docker里的定时备份面板，把关键数据推到另一块盘或云端，下次出事时，重装的是系统，而不是你三年的照片库。哔哩哔哩
绿灯全亮≠一切正常。容器和猫一样，养得起几只就养几只，铲得动屎的才是合格玩家。
