兰空图床进阶配置：多存储策略与防盗链 兰空图床进阶配置：多存储策略与防盗链图床搭起来只是第一步。用上一段时间，真正让人头疼的是两件事：图片越存越多，本地磁盘先扛不住；链接被人到处盗用，流量白白烧掉。本文是兰空图床基础篇的进阶续篇，讲多存储策略怎么配、防盗链怎么做，都是在自家图床上实测过的配置。一、多存储策略解决什么问题兰空图床（Lsky Pro）默认只有本地存储：图片存在服务器硬盘上，访问走图床自己的域名。初期够用，跑上几个月就会撞上三堵墙：磁盘满、备份难、被盗链烧流量。多存储策略就是把"图片存哪"拆开：本地存高频小图，对象存储存大图和冷数据，不同用户组走不同策略。再配上防盗链，链接只能在自己的站上用。本文基于兰空图床 2.x 实测，部署环境是群晖 + 宝塔上的 Docker 容器。基础安装和粘贴上传插件的用法见旧文：利用兰空图床更加快捷的进行图片传输。二、先搭好"分流"，再谈配置2.1 兰空支持哪些存储Lsky Pro 2.x 内置的存储策略分四类：存储类型适合场景成本参考本地存储小图、封面、高频访问磁盘成本S3 兼容存储大图、原图、冷备份R2 有免费额度，OSS/COS 按量FTP / WebDAV已有现成存储空间看原有空间其他对象存储七牛、又拍云等按量计费我的实际分法是：文章配图走本地（访问快、备份跟着整站走），大文件和原图走 S3 兼容存储（不占 VPS 磁盘）。这样 VPS 磁盘常年保持在安全水位，图片丢了也能从对象存储侧找回。2.2 新增一条 S3 兼容存储策略以 Cloudflare R2 为例（免费额度对个人站很友好）：登录兰空后台，进入「管理 → 存储策略 → 添加策略」。存储类型选「AWS S3」（R2 兼容 S3 协议，用这个类型）。按 R2 后台给的参数逐项填写：Access Key / Secret Key（在 R2 的「管理 R2 API 令牌」里创建，只给当前 Bucket 的读写权限，不要用账号级密钥）、Endpoint（形如 https://<account-id>.r2.cloudflarestorage.com）、Bucket（提前建好的桶名）、Region（填 auto）、自定义域名（绑自己的子域名，如 img.yeyhome.com，并在 R2 侧开启公共访问；不要直接用 *.r2.dev 默认域名，它有访问频率限制）。保存后点「测试连接」，返回成功再启用。测试失败先看 Endpoint 和密钥有没有多打空格，这是最常见的错。实测提醒：自定义域名一定要走 HTTPS。R2 侧绑定域名后要等证书签发完成再测，否则图片能上传、打不开，排错会绕大弯。2.3 策略怎么分流默认策略：后台「设置 → 上传配置」里指定，所有不指定策略的上传都走它。我把默认策略设为本地，保证博客配图的速度。按用户组分配：给不同用户组绑定不同策略，比如管理员走本地、普通访客走对象存储，避免公开上传把本地磁盘灌满。上传时指定：API 上传可带 strategy_id，Typecho 粘贴上传插件的设置里也有这个字段（见旧文），需要分流的场景直接填策略 ID 即可。三、防盗链：三道防线，别只靠一道防盗链没有银弹，我的实测结论是：图床后台鉴权 + Nginx Referer 校验 + 对象存储侧防盗链，三道一起上，单道被绕过也不至于裸奔。3.1 第一道：开启 URL 签名兰空支持图片 URL 签名（后台「设置 → 图片鉴权」相关选项，不同版本位置略有差异）：开启后链接带有效期签名，过期自动失效。代价是 CDN 缓存命中率会下降，我的做法是博客正文配图不签名（需要长期稳定、被 CDN 缓存），临时分享的大文件链接才签名，分场景取舍。3.2 第二道：Nginx Referer 白名单（最常用）图床前面如果有 Nginx 反代（我的图床就是宝塔 Nginx 反代到容器），加一段 Referer 校验最直接：location ~* \.(jpg|jpeg|png|gif|webp)$ { valid_referers none blocked server_names *.yeyhome.com yeyhome.com; if ($invalid_referer) { return 403; } }注意两点：none 允许直接访问（浏览器地址栏打开、RSS 阅读器等场景需要），不要把 none 去掉，否则自己的 RSS 订阅和微信里点开图片都会 403；白名单要写全，通配符 *.yeyhome.com 别漏。改完重载 Nginx（nginx -s reload 或宝塔面板点重载），用无痕模式测一遍。验证方法，用 curl 模拟盗链：# 模拟自己站引用，应返回 200 curl -I -e "https://www.yeyhome.com/" https://lsky.yeyhome.com:8666/i/2026/11/09/xxx.png # 模拟外站盗链，应返回 403 curl -I -e "https://evil.example.com/" https://lsky.yeyhome.com:8666/i/2026/11/09/xxx.png3.3 第三道：对象存储侧防盗链走 S3 兼容存储的图片，Nginx 那道防线管不着（流量直接走对象存储域名），要在对象存储侧再设一道：R2 在 Bucket 设置里配 Referer 白名单或用 Worker 做鉴权；阿里云 OSS / 腾讯云 COS 控制台直接有「防盗链」设置，填白名单域名即可。注意：对象存储侧的白名单要把图床域名和博客域名都加上，否则图床后台预览图自己都打不开——这个坑我踩过，排查了半小时才发现是白名单漏了图床自己的域名。四、实测结果：盗链前后对比场景开启前开启三道防线后本站文章内图片正常显示正常显示外站直接引用图片链接正常显示（被白嫖）403，显示破图微信内点开图片正常显示正常显示（空 Referer 放行）RSS 阅读器加载图片正常显示正常显示盗链者伪造空 Referer 抓取正常显示仍能打开（已知局限）最后一行是实话：Referer 防盗链防的是"随手引用"的君子，防不住刻意伪造 Referer 的爬虫。真要防死，得上 URL 签名 + 短期有效期，但那会牺牲 CDN 缓存和 RSS 体验。个人小站做到"随手引用打不开"这个程度，性价比最高。五、避坑清单删策略不等于删图片：后台删除存储策略只删配置，对象存储桶里的文件还在。换策略前先确认图片已迁移或不再需要。密钥只给最小权限：R2 / OSS 的 API 密钥只授权当前 Bucket 的读写，别用账号级密钥，泄露了别人能清空整个桶。自定义域名先配 HTTPS 再启用：对象存储绑定域名后证书签发要几分钟，证书没好就启用策略，图片能传不能看，报错还不直观。签名和 CDN 缓存冲突：开了 URL 签名又套了 CDN，缓存键要包含签名参数，否则 CDN 会把带旧签名的图片缓存下来，过期后全站破图。插件里的策略 ID 要同步改：Typecho 粘贴上传插件里填了 strategy_id 的，换策略、删策略后记得同步更新，否则上传会报策略不存在。本地磁盘也要留监控：多策略不等于不用管本地盘。本地策略的图片继续增长，配合群晖的存储空间告警设个阈值，备份思路见旧文：群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好。六、怎么回退与卸载进阶配置都是可逆的，不用怕改坏：切回单策略，把默认策略改回本地，新上传就走本地，已存对象存储的图片链接不受影响；删除多余策略，后台直接删，文件保留在对象存储桶里，之后手动清理桶即可；关掉防盗链，Nginx 那段配置注释掉并重载，对象存储侧白名单清空，立刻恢复开放访问；彻底停用图床，先导出图片清单（后台图片管理可按策略筛选），再把各策略桶里的文件下载备份，最后停容器、删目录——图片外链会随之失效，博客正文要批量替换回本地路径，所以大图上对象存储之前，先想好这一步。写在最后多存储策略和防盗链，本质上都是"图床长大之后"的必修课：存储要分流、流量要设防、密钥要最小权限。配置本身不复杂，复杂的是想清楚自己站点的图片分哪几类、每类走哪条路、每条路配什么防线。配好之后，图床就能从"能用"变成"耐用"——磁盘不爆、流量不被白嫖、换策略也不慌。相关旧文利用兰空图床更加快捷的进行图片传输（基础篇：安装与粘贴上传插件）群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好（图片数据的备份思路）Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选（图床内网访问与反代相关）

为什么放弃 FRP 选了 Lucky：一次工具选型心路 为什么放弃 FRP 选了 Lucky：一次工具选型心路家里这台群晖 NAS 跑了三四年，上面挂的东西越来越多：博客、相册、文件分享、下载器、监控面板，全都要从外网访问。内网穿透这件事，我最早用的是 FRP，后来换成了 Lucky。不是 FRP 不好，而是我的需求变了，工具没跟上。这篇不讲部署步骤，只讲一次真实的选型心路：当初为什么选 FRP、后来哪里不顺手、换 Lucky 之前我列了哪些需求、又是怎么验证的。如果你也在 FRP 和 Lucky 之间纠结，希望这篇能帮你少走点弯路。一、先说背景：我用 FRP 的那两年2024 年刚把博客和几个服务搬上 NAS 时，我用的是 FRP。老牌开源方案，文档全、教程多，群晖上用 Docker 跑一个 frpc 客户端，配好 frpc.ini，指向一台有公网 IP 的 VPS，几分钟就能把服务穿出去。那两年 FRP 跑得很稳，博客、相册、文件分享都走它，VPS 上一个 frps 服务端带五六个隧道，没出过什么大问题。说实话，如果需求一直停在“穿出去就行”，FRP 完全够用，我也不会换。转折点出现在服务越挂越多之后。每次加一个新服务，都要改 frpc.ini 加一段配置、重启容器、去 VPS 上确认端口。改一次两分钟，不麻烦，但改十次就烦了。更关键的是，有一次我手滑把配置文件里一个端口写错，重启后博客和相册一起断了，排查了半小时才发现是自己改错了行。那一刻我意识到：问题不是 FRP 不稳定，而是我的使用方式已经超出了“改配置文件”这种模式的舒适区。我需要一个能看得见、改得快、出错能立刻发现的管理方式，而不是每次靠文本编辑器和重启碰运气。二、换之前，先把需求写下来选型最忌讳凭感觉。换之前，我先把自己的真实需求列了一张表：多服务、多域名：NAS 上七八个服务，每个都要独立域名和 HTTPS，不能共用一个端口硬凑。改配置要快：加一个服务、改一个端口，最好在网页上点几下就完成，不用 SSH 进容器改文件、重启。证书要自动：HTTPS 证书到期要自动续，不能靠我每三个月想起来手动续一次。能看到状态：哪个隧道通、哪个断了、流量走了多少，最好一眼看得到，出问题不用先猜。维护成本低：家里这台 NAS 是 7×24 小时跑的，我不想每周都花时间伺候穿透工具，越省心越好。留退路：新工具如果水土不服，要能在一小时内切回 FRP，不能把全家服务押在一个没验证过的方案上。列完这张表我才发现，FRP 能满足前两条的一半：它能穿多服务、也能配 HTTPS，但“改配置要快”“能看到状态”“证书自动”这三条，它天生就不擅长。FRP 的设计哲学就是“配置文件即全部”，稳定、透明、可脚本化，代价就是一切都要手改文件、重启生效。这不是 FRP 的缺点，是它的定位。只是我的需求变了。三、为什么是 Lucky，不是别的当时摆在我面前的选择有三个：继续用 FRP、换 Lucky，或者试试 ECH（Cloudflare 隧道那套）。三者我之前都实测过，结论写在《Lucky / FRP / ECH 三种内网穿透实测对比》里：延迟上 FRP 和 Lucky 差不多，ECH 免费但节点和稳定性要看运气。这次选型我换了一个判断标准：不再只比延迟和成本，而是按上面那张需求表逐项打分。改配置：Lucky 带 Web 界面，端口转发、反向代理、域名绑定都在网页上点几下完成，改完即时生效，不用重启容器，直接命中我最痛的地方。证书：Lucky 内置 ACME 自动申请和续期，域名解析过去之后，证书自己申请、自己续期。我之前为证书单独写过同步脚本，换了 Lucky 之后那套脚本直接退役了。状态可见：Lucky 的管理界面能看到每条转发规则的状态，断了就是断了，不用先 SSH 再查日志。反代能力：Lucky 本身就是一个反向代理，多域名、多服务、路径分流都能在一个地方配齐，NAS 上的服务统一从它进出，架构反而比“FRP 穿透 + 另外一个反代”更简单。成本：Lucky 和 FRP 一样开源免费，部署同样是 Docker 一个容器，迁移成本就是把规则从配置文件抄到网页上，一个晚上能做完。ECH 我认真考虑过，但它依赖 Cloudflare 的网络，对我这种要稳定访问家里摄像头和 NAS 管理界面的场景来说，多一层不确定因素。免费是真免费，不可控也是真不可控。我的结论是：ECH 适合做备用通道，不适合当主力。所以最后的决定是：主力切到 Lucky，FRP 的服务端和客户端配置原样保留一个月，当作回滚预案。四、切换过程：一个晚上，平滑完成切换我分了三步走，没敢一次性全切：第一步：先搭 Lucky，不动 FRP。 在群晖 Container Manager 里新建一个 Lucky 容器，先把一个不重要的服务（下载器的 Web 界面）切过去跑两天，验证反代、HTTPS、证书续期都没问题。第二步：逐个服务迁移。 按“先边缘、后核心”的顺序迁移：先是文件分享、监控面板这类影响小的，最后才是博客和相册。每个服务切过去后，立刻从外网打开验证一遍，确认没问题再迁下一个。整个过程里 FRP 一直在跑，任何一个服务出问题，改回域名解析就能立刻恢复。第三步：观察两周，再拆 FRP。 全部服务切完后，我没有马上删 FRP，而是让它空跑了两周。这两周里 Lucky 经历了两次 NAS 重启、一次宽带断线重拨，都自动恢复了，证书也正常续了一次。确认稳定后，才把 FRP 的容器停掉，配置文件备份存档。整个切换没有一次全家断网，最长的一次单服务中断是博客切域名解析的几分钟，还是我自己手快改错了记录，改回来就好了。五、用了半年之后，诚实地说说 Lucky 的短板选了 Lucky 不代表它完美。用了半年，短板也得如实写出来：界面是强大，但也是负担：Lucky 的功能非常多，第一次打开管理界面，菜单密密麻麻，新手容易不知道从哪下手。FRP 的配置文件虽然原始，但至少一眼能看全。出了问题，排查要进界面：FRP 出问题看日志文件就行，Lucky 出问题要先打开管理界面，再找对应的规则和日志。对习惯命令行的老手来说，这一步反而多绕了一圈。版本更新要自己盯：Lucky 更新不算频繁，但也没有 FRP 那种“几年不动也稳”的气质。大版本升级前，最好先看一眼更新说明，别无脑点更新。这三条没有一条是致命的，但如果你是那种“配好一次、五年不碰”的用户，FRP 反而更合适。工具没有高下，只有适不适合当下的你。六、我的结论：选型看需求，不看名气这次选型最大的收获不是“Lucky 比 FRP 好”，而是想明白了一件事：工具的优劣是相对的，锚点是你自己的需求清单。如果你只有一两个服务要穿透，配置改得少，FRP 依然是最稳、最省心的选择。如果你的服务越来越多，改配置越来越频繁，又想要证书自动续、状态一眼可见，那 Lucky 值得换。如果你追求零成本、不在乎多一层不确定性，ECH 可以当备用通道，但别当唯一主力。顺便提醒一句：站内 2024 年写的 FRP 客户端部署旧文（用 Docker 跑 frpc、接免费 FRP 服务那套）现在看流程还能跑通，但思路已经过时了——免费 FRP 服务的稳定性、端口限制和现在的需求对不上号，如果你是新上手，建议直接按本文的思路先列需求、再选工具，不要照着旧文一步步抄。选工具和选人一样，没有完美的，只有合适的。FRP 陪我跑了两年，功劳簿上有它一笔；Lucky 接过下一棒，是因为下一程的路变了。下一程路再变的时候，我还会再列一次需求表。相关旧文Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：https://www.yeyhome.com/2026/10/14/268.htmllucky证书更新群晖自动同步：https://www.yeyhome.com/2026/10/25/296.htmlLucky 反代宝塔面板 — Docker macvlan + bridge 双网络解决方案：https://www.yeyhome.com/2026/02/26/68.html群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家：https://www.yeyhome.com/2026/11/05/304.html

群晖 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

青龙面板进阶：PT 签到之外还能自动干什么 青龙面板很多人是冲着 PT 签到装的，装完跑一个签到脚本就扔在那里吃灰。其实它本质上就是一台带可视化界面的“定时任务服务器”：能跑脚本、能定 cron、能看日志、能发通知。签到只是它最不起眼的一种用法。这篇是之前那篇 PT 签到文的进阶篇，讲讲青龙在群晖 NAS 上除了签到，还能替你自动干哪些正经事，以及哪些坑别踩。青龙到底是什么，先说清楚青龙面板（Qinglong）是一个支持 Python、Node.js、Shell 等多种脚本的定时任务管理面板。你可以把它理解成“带界面的 crontab + 脚本仓库 + 日志查看器”：脚本往里一贴，执行时间用 cron 表达式一填，跑没跑、跑出什么结果，都能在面板里直接看到。它适合干的活有一个共同点：重复、定时、不需要人盯着。签到符合，备份、清理、巡检、提醒也都符合。反过来，需要交互、需要实时响应的活（比如远程桌面、在线聊天）就不适合它，别硬塞。如果你已经装过青龙，直接跳到下一节；还没装的，先用下面这段 Compose 在群晖 Container Manager 里起一个。Docker 一键部署在群晖上新建一个项目，docker-compose.yml 如下：services: qinglong: image: whyour/qinglong:latest container_name: qinglong restart: unless-stopped ports: - "5700:5700" volumes: - ./data:/ql/data environment: - QlBaseUrl=/部署要点只有三条：数据卷 ./data 一定要映射出来，否则容器一删，脚本、定时任务、环境变量全没了；端口 5700 别和已有服务冲突，冲突就改左侧端口，比如 5701:5700；首次打开 http://群晖IP:5700，按向导设好账号密码和通知方式（推荐 Bark 或邮件，巡检告警全靠它）。部署完先别急着往里塞脚本，先把下面这套“进阶用法”想清楚：你到底想让它替你省哪几件事。进阶用法一：多站点签到聚合，不止 PTPT 签到是起点，不是终点。很多论坛、网盘、工具站都有每日签到或每日任务，逻辑大同小异：登录、请求签到接口、判断返回结果、失败发通知。进阶的做法不是一个站点写一个脚本到处复制，而是一个脚本管一类站点：把账号、Cookie、签到地址放进青龙的环境变量，脚本只读变量不写死账号。新增一个站点，只加一组变量，不用改代码。实测步骤：在青龙「环境变量」里新建变量，如 SITE_COOKIE、SITE_SIGN_URL；在「定时任务」里新建任务，命令填 task 脚本名.py，cron 填 0 8 * * *（每天 8 点跑）；手动点一次「运行」，看日志里是“签到成功”还是“已签到”，确认无误再交给定时。提醒一句：签到脚本只用在你自己有账号、且站点规则允许自动签到的地方。有的站点明文禁止脚本签到，封号风险自担，别为了几个积分把主力账号搭进去。进阶用法二：NAS 自动运维，清理与备份交给它群晖用久了最常见的两件事：磁盘被 Docker 镜像、日志、缓存慢慢吃满；青龙自己的配置、脚本改了半天没备份。这两件都可以交给青龙自己干。定时清理 Docker 悬空镜像和日志，每周跑一次 Shell 脚本：#!/bin/bash # 每周清理一次悬空镜像，保留最近 7 天日志 docker image prune -f find /var/log -type f -name "*.log" -mtime +7 -delete 2>/dev/null echo "清理完成：$(date)"注意：这条脚本要在能访问 Docker 的宿主机定时任务里跑，或者把 Docker 套接字挂载进青龙容器——新手更稳妥的做法是把清理脚本放在群晖「任务计划」里，青龙只负责发提醒、记日志。别在没看懂命令的情况下直接 prune -a，会把没在运行的镜像也清掉，下次启动容器要重新拉取。定时备份青龙自身：把 /ql/data 打包一份，拷到群晖的备份目录或异地备份路径。备份方案本身可以参考本站的 3-2-1 备份思路：本地一份、快照一份、异地一份，青龙数据虽小，丢了却最麻烦——因为所有定时任务都在里面。进阶用法三：服务存活巡检，挂了第一时间知道Uptime Kuma 是专门的监控面板，青龙则适合做“轻量巡检 + 动作联动”。比如每 10 分钟 curl 一次家里的几个关键地址：博客首页、图床、NAS 的 Web Station 页面，状态码不是 200 就通过 Bark 推送告警。import requests URLS = [ "https://www.yeyhome.com/", "http://群晖内网IP:5000/", ] for url in URLS: try: r = requests.get(url, timeout=10) print(url, r.status_code) except Exception as e: print(f"告警：{url} 访问失败 {e}")把告警逻辑接上通知渠道后，巡检就从“偶尔想起来看一眼”变成了“挂了手机立刻响”。它和 Uptime Kuma 不冲突：Kuma 看得细、看板好看，青龙胜在顺手——巡检发现问题后，可以直接在同一个面板里再跑一个重启、清理脚本，形成“发现—处理”的闭环。进阶用法四：定时提醒与数据汇总还有一类活，青龙做起来比手机闹钟靠谱：每天固定时间汇总一件事，推到你面前。每天早上 8 点，把昨天各站点的签到结果汇总成一条推送；每周一，把 NAS 磁盘占用、Docker 容器状态汇总成一条周报；每月 1 号，提醒自己检查证书到期、域名续费、VPS 账单——这些事不难，难的是记得。实现方式都一样：脚本跑完把结果拼成一句话，调用 Bark 或邮件通知接口发出去。关键是只推值得看的：巡检正常时别天天推“一切正常”，只在异常或汇总节点推，否则推送一多，人就自动忽略了，等于没装。进阶用法五：脚本管理规范，别让面板变成垃圾场青龙用半年，面板里脚本一多就乱。进阶玩家的分水岭不在脚本写得多花哨，而在管理得干不干净。我的规矩是四条：命名规范：站点_用途.py，如 pt_sign.py、nas_cleanup.sh，一眼知道干什么；变量与代码分离：账号、Cookie、Webhook 地址一律放环境变量，脚本里不出现明文密钥，分享、迁移都不怕；依赖单独记：Python 脚本用到的第三方库，在青龙「依赖管理」里装好并记在脚本头部注释里，换机器重装不抓瞎；日志定期清：青龙日志默认越攒越大，定时任务里加一条每月清理旧日志的任务，别等磁盘告警才想起来。避坑清单：这几条都是实测踩过的时区先对齐：青龙容器时区默认可能是 UTC，cron 按 UTC 跑，想每天 8 点跑却 16 点才跑，先检查容器时区和群晖时区是否一致；别跑来路不明的脚本：网上“复制粘贴即用”的青龙脚本，先看它读了哪些变量、往外发了什么请求，再决定跑不跑；要你填账号密码的脚本，先确认它发到哪里；失败要通知：定时任务只设成功路径等于没设，脚本里把异常分支也接上通知，跑失败了你得知道；先手动跑一次：任何新任务上线前，先手动运行一次、看日志、确认输出，再交给定时。直接上定时，出问题都不知道是哪天开始坏的；别用青龙干重活：转码、压缩、大文件同步这类吃 CPU 和 IO 的活，交给群晖任务计划或专门工具，青龙只做轻量调度。怎么卸载：干净收尾哪天不想用了，卸载分两步：先停容器、删容器，再决定数据卷留不留。docker compose down # 数据也不要了，再加 -v： # docker compose down -v只 down 不加 -v，数据卷还在，以后重新 up 还能恢复；确认彻底不用，再加 -v 连数据一起清掉。卸载前如果脚本里有自己写的通用工具，先导出一份存到群晖的文档目录，别跟着容器一起删了。结语青龙的价值不在它能跑多少脚本，而在它把“每天、每周、每月都要做一次的小事”从你的脑子里接过去。PT 签到只是入门，从签到聚合、NAS 运维、服务巡检到定时汇总，一台群晖 + 一个青龙，就能搭起一套不用人盯着的家庭自动化小中枢。先从一个巡检任务开始跑通，跑稳了再往上加，别一次塞十个脚本——自动化最怕的不是少，而是乱。相关旧文：青龙面板 PT 站点自动签到脚本Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好

Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清 前言：家里服务一多，靠“感觉”就不够用了群晖 NAS、VPS、摄像头、图床、博客……家里和云上的服务一多，最怕的不是某一个挂了，而是挂了半天你还不知道。等要用的时候才发现 NAS 的某个容器早停了、VPS 的网站打不开了、摄像头离线了，那种被动是最难受的。之前写过一篇Komari 轻量服务器监控，Komari 强在看服务器本身：CPU、内存、磁盘、流量这些指标一目了然。但它回答不了另一个问题——“我的某个服务现在到底通不通？”这正是 Uptime Kuma 的位置：它不看机器有多累，只盯着服务在不在、响应快不快，挂了立刻告警。一句话总结分工：Komari 看机器状态，Uptime Kuma 看服务存活。两个都装上，才算把监控补齐。Uptime Kuma 干什么用Uptime Kuma 是一个开源的自托管监控面板，界面就是一个大看板：每个监控项绿就是通、红就是断，还能看到最近的响应时间和可用率曲线。它适合盯这些东西：群晖 NAS 的 DSM 网页、Web Station 站点、Docker 里跑的某个服务VPS 上的网站、反代入口、SSH 端口摄像头的 Web 管理页、NVR 的管理页（用 HTTP/TCP/Ping 判断在线）家里的路由器、软路由、图床、相册等一切有地址的服务监控类型很全：HTTP/HTTPS、TCP 端口、Ping、DNS、Docker 容器状态、关键词匹配（页面里必须出现某个词才算正常）等。告警通道也全：Bark、邮件、Telegram、Webhook 等，手机上第一时间就能收到。最重要的是：它本身也只是一个 Docker 容器，部署成本极低，跑在群晖上正合适。Docker 一键部署：群晖 Container Manager 实战准备工作一台能跑 Docker 的群晖 NAS（DSM 7.2 的 Container Manager），或任意一台 VPS给 Uptime Kuma 留一个端口，默认是 3001一个用来持久化数据的目录，否则容器一删监控数据全没了方法一：Container Manager 图形界面（推荐新手）在群晖 File Station 里新建文件夹，例如 docker/uptime-kuma/data。打开 Container Manager → 项目 → 新增，项目名称填 uptime-kuma，路径选刚才的文件夹。把下面的 Compose 内容粘贴进去，点下一步完成，容器就会自动拉起。方法二：docker-compose（VPS / 命令行通用）services: uptime-kuma: image: louislam/uptime-kuma:1 container_name: uptime-kuma volumes: - ./uptime-kuma-data:/app/data ports: - 3001:3001 restart: unless-stopped启动命令：docker compose up -d docker compose logs -f uptime-kuma看到日志里没有报错，就可以打开 http://NAS内网IP:3001。第一次打开会让你创建一个管理员账号和密码，记好——这就是以后进监控面板的账号。方法三：单条 docker rundocker run -d \ --name uptime-kuma \ -p 3001:3001 \ -v uptime-kuma-data:/app/data \ --restart=unless-stopped \ louislam/uptime-kuma:1三种方法本质一样，选顺手的一种就行。群晖用户建议用 Compose 项目的方式，以后升级、改端口都在一个地方改，不用来回敲命令。添加监控：NAS、VPS、摄像头一次加齐进面板后点右上角“添加监控项”，先从最关键的几个开始加，不要一上来就加几十个，把自己看晕了。1. 群晖 NAS 本身类型选 HTTP(s)，地址填 http://NAS内网IP:5000（如果开了 HTTPS 就填 5001 端口）心跳间隔建议 60 秒，重试 2 次再判为断线，避免网络抖一下就误报名字写清楚，例如“群晖 DSM”2. VPS 上的网站类型选 HTTP(s)，填网站域名可以顺手打开“证书过期提醒”思路：Uptime Kuma 会在证书快过期时在面板里提示，配合告警就不会再出现证书过期了才发现的尴尬如果网站走了反代，建议直接监控最终用户访问的域名，而不是只监控内网端口，这样才真正等于用户视角3. 摄像头和 NVR摄像头一般不建议直接监控视频流地址，那个地址本身就不稳定。实用的做法是：Ping 摄像头内网 IP：通就说明设备在线、网络没断TCP 监控 554（RTSP）或 8000（ONVIF）端口：端口通说明服务进程还在HTTP 监控摄像头或 NVR 的 Web 管理页：页面能打开，基本等于整机正常这三层从“设备在”到“服务在”逐步收紧，组合起来误报最少。之前那篇群晖 Surveillance + 海康/大华摄像头 + NVR 联动存录像实战里讲的录像链路，也可以用这种方式顺手盯住。4. Docker 容器状态（进阶）如果你把 Uptime Kuma 和被监控的容器放在同一台机器上，还可以用 Docker 监控类型直接盯容器：容器一停就告警，比只盯端口更直接。不过要注意：Uptime Kuma 容器本身需要能访问 Docker 守护进程，配置时要按官方文档挂载 Docker socket，权限给多了有风险，不熟悉的话先用 HTTP/TCP 方式，够用了再上这一步。5. 关键词监控（防“假活”）有些服务会出现“端口通、页面能打开，但内容已经错了”的假活状态。这时可以用 HTTP 关键词监控：要求返回页面里必须包含某个词（例如你博客的标题、某个服务的特征词），没出现就判为异常。这个小功能在监控网站时特别实用。告警接通：挂了第一时间推到手机上只看面板不接告警，监控就只完成了一半。Uptime Kuma 的告警是在“设置 → 通知”里配的，配好后在每个监控项里勾选对应的通知方式。Bark 告警（iPhone 用户首选）手机上装好 Bark，拿到自己的推送地址（形如 https://api.day.app/你的Key/）。Uptime Kuma 里新增通知，类型选 Bark，填入这个地址。点“测试”发一条，手机能收到就说明通了。Bark 的好处是轻、不依赖邮箱，手机上不用再装新应用。邮件告警（通用兜底）新增通知，类型选 SMTP。填发件邮箱的 SMTP 服务器、端口、账号密码（建议用邮箱的专用授权码，不要填登录密码）。收件人填你常用的邮箱，测试一封能收到即可。建议 Bark 和邮件至少配一个，最好两个都配：Bark 负责“立刻知道”，邮件负责“留底可查”。告警文案里会带上是哪个监控项断了、断了多久，收到后不用再进面板猜。告警策略的小经验心跳间隔不要设得太短：20 秒一次看着爽，但对 VPS 和内网设备都是负担，60 秒是家用场景的平衡点。重试次数设 2～3 次：网络抖动、路由器重启那几十秒不应该算一次故障。维护窗口记得用：计划内的 NAS 重启、VPS 升级前，先在 Uptime Kuma 里给相关监控项开维护时段，免得半夜被自己计划内的操作吵醒。状态页：给家人和自己一个“服务状态”入口Uptime Kuma 还能生成一个公开状态页：把你想公开的监控项放上去，别人打开就能看到“博客正常、图床正常、相册正常”这样的总览。不用公开全部，只放对外服务即可；内网摄像头、NAS 管理页这种千万别放进公开状态页。状态页的另一个用处是自查：扫一眼比逐个打开服务快得多。实测小结：跑了一段时间后的真实感受这套组合在我这边跑下来的感受是：部署确实一键：一个 Compose 文件、一个数据卷，十分钟内能跑起来。面板够直观：绿色一片就是安心，红色一项就能立刻定位到是哪个服务。告警够及时：Bark 一推，基本就是故障发生后一分钟内的事，比“用户反馈”早得多。资源占用很小：家用规模下对 NAS 几乎没有可感知的负担，适合长期挂着。它替代不了 Komari 那种看机器指标的监控，也替代不了群晖 3-2-1 备份方案那种数据层面的兜底——监控只能告诉你“出事了”，备份才能保证“出事了还能恢复”。这三层各司其职，别指望一个工具包打天下。避坑清单数据卷别忘挂：没挂 /app/data 的话，容器重建后所有监控项和历史都要重配，这是新手最常见的坑。别用 latest 乱升级：生产在用的监控，镜像标签建议固定大版本（例如 louislam/uptime-kuma:1），升级前先备份数据卷。监控 Uptime Kuma 自己：监控面板本身挂了就没人告警了，重要的对外服务建议再配一个外部视角（例如 VPS 上再跑一个轻量实例互盯，或者用公网监控服务做兜底）。内网地址别放公网状态页：状态页只放对外服务，内网 IP、内网端口不要出现在公开页面上。反代后注意端口：如果用 Lucky 或其他反代把 3001 映射出去，记得给面板加上强密码，最好再套一层访问控制，不要裸奔在公网上。摄像头监控别贪多：十几个摄像头每个都设 20 秒心跳，内网会被无意义的探测流量打满，60 秒、Ping 为主就够了。怎么卸载不想要了也很简单，数据清得干净：docker compose down # 再删掉 uptime-kuma-data 数据目录Container Manager 图形界面的用户：项目里点停止、删除项目，再到 File Station 里删掉对应的数据文件夹即可。卸载前如果状态页或告警配置以后还想用，先把数据卷备份一份，几十 MB 的事。结语家里服务越多，越需要一个“替你盯着”的角色。Uptime Kuma 不花哨，就是把“通不通”这件事做到位：部署一键、看板一屏、挂了立刻推到手机上。配合 Komari 看机器、配合备份保数据，这套家用监控组合才算完整。如果你家里也已经有 NAS、VPS、摄像头这几样，不妨花十分钟把它装上——下一次服务挂掉时，第一个知道的人会是你，而不是来找你的家人。相关旧文Komari 轻量服务器监控：Docker 一键部署 + 与 Uptime Kuma 区别详解群晖 Surveillance + 海康/大华摄像头 + NVR 联动存录像实战群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选

群晖 Surveillance + 海康/大华摄像头 + NVR 联动存录像实战 家里、店里、工地现场装了摄像头，最怕的不是“看不到”，而是“关键时刻录像不在”。单靠一台 NVR 硬盘录像，硬盘一坏、机器一被偷，录像就全没了；单靠群晖 Surveillance Station 直录，摄像头一多、授权一超预算，又容易顾此失彼。这篇讲一套我现场常用的组合：NVR 主录 + 群晖 Surveillance 备份录 + 关键通道双录，海康、大华摄像头混接，一次把接入、存储、回放、权限讲透。一、先定架构：三种组合怎么选先别急着加摄像头，先定“录像存在哪、丢了哪一份还能找回”。方案录像落点优点缺点适合谁A. NVR 主录只存 NVR 硬盘成本最低、接线最简单NVR 坏了就全丢只有 4 路以内、能接受单点风险的小店B. NAS 直录只存群晖回放、权限、远程看都统一授权按路数买，路数多就贵；NAS 宕机也丢已有群晖、路数少于授权数C. NVR 主录 + NAS 备份录两份，互为备份一份坏了另一份还在；NAS 还能做权限分级和远程回放初期多花一台 NAS 的盘和授权门店、仓库、工地、别墅，本文推荐本文按方案 C 写：平时看 NVR，查事、给人看回放、远程调阅走群晖。两份录像不同盘、不同设备，才算真备份——同一台机器里两块盘，不叫异地备份，顶多叫冗余。二、动手前先对齐的几件事1. 授权数先算清。 群晖 Surveillance Station 自带 2 路免费授权，超出部分按路数买授权，一路一码、绑定 NAS，不要先装 8 个头再发现只剩 2 路。规划时只把“必须双录的关键通道”接进群晖，比如大门、收银台、仓库门、机房；走廊、后院这种只看实时的，可以只走 NVR。2. 时间必须同步。 摄像头、NVR、群晖三方时间差超过几分钟，回放对不上、报警时间也对不上。统一做法：群晖开 NTP 服务或三方都指向同一个 NTP 服务器（路由器或群晖都行），摄像头里把 NTP 地址填上，别用默认的出厂时间。3. 编码与码流先定好。 主码流录像用 H.265、1080p 或 4MP 即可，4K 全开只会把存储和带宽吃爆；子码流用来多画面预览和手机远程看，码率压低一点。双码流都开，后面回放和远程才不卡。4. 网段与 IP 先规划。 摄像头、NVR、群晖放同一个局域网段，摄像头用固定 IP（DHCP 保留或手动静态），别让摄像头 IP 隔三差五漂移——IP 一变，Surveillance 里就掉线。PoE 供电的，交换机功率要留余量，别按满配算。三、海康、大华摄像头接入群晖海康和大华都支持 ONVIF，这是混接的关键：不用管品牌，先用 ONVIF 通用协议接通，再按需换原厂协议调细节。海康摄像头：浏览器进摄像头后台，确认 ONVIF 已开启，并新建一个专门给群晖用的 ONVIF 用户（别用 admin 直连，改密码、降权限后出问题也好排查）。确认视频编码为 H.265、主码流分辨率与帧率符合规划。群晖 Surveillance Station → IP 摄像机 → 新增，品牌选 Hikvision 或 ONVIF，填入摄像头 IP、ONVIF 用户名密码、端口（ONVIF 默认 80，具体以摄像头后台为准），点“测试连接”，通了再保存。大华摄像头：同样在摄像头后台开启 ONVIF，建独立 ONVIF 用户。大华部分型号的 ONVIF 端口与 RTSP 端口分开，填错端口是掉线最常见的原因，对照摄像头后台的端口页逐项核对。群晖侧品牌选 Dahua 或 ONVIF，测试连接通过后再进下一步；如果 ONVIF 通但画面黑，先把编码从 H.265 切到 H.264 试一次，排除解码兼容问题，再切回来定位。通用排错清单： 测试连接失败时按这个顺序查：IP 通不通（ping 一下）、端口对不对、ONVIF 开没开、用户名密码对不对、摄像头时间与群晖时间差几分钟、是不是子码流参数被改乱了。一次只改一个变量，别同时改 IP 又改编码。四、NVR 联动：让 NVR 和群晖各录一份NVR 联动有两种接法，按现场已有设备选一种，别两种混着配：接法一：摄像头双推流（推荐）。 摄像头同时被 NVR 和群晖拉流：NVR 按自己的通道录一份，群晖按 ONVIF 再录一份。优点是两份录像完全独立，NVR 拔电也不影响群晖；缺点是摄像头要扛两路拉流，老型号或低端头同时推两路主码流会卡，解决办法是给群晖那一路用子码流或降一档分辨率。接法二：群晖拉 NVR 的流。 NVR 已接好所有头，群晖不再直连摄像头，而是通过 NVR 的 RTSP/ONVIF 通道把画面拉过来再录一份。优点是群晖侧只配 NVR 一个设备、授权占用少；缺点是 NVR 一挂，两份一起断，只能算“多一份拷贝”，不算真独立备份。现场已有 NVR 且不想动摄像头接线时，用这个过渡可以，但关键通道建议还是走接法一。不管哪种接法，录像计划都要分开设：NVR 侧设 24 小时连续录像，群晖侧对关键通道设连续录像 + 移动侦测报警录像叠加，非关键通道只设移动侦测录像，省盘又不漏事。报警联动别贪多：先把移动侦测灵敏度、侦测区域调准，再开推送，不然手机每天被误报刷屏，最后人就把推送关了，等于没装。五、存储怎么算、怎么配才不爆盘录像存储先算再买盘，公式很简单：单路每天存储 ≈ 码率（Mbps）× 86400 ÷ 8 ÷ 1024（GB）按主码流 4Mbps 算，单路每天约 43GB，8 路连续录 30 天约 10TB。群晖侧只给关键通道做连续录，移动侦测通道按实际触发时长打折算，盘就省下来了。群晖侧配置要点：给 Surveillance 单独建一个存储空间或共享文件夹，别和照片、文件备份混在一个卷里，录像写满不会拖垮别的服务。每个摄像头设录像保留天数和空间上限，写满按“先删最旧”循环覆盖，别等盘满了才发现新录像写不进。重要事件单独存档：查到关键片段后，用 Surveillance 的导出功能另存一份到别的共享文件夹或备份任务里，循环覆盖删不到它。结合 3-2-1 思路：NVR 一份、群晖一份，关键事件再导出一份到别处，才算闭环。备份方案的完整做法见相关旧文。六、回放与权限：谁能看、能看哪一路装完能看只是及格，分得清“谁能看哪一路”才算交付。群晖 Surveillance 里按人建账号：店长看全部，值班员只看大门和仓库，保洁、临时人员不给 Surveillance 账号，只给实时预览或干脆不给。手机端用 DS cam 登录，远程看之前先确认群晖的远程访问走的是自家内网穿透或 QuickConnect，别把 Surveillance 端口直接暴露到公网。回放查事流程固定下来：先定时间段，再按摄像头筛选，最后导出片段并备注事件时间——现场最常见的浪费时间不是没录像，而是没人知道去哪个时间点找。隐私红线：别把摄像头对着邻居家、员工更衣室、卫生间；员工、家人知情，是装监控的前提，不是可选项。七、现场避坑清单别用默认密码。 摄像头、NVR、群晖、ONVIF 用户，四个密码全改，摄像头后台的弱密码、不明端口、P2P 云服务不用的就关掉。固件先升级再交付。 海康、大华老固件的 ONVIF 兼容性坑最多，升级一次能省后面三趟上门。PoE 功率留余量。 交换机标称功率打七折算，红外夜视一开功耗就上去，满配必掉线。先通一路再批量。 第一路海康、第一路大华、第一路 NVR 联动都跑通并录满 24 小时，再批量复制配置，别一次加 16 路再排错。留一张拓扑图和一份 IP 表。 哪路头在哪个位置、IP 是多少、接哪个 PoE 口、录像存哪，写下来贴在机房或存进 NAS 文档里，下次维护的人（很可能就是半年后的你）会感谢这张纸。定期演练恢复。 每季度随机抽一天，实际从 NVR 和群晖各导出一段录像，确认两份都能播——没演练过的备份，等于没备份。八、结语监控这套东西，贵不在摄像头，贵在“出事时拿得出录像”。NVR 主录保底、群晖备份兜底、关键通道双录，这套组合不花哨，但停电、坏盘、被偷三种情况里至少有一种能保住证据。先按本文把一路海康、一路大华、一条 NVR 联动跑通，跑满 24 小时没掉线，再往上加路数，稳得多。相关旧文群晖 Surveillance 接入监控摄像头实现无限制空间存储录像（2024 年旧文，单点接入思路，本篇的多品牌 + NVR 联动为其进阶做法）：https://www.yeyhome.com/2024/05/05/38.html群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好：https://www.yeyhome.com/2026/10/20/285.html一个门禁项目的布线到调试踩坑手记：https://www.yeyhome.com/2026/10/18/284.htmlLucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选（远程看回放的通道选型）：https://www.yeyhome.com/2026/10/14/268.html

lucky证书更新群晖自动同步 引言家里这套东西跑起来之后，有一个细节很容易被忽略：反代用的证书和群晖 DSM 用的证书，其实是同一张。Lucky 作为反代入口，负责申请和续签 Let's Encrypt 证书；DSM 的 Web 界面、群晖套件的 HTTPS 访问，走的也是这张证书。Lucky 续证很勤快，DSM 这边却不会自己跟着换——续证之后如果不把新证书同步过去，DSM 用的还是旧证书，拖到旧证书过期，浏览器就会开始报不安全。所以需要一个同步机制：Lucky 证书一变，DSM 里的证书就跟着变。这篇文章记录的就是我最后定下来的方案：不按固定日期跑，改成每天检测证书指纹，变了才同步。一、原来每三个月跑一次，为什么不好最开始我用的是 DSM 任务计划里一个每三个月执行一次的任务，到日子就跑更新脚本。这个办法能用，但有两个别扭的地方。第一，续证时间不固定。Let's Encrypt 证书有效期 90 天，Lucky 一般提前 30 天左右续签，也就是说证书实际变化的时间点，取决于 Lucky 的续签策略，而不是日历上的固定日期。按固定日期跑，运气好能赶上，运气不好就错过一轮。第二，时间卡得太死。我当时把任务定在证书到期日当天晚上，等于一点缓冲都没有。万一那次执行出点问题（比如脚本报错、服务没重启），旧证书过期了都还没人发现。后来我想明白了：与其算日子，不如直接盯着证书文件本身。文件变了，就说明续证发生了；文件没变，就什么都不用做。二、更新脚本到底做了什么同步的核心是一个更新脚本，它做四件事：先把 DSM 里正在用的旧证书备份一份，带时间戳，存在 Lucky 的配置目录下；把 Lucky 的新证书、新私钥复制到 DSM 的证书存档目录；把证书和中间证书合并成 fullchain；重启 DSM 的 nginx，让新证书生效。这里有个坑，值得单独说一句：这个脚本是宿主机脚本，不能在 Lucky 容器终端里跑。容器里看到的 /app/conf，其实就是宿主机上的 /volume1/docker/lucky 映射进去的；而 DSM 的证书目录 /usr/syno/etc/certificate/_archive/... 根本没有挂载进容器，synosystemctl 也是宿主机才有的命令。在容器里执行，只会得到一堆"文件不存在"。所以更新脚本必须跑在宿主机上，DSM 任务计划的用户账号选 root 就是这个原因。更新脚本全文如下（域名和存档目录换成自己的）：#!/bin/bash # 证书源目录 CERT_SRC_DIR="/volume1/docker/lucky/ssl" # 证书文件名，这里需要你按照你自己的情况修改，把你自己的域名填写在里面，比如上面你的域名填写的是*.qq.com，那么这你就填qq.com CERT_FILE="$CERT_SRC_DIR/yeyhome.pem" KEY_FILE="$CERT_SRC_DIR/yeyhome.key" CHAIN_FILE="$CERT_SRC_DIR/yeyhome_issuerCertificate.crt" # 群晖证书目标目录，这里需要你按照你自己的情况修改，一会在第三点里面会讲这个具体的位置是什么，每个人都不一样 CERT_DEST_DIR="/usr/syno/etc/certificate/_archive/9i9viz" # 备份旧证书 BACKUP_DIR="/volume1/docker/lucky/ssl/backup/cert_backup" mkdir -p "$BACKUP_DIR" # 创建备份目录 cp "$CERT_DEST_DIR/cert.pem" "$BACKUP_DIR/cert.pem.$(date +%Y%m%d%H%M%S)" # 备份证书 cp "$CERT_DEST_DIR/privkey.pem" "$BACKUP_DIR/privkey.pem.$(date +%Y%m%d%H%M%S)" # 备份私钥 cp "$CERT_DEST_DIR/fullchain.pem" "$BACKUP_DIR/fullchain.pem.$(date +%Y%m%d%H%M%S)" # 备份完整证书链 # 更新证书 cp "$CERT_FILE" "$CERT_DEST_DIR/cert.pem" # 复制新证书 cp "$KEY_FILE" "$CERT_DEST_DIR/privkey.pem" # 复制新私钥 cat "$CERT_FILE" "$CHAIN_FILE" > "$CERT_DEST_DIR/fullchain.pem" # 合并证书和中间证书 # 重启群晖 Web 服务 synosystemctl restart nginx # 重启 Nginx 使新证书生效 echo "证书已更新并重启服务。"注意事项：存档目录因人而异：9i9viz 是 DSM 给这张证书分配的存档编号，每台机器、每张证书都不一样，不能照抄。用 SSH 看 /usr/syno/etc/certificate/_archive/ 下面哪个目录里的证书和你的域名对得上（可以用 openssl x509 -in 目录/cert.pem -noout -subject 看域名），就用哪个。文件名按自己域名改：yeyhome.pem、yeyhome.key、yeyhome_issuerCertificate.crt 换成你自己的证书文件名。必须用 root 跑：DSM 的证书存档目录只有 root 能写，DSM 任务计划的用户账号要选 root，普通账号连查看都会被拒绝。只能在宿主机上跑：不要在 Lucky 容器终端里执行，容器里没有 DSM 证书目录，也没有 synosystemctl 命令。别只看成功提示：这个脚本没有 set -e，中途某一步失败也不会停下，最后还是会打印“证书已更新并重启服务”。所以每次同步后都要核对 DSM 里证书的修改时间和指纹，确认真的换了。旧证书有备份：每次执行都会把旧证书、旧私钥、旧 fullchain 带时间戳备份到 ssl/backup/cert_backup，万一新证书有问题可以回滚。三、新方案：每天检测指纹，变了才同步新方案的思路很简单：每天凌晨 3 点跑一次检测脚本，比对 Lucky 证书文件的 md5 指纹。指纹和上次记录的一样，说明证书没变，直接退出，nginx 也不会被重启；指纹不一样，说明 Lucky 续证了，马上执行更新脚本，同步成功后才把新指纹写下来。如果更新失败，指纹不会被写死，第二天还会再试一次。检测脚本全文如下：#!/bin/sh CERT=/volume1/docker/lucky/ssl/yeyhome.pem STATE=/volume1/docker/lucky/.cert_last_md5 LOG=/volume1/docker/lucky/check_ssl.log [ -f "$CERT" ] || exit 0 NEW=$(md5sum "$CERT" | awk '{print $1}') OLD=$(cat "$STATE" 2>/dev/null) if [ "$NEW" != "$OLD" ]; then if bash /volume1/docker/lucky/update_syno_cert.sh; then echo "$NEW" > "$STATE" echo "$(date '+%Y-%m-%d %H:%M') 证书变化，已同步" >> "$LOG" else echo "$(date '+%Y-%m-%d %H:%M') 证书变化，但更新脚本失败" >> "$LOG" fi else echo "$(date '+%Y-%m-%d %H:%M') 证书未变，跳过" >> "$LOG" fiDSM 任务计划里的设置也很简单：任务名 check ssl，用户账号 root，计划每天 3 点，脚本直接粘贴到任务的脚本框里，不用单独存文件。第一次跑的时候还没有旧记录，会先同步一次并重启一次 nginx，这是正常的；之后证书没变就每天只记一行日志。这里面有三个文件，分工很清楚：yeyhome.pem：Lucky 维护的证书本体，是检测对象；.cert_last_md5：上次同步时的证书指纹，是判断"变没变"的基准；check_ssl.log：每次运行的记录，能看到哪天跳过、哪天同步。四、怎么确认它真的在工作搭好之后不用天天盯着，但第一次最好验证一下：看日志：check_ssl.log 里应该有一行"证书未变，跳过"，说明检测脚本已经跑通过；看 DSM 证书：DSM 证书存档目录里 cert.pem 的修改时间，应该和 Lucky 证书同步的时间对得上；也可以直接比对两个文件的 md5，完全一致才算同步到位；看任务状态：DSM 任务计划列表里，check ssl 的"上次运行时间"和"状态"每次跑完都会更新，状态是成功就说明没问题。资源占用也不用担心。每天一次的检测，就是读一个 5KB 多的文件算个 md5、再读一个几十字节的状态文件，全程几十毫秒，没有常驻进程。真正"重"的重启 nginx，一年也就发生几次——只在证书真的续签了那天。五、另外两条路为什么没选其实还考虑过另外两个方案，最后都没用，顺便记一下，免得以后绕回来。一个是 Lucky 的触发器 + Bark 推送：Lucky 续证后触发一条 Bark 消息，再由脚本检测到消息后执行更新。这个办法的问题是 Bark 只有推送接口，没有查询历史消息的接口，脚本没法直接"看到"消息；要实现就得去翻 Bark 容器的日志，可靠性差了一截。另一个是 inotify 实时监听：守着证书文件，一变立刻执行。这是最实时的，但群晖默认没有 inotifywait，得另外装工具、搞常驻进程和开机自启，为 90 天才发生一次的事折腾这个，不值。指纹检测算是折中得刚刚好：每天一次，延迟最多 24 小时，失败自动重试，没有常驻进程，也不依赖任何外部服务。结尾证书这种东西，平时感觉不到它的存在，出问题的时候却都是大事。把同步做成"变了才动、动了必记"的样子，之后就不用再算日子、不用再惦记续证时间，交给每天凌晨 3 点的那一次检测就行。相关旧文：Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选

Immich 自建相册实测：能不能替代群晖 Photos Immich 自建相册实测：能不能替代群晖 Photos家里群晖 NAS 用了几年，Photos 里的照片从几千涨到了几万张。最近家人开始抱怨：手机备份经常漏、找人脸照片要翻半天、AI 识别的准度也不太行。趁这个机会，我在群晖上用 Docker 部署了开源的 Immich，实测跑了两周——这篇就说说它能不能替代群晖 Photos、部署过程和从 Photos 迁移过来的成本。先说结论：Immich 是干什么用的Immich 是一个开源的自托管照片/视频备份方案，号称"Google Photos 自建版"。它和群晖 Photos 最大的区别有三点：多端备份更主动：iOS / Android 客户端有真正的后台备份，定时任务、仅 Wi-Fi、仅充电等策略都有；AI 能力更强：内置人脸识别、语义搜索（比如搜"海边""狗"直接出图）、地图时间线，用的都是本地模型，不上传云端；权限更开放：支持多用户、共享相册、相册链接分享，API 完善，第三方客户端和插件多。如果你只是要一个"NAS 上存照片"的地方，群晖 Photos 够用了。但如果你要的是全家人手机自动备份 + 能按人脸/场景快速找回，Immich 值得一试。Docker 一键部署：群晖 Container Manager 实战Immich 官方提供 docker-compose 部署，一共 4 个核心容器：服务端（server）、PostgreSQL 数据库、Redis、机器学习服务（machine-learning）。群晖 DSM 7.2 的 Container Manager 直接支持 compose 项目，步骤如下：第 1 步：准备共享文件夹在 File Station 建两个共享文件夹（或同一文件夹下的子目录）：/docker/immich —— 放配置文件和数据库数据/volume1/photo/immich-library —— 放真正的照片库（建议和 Photos 用同一个 volume 但不同目录，方便迁移对比）第 2 步：写 compose 文件去 Immich 官网 release 页下载官方的 docker-compose.yml 和 .env 模板（官网有完整文档，本文用当时最新版 v1.1xx）。核心配置注意这几项：services: immich-server: container_name: immich_server image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release} volumes: - ${UPLOAD_LOCATION}:/data # 照片实际存储路径 - /etc/localtime:/etc/localtime:ro env_file: - .env ports: - 2283:2283 depends_on: - redis - database restart: always.env 里关键的几项：UPLOAD_LOCATION=/volume1/photo/immich-library DB_PASSWORD=改一个强密码 IMMICH_VERSION=release第 3 步：Container Manager 建项目Container Manager → 项目 → 新增 → 输入项目名称 immich，把 compose 文件内容粘贴进去，建好后启动。第一次启动会拉 4 个镜像，大约 2~3 GB，群晖的千兆内网一般几分钟拉完。启动成功后浏览器打开 http://群晖IP:2283，先注册管理员账号（第一个注册的就是管理员），然后就可以建用户、装手机 App 扫码登录了。第 4 步：挂载已有照片目录如果你 NAS 上已经有整理好的照片目录（比如 Photos 的备份文件夹），可以直接把目录映射进容器，然后在后台"外部库（External Libraries）"里添加，Immich 会扫描入库，不复制文件。这是我从 Photos 迁移时最省事的一步，下面迁移部分细说。两周实测：和群晖 Photos 对比体验我拿了同一批约 1.2 万张照片 + 800 个视频做对比，结论先行：对比项群晖 PhotosImmich手机自动备份iOS 后台经常被杀，需手动打开后台备份稳定，可设仅 Wi-Fi / 仅充电人脸识别有，但合并/纠错麻烦人脸聚类 + 手动命名，准确率明显更高语义搜索基本没有"日落""猫"这类词直接搜，中文关键词可用分享共享空间/相册相册链接分享 + 密码 + 有效期，更灵活多用户需 DSM 账号体系独立用户体系，家人不用给 DSM 账号资源占用轻较重，AI 识别时 CPU 会跑满一阵几个实测细节：备份可靠性：iPhone 上 Immich 的后台备份两周零漏传；Photos 之前平均每周漏 2~3 天，得手动点开 App 触发。这对"给爸妈备份"这个场景是决定性差距。人脸识别速度：DS920+ 上 1.2 万张照片的初始识别跑了约 6 小时（CPU 满载），之后增量识别无感。识别准度上，同一人的不同年龄段照片基本能聚到一起，Photos 那边我手动合并了几十次。视频回放：Immich 默认会转码生成预览，手机端滑动时间线很跟手；原画质点开即看。HEVC 视频在部分旧安卓机上需要转码，NAS CPU 弱的话会有点卡。搜索体验：搜"身份证""发票"这种文档类照片，Immich 的 OCR + 语义搜索基本能命中，Photos 只能靠文件名和时间。避坑：部署前必须知道的 5 件事内存至少 4GB 可用：machine-learning 容器吃内存，2GB 内存的入门 NAS（如 DS220j 这类）别折腾，会卡到怀疑人生。DS920+ / DS923+ 这种 4GB 起步的没问题。数据库密码别用特殊字符：DB_PASSWORD 里如果有 # ! 这类字符，compose 解析可能出问题，用纯字母数字最稳。照片目录权限：容器内默认用 UID 1000 读写，群晖上给共享文件夹的读写权限时，注意勾选"应用到子文件夹"。权限不对的表现是上传 0 字节文件。版本升级别追 latest 太快：Immich 迭代快，偶尔有 breaking change。生产库建议锁 IMMICH_VERSION 为具体版本号，升级前先看 release notes，有数据库迁移的一定先备份。备份 Immich 的数据库：照片文件在 /data 里好备份，但人脸标注、相册关系都在 PostgreSQL 里。定期用 pg_dump 导出一份，或者把 database 容器的数据卷纳入 Hyper Backup。从 Photos 迁移过来，成本有多大这是大家最关心的。我实测的迁移路径：照片文件：Photos 的照片实际存在 /photo 下（按时间分目录），直接把该目录映射为 Immich 的外部库，扫描入库，零复制、零耗时（除了 AI 识别那几小时）。相册关系：Photos 里的相册不会自动过来。我的做法是：重要的家庭相册（大概 30 个）在 Immich 里重建，用"按条件筛选 + 批量加入"的方式，两个人一下午搞定。不重要的相册直接放弃——迁移是个断舍离的好机会。人脸标注：Photos 的人脸数据导不出来，Immich 要重新识别。这是最大的一次性成本，但识别完准度更高，算值得。分享链接：Photos 的旧分享链接会失效，提前通知家人换新链接。总成本：一下午的人工 + 一晚上 AI 识别的电。迁移完我把 Photos 保留为"冷备份"，Immich 作为日常主力。怎么卸载：不喜欢就干净撤走Immich 是纯 Docker 部署，卸载非常干净：Container Manager 里停止并删除 immich 项目（勾选"同时删除容器"）；删掉 /docker/immich 配置目录（数据库数据在这里）；照片库目录 /volume1/photo/immich-library 如果是外部库映射的，不要删，那是你的原照片；手机 App 卸载即可。整个过程不碰 DSM 系统，Photos 的数据完全不受影响，可以随时回滚。这也是我敢拿主力照片库做实测的原因。总结：谁适合换，谁没必要适合换：家人多、手机备份老是漏、人脸/场景搜索是刚需、NAS 内存 4GB 以上。没必要换：就自己一个人用、照片量不大、Photos 用得挺顺手、NAS 是入门款。我自己的选择：Immich 主力 + Photos 冷备份，两条腿走路。毕竟照片这东西，丢一次的教训比什么都贵。相关旧文群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好 —— Immich 的数据库记得纳入备份计划Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战 —— 容器管理更顺手Komari 轻量服务器监控：Docker 一键部署 + 与 Uptime Kuma 区别详解 —— 顺手监控下 NAS 负载

群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好 群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好前言：NAS 不是保险箱很多人把数据塞进群晖 NAS 就觉得万事大吉：RAID 保护、硬盘冗余、UPS 续航……听上去固若金汤。但干了这些年弱电和 NAS 维护，我见过的翻车实在太多：硬盘到寿批量坏掉、勒索病毒加密全盘、一场雷击带走整台机器、装修工人一脚踢掉电源。这些事故发生时，很多人才第一次意识到：RAID 只是"高可用"，不是备份。硬盘坏一块能恢复，数据被加密、被删除、整机被偷，RAID 一点忙都帮不上。真正靠谱的做法是业界用了几十年的 3-2-1 备份原则：至少 3 份数据，存放在 2 种不同介质上，其中 1 份放在异地。今天这篇文章，就在群晖 DSM 7.2 上把这套方案一次配好：快照（防误删、勒索）+ Hyper Backup 本地备份（防整机故障）+ 异地备份（防火灾、盗窃），最后再做一次完整的恢复演练——没演练过的备份，等于没备份。一、先规划：三层防线各防什么层级工具防什么恢复速度成本第一层快照复制（Snapshot Replication）误删、改错、勒索病毒秒级几乎为零第二层Hyper Backup → USB 移动硬盘整机故障、硬盘全挂分钟~小时级一块硬盘的钱第三层Hyper Backup → 异地 NAS / 公有云火灾、盗窃、本地天灾小时~天级按量付费三层是"串联"不是"三选一"：快照快但怕整机没了，本地备份全但怕家里出事，异地备份最保险但恢复最慢。配齐三层，任何一层出问题都有兜底。二、第一层：快照——防误删和勒索的最快防线快照严格说不算备份，但它是性价比最高的防线。Btrfs 文件系统的写时复制（COW）特性，让快照生成只需几秒、平时几乎不占空间。只有装在 Btrfs 文件系统上的共享文件夹才能拍快照——如果是旧存储池（EXT4），得先迁移，这个提前确认好。配置步骤打开 快照复制 套件，选中存放重要数据的共享文件夹（比如 home、photo、docker）；点击「快照」→「设置」→「计划」，设为每天自动快照一次，建议凌晨业务低峰时段；「保留原则」里设保留最近 30 个快照，勾选「锁定」最关键时间点的快照，防止被保留策略自动删掉；开启「快照可见性」，这样在 File Station 里可以直接浏览快照里的历史文件。恢复怎么用在 File Station 里右键共享文件夹 →「浏览以前的版本」，找到删错之前的时间点，把文件拖出来就行，整个过程几秒钟。勒索病毒加密了当前文件？快照是只读的，加密软件动不了快照里的旧版本，直接从快照还原即可。避坑快照防不了整机故障：机器丢了、存储池崩了，快照跟着一起没。它只负责"第一层"，千万别把它当完整备份。快照保留数量别贪多：每个快照都保留一份"差异数据"，保留 30 天对普通家庭/小办公室足够，保留一年会把空间吃光。重要目录建议单独建共享文件夹拍快照，比如把 Docker 容器映射卷单独放一个共享文件夹，恢复容器数据时不会影响别的文件。三、第二层：Hyper Backup 本地备份——防整机故障Hyper Backup 是群晖官方备份套件，支持备份到本地文件夹、USB 外接设备、另一台群晖、公有云。先配本地这层：拿一块容量大于等于源数据的移动硬盘（建议 USB 3.0 以上接口），插到 NAS 的 USB 口上。配置步骤套件中心安装 Hyper Backup，打开后「新增」→「数据备份任务」→ 选择「本地文件夹和 USB」；勾选要备份的共享文件夹（建议全选重要目录）、应用程序（比如 Container Manager 的配置、MailPlus）；备份目的地选插好的 USB 移动硬盘，勾选「启用备份计划」（每周一次全量+每日增量是常用组合）；务必勾选「启用客户端加密」并记好密码：硬盘丢了也不怕数据泄露；但密码丢了备份就彻底打不开了，密码和备份介质必须分开存放；开启「备份完整性检查」，让 NAS 定期验证备份包没坏。恢复怎么用Hyper Backup →「还原」→「数据」，选择 USB 上的备份任务，可以整包还原，也可以只挑几个文件还原。手机端装 Hyper Backup Explorer 同理。避坑USB 硬盘建议两块轮换：A 盘在 NAS 上备份，B 盘放在公司/亲戚家，每周换一次。这其实是"异地"的廉价实现，我称它为"人肉异地"。备份完拔掉硬盘或至少在 Hyper Backup 里暂停任务：勒索病毒如果能访问到挂载的 USB 盘，备份盘也可能遭殃。离线，才是备份的终极保险。别用杂牌硬盘做备份盘：备份盘是最后防线，用靠谱品牌，SMART 定期检查。四、第三层：异地备份——防火灾和盗窃本地两层都配好了，还剩最后一层：异地。方案按成本从低到高：方案 A：备份到亲戚/老家的另一台群晖（推荐）在对方 NAS 上装 Hyper Backup Vault 套件，本机 Hyper Backup 新增任务选「远程 NAS 设备」，填对方的 QuickConnect ID 或域名+端口。首次全量备份建议把硬盘拿到现场做（几百 GB 走公网传要传到天荒地老），之后每天增量走公网即可。异地机器如果在内网没有公网 IP，可以用本站之前实测过的内网穿透方案打通：参考本站文章《Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选》。方案 B：备份到公有云Hyper Backup 原生支持 Synology C2、S3 兼容存储、阿里云 OSS、腾讯云 COS 等。优点是省心、不用求人；缺点是长期费用。小数据量（<100GB）可以考虑 C2 的免费/低价档；大照片库走公有云一年下来不便宜，建议只把最重要的文档类数据放云端。方案 C：备份到 VPS（rsync）有闲置 VPS 的话，Hyper Backup 支持 rsync 目标。注意 VPS 硬盘一般不大，适合文档类数据；另外记得给 VPS 也做好快照，异地备份本身也需要被保护。避坑异地备份必须开客户端加密：数据要经过公网、放在别人机器上，不加密等于裸奔。加密密码、Hyper Backup 的备份任务配置，单独记一份放在密码管理器里（本站有《Vaultwarden 自建密码库：Docker 一键部署 + 多端同步实战》可以参考）。异地备份的恢复演练最容易被忽略，但恰恰是它最可能在关键时刻掉链子——见下一节。五、恢复演练：没演练过的备份等于没备份备份配完只是完成了 50%，另外 50% 是确认它真的能恢复。建议每季度做一次，流程如下：快照演练：在测试目录新建一个文件，删掉，然后从快照里找回来。确认快照计划真的在跑、保留策略没把需要的版本清掉。本地备份演练：从 USB 备份里还原一个共享文件夹到临时目录（别直接覆盖生产数据），打开几个文件确认能正常读取。异地备份演练：模拟"本地全挂"——从异地备份里拉回一份关键数据。重点验证：网络通不通、加密密码对不对、恢复速度能不能接受（几百 GB 的异地恢复可能要一整天，这个时间要心里有数）。把演练结果记下来：哪一层花了多久、有没有报错。演练中发现的问题（比如 USB 盘 SMART 报错、异地任务连续失败一周没人看）现在修，总比灾难那天修便宜。另外给 Hyper Backup 开启通知：控制面板 → 通知 → 勾选 Hyper Backup 任务失败时推送到手机/邮箱。备份任务静默失败几个月，是我见过最多的"假备份"。六、避坑清单（全文精华）RAID ≠ 备份，再说一遍。快照只防"文件级"事故，整机没了快照也没了。备份盘备份完就离线，防勒索。异地备份必须客户端加密，密码和介质分开存。备份通知必须开，静默失败最致命。每季度做一次恢复演练，恢复时间要心里有数。USB 备份盘两块轮换，等于廉价异地。应用程序配置也要备份：Docker 容器的 compose 文件、MailPlus 设置，重装时比数据还难找回。写在最后3-2-1 听起来像大道理，落到群晖上其实就是三个套件、一下午的配置：快照复制管"手滑"，Hyper Backup + USB 管"机器挂"，Hyper Backup + 异地管"家没了"。配完记得做一次演练，然后你就可以安心地把照片、文档、项目资料交给这台小黑盒子了——毕竟，备份的价值不在"有"，而在"灾难那天真的能拿回来"。相关旧文Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选 —— 异地备份到另一台 NAS 时，内网穿透选型参考Vaultwarden 自建密码库：Docker 一键部署 + 多端同步实测 —— 备份加密密码存哪？放进自建密码库Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战 —— 记得把 Docker 容器数据目录也纳入备份范围

Komari 轻量服务器监控：Docker 一键部署 + 与 Uptime Kuma 区别详解 Komari 轻量服务器监控：Docker 一键部署 + 与 Uptime Kuma 区别详解手里几台 VPS、NAS、小主机，CPU 飙了、磁盘满了、流量跑超了都不知道？今天介绍 Komari：一款轻量开源的服务器监控面板，MIT 协议免费，Docker 一条命令跑起来，多台机器的资源状态一屏看清。顺带讲清楚它和 Uptime Kuma 到底有什么区别、该怎么选。Komari 是什么？Komari（komari-monitor/komari）是一个自托管的服务器监控工具，Go 语言开发，GitHub 6000+ Star，MIT 开源协议，完全免费无付费版。它的工作模式和“哪吒探针”类似：面板端 + Agent 端。你在 NAS 或一台 VPS 上部署面板（Dashboard），然后在每台要监控的机器上装一个轻量 Agent，Agent 会把 CPU、内存、磁盘、网络、流量、负载等指标实时上报到面板，打开网页就能看到所有机器的状态。核心特点：极轻量：Agent 资源占用极小，面板默认 SQLite，不用额外装数据库；秒级实时：官方称监控数据按秒级间隔展示，机器状态变化立刻可见；自托管：数据只留在你自己的服务器上，不经过第三方；可玩性高：支持自定义主题和插件，社区有主题市场，监控页可以做得很好看；附带 Web 终端：面板里可以直接打开被控机的终端，排查问题不用再 SSH。Docker 部署面板：一分钟搞定官方镜像在 GitHub Container Registry，默认端口 25774，数据目录 /app/data，不配数据库就用 SQLite：mkdir -p ./data && docker run -d \ -p 25774:25774 \ -v $(pwd)/data:/app/data \ --name komari \ --restart unless-stopped \ ghcr.io/komari-monitor/komari:latest更推荐 Compose，方便以后升级：services: komari: image: ghcr.io/komari-monitor/komari:latest container_name: komari restart: unless-stopped ports: - "25774:25774" volumes: - ./data:/app/data启动后打开 http://服务器IP:25774，首次访问会进入安装向导：创建管理员账号、设置站点名称。./data 目录存着账号、配置和监控记录，记得定期备份。群晖 NAS（Container Manager）部署步骤Container Manager → 项目 → 新增，项目名填 komari，路径选一个顺手的共享文件夹；把上面的 Compose 内容粘贴进 docker-compose.yml；下一步完成，等镜像拉取完、容器状态变为运行中；浏览器打开 http://群晖IP:25774，按向导创建管理员账号。端口提醒：25774 记得在群晖防火墙放行（仅内网访问的话不用映射到公网）。接入被控机：装 Agent面板跑起来只是第一步，Komari 的精髓是 Agent 上报。流程：登录面板后台，进入节点管理，添加一个节点（填个名字，比如“腾讯云-上海”）；面板会生成一条一键安装命令，里面带了面板地址（endpoint）和节点 Token；去被控机上以 root 执行这条命令，Agent 就会自动下载、安装并连回面板；回到面板，节点显示在线，CPU/内存/磁盘/流量曲线开始滚动。Agent 本身也支持容器化（ghcr.io/komari-monitor/komari-agent，参数 -e 面板地址 -t Token），但注意：容器里的 Agent 只能看到容器视角的资源，想监控整台宿主机还是建议用一键脚本直接装在宿主机上。装完后的效果大概是这样（官方仪表盘实拍）：核心功能速览节点总览：所有机器在线状态、CPU/内存/磁盘/流量、累计流量一屏展示；历史曲线：每台机器的资源使用历史图表，半夜谁在偷跑流量一目了然；Web 终端：面板里直接进被控机终端，应急排查不用找 SSH 客户端；通知告警：节点掉线、资源超限可以推送通知（支持 Telegram 等常见渠道）；主题市场：监控页支持换主题，做成公开的服务器状态页也很好看。重点：Komari 和 Uptime Kuma 有什么区别？这是被问得最多的问题。两者都是“监控”，但监控的东西完全不是一回事：对比项KomariUptime Kuma监控对象服务器本身（CPU/内存/磁盘/流量）服务是否在线（网站/API/端口通不通）工作原理被控机装 Agent，由内向外上报指标监控端由外向内主动探测（HTTP/TCP/Ping/DNS）被监控端需要安装 Agent什么都不用装典型问题“这台 VPS 内存是不是又满了？”“我的博客是不是又挂了？”状态页有（展示机器状态）有（展示服务在线率，更成熟）告警节点掉线、资源超限告警服务 Down 告警，通知渠道极丰富（90+ 种）部署面板容器 + 每台机器装 Agent单个容器即可资源占用都很轻都很轻一句话总结：Komari 回答“机器健不健康”，Uptime Kuma 回答“服务活没活”。举个例子：你的博客打不开了——Uptime Kuma 会立刻告诉你“网站 Down 了”；而 Komari 会告诉你“这台 VPS 的内存 98%、磁盘满了”，帮你定位为什么挂了。一个管“现象”，一个管“原因”。该怎么选？只想知道网站/服务有没有挂 → Uptime Kuma 就够了，部署最简单；手里有多台 VPS/NAS，想看资源用量、流量统计 → Komari；都想要 → 两个都跑，它们是互补关系不是替代关系。很多人的标准组合就是：Uptime Kuma 做存活告警 + 状态页，Komari 做资源总览。（本站后续也会出一篇 Uptime Kuma 的部署教程，敬请期待。）远程访问与安全建议面板默认 HTTP，不要直接把 25774 暴露到公网。需要外网看监控页，走反代 + HTTPS（Lucky / Nginx Proxy Manager 都行）；Agent 连面板走的是出站连接，被控机不用开入站端口，NAT 后面的机器也能接；管理员设强密码，./data 目录定期备份——监控历史丢了是小事，账号配置丢了重建麻烦。总结Komari 是一款“装完就回不去”的小工具：面板一条 Docker 命令，被控机一条安装命令，几台机器的 CPU、内存、流量就全收进一个仪表盘了。配合 Uptime Kuma，一个管机器健康、一个管服务存活，个人服务器的监控体系就算齐活了。花二十分钟搭起来，以后半夜收到告警，打开面板就知道是哪台机器在作妖。相关阅读：Dockhand 开源 Docker 可视化管理面板：群晖 NAS 一键部署实战群晖 Docker 容器升级失败怎么办：备份、回滚与日志排查完整指南群晖 NAS 使用 Docker 部署 Lolia FRP 实现多隧道内网穿透Lucky 反代宝塔面板 — Docker macvlan + bridge 双网络解决方案