欢迎来到 LiMing笔记 👋

13. GW600 SSD 温度异常与压力测试 本文发现 PVE 上唯一一颗"病态"硬盘 — Great Wall GW600 1TB SSD。 同一环境、同一风道、其他 4 块盘都正常,只有它常年 48-51°C,压力测试下还"涨不上去"。 Wear_Leveling_Count 是其他 SSD 的 3000 倍。是定时炸弹。 TL;DR (一段话总结) sdc (Great Wall GW600 1TB SSD) 长期跑 48-51°C,比其他 SSD 高 15-20°C 压力测试 (90秒 CPU+全盘 IO) 下温度几乎不变 (健康 SSD 应升温 10-20°C) SMART 错误暂时 0,但热应力在累积 Wear_Leveling_Count 37,822,775 → sdb 同工作时长只有 12,635 (3000 倍) 国产低价 SSD 常见问题:控制器功耗大 + 散热差 + 二手/降级 NAND 建议:立即备份 sdc 上的 VM 镜像 → 买新 SSD 替换 → 1-2 周内完成迁移 背景 [02-硬件体检-SMART与温度] 写完后,我加了第二把机箱风扇,又把所有 SSD 物理分散安装。本以为这样温度就该降了,结果sdc 还是最热 (49°C),用户自己摸机箱感觉 HDD 更热 (实际是 SMART 数字的迷惑性)。 ...

09. 经验教训汇总 这几天所有踩坑、原则、工具沉淀的一句话清单。 每条都对应实际发生过的事。 配置类 1. Tailscale 在 LXC 三件套 1 2 3 features: nesting=1 # 不能是 0 lxc.cgroup2.devices.allow: c 10:200 rwm # /dev/net/tun lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file 少任何一条 tailscaled 起不来。 2. Syncthing GUI 别绑 127.0.0.1 <address>0.0.0.0:8384</address> 或 default,不是 127.0.0.1。 “内网机器,不用这么严格”。 3. Syncthing systemctl 别加 .service systemctl enable syncthing@syncthing,不是 syncthing@syncthing.service。 4. systemd template unit 用户名要对 syncthing@syncthing 第二段是用户名,要先 useradd -r syncthing。 5. CT111 /data 不能用 root mkdir 任何给 daemon (syncthing/tailscale/…) 用的目录,必须用 daemon 用户创建,或创建后立刻 chown。 ...

[!warning] 敏感信息说明 本文涉及的真实密码 (<your-password>) 与用户名 (<kopiauser@host>) 已脱敏。阅读时按你的实际部署替换占位符。 10. Kopia 数据丢失与复盘 ⚠️ 本文涉及真实数据丢失事件。 Kopia 仓库 (57GB 备份) 在 2026 年 8 月因 ZFS 池损坏事件受损。 阅读时请注意:不是所有备份都救回了。 时间线 1 2 3 4 5 6 7 8 2026-05-30 在 PVE 上首次部署 Kopia (CT102, kopiaserver) 2026-06-09 Kopia 最终方案跑稳:274GB 逻辑 / 30GB 物理 (89% 去重) 2026-06-09 → 2026-08-29 期间 ← 数据丢失发生在这段时间(?) 2026-08-30 发现 HHD_3TB 池 metadata 永久损坏,kopia 数据在坏池上 2026-08-30 紧急 rsync 抢救 Kopia 数据到 SSD_1TB/kopia_rescue 2026-09-01 部署 RustFS (CT110) 作为新的 S3 后端 2026-09-01 CT102 (kopiaserver) 退役 2026-09-01 新 Kopia 仓库建立在 RustFS S3 上 Kopia 原本是什么 Kopia 是一个开源的、加密的、增量备份工具,支持多种后端 (filesystem / S3 / SFTP / B2 等)。 ...

[!info] CT110 实际 IP 是 DHCP 分配的 (192.168.31.128),不是手写固定的 部署后用 pct exec 110 -- ip -4 addr | grep inet 查实际 IP。Tailscale IP (100.115.66.48) 也可能变。 [!warning] 敏感信息说明 本文涉及的 RustFS SECRET_KEY 已脱敏为 <your-secret-key>。部署时用你生成的随机密钥,生产建议从环境变量读取。 11. RustFS 部署与 Kopia 切换 背景 2026-08-30 发现 HHD_3TB 池 metadata 损坏、Kopia 仓库受损后,决定: 不把 Kopia 留在 local FS (风险太高) 要给 Kopia 一个更可靠的后端 → S3 要这个 S3 在自己控制之下 → 自建 (RustFS, 不依赖 AWS) 自建 S3 的好处: 数据在自己机器上 (PVE 内) 无月费、无 egress 费 隐私可控 替代品多 (MinIO / Garage / SeaweedFS) 为什么选 RustFS 而不是 MinIO? ...

[!warning] 敏感信息说明 本文涉及的 Tailscale IP 已脱敏 (<pve-tailscale-ip> / <ct111-tailscale-ip>)。实际部署时用 tailscale ip -4 查自己的节点 IP。 01. 概述与时间线 为什么折腾? 家里 PVE 主机已经跑了一年多,服务越来越多,但没有系统化体检过。飞牛 NAS (VM105) 也用了很久,感觉是时候考虑替换方案(更稳、更可控、更省电)。 起点 2026-08-31 晚 发现 Syncthing 之前用的 VM105 (飞牛 NAS) 在公开网络上,挂了 GUI(127.0.0.1:8384),外网和手机端访问不到同步 web UI → 想搞个独立的 Syncthing 节点,跑在 Tailscale 上,任何地方都能访问。 时间线 1 2 3 4 5 6 7 2026-08-31 晚上 启动:调研 Tailscale 在 LXC 上的支持 2026-09-01 上午 PBS datastore 迁移到 backup-mirror 2026-09-01 下午 CT111 创建 + Tailscale 安装 (折腾透传配置) 2026-09-01 晚 Syncthing 部署 + 发现工作学习 folder path 错误 2026-09-02 凌晨 排查 16379 个 permission denied 错误 2026-09-02 上午 完成,所有 sync 在跑 2026-09-02-09-09 VM105 7 天观察期 整体架构 (前后对比) Before 1 2 3 4 5 6 [手机/电脑] → [VM105 飞牛 NAS (Syncthing)] ├─ 工作学习 (16GB) ├─ 服务物资对账单 (40GB) └─ 共享文件夹 (1GB) [VM100/CT104/...] → 直连 VM105 After 1 2 3 4 5 6 7 8 9 [手机/电脑/家里电脑] ── Tailscale ──→ [PVE] ├─ CT111 (Syncthing + Tailscale) │ ├─ /data/工作学习 (16GB) ← HHD_3TB │ ├─ /data/同步文件夹/服务物资对账单 (40GB) ← HHD_3TB │ └─ /data/共享文件夹 (1GB) ← HHD_3TB │ └─ VM105 (观察期 7 天,跑完即删) ↓ (继续往 CT111 同步) 关键决策 决策 1: 用 CT 而不是 VM 跑 Syncthing 为什么不用 VM? ...

[!warning] 敏感信息说明 本文涉及的 CT111 Tailscale IP 已脱敏 (<ct111-tailscale-ip>)。实际部署时用 pct exec 111 -- tailscale ip -4 查。 04. CT111 Syncthing LXC 部署 背景 VM105 (飞牛 NAS) 跑 Syncthing 已经很久,问题: GUI 经常挂 (web UI 启动失败) 想从手机外网访问,需要装 VPN/内网穿透 VM 太重,跑个 Syncthing 占用资源高 想:搞一个专用 LXC (CT111) 跑 Syncthing + Tailscale,干净可控。 整体设计 1 2 3 4 5 6 7 8 9 10 ┌─────────────────────────────────────────┐ │ PVE Host │ │ │ │ ┌──────────┐ ┌─────────────────┐ │ │ │ Tailscale│ │ CT111 (LXC) │ │ │ │ 100.74.x │◄──►│ - Tailscale │ │ │ └──────────┘ │ - Syncthing │ │ │ │ - /data → HHD │ │ │ └─────────────────┘ │ └─────────────────────────────────────────┘ 设计原则: ...

08. 调试方法论 这几天调试 PVE / Syncthing / VM105 时沉淀下来的方法论。 每条都是从一次实际跑偏/正确中找到的。 核心原则:先查本端,再碰远端 ⭐ 反面例子 排查"VM105 的工作学习 文件夹为什么不同步到 CT111"时,我先尝试: 挂载 VM105 数据盘 (失败:RAID member) 用 qemu-nbd 暴露 zvol (失败:boot 盘已挂载) zfs send VM105 数据盘到文件 (慢) 5+ 步后才发现:CT111 的 /rest/events 已经把错误说清楚了 (mkdir /data/工作学习/.obsidian: permission denied)。 正解: CT111 端 2 步搞定 (查 events → 修 owner)。 正面例子 排查"为什么 SSH 慢" 时: time -p ssh user@host echo → 总耗时 5s ssh -vvv → 看到 DNS 反查慢 修 /etc/ssh/sshd_config: UseDNS no → 立刻好 原则: 任何"为什么 X 没工作"的问题,先查 X 这一端的可观测面 (logs / metrics / events / API status),再决定是否要碰 Y 端。 ...

07. VM105 迁移与 7 天观察期 VM105 是什么 VM105 是 2024 年装的飞牛 NAS (fnOS) 虚拟机: 1 2 3 4 5 6 7 8 9 10 VMID: 105 名字: myNas OS: fnOS (基于 Debian 的 NAS 系统) CPU: 4 cores RAM: 8GB 磁盘: - SSD_1TB/vm-105-disk-0 64GB ← boot - SSD_1TB/vm-105-disk-1 500GB ← data (RAID 1) - HHD_3TB/vm-105-disk-0 1TB ← extra 网络: 192.168.31.233, vmbr0 VM105 同时承担: ...

06. 16379 个 permission denied 排查 问题 CT111 Syncthing 部署好,三个文件夹都加了: ✅ 共享文件夹: inSync (立刻) ✅ 服务、物资对账单: 27GB/40GB (持续 sync, 18 MB/s) ❌ 工作学习: 0/16GB,完全没动 用户报告:“VM105 也有工作学习文件夹,怎么没同步?” 第一步:确认 VM105 真有数据 从 CT111 端看: 1 2 curl -H "X-API-Key: $KEY" \ http://127.0.0.1:8384/rest/db/status?folder=nsylc-yh8lq | jq 1 2 3 4 5 6 7 { "globalBytes": 17718404663, ← 16.5GB!VM105 确实有 "localBytes": 0, ← 但 CT111 没有 "needBytes": 17718404663, ← CT111 想拉 "pullErrors": 16379, ← 16379 个错误! "state": "idle" } 结论: VM105 确实有 16.5GB,CT111 想拉,但 16379 个 pull 错误 拦住了。 第二步:看具体错误 /rest/events?limit=500: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [2026-09-02T01:20:21] ItemFinished: { 'action': 'update', 'error': 'mkdir /data/工作学习/.obsidian: permission denied', 'folder': 'nsylc-yh8lq', 'item': '.obsidian', 'type': 'dir' } [2026-09-02T01:20:21] ItemFinished: { 'error': 'mkdir /data/工作学习/.space: permission denied', 'item': '.space' } [2026-09-02T01:20:21] ItemFinished: { 'error': 'mkdir /data/工作学习/0未整理文件: permission denied', 'item': '0未整理文件' } ... (重复 16379 次) 关键错误: mkdir /data/工作学习/.obsidian: permission denied ...

05. Syncthing 配置调试 背景 CT111 装好 Syncthing 后,有几个问题要修: GUI 无法外部访问: 默认 127.0.0.1:8384 工作学习 folder path 错: 装在 4GB rootfs,应该在 /data (2.1TB) REST API 调用 “200 但没改”: PUT 改 folder path 没生效 1. 修 GUI bind 问题 1 2 3 # 从 PVE host 测 curl -I http://192.168.31.109:8384 # Connection refused 排查 1 2 3 # CT111 里 ss -tlnp | grep 8384 # tcp LISTEN 127.0.0.1:8384 ... 只 listen 在 loopback,外网访问不到。 ...