背景：2026 年 10 月 28 日，家里那台 2024 年装的黑群晖（旧引导伪装成 DS918+，DSM 7.2）被 C3RB3R 勒索病毒加密——公网端口映射裸奔 + 系统两年没更新，中招的经过另有一篇记录。这台机器只存门口监控录像，数据可弃，所以处置路线很干脆：旧系统不修了，整台推倒，全新重装。这篇记录的是 10 月 29 日晚间重装的全过程，给同样玩黑群晖的朋友做个参考。

一、为什么是"全新安装"，不是"恢复"

29 日傍晚最初的想法，是先把旧系统断网开机，看一眼快照还在不在。为此在路由器上专门建了一条拦截规则（Block-Syno-Internet）防它联网，结果旧 DSM 通过 DHCP 拿了个新地址绕开了按 IP 写的规则；Synology Assistant 里它的状态显示"设置数据毁损"（系统配置已丢失）。

看到这个状态就不用纠结了：系统配置已毁、数据全加密，就算勉强恢复也是个带毒的烂摊子。当即拍板：不恢复、不迁移，全新安装，用当前最新的引导和系统组合。（中途还闪过"干脆删掉群晖改装 Debian"的念头，也否了——监控这件事，DSM 的 Surveillance Station 还是最顺手的。）

二、准备引导：RR 26.9.0

  1. 下载 RR 引导镜像 rr-26.9.0.img.zip（RROrg 的 RR 是目前黑群晖主流引导）；
  2. 在 PVE 里用 qm importdisk 把镜像导入群晖虚拟机（VM 102），作为新引导盘；旧的 GXNAS 引导盘没有删，留着作后备——引导出问题时能退回去，这一步很值；
  3. 进 RR 编译引导：机型选 SA6400（对新平台支持更好，没必要再伪装老机型），DSM 版本选 7.4.1。RR 26.9.0 与 DSM 7.4.1 是官方配套支持的组合，这点务必先确认——黑群晖的铁律是先确认引导支持、先升引导、再碰系统，顺序反了就是变砖。

一个小插曲：编译前忘了在 RR 里预设 MAC 地址，后来一想随机就随机吧。后果仅仅是路由器上按旧 MAC 做的静态租约和拦截规则对不上号了，无伤大雅——新系统本身已是干净状态（新密码、无端口转发、无 QuickConnect），不需要靠 MAC 隔离。

三、全新安装：关键一步是"不恢复"

从新引导启动后，DSM 安装器检测到硬盘上存在旧系统，弹出提示：检测到已安装的 DSM 系统，是否先尝试恢复？

这里选"不恢复"，走全新安装。旧系统是被勒索加密过的，恢复它等于把风险一并请回来。

安装完成后，先去看了一眼旧数据：满目 .L0CK3D，和预期一致。于是彻底格式化：

  • 删除旧存储池和存储空间；
  • 用直通的 WD Red WD40EFAX 4 TB（红盘）重建存储池：Basic + Btrfs（单盘监控盘，不需要 RAID；按摄像头约 4.2 Mbps 的主码率算，一天约 45 GB，4 TB 存 30 天录像绰绰有余）。

四、坑一：硬盘"与型号未验证"

建池时存储管理器提示硬盘"与型号未验证"。这是 SA6400 这类企业级机型的兼容性名单门槛：非群晖认证硬盘不在名单里就报这个，只是警告，不影响建池和使用，先放行。

当晚晚些时候顺手把它根治了：SSH 进 DSM，以 root 运行 007revad 的 Synology_HDD_db 脚本（v3.6.139），它把这块 WD40EFAX 和虚拟机的虚拟盘都注册进了 SA6400 的兼容数据库，硬盘立即转绿，全程不需要重启、更不需要重编引导。脚本输出顺带确认了系统构建号：DSM 7.4.1-90080-1。

用ssh登录群晖，以下命令：

sudo mkdir -m775 /opt
cd /opt
sudo curl -O "https://raw.githubusercontent.com/007revad/Synology_HDD_db/refs/heads/main/syno_hdd_db.sh"
sudo curl -O "https://raw.githubusercontent.com/007revad/Synology_HDD_db/refs/heads/main/syno_hdd_vendor_ids.txt"
sudo chmod 750 /opt/syno_hdd_db.sh
sudo /opt/syno_hdd_db.sh

留个备注：日后 DSM 更新有可能覆盖兼容数据库、让这个警告复活，届时把脚本重跑一遍即可。所以下面"冻结版本、不再升级"的决定，也顺带让这个小毛病永不复发。

五、坑二：SVE 装不上，监控套件被卡住

装 Surveillance Station 时，它的前置组件 SVE（Surveillance Video Extension）报错：

无法正确安装此套件。必须通过网络连接安装 SVE。请检查您的网络连接并再试一次。

这个报错文案是骗人的，跟网络一点关系没有。真正原因：SVE 安装时要做基于序列号的授权校验，而 RR 生成的 SA6400 序列号过不了这一关——这是 SA6400 + RR 的已知问题。

解法很简单：SSH 进 DSM，以 root 运行 RROrg 自家 rr-tools 里的 installsve 脚本，绕过授权校验，SVE 随后自动安装成功，Surveillance Station 跟着顺利装完。（备选方案是"半洗白"：在 Virtual Machine Manager 里建一台虚拟 DSM、取它的合法序列号回写引导——这次没用上，知道有这条路就行。）

同样，在ssh里输入：

curl -fsSL https://github.com/rrorg/rr-tools/raw/main/installsve -o /root/installsve && chmod +x /root/installsve && /root/installsve
之后把门口摄像头按原参数重新加回来（RTSP），监控恢复正常。当晚临时在另一台机器上顶班的 Frigate 容器随即删除，监控正式回归 DSM。

六、收尾设置：新系统的规矩

重装只是把系统救回来，这次真正的教训在设置上。新系统当晚和随后两天陆续定下这些规矩：

  • 纯内网使用：不做任何端口转发，不开 QuickConnect，远程访问一律走 Tailscale 这类加密通道先进内网；
  • 更新改为仅通知、手动决定，并且版本就冻结在 7.4.1 不再升级——纯内网的监控机没有追新的必要，冻结反而避开了"引导与系统版本脱节变砖"和"更新覆盖补丁"两类麻烦；
  • IPv6 关闭，确认这台机器不拿公网 IPv6 地址（IPv6 直达是很多人忽略的暴露面）；
  • 手机备份目录开不可变快照：另建了一个手机照片备份的共享文件夹（照片现在双路备份，一份进另一台 NAS 的 Immich，一份进这里），用 Snapshot Replication 给它设了每天一张快照、保留 30 张、其中 14 天不可变——谁都删不掉。监控录像本身则不做快照，可弃的东西不值得占这份资源。

七、经验小结

  1. 黑群晖中招之后别想着"修好旧系统接着用"，全新安装是最干净的路；安装器问要不要恢复旧系统，选否。
  2. 引导先行：RR 版本与 DSM 版本必须配套，导入 PVE 用 qm importdisk，旧引导盘留作后备。
  3. SVE 报"检查网络连接"先怀疑序列号授权，installsve 一条脚本解决，别在网络设置里瞎折腾。
  4. "硬盘未验证"是兼容名单问题，Synology_HDD_db 脚本可解，不用重编引导。
  5. 系统装好只是开始：纯内网、更新手动、重要目录不可变快照——这三条才是这次用一台机器的代价换来的东西。

（记录于 2026 年 11 月 3 日，事件发生于 2026 年 10 月 29 日晚。）

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注