我的 TrueNAS SCALE 入門：先把儲存打穩，再談 Docker 與 VM

如果把 HomeLab 想成一座小型城市，TrueNAS SCALE 就像它的倉庫、檔案室和地下管線：先把資料放在哪裡、誰可以讀取、怎樣恢復想清楚，後面的 Docker App、虛擬機和自架服務才不會變成一堆互相牽連的黑盒子。

這篇先不急著進入複雜的 App 部署，而是從我長期使用 TrueNAS 的硬體基線與思考方式開始。後續再沿著同一套架構，逐步談容器、VM、反向代理與備份。

這篇文章的定位

TrueNAS 不只是「把幾顆硬碟組起來的檔案伺服器」。它真正有價值的地方，是把儲存、權限、快照、共享與服務邊界放在同一個可管理的基礎上。對 HomeLab 來說，這個基礎比一開始安裝多少服務更重要。

因此，這篇的目標是建立一張地圖：知道目前這台機器大致能做什麼、哪些地方不能靠猜，以及之後新增服務時，應該把它放在儲存層、App 層還是 VM 層。

我的 TrueNAS SCALE 硬體基線

項目	公開化後的摘要
平台	TrueNAS SCALE，x86_64
CPU	Intel Core i3-10100F，4 核心／8 執行緒
記憶體	64GB DDR4
系統碟	約 232.9GB，作為系統用途
資料碟	6 顆、每顆約 931.5GB
網路	Realtek Gigabit Ethernet
其他硬體	額外 SATA 控制器與基本顯示輸出卡

這份表格只描述硬體摘要，沒有把實際儲存池布局猜成某一種 RAIDZ 或 mirror。硬碟數量不等於資料保護策略；真正要確認的，還包括 vdev 組成、可用容量、快照政策、備份副本，以及故障時的復原流程。

為什麼這樣的配置適合拿來做 HomeLab

• 記憶體先行：64GB RAM 為 ZFS 快取、檔案服務和少量背景服務留下了空間，但仍然要觀察實際工作負載，不能把 RAM 當成備份。
• 系統與資料分開：獨立的系統碟讓系統維護和資料池的生命週期比較容易分開管理。
• 六顆資料碟留有規劃空間：可以依照容量、容錯和效能需求選擇合適的 vdev；重點是先定義資料重要程度，再決定布局。
• 1GbE 是清楚的邊界：一般共享、文件同步和小型服務足夠使用；大量備份或影像工作流則需要把網路速度納入整體設計。

我會怎樣分層使用 TrueNAS

1. 儲存層：先讓資料可理解、可恢復

資料集命名、權限、快照和備份要先定義。不同類型的資料不一定要放在同一個 dataset；把文件、媒體、App 資料和備份分開，日後設定權限與保留週期會清楚很多。

2. App 層：讓服務依賴清楚

Docker App 最容易讓 HomeLab 變得有趣，也最容易讓資料路徑、環境變數與權限失控。我的原則是：應用程式可以重建，資料不能只存在容器裡；每個服務都要知道自己的設定檔、持久化路徑和備份方式。

3. VM 層：把需要獨立系統邊界的工作隔開

當服務需要不同核心版本、不同網路策略或更完整的系統隔離時，VM 會比把所有東西塞進同一個容器更容易維護。VM 不代表自動安全，仍然要處理更新、帳號、網路暴露和備份。

公開文章的隱私處理規則

這個系列的文章會把真實 IP、網域、使用者名稱、密碼、Token、序號和內部路徑視為不可直接公開的資料。示例只使用文件專用的保留網段，並且不對應到實際設備。

TrueNAS 管理介面   192.0.2.10
Docker App 範例    198.51.100.10
VM 範例            203.0.113.10
公開網域範例       nas.example.com

後續文章會沿用這套規則：同一類角色使用同一組文件網段，密碼與 Token 一律改成不可逆的佔位符，真實服務網域則改成 example.com 底下的示例名稱。這樣文章仍然可以教人理解拓撲和設定方式，又不會把家中網路變成公開地圖。

接下來的 TrueNAS 系列

• 用 dataset、權限與快照建立穩定的資料底座。
• 在 TrueNAS 上管理 Docker App：持久化、環境變數與更新策略。
• 用 VM 隔離不同用途的服務，整理網路與資源分配。
• 加入反向代理、遠端存取、監控和備份，讓 HomeLab 從「能跑」變成「可維護」。

我喜歡 TrueNAS 的原因，不是它能一次解決所有問題，而是它逼你先把資料和邊界想清楚。當儲存層穩定下來，Docker 和 VM 才會從「一直在救火」變成真正可以累積的實驗。