NetBox 多叢集備份與災難復原架構 (Central-to-Site)

本指南專為 「中央 (Central K8s) 控管多個分站 (Site K8s)」 的架構所設計。在此情境下，每個 Site 皆獨立部署 NetBox，而中央叢集負責統一的資料備份、監控與異地災備 (DR)。

1. 核心架構前提

在討論備份方案前，必須先理解災難復原的兩大核心指標：

RPO (Recovery Point Objective, 復原點目標)：
- 定義：災難發生時，企業允許遺失多少時間的資料。
- 範例：若每 24 小時備份一次，RPO 就是 24 小時；若採用即時串流複製，RPO 則趨近於 0。
RTO (Recovery Time Objective, 復原時間目標)：
- 定義：從災難發生到服務恢復正常運作所需的時間。
- 範例：若重建環境需要 4 小時，還原資料庫需要 2 小時，則 RTO 為 6 小時。

方案類型	技術手段	RPO (資料遺失)	RTO (恢復速度)	優點
A. 分站推送 (Push)	`pg_dump` to Central S3	中 (取決於排程)	中 (需手動還原)	權限隔離、網路容錯
B. WAL 增量倉庫	pgBackRest	極低 (可 PITR)	快 (自動化還原)	支援時間點還原、省頻寬
C. 異地串流溫備	Streaming Replication	趨近於零	極快 (溫備切換)	災難接管首選方案

在「具備應用部署權限，但無 Cluster-Admin 權限」的前提下，我們排除「中央拉取」與「邏輯複製」(經實測有 Sequence 不同步問題)，專注於以下可靠方案：

在分站 NetBox 所在的 Namespace 部署一個 CronJob。

機制：
1. CronJob 在分站本地執行 pg_dump 並進行 gzip 壓縮。
2. 利用 curl 將備份檔透過 REST API 推送至中央 (Central-DR) 的 Nexus Raw Repository。

Option A Architecture

中央站點 (Central-DR):
- 執行 setup_nexus.sh 安裝 Nexus.
- 登入 Nexus UI，創建一個類型為 raw (hosted) 的 Repository，命名為 netbox-backups。
- 創建一個專用帳號 (如 backup-user) 並賦予上傳權限。
分站站點 (Site-A):
- 建立 nexus-credentials Secret 儲存帳密。
- 部署 netbox-backup-cronjob.yaml，並修改 NEXUS_URL 指向中央站點 IP。

在中央部署 pgBackRest Repo 服務。各分站資料庫 Pod 只需配置 archive_command 指向中央服務。

Option B Architecture

運作原理：
1. WAL 歸檔 (WAL Archiving)：分站資料庫將每次異動產生的 Write-Ahead Log (WAL) 檔案，即時推送到中央的 pgBackRest Repo (或指定的 S3 儲存)。
2. 增量/差異備份 (Incremental/Delta Backups)：除了一開始的完整備份，後續的備份 pgBackRest 只會比對並傳輸修改過的資料塊 (Block-level)，極大程度節省了網路頻寬與備份時間。
3. 時間點還原 (PITR)：因為擁有連續的 WAL 日誌，當災難發生時，您可以將資料庫還原到「過去的任意一秒鐘」，避免人為誤刪造成的無法挽回的損失。
優勢：pgBackRest 是在應用層運作，不需要 kubectl exec 權限，只需網路埠 (TLS) 連通即可。
實施門檻：⚠️ 極高 (不建議 User Role 採用)。
- 預設限制：NetBox 依賴的 Bitnami PostgreSQL 鏡像基於極簡與安全設計 (以非 root uid 1001 運行)。雖然可能內含 pgBackRest 執行檔，但完全沒有預先設定，也缺乏將 WAL 寫入 S3/Repo 的環境權限。
- 改造複雜：若要強行使用，必須打破「單一容器」原則。您需要自行撰寫 Dockerfile 製作 Custom Image 植入設定，或是透過 Helm 撰寫複雜的 Sidecar 容器並共用磁碟 (/bitnami/postgresql/data)，這超出了一般應用部署權限 (User Role) 的能力範圍。

在中央部署分站的備援 Pod (Standby)。

Option C Architecture

部署實務：只需在中央部署普通的 StatefulSet，並在配置中填入分站資料庫的連線字串。
優勢：物理級同步，包含 Schema 與 Sequence，災難發生時一鍵 promote 即可接管，無需修復資料。
缺點 (規模化限制)：必須維持 1:1 的實例映射。若有 20 個分站，中央叢集就必須建立 20 套獨立的 PostgreSQL Standby 實例。這會導致中央叢集的資源消耗 (CPU/Memory/PVC) 與維運複雜度隨著分站數量線性暴增。

# 當分站故障，在中央提升備援庫
kubectl -n dr-namespace exec netbox-postgresql-dr-site-a-0 -- \
  bash -c "pg_ctl promote -D /bitnami/postgresql/data"

velero backup create site-a-netbox-config \
  --include-namespaces netbox \
  --selector "app.kubernetes.io/instance=netbox"