這個工程師把家庭服務器做成2節點集群

家庭服務器玩家有個默契：玩到第三年，要么退坑，要么把機柜塞滿。前者嫌折騰，后者嫌不夠折騰。

一位玩了八年的老玩家最近曬出自建方案——雙節點高可用集群、異地災備、自動化快照，每月電費賬單比鄰居高出一截。他在技術社區寫道：「所有配置都過度設計，但這是我最不后悔的決定?！?/p>

從單臺礦渣到2節點集群，他花了三年踩完所有坑

他的起點和多數人一樣：一臺幾百塊收的礦渣主機，刷個開源系統，跑幾個容器嘗鮮。前兩年的樂趣在于折騰——今天試這個發行版，明天換那個虛擬化方案，配置文件改崩了就重裝。

轉折點出現在第三年。當時他跑的生產級服務越來越多：去廣告用的Pi-hole、筆記工具Trilium、消息推送Gotify、本地大模型Ollama。某次手滑改錯一個變量，整個環境癱瘓，花了整晚重建。

「那次之后我算明白了，實驗環境可以隨便炸，但生產環境必須能自愈。」他在復盤帖里提到。

現在的架構分兩層：主節點是一臺Xeon工作站，承擔實驗性質的項目；雙節點Proxmox VE集群跑關鍵服務，用ZFS做實時復制。第三個角色是樹莓派，充當仲裁設備——這是集群腦裂時的救命稻草。

這套配置的成本很具體：兩臺x86小主機約2000元，樹莓派400元，電費每月多掏200塊。

備份策略細到「 fortnight 」這個單位

他的備份設計比多數中小企業的IT規范還細。本地層面，Proxmox虛擬機幾乎隔天快照到低配備份服務器；遠程層面，關鍵快照自動同步到另一臺異地NAS，頻率從兩周到一個月不等。

「 fortnight 」這個詞出現在他的配置文檔里——兩周一次，精確到讓人不適。低優先級的容器和虛擬機則被區別對待，快照間隔更長。

TrueNAS存儲層同樣雙保險：兩臺裸機部署，互為備份。他解釋過這種「過度設計」的動機：「不是怕硬盤壞，是怕我自己手賤?！?/p>

社區里有新手問他值不值。他回得干脆：「等你因為一條錯誤配置熬夜重裝三遍，就會覺得值?！?/p>

高可用不是不停機，是「炸得優雅」

集群方案最被誤解的一點，是把「高可用」等同于「永不停機」。他的實踐更接近另一種定義：單點故障時，服務能漂到另一節點，用戶無感知。

具體場景是：主節點維護或崩潰時，Pi-hole、筆記服務、消息推送會在幾十秒內切換到備用節點。ZFS復制保證了數據一致性，仲裁設備防止腦裂——兩臺主機同時以為自己是主節點，這是集群部署最兇險的故障模式。

他坦承這套方案對普通家庭用戶完全多余?！溉绻阒皇桥軅€下載機和影音庫，單臺NAS足夠。」

但目標讀者顯然不是普通用戶。技術社區的跟帖里，有人曬出自己的三節點方案，有人在討論把仲裁設備換成ESP32省電費。過度設計在這里是社交貨幣，不是性能需求。

「第二份工作」的悖論

家庭服務器圈子里有句老話：玩到后期，這愛好會變成第二份工作。他認同這個說法，但加了限定條件——只有當系統缺乏自動化時，才會變成負擔。

他的應對策略是腳本化一切：快照任務、同步任務、健康檢查、告警推送。初期投入時間寫腳本，后期節省的時間呈指數級增長。

「現在機柜燈閃的時候，我不用猜是正常備份還是硬盤報錯，手機會告訴我。」

這種設計思路帶有明顯的產品經理痕跡：把運維成本前置，換取長期的確定性。他在評論區回復過一位質疑者：「你說電費不劃算，但沒算過凌晨三點起床修服務器的情緒成本?！?/p>

社區數據顯示，他的完整方案帖獲得超過400條回復，收藏數是點贊的三倍。典型的「看不懂但先存著」型內容。

一位跟進實踐的讀者兩周后反饋：「按這個架構搭了一半，發現最難的不是技術，是說服家人接受客廳里的機柜噪音?！?/p>

你的家庭服務器停在哪個階段——還在折騰單機的樂趣，還是已經開始規劃第二臺主機？