把全家照片从云端搬回卧室：一台自组 NAS 的选型全是取舍

Tue, 30 Jun 2026 00:00:00 +0800

MOONSHADE · Bedroom NAS Architecture

Published 2026-06-30 · neutralized

SELF-HOSTED INFRASTRUCTURE · HOME NAS · 2026-06-30 · V1.0

把全家的照片
从云端搬回卧室

一台放在卧室、24×7 常开的自组 Mini-ITX NAS：65W APU、ZFS 双池、tailnet-only 不上公网，再加一整套自托管照片与门户服务。它叫 MoonShade。

A self-built, always-on bedroom NAS that hosts a family's entire photo pipeline on its own disks — every part chosen against one target: quiet, low-power, private, and yours.

为什么自己攒一台卧室 NAS / Why build one at all

P. 02

它在家里是什么节点 / The one hub on a private mesh

P. 03

硬件底盘：安静是硬指标 / The silent chassis

P. 04

存储地基 ZFS / Storage on ZFS

P. 05

服务栈：一台机器长出的一整套服务 / The service stack

P. 06

网络接入与安全模型 / Access & security

P. 07

会自己照顾自己 / Automation, human-in-the-loop

P. 08

门户与数据流 / Portal & data flows

P. 09

演进史：从 WSL2 到裸机 / How it got here

P. 10

备份、内存与取舍 / Backup, memory, honesty

P. 11

SCOPEOne machine — hardware to portal CHASSISMini-ITX · Ryzen APU · 65 W STORAGEZFS · RAID-Z1 · ~8 TB usable ACCESStailnet-only · trusted HTTPS

CHAPTER 01 · 立项

它存在的理由不是炫技，
是把照片赎回来

The point isn't a cool rig — it's pulling private data out of a rented cloud and onto a machine you fully control.

这台机器没有一处是为了「跑分好看」。它要解决的是一个很具体的焦虑：全家最重要的照片，正托管在一家随时可以改价、改条款、改可用性的商业云上。把它们搬回一台自己完全掌控、放在卧室、常年开着的盒子里——这是所有后续选型的出发点。

MoonShade 是一台自组 Mini-ITX 一体机，不是买来的成品 NAS。立项动机是三件事叠在一起：数据主权（照片「真身」握在自己盘里）、省掉云订阅（一次性硬件投入换长期不按月付费）、完全掌控（自己攒、自己定架构）。核心诉求写成一句话——桌面级性能 × 服务器级静音功耗 × 卧室可接受噪音。

选择自己攒而不是买成品，代价很清楚：要自己选料、自己装、自己维护。换回来的，是这几样成品机不容易同时给到的东西——核显硬件加速、跑得动完整 Docker 服务栈加机器学习负载、系统盘与数据盘物理分离、以及 ZFS 的完全自主。这台机器还兼一个身份：它自己托管着一个 AI agent 运行时（OpenClaw），由那个 agent 实例充当「NAS 管家」，日常看护这台机器的运维。

立项判断 · THE PREMISE

一台家用 NAS 值不值得自己攒，不取决于它多快，而取决于你愿不愿意为「数据握在自己手里」承担自攒自维的麻烦。这篇通篇讲的都是这份麻烦具体长什么样。
Whether to build your own NAS isn't about speed — it's about whether you'll accept the cost of building and maintaining it, in exchange for holding your own data. This whole piece is what that cost looks like.

CHAPTER 02 · 家庭网络里的定位

七个节点的私有网里，
它是唯一「两个中枢合一」的那台

On a private mesh of seven nodes, the NAS is the only one that is both the storage hub and the service hub.

先把这台 NAS 放回它所在的网络里看。整个家是一张基于 Tailscale（WireGuard mesh）的私有网，七个节点各有各的角色。其中六个要么是纯客户端、要么各自只跑一个 agent 实例；只有 MoonShade 一台，同时身兼存储中枢与服务中枢——照片库、文件库、备份、统一门户全落在它身上。

FIG 01 · 家庭 tailnet 拓扑 · HOME MESH7 NODES · NAS AS SOLE HUB

七个节点同在一张 WireGuard mesh 私有网内（彼此可直连，图中只画出以 NAS 为中心的服务/存储关系线）。焦点方框 = MoonShade，全网唯一同时承担存储与服务的节点；其余节点各自是客户端或单一 agent 宿主。没有任何一条线通向公网入站。

这张网有几条让它「省心」的性质：节点之间点对点直连（打洞成功后走公网直连而非中转），每台设备拿一个固定的私有地址（100.x 段，换 Wi-Fi 也不变），可以用主机名代替 IP 访问，不需要任何公网端口转发，而且「设备连进这张网」本身就等于完成了一次设备级身份认证。最后一条尤其关键——它让后面第 6 段的「透明单点登录」几乎零成本。

存储中枢 · STORAGE

RAID-Z1 机械盘池 + NVMe + 可插拔移动盘；每日快照，SMB 直接暴露给家中设备读写

服务中枢 · SERVICE

容器化跑两套照片库 / 文件管理 / SSO / 监控，收进一个统一门户

为什么是它 · WHY NAS

全网唯一 7×24 常在线又有大容量的节点——照片、备份、门户只能落这台

CHAPTER 03 · 硬件底盘

每一处选型，
都在为「安静地长期省电地跑」让路

Every part is a concession to one goal: run quiet, run low-power, run 24×7 — in a bedroom.

卧室、常开、要安静、要省电，但性能得够跑照片库的机器学习索引——这四个约束互相拉扯，硬件选型就是在它们之间找平衡点。下面三张卡片是三个关键取舍。

CPU · APU

Ryzen 5 5600G，要的是核显

6 核 12 线程、TDP 65W 的 APU。选带核显的 G 版而非标准 Ryzen 有两个用意：自带核显省掉一张独显的功耗与空间，还能给照片服务做硬件加速；65W 低热更容易压进 Mini-ITX 的静音热预算。

An APU, not a CPU — integrated graphics kill the need for a discrete card, and 65 W fits a silent ITX thermal budget.

BOARD · ITX

X570 I，要的是通道与板载 Wi-Fi

实机是 Gigabyte X570 I AORUS PRO WIFI。比更省的 B550 贵，换来的是更完整的 PCIe / 存储通道和更强供电——足够挂多块 SATA 机械盘加多条 NVMe；板载 Wi-Fi 让它摆位不受网口位置限制。

X570 ITX for full storage lanes and onboard Wi-Fi, so placement isn't tied to an ethernet jack.

LOAD-BEARING

散热：确定性 > 灵活性

120mm 一体水冷，水泵恒定转速（不调速，避免忽快忽慢的噪音起伏）。风扇曲线只能在 BIOS 里调——主板监控芯片是 ITE IT8689E，Linux 的 it87 驱动不认它，系统层拿不到 PWM 控制权。于是牺牲 OS 层动态调速，换 BIOS「设一次就静音」的确定性。

Fan curve lives in BIOS only — the mainline it87 driver can't see the IT8689E, so OS-side control is gone. Traded flexibility for set-once silence.

内存给了 16GB（系统可见 14GiB）加 4GiB swap。轻载常态下 used 约 3.6GiB、大量空闲页拿去做文件系统缓存——8 容器加照片库机器学习并发时到底够不够，留到第 10 段用实测峰值正面回答。

温度与功耗实测 · MEASURED THERMALS & POWER

传感器 / 指标	实测	说明 · Meaning
CPU（Tctl）	~54 °C	Light idle load — far from any throttle or alarm point.
系统 NVMe	~53 °C	Composite die temp; crit is 87.8 °C.
数据 NVMe	~41 °C	Cooler still.
机械盘 ×4	~33–35 °C	Each SATA HDD; historic peak ~38–41, well under the 65 °C line.
核显（idle）	~49 °C · 4–8 W	Basically idle — single-digit watts.
整机功耗	~35 W idle / ~150 W 满载	24×7 at 35 W idle is the payoff of a 65 W APU + silent design.

诚实的热天花板 · THE HONEST CEILING

日常轻载 54 °C 很凉；但当第二相片库批量做 RAW 显影（持续满核）时，这块 120mm 薄冷排的紧凑机型会冲到约 92 °C。这不是缺陷，是「小体积 + 静音」换来的确定性代价——薄排压不住持续重载，但这类批处理是偶发（索引一次、平时不跑）。把这一句写出来，比只报 54 °C 诚实。
Idle sits cool at 54 °C; sustained RAW rendering pushes a thin-radiator compact box to ~92 °C. Not a defect — the price of small-and-silent. Saying so is more honest than quoting only the idle number.

CHAPTER 04 · 存储地基

普通文件系统「存了就存了」，
ZFS 记账、对账、自愈、还能倒带

A plain filesystem stores and forgets; ZFS journals, reconciles, self-heals, and rewinds.

存全家照片的机器，文件系统不是选型细节，是地基。这台 NAS 全线走 ZFS——把校验和、软件 RAID、快照、卷管理揉在一起。它切成两个池，各司其职。

FIG 02 · ZFS 双池与数据集 · POOLS & DATASETSRAID-Z1 · 单盘容错

左：主数据池 tank，4 盘 RAID-Z1，切三个数据集；右上：ssd-tank 单盘快取（预留，近空）；右下：两块不入池的盘——系统盘与外接盘，与数据物理分离，重装系统不碰 tank。

ZFS 在这台机器上解决三件普通文件系统解决不了的事。一是端到端校验和：机械盘长期存放会有静默位翻转，普通文件系统读到坏数据照样返回给你，ZFS 每次读都验校验、有冗余就自动修，还能主动 scrub 全盘扫一遍。二是软件 RAID：tank 用 4 盘 RAID-Z1，拿一块盘的空间换奇偶校验，任意单盘挂掉数据仍在、换盘可重建。三是秒级快照：copy-on-write，创建瞬间完成、初始不占空间，之后只按变化量长——tank/backup 上保着最近约 30 天的每日时间点（数据库 dump 另按 14 天滚动）；每个增量只有几百 K，却能把整库还原到任意一天。采集时两池都是 ONLINE、0 读错 / 0 写错 / 0 校验错。

为什么月度 scrub 是纯手动 · MANUAL BY DESIGN

scrub 对 CPU、内存几乎无感，唯一的代价是噪音——4 块机械盘要连续寻道约 3–5 小时。在卧室，「什么时候能容忍这个噪音」只有人知道。所以这条巡检刻意不设自动 timer：自动化只负责每月提醒一次（提醒文案明写「只提醒、不自动跑」），真正开跑的命令由人挑一个不在卧室的时段手动敲。判读也简单——with 0 errors 就是健康，一旦出现非 0 错误或有实际修复量，就是某块盘可能要换的信号。

CHAPTER 05 · 服务栈

不是功能堆砌，
是一条主线牵出的一串真实需求

Not a pile of features — a chain of real needs pulled by one thread: bring the photos home.

这台 NAS 上跑着八个容器加两个自研服务。它们不是「看别人装了我也装」，每一个都对着一个具体痛点。主线是「把租来的云搬回自己家」，其余都从这条线上长出来。

地基

Immich · 照片库 A

整个系统的地基。immich-server:v2.7.5 加 ML、PostgreSQL（带向量扩展做人脸/相似检索）、Valkey 缓存共四容器。它是手机相册的自托管替代——每小时自动从云端增量拉取归档，把照片真身握回自己盘，库有每日备份写进 ZFS。

照片库 B

PhotoPrism · 专读 RAW

补第一套的短板：专门只读编目相机 RAW 与 DNG（第一套引擎读不了这些格式）。RAW 预览统一走 darktable 中性渲染，只读编目、不动原始文件。

文件

FileBrowser · 网页文件管理

挂载三块内置盘加一块外接移动盘。不装客户端，任何设备浏览器打开即用。照片目录挂只读防误删。

身份

Authelia · 单点登录

authelia:4.39.20。以 OIDC 身份提供方形式给照片库提供统一登录，证书每周自动续。另有 Homepage 作兜底仪表盘——自研门户挂了，「一个书签进所有服务」这条底线也不断。

门面

母港门户 v2 · 自研

主入口。无框架纯静态 Web App 加一个约 110 行、零依赖的 Node 标准库 HTTP 服务器；浏览器侧只有原生 vanilla JS，无 React/Vue、无构建、无 npm 运行时依赖。把全部服务聚合，叠加照片轮播、状态监控、可视化设置。

监控

oc-fleet-monitor · 只读状态

纯 Python，暴露一个 /status 端点，把本机 agent 运行时状态以 JSON 吐出，喂门户「监控」页做实时可视化。只读、无副作用、零 token 成本，可放心高频轮询。

贯穿这一栈的是两条取向：私有优先——所有服务 tailnet-only、不开公网端口、统一走受信 HTTPS 门户；数据主权 + 能自己造就自己造——照片真身都落在自家 ZFS 盘，能自研的门面坚持无框架零依赖手写，现成方案只作兜底。下一段说清「不开公网」到底怎么做到的。

CHAPTER 06 · 接入与安全

最关键的一层防御，
是它压根不在互联网上

The most important layer of defense is that it simply isn't reachable from the internet.

这台 NAS 的攻击面，从「整个互联网」收缩到「几台已认证的自家设备」。它没有端口转发、没有 DDNS、没有一个公网入口。这不是企业级零信任，是恰到好处的家用防御纵深——它的边界在哪，这段会诚实标出来。

接入层——不可从公网访问。它只加入一张私有 mesh VPN（Tailscale / WireGuard）。主机防火墙（ufw，active）入站收得极紧：只放行回环口、mesh 虚拟网卡、WireGuard 握手端口，普通局域网入站一律拒绝——即便某个服务在进程层监听 0.0.0.0，ufw 在网络层也会把 LAN 来源的包直接丢掉（容器发布端口是例外：docker 会自行改写 iptables 绕过 ufw，这层由另一条自建守卫链兜底、把发布端口重新锁回 tailnet-only，详见第 9 章「网络收口」）。受信 HTTPS 层——绿锁、无 IP、无警告。入口用 mesh VPN 自带的反向代理，跑在已存在的 VPN 守护进程里，不新增进程、容器或内存开销；tailnet 给节点 FQDN 自动申请并续期 Let's Encrypt 受信证书。因为浏览器不按端口区分信任，同一域名下每个高端口都是绿锁——门户、两套照片库、文件管理、SSO 各占一个受信入口。

身份① · 设备身份

设备连进 tailnet 并通过认证 = 已完成一次身份验证，零额外登录页（透明 SSO）

身份② · 应用 SSO

自托管 OIDC（单用户），两套照片库接入，登一次会话期内其它应用不重登

身份③ · 本地密码兜底

接了 SSO 的服务同时保留本地密码，防 SSO 故障把人锁在门外

有一处工程细节值得记：docker 容器本身不是 tailnet 节点，够不到 tailnet-only 的入口端口；而 OIDC 的 issuer（签发者 URL）只能是一个值，浏览器跳转和后端换 token 都得用它。解法是让身份提供方自持一张对 FQDN 有效的受信证书，再用 docker 网络别名把它挂进照片库所在的容器网络——这样容器内和浏览器侧都够到同一个受信 URL，issuer 保持一致。另外，文件管理器特意不接自动 SSO（它挂了整盘，自动登录一旦被滥用等于「任何设备自动拿到全盘管理员」），并被改成只绑 127.0.0.1。

边界在哪 · WHERE THE LINE IS

诚实地说：这套模型的安全性，建立在「tailnet 边界可信」这个前提上。一旦某台已认证设备被攻陷，攻击者就进了内网可达范围，后面只剩应用层密码这一关（这也是文件管理器坚持不上自动 SSO 的原因）。它没有企业级的持续设备态势评估，也没有细到每请求的授权策略。但对家庭威胁模型——挡住互联网扫描器、机会主义攻击，顺便治好「懒得记 IP、怕看证书警告」——这个结构恰到好处。
Its security rests on trusting the tailnet boundary. Compromise one authenticated device and only app passwords remain. No enterprise posture checks, no per-request policy — but for a home threat model, exactly enough.

CHAPTER 07 · 自动化

值得讲的不是「全自动了」，
是它清楚哪些事不该自动

The interesting part isn't what's automated — it's knowing what must not be.

一台 systemd timer 织成的自动化系统在后台默默跑。核心哲学是一句话：能全自动的全自动，一旦某个操作不可逆、或会打扰到人，就把最后那一下留给人。

定时管道一览 · SCHEDULED PIPELINES

管道	节奏	做什么 · What
云端照片导入	每小时 :05	Pull new photos → trigger library scan → file into albums. Serial + flock; download-only, never deletes cloud.
照片库备份	每日 03:30	DB dump + rsync to HDD pool + ZFS snapshot. Snapshots kept 30d, dumps 14d.
可删账目	每小时 :50	Compute "safe to delete from cloud" per album, atomically write a status file. Read-only — deletes nothing.
磁盘水位	每 6 小时	Warn when system disk ≥ 85%.
门户收藏物化	每日 06:30	Copy 20 random starred photos to portal carousel. Zero root, zero API key.
证书续期	每周一 04:10	Renew SSO cert; restart gateway only if the cert actually changed.
卫生重启	每周一 03:00	Clear memory / handles / zombies — gated by the in-flight guard below.
ZFS scrub	手动 · 月度	Deliberately no timer — reminds monthly, never auto-runs (bedroom noise).

留一手 · 01

重启前的「在途守卫」

重启是破坏性的——若正好有照片在下载或备份 rsync 跑到一半，砍下去数据不完整。所以重启前先跑守卫逐个查完整性关键任务，任一在跑就跳过本周。设计成 fail-closed：连状态都查不准时一律当「在跑」——宁可漏重启一周，也不冒险砍一次同步。

留一手 · 02

scrub 只提醒，不开跑

它对性能几乎无感，唯一代价是几小时的机械盘噪音。「何时能容忍」只有人知道，所以自动化只每月提醒一次，扳机由人在不在卧室的时段手动扣。

不可逆

删云端：只算「可以删」

每小时导入只下载、从不删云端。回收被拆成独立、且没排进任何 timer 的任务。系统每小时算一次账、标出「已进快照且已同步 = 现在删是安全的」，把结论摊给人看，自己一个字节都不删——删云端不可逆，扣扳机的永远是人。

那个在途守卫本身还踩过一个很典型的坑：同步任务是 oneshot 类型，跑的时候状态是 activating 而不是 active；早期版本只认 active，导致「正在跑」反而被当成空闲、照样重启。修复后把中间态也显式算作「在跑」——这正是 fail-closed 该有的样子。

CHAPTER 08 · 门户与数据流

把一堆散服务，
收成一个书签

Fold a dozen scattered services into a single bookmark — with credentials that never touch the front end.

「母港」门户把分散在多个后台的数据汇成一个页面。三条数据流各自独立、互不阻塞，贯穿全部的一条红线是——凭据永不进前端：所有要密钥、数据库、采集权限的活儿都在服务端干完，前端只消费轻量 JSON。

FIG 03 · 照片数据流 · PHOTO PIPELINEphase-1：只下载不删

从左到右读。每一跳都刻意「减权」：下载器只读拉取、库只读索引、物化脚本零 root 零 API key（直接复制库早已生成的世界可读预览图），到门户前端时手里已经没有任何凭据。

第二条监控流走的是另一套思路：每台主机各跑一个零依赖的 Python /status 端点，经 tailnet 反代出受信 HTTPS，读路径免 token、零成本。架构上没有中心聚合器——门户前端在浏览器里并行 fetch 各端点、自己拼装渲染，用 Promise.allSettled 包全队，一台失败不拖累其它。第三条是门户本体，分四层：

皮 · SKIN

借一套成熟商业网站的母版 CSS，只引用不覆盖

骨 · SKELETON

捕获的 DOM 骨架

肌 · MUSCLE

原创 vanilla JS（约 4.5k 行，IIFE 自注册）

数据 · DATA

seam 适配层——mock ↔ real 无缝切换，取数失败自动回退 mock，页面永不空白

这三条流共享一套设计哲学：凭据永不进前端；重活在后台各自定时跑，一条流慢或挂不拖累另一条；强容错优先——字段可缺、值可为 null、一台/一源失败不拖垮整页。这不是可选项，是家用异构系统现实约束下的必须项。整站无框架、无构建，纯静态加一个零依赖 Node 服务器，图的就是长期低维护、不吃 npm 生态的版本腐坏。

CHAPTER 09 · 演进史

它不是一次设计出来的，
是被真实需求一步步逼出来的

Nothing here was designed up front — each present-day shape was forced by a specific push.

今天看到的每一处选型，几乎都能追溯到一个具体的痛点在推。把这条线倒过来看，比正着讲架构更能说清「为什么是这样」。

起点：寄居在 Windows 里。NAS 那个 agent 实例最早只是跑在一台 Windows PC 的 WSL2 里的运行时——记忆和会话历史与宿主环境深度耦合在半虚拟层，这台机器既不专职存储、也不适合长期无人值守。决策：整机重装成裸机 NAS，但只要记忆能留下。关键的范围决策是「只保留 agent 的纯记忆核心（约 134MB / 1400 个文件），其余环境性的东西全丢、新机重设」。迁移不做整盘镜像，而是冷快照：停机、narrow-rsync 只抓记忆目录、打包压到 19MB、生成逐文件 sha256 清单，快照留一周观察期后才准删。

重装后，三层物理隔离。系统盘（装 OS + agent 记忆）、快取池、数据池分开，第一性原则是「池炸了 ≠ agent 失忆」。存储最初选了零冗余的 RAID 0，一轮复核标出「任何一块盘坏就全没」的风险后改成 RAID-Z1，牺牲一块盘容量换单盘容错；组池用 /dev/disk/by-id/ 全名而非会变的 /dev/sdX，避免重启后 degraded。一个诚实的已知取舍：那 4 块是 SMR 盘，换盘重建会慢，于是约定未来「4 盘一起换」绕开单盘 resilver。网络收口时还发现 Docker 会绕过系统防火墙自己改 iptables 把容器端口暴露到 0.0.0.0，于是加了一条自建守卫链把所有发布端口重新锁回 tailnet-only——这条守卫是后面所有服务能安心用 0.0.0.0 端口的前提。

裸机 NAS

← 要专职存储 + 让 agent 记忆和宿主环境解耦

RAID-Z1 + 记忆放系统盘

← 池炸 ≠ 失忆；单盘坏不丢数据

两套相册

← 主库引擎读不了相机 RAW / DNG

自持证书 + 网络别名的 SSO

← 容器不是 mesh 节点、issuer 只能一个值

手动月度 scrub

← 机器在卧室，半夜会吵

tailnet-only · 凭据不落盘 · 破坏性操作当面确认

← 这是家用系统，要睡得着觉

服务也是一层层长出来的，不是一次铺开：先是照片主库（自托管相册 + 从手机云端自动归档），发现主库缩略图引擎读不了 RAW 全是裂图，才加了专读 RAW 的第二套；有了照片要管文件，才有网页文件管理器；服务多到记不住 IP，才有统一门户；门户想要能自己改，才把它逆向重写成无框架的自研 v2；多台机器要一屏看状态，才有了那套零成本监控。中途还插进一轮多 agent 并行的大 code review——几十条 finding 分批修（存储型 XSS 收口、监控不再把真宕机伪装成 LIVE、大视频拷贝原子化、在途守卫的 oneshot 漏检改成 fail-closed），修完达到「零 failed 单元、open PR 清零」的干净状态。月度 ZFS scrub 也是在一次评估发现两个池疑似从未 scrub 过之后才补上的。

CHAPTER 10 · 备份、内存与取舍

它换来的不是省下的订阅费，
是数据自主，外加睡得着觉

What you buy isn't the saved subscription — it's sovereignty, plus sleeping soundly. And one honest gap.

收尾要诚实：既讲它做到了什么，也讲它至今没做到的那一件事。

35 W

IDLE POWER

24×7 常开的 idle 功耗，长期电费很低——65W APU + 静音方案的直接回报。

~8 TB

USABLE · RAID-Z1

4× 3TB 机械盘做 RAID-Z1，可用约 8T，容单盘故障 + 每日快照可倒带 30 天。

12 / 16 GB

PEAK MEMORY

8 容器 + agent runtime + 照片 ML 并发下峰值约 12GB，从未触顶、无 swap——正面回答「16GB 够不够」。

INCIDENTS

至今未遇盘掉线或服务崩（knock on wood）；RAID-Z1 + 快照 + 离线盘就是为那一天准备的。

做到了 · WHAT IT DELIVERS

这套值得的理由

照片回到本地：手机相册每小时自动归档进自托管库，真身握在自己盘。
分库管理：日常照片与专业相机 RAW 各一套，互不干扰。
数据安全网：ZFS 校验 + RAID-Z1 + 每日快照 + 一块离线冷盘，四道叠一起。
一个绿锁进全部：不记 IP、不看证书警告、透明 SSO，移动端点书签即用。
基本不用盯：自动化管道 + 在途守卫，装完之后日常极少人工介入。

还没做到 · THE HONEST GAP

3-2-1 里缺的那个「1」

本地做到了「3 份副本、2 种介质」：RAID-Z1 + 每日快照 + 一块平时断开的离线冷盘。
离线盘挡得住勒索软件横扫 / 误删 / 逻辑损坏——在线冗余挡不住的那类。
但所有副本目前在同一物理位置：还没有地理异地备份。
防不了「火灾 / 失窃 / 水浸」端掉整个位置——异地那份是明确的 TODO。

最终判断 · CLOSING JUDGEMENT

自己攒一台 NAS，换来的从来不是省下的那点云订阅费——那点钱远不够抵自攒自维的麻烦。真正换来的是数据自主权，和一套「装完之后基本不用盯」的省心。它不完美：薄冷排在满载会烫、异地备份还欠着。但它把照片、文件、备份、服务入口和运维自动化，收进了一台自己完全掌控、默认只在私有网络里可达的机器。对一个想把数据握回手里的人，这笔取舍，划算。
Building your own NAS never pays back in saved subscriptions — it pays in sovereignty, and in not having to watch it. It isn't perfect: the thin radiator runs hot under load, offsite backup is still owed. But it pulls photos, files, backups, service entry and ops automation onto one machine you fully control. For someone who wants their data back, the trade is worth it.

END OF MOONSHADE · NEUTRALIZED · 2026-06-30 · V1.0 · Source MoonShade 架构研究 · 内部素材 · 已中立化

南墙 / SOUTH WALL