请不要把任何和邀请码有关的内容发到 NAS 节点。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
邀请码相关的内容请使用 /go/in 节点。
如果没有发送到 /go/in，那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动，会导致账号被禁用。
这是一个创建于 214 天前的主题，其中的信息可能已经有所发展或是发生改变。
都说 All in one 是 All in boom 但是真的 boom 的时候是哪个地方炸？
自组了一台 NAS 配置是 8100 + 32G 内存 + 海韵 GX650 电源，多盘位塔式机箱装了 3 个前风扇，主板也是一手的，硬件上爆炸的风险应该不高。
软件上 SSD 装 PVE 并存放虚拟机的磁盘镜像，直通 Sata 控制器到 Debian 虚拟机里做存储服务，然后在飞牛的虚拟机里挂载并提供影音服务。
网络
网络使用全家硬路由，PVE 里面也没有装软路由，只是在 Debian 里用 Docker 装了 Sub-Store 来整合复数个机场的订阅给其他设备的客户端使用，避免单个机场跑路的问题。
不折腾全家网络和软路由自然网络不会因为 All in one 爆炸。
意外断电
无论是否 All in one 都有这个问题而且城市供电一般没什么问题，最多加一个 UPS 就搞定了，所以暂时不纠结这个
硬件磨损
作为数据盘的 HDD 注定是有寿命的，在散热和电源都比较到位的情况下做好备份就行。其他的部件比如 CPU 、内存、电源、主板、风扇和机箱等基本不考虑寿命问题。
唯独作为系统盘的 SSD 可能是风险点出问题的话自然就是全 Boom 了，但是用 PVE 定时备份系统到 HDD 里届时恢复反而会比物理机直装更方便些。
作为参考某些 Nas 厂商会在多个数据盘上多分一个区以此组 Raid 给系统盘，这个方法对于存储设备来说是挺好的，但是除非组黑裙否则这个路子没法用。
软件爆炸
更新/配置 PVE 导致系统全挂或者整机无法联网，这个算人为的错误不是设备的问题，熟悉 Linux 的各种操作和习惯之后一般不会炸。
其他潜在的 Boom ？
最后的问题就是，在考虑了上述的问题之后是否还有其他会导致爆炸的点？
103 条回复 2026-01-04 12:30:14 +08:00
 | 1 v2gba 2025 年 8 月 22 日 你可以买一块便宜的新盘试一下 假设手头的系统盘坏掉了 （就从机箱里拔掉） 然后你看看恢复到之前的状态是要多久。 我测试过，也写了完整的恢复流程，个人是比较满意的，不算硬盘寄过来的时间(家里有多余的 ssd)，down time 是 1 小时不到。 |
 | 2 minami 2025 年 8 月 22 日  1 "硬件上爆炸的风险应该不高"你好，真的会炸，这不是概率高低的问题，再低的概率落到自己头上就是 boom 。 |
 | 3 sentinelK 2025 年 8 月 22 日 7 这个“boom”我理解的含义是会因为一个点的损坏（这个损坏包含软件崩溃、硬件损坏、以及人为失误），导致网络、存储等多个功能因为耦合性太强直接瘫痪。 楼主把人为、软件崩溃和硬件损坏全排除了，那当然就没什么可“boom”的了。 |
 | 4 billlee 2025 年 8 月 22 日 你配置监控告警了吗？没有到时候就是 RAID 一块盘炸完带病运行，直到另一块盘也炸了 |
 | 5 irainsoft 2025 年 8 月 22 日  [危险操作，请勿模仿] boom 过一次，从云端拉了 4 天数据恢复过来 |
 | 6 cmos 2025 年 8 月 22 日 4 首先，"网络使用全家硬路由"，你这个就已经不是 all in boom 了，要虚拟机装 OpenWrt 做全屋代理才有资格称呼 all in boom 。 |
 | 7 Tink PRO 任何地方都有可能炸，我的是从架子上摔下来炸了 |
 | 8 ATKLLL 2025 年 8 月 22 日 boom 就 boom 在折腾,你想折腾 A 可能要调整主机配置可能要调整硬件,意外或者操作失误可能导致连锁反应,影响 BCD 等系统. |
 | 9 OneLiteCore OP @MrGba2z 之前试过了不过是原盘重装的，从 Ubuntu 24 服务器版重装到 Debian 13 服务器版结果重新配置环境太过繁琐了： - 配置 DHCP - 路由器固定 IP - 换源 - 在没有梯子的情况下安装梯子 - 安装 zsh/tmux 等日常工具 - 安装 Docker 然后恢复各种服务 - 添加硬盘自动挂载 - 设置硬盘自动休眠 - 安装 Smb 服务并共享文件服务 - 安装 Zerotier/Tailscale - 安装日常开发环境 - 解决 Github 访问不了的问题 - 安装 rdp - 安装飞牛虚拟机 - 创建虚拟机内网 - 飞牛内网挂载 Smb 提供服务 - 到电视上查看飞牛 TV 是否正常连接和播放 整个过程非常的繁琐和重复，最后实在搞烦了才觉得 PVE 直接备份系统之后以后再也不折腾这些了。 我现在的感觉是 PVE+Debian 会比单独 Debian 更容易维护，一个是 PVE 代替了 IPKVM/IPMI 省的来回拔插键鼠显示器，二是备份恢复整个系统会更方便。本质上就是加了一个中间层解耦了操作系统和硬件。 |
| 10 OneLiteCore OP @minami 对的，所有的硬件都会 Boom 所以才需要备份，加上 PVE 使得备份和恢复整个系统会变得更容易些，如果是物理机直装的话手动重装各种服务要烦死人的。 |
| 11 OneLiteCore OP @sentinelK 就是在担心还有什么没考虑到的点导致 Boom ，因为重装系统和恢复所有服务的过程实在是太繁琐了，想着 PVE 可以更方便的备份和恢复系统才这么做的。有点类似以前有个老哥发帖是直接在虚拟机里面搞开发，这样开发环境随时可以迁移的感觉。 |
| 12 OneLiteCore OP @billlee 目前就靠 PVE 和虚拟机上的 Smart 手工查看并且没有配置 Raid ，而是用 Crontab 每日备份数据到不休眠的磁盘 A 上，然后每周备份到会定时休眠的磁盘 B 上。家用环境感觉备份还是比 Raid 重要些。 |
| 13 OneLiteCore OP @irainsoft 是什么原因导致的 Boom ？我的重要数据都不到 1TB 大小甚至可能 100GB 都不到，所以考虑没那么周全。 |
| 14 OneLiteCore OP @imes 是的，我查到的都说只要网络不 Boom 其他的都好搞定。 |
| 15 OneLiteCore OP @Tink 我家里养猫出现过猫毛堵住进风口的问题，但是这个就是系统之外的风险了，没办法在系统内部进行风险管理 |
 | 16 SakuraYuki 2025 年 8 月 22 日 @imes 对的，而且大部分时间 all in boom 都是从虚拟机里的 openwrt 开始 boom 起导致一连串的服务因为网络异常连环 boom |
| 17 OneLiteCore OP @ATKLLL 是的，遇到过设置 PVE 自动进行 DHCP 配置错误导致断网的，后面每次修改配置都会先 cp 原来的配置到通目录下的 .bak 文件里，然后额外插了一个无线网卡给 PVE 作为保险。 人为操作的风险始终是存在的，只能够 Boom 了之后吸取教训了。 |
| 18 OneLiteCore OP @SakuraYuki 那这套配置暂时没啥问题了先运行一段时间，哪天要是 Boom 了我在上来现身说法吧 |
 | 19 Rorysky 2025 年 8 月 22 日 boom 其实就是在网络 把网络服务软硬件单独出来，一点问题没有 |
| 20 irainsoft 2025 年 8 月 22 日 @OneLiteCore #13 无法判断，没有意外断电之类的外部因素，可能真的只是自己出问题了。 |
 | 21 totoro625 2025 年 8 月 22 日 2 直通 Sata 控制器： 高危行为，极其容易炸，就自己玩没必要直通 假如硬件序列号变化 网络： Debian 、Docker 、Sub-Store 任何一项炸了怎么办 我曾经网络反代依赖 clash ，clash 依赖自建订阅，自建订阅依赖网络反代，搞了个循环 意外断电： UPS 爆炸了解一下，真实爆炸 APC 自动关机演练过吗？ UPS 定期检查过吗 主板、电源寿命： 比你想象中更加脆弱，很可能 reboot 就炸了 系统盘寿命，swap 分区在系统盘吗？ smart 定期跑吗 PVE 定时备份： 不知道你是什么备份恢复方案，实战演练过没有 官方的 PBS 我自己的经常炸，后来直接备份数据了 “熟悉 Linux 的各种操作和习惯之后一般不会炸” 都是人为： /t/1151375 社区的程序员算是熟悉了吧，普通人呢？ 软件爆炸： 关闭自动 apt update 了吗？ 关闭 docker 自动更新了吗？ 软件源用的是官方、大学的、还是自建的，会被投毒吗 防火墙： pve 关闭密码登录 ssh 了吗 pve 自带防火墙打开了吗 ipv4/6 入站关闭了吗 |
 | 22 moifmwisdfewmi9 2025 年 8 月 22 日 @OneLiteCore PVE 整个系统是怎么备份的方便简单介绍一下吗 感谢 用 proxmox backup server? |
 | 23 rabt 2025 年 8 月 22 日 上午系统盘突然变只读了，某些文件损坏打不开了，某个 docker 运行不了了，晚上回家断电重启开不了机了，系统盘数据导出来后发现很多文件坏了，文件打开是空白。没备份到其他设备！没备份到其他设备！没备份到其他设备！搞了一个周末才恢复的七七八八。 |
 | 24 cpstar 2025 年 8 月 22 日 鸡蛋放在一个篮子里就是这个 boom |
| 25 OneLiteCore OP @irainsoft 表现形式是什么？ HDD 挂掉了还是？ |
 | 26 94188 2025 年 8 月 22 日 PVE 系统盘是怎么备份的？只备份核心配置 /etc/pve 目录下的东西吗？ 还是定时 dd 整个系统到另外的盘？ |
| 27 OneLiteCore OP @totoro625 感谢回复，你提到的很多点我可能都没有顾及到/顾及好。我后续再完善一波就打算先试着用用了，等真 Boom 了我再上来现身说法，T_T |
| 28 OneLiteCore OP @moifmwisdfewmi9 收实话暂时没有深入研究过这块，计划是等需要的服务和环境都配置好了之后先手动备份一次，之后打算不直通 Sata 而是将单独的硬盘分配给 Debian ，同时分 1~2 块硬盘给 PVE 看看能不能备份到本地。我有 3 块 256G 大小的 HDD 二手不值钱又还能用，打算用这个来备份。 |
 | 29 xFrye 2025 年 8 月 22 日 通常来说 boom 就是网络爆炸了，你把网络单独分出来那肯定不会 boom |
| 30 OneLiteCore OP @rabt 有检查过这个状态下的 Smart 信息么？是不是 TBW 用完了？ |
| 31 OneLiteCore OP @cpstar 想尽可能了解大多数情况下 Boom 的原因好做预防/补救措施，但是目前查到的 Boom 大都是 All in one 里面的网络炸了导致全家断网。 |
| 32 OneLiteCore OP @xFrye 所以可以理解为目前系统内潜在的风险就是配置出错和硬盘磨损么？在想着只要搞好备份的话，是否能够认为这套方案“足够稳定”以当作生产环境来使用。 |
 | 34 HandForLove 2025 年 8 月 22 日 我的软路由（ esxi：爱快+openwrt ）和 NAS （ pve：TrueNAS ）是分离的，软路由挂了可以换个路由器先把网搞通，NAS 系统坏了其实也没事，我自己换过系统（从 esxi 换到 pve ），数据还在。 |
| 35 OneLiteCore OP @ffxrqyzby 容器和 Docker Compose 文件都有备份，但是开发环境之类的要单独备份比较麻烦，不如整个操作系统都给备份了省的后面重装要全部手搓。 |
| 36 OneLiteCore OP @HandForLove 你是将软路由作为主路由么？我的理解是要搞软路由的话可以搞旁路由，这样炸了不影响家人上网。但考虑了下之后感觉软路由无非是用作梯子和去广告，前者的话客户端可以解决，后者的话不乱装国产软件基本不会有系统弹窗而浏览器的广告可以靠插件解决。想了解下目前对软路由的需求是什么？ |
 | 37 davidyin 2025 年 8 月 22 日 via Android 我是把软路由单独一个机器，nas 单独一个机器，然后就是 PVE ，里面有些 VMs ，备份就备到 nas 上。 三个都是单独的，好些。 在墙外，无需再多一个。 |
 | 38 worker201 2025 年 8 月 22 日 1 炸了不可怕，关键在于炸了能不能恢复，比如更换硬件 恢复需要多长时间，宕机期间你能不能接受 |
 | 39 liqingyou2093 2025 年 8 月 22 日 是人心态炸了 哈哈 |
 | 40 helleon 2025 年 8 月 22 日 1 机器再怎么炸都不是大事，严重的是老婆炸，更严重的是全家一起炸。 老婆在和闺蜜微信八卦吃瓜，女儿在线考试，儿子在开黑，老丈人在看球，这时候炸了，最最可怕 所以只要不影响主干网的应用，路由/dns 啥的不在你折腾的机器上就没啥大事 |
 | 41 wmgylc 2025 年 8 月 22 日 我用绿联，自己写了个打包 docker 然后扔到云盘的脚本，没注意到 docker 零散文件太多了，某天晚上打包直接把 ssd 干到变成只读，然后同个 ssd 里的虚拟机里的旁路由跟着挂掉，直接连不上了，还好重启了没事，发现原因后把脚本下了就没事了 |
| 42 OneLiteCore OP @davidyin 这个确实是个好办法。我选择 PVE 有一个点就是电源买的是海韵 GX650 用来做家用服务器或者 NAS 无论是功率还是纹波稳定性都是足够好了，日常负载大概也就 35W 而电源足够跑 600W 于是觉得有点大材小用，所以才觉得可以上点强度。 |
| 43 OneLiteCore OP |
 | 44 bytesfold 2025 年 8 月 22 日 via iPhone 折腾了一遍，pve+pbs 似乎约等于 1 小时恢复 |
 | 45 zod9527 2025 年 8 月 22 日 @OneLiteCore 有道理 |
 | 46 zhaoxiaofeng 2025 年 8 月 22 日 硬路由+PEV(fnos+immortalWRT+linux+win)，默认还是指给硬路由，有需要的自己指给 immortalwrt PEV 挂了还有硬路由可以用，硬路由挂了没辙 |
| 47 zhaoxiaofeng 2025 年 8 月 22 日 @zhaoxiaofeng 非下载服务直接扔给阿里云 docker 部署，还配置了 tailscale 中继，直接练到家里的内网 |
 | 48 coldle 2025 年 8 月 22 日 boom 过一次主板，整个周末都在搭灾备环境 |
 | 49 lovelylain 2025 年 8 月 22 日 via Android 你这个网络使用硬路由，不算 all in boom ，看看我的：n1 刷 openwrt 做主路由，上面 docker 跑 homeassistant+nodered+zigbee2mqtt ，家里的开关窗帘都是接入这个 zigbee2mqtt ，接移动硬盘当 NAS 用，外面用手机和老家电视也能通过 wireguard 访问，手机访问 google V2EX 也是 wg 连回来，还在上面跑了 frigate 当 nvr ，emmc 剩余寿命 20%,你说我这个炸的风险有多高，炸了影响有多大。 |
 | 50 charles0 2025 年 8 月 22 日 我的理解是有单点故障的风险，包括误操作、硬件问题等等 |
 | 51 Kylin30 2025 年 8 月 23 日 手贱 |
 | 52 AkinoKaedeChan 2025 年 8 月 23 日 via Android 漏了一点啊，内存故障导致比特翻转，然后文件损坏出现不可预测的错误，建议换成 REG ECC 内存。 |
 | 53 xixiv5 2025 年 8 月 23 日 昨天炸了一次，应该是路由器的电源适配器里的电容炸了 导致这条回路的空开跳闸，UPS 没有成功完成关机操作，看到日志只有切换到 UPS ，但是没有关机的日志，通电后查看电量有 90%，估计是电池噶了 |
 | 54 WizardLeo 2025 年 8 月 23 日 人家 all in boom 路由、储存、服务全在一台设备的一块盘上，启动顺序不对 boom 、掉盘 boom 、手贱改网络配置 boom 、异常断电 boom 。 最主要的还是 0 修复宽容度，只要坏一次基本就得大动干戈用其他设备直接修改磁盘内的系统文件。 |
 | 55 msg7086 2025 年 8 月 23 日 用软路由炸了直接把线接到硬路由上先把网络搞通再搞别的啊，多大点事。 我是服务器上跑 PVE ，PVE 上直接用 zfs 跑 NAS ，然后一个虚拟机里 OPNSense 做路由，另一个跑 frigate 。 PVE 本来也挺稳的，真炸了就 IPMI 连上去修。 唯一要担心的是 SSD 损坏。真要担心的话就定期备份一下就好了。 |
 | 56 CapNemo 2025 年 8 月 23 日 还有一个可能性是没有仔细考虑冷启动/恢复时的循环依赖，导致到时候要修好 A 得从 B 里提取备份，要修好 B 得从 A 里提取备份 |
| 57 AkinoKaedeChan 2025 年 8 月 23 日 还有一点 消费级主板普遍没有 IPMI ，在没有的情况下把宿主机显卡全部直通了的话会导致宿主机网络挂掉的情况下难以维护，可以通过 SR-IOV 保留 PF 在宿主机（仅 12th 后 Intel 核显和工作站/数据中心显卡（须购买付费授权））。 |
 | 58 buruoyanyang 2025 年 8 月 23 日 我之前是路由器都是用的爱快，然后突然有一天盘炸了，刚好我出差了，家里直接断网 |
 | 59 bowencool 2025 年 8 月 23 日 All in Boom 六七年了，boom 的时候把路由器插在光猫上，自己插网线 debug 不就行了。。。 |
 | 60 alb 2025 年 8 月 23 日 via Android All in One ，玩的就是家庭环境下的 DIY 。考虑省钱，涉及的东西又太多，不 boom 怎么去折腾呢。比如说，电源波纹对电容的长期影响，Lucky 的每次升级了什么代码。都是年轻人在玩，有精力的把票玩成品牌就出坑，没精力的，玩上几年，理清需求了也就转赛道了。 |
 | 62 libregratis 2025 年 8 月 23 日
|
Select Language