💾 Proxmox Backup Server (PBS) 深度實作：異地增量備份與勒索軟體防護策略

PBS 不是「備份做一做就好」的工具；你要它真的能扛住災難（硬碟壞、機房斷電、甚至勒索軟體），關鍵在於： 架構（Offsite）、權限（最小化）、維護（Verify/Prune/GC） 三件事要一起做。

這篇用「能上線、能維運、能抗風險」的角度，把 PBS 的異地增量備份與防勒索策略拆成可落地的段落。你照著做完，至少能達到：

✅ 異地端也能「增量同步」（只同步變更）
✅ 來源端被入侵時，降低「順便把備份刪光」的機率
✅ 備份可驗證、可稽核、可長期保留

📌 目錄

1) 目標與威脅模型
2) 推薦架構：本地 PBS + 異地 PBS（Pull Sync）
3) 最小權限：讓來源端「只能備份、不能刪除」
4) 異地增量：Sync Job（Pull/Push）怎麼選、怎麼排程
5) Verify / Prune / GC：維護工作排程與最佳實務
6) 近似不可變（Immutable）策略：protected 快照與注意事項
7) 加密與金鑰：Client-side Encryption 的實務要點
8) 上線檢查清單
FAQ
🔗 延伸閱讀

1) 📌 目標與威脅模型

如果你只考慮「硬體故障」，那備份通常不難；真正難的是勒索軟體與入侵事件：攻擊者拿到 PVE（或管理端）權限後，最常見的下一步就是：先清備份，再加密正式資料。這也是為什麼很多人會質疑「Push 備份」在資安上比較脆弱。:contentReference[oaicite:0]{index=0}

本文策略的核心，是把備份系統做成「分層與分權」：

來源端（PVE）只負責產生備份：權限到此為止，不給刪除權。
本地 PBS 做主要備份與日常還原：速度快、維運方便。
異地 PBS 用 Pull Sync 拉取副本：就算來源端出事，也降低異地副本被同時清掉的機率。:contentReference[oaicite:1]{index=1}

你可以把它對應成更容易理解的備份原則：在 3-2-1 的基礎上，加入「不可變副本」與「零錯誤驗證」的概念（3-2-1-1-0）。:contentReference[oaicite:2]{index=2}

2) 🧱 推薦架構：本地 PBS + 異地 PBS（Pull Sync）

[Proxmox VE Cluster]
   |  (Backup: vzdump to PBS storage)
   v
[本地 PBS（主備份）]  ---（Sync Job：Pull）--->  [異地 PBS（離線/異地副本）]
   |                                     ^
   | (Verify / Prune / GC)               |
   +-------------------------------------+
          （最小權限、來源端不可刪除）

PBS 的 Sync Job 本質上就是「把 Remote datastore 的內容同步到本地 datastore」，可排程定期跑。:contentReference[oaicite:3]{index=3}

實作上你會做兩台 PBS：

本地 PBS：PVE 備份目標（最常用、還原最快）
異地 PBS：設定 Remote 指向本地 PBS，並以 Pull Sync 拉取（偏資安/災難復原導向）:contentReference[oaicite:4]{index=4}

3) 🔐 最小權限：讓來源端「只能備份、不能刪除」

勒索事件最怕的是「備份也被刪」。一個很務實的做法是：讓 PVE 連 PBS 的帳號只擁有寫入備份能力，不給 prune/delete。因為攻擊者就算拿到 PVE，最多只能把備份「塞爆」或「做很多份」，但不容易直接刪光歷史快照。:contentReference[oaicite:5]{index=5}

在 PBS 權限模型裡，若你給的是偏「只備份」的角色，它就不應具備 prune 權限；而要 prune 則需要更高的 datastore 權限（例如包含 Datastore.Prune 的角色）。:contentReference[oaicite:6]{index=6}

建議做法：

PVE → PBS：使用「只備份、不刪除」的帳號/token
Prune/Retention：改在 PBS 端以 prune job 統一做（由 PBS 管理者權限執行）:contentReference[oaicite:7]{index=7}
異地 Sync：異地端用另一組更嚴格權限（至少 Read/Audit），避免把本地 PBS 的管理權外放:contentReference[oaicite:8]{index=8}

4) 🌍 異地增量：Sync Job（Pull/Push）怎麼選、怎麼排程

4.1 Pull vs Push：我的建議

Pull（建議）：異地端主動拉，本地端只需提供可讀取的 Remote datastore 權限；對勒索/入侵情境更友善。:contentReference[oaicite:9]{index=9}
Push（可用但要更小心）：本地端主動推到異地，若本地端被拿下，異地端更容易跟著遭殃（取決於你怎麼設權限與網路隔離）。:contentReference[oaicite:10]{index=10}

4.2 Sync Job 設定重點（維運角度）

PBS 文件明確說明：Sync job 用來把「Remote datastore」同步到「本地 datastore」，可在 Web UI 建立與排程，也可用 CLI 管理；其設定檔位於 /etc/proxmox-backup/sync.cfg。:contentReference[oaicite:11]{index=11}

排程建議：

本地 PBS 備份完成後再 Sync（避免同步到一半又新增大量 chunks）
跨站頻寬有限：Sync 頻率可拉長，但務必確保 RPO 符合需求（例如每日、每 6 小時）
異地端再做一次 Verify（把「零錯誤」落地）:contentReference[oaicite:12]{index=12}

5) 🧰 Verify / Prune / GC：維護工作排程與最佳實務

PBS 的長期可靠度，靠的不是「備份有跑」，而是「備份可驗證、空間可回收、保留策略可控」。官方文件把 Verify 視為透過 verify jobs 定期執行的驗證機制，並可設定重新驗證週期。:contentReference[oaicite:13]{index=13}

5.1 Verify：把「可還原」變成可量測

Verify 的目的，是檢查 chunk 是否損壞或遺失；不做驗證等於把風險全押在儲存層永遠不出錯。:contentReference[oaicite:14]{index=14}
建議：本地每週一次、異地每週或雙週一次（依容量/效能調整）。

5.2 Prune 與 GC：兩件事，不要混為一談

Prune 會依保留策略移除快照；GC（Garbage Collection）用來清掉「已無快照引用」的 chunks。兩者是獨立機制。:contentReference[oaicite:15]{index=15}

排程建議（避免 I/O 打架）：

備份完成後 → 跑 Prune
Prune 後隔一段時間（例如隔天離峰）→ 跑 GC
Verify 與 Prune/GC 分時段，避免同時掃大量資料:contentReference[oaicite:16]{index=16}

6) 🧊 近似不可變（Immutable）策略：protected 快照與注意事項

PBS 提供「protected flag」用來保護快照：被標記 protected 的快照，不會被 prune 或手動刪除，直到你解除保護。:contentReference[oaicite:17]{index=17}

# 範例：把指定快照設為 protected
proxmox-backup-client snapshot protected update <snapshot> true

# 解除 protected
proxmox-backup-client snapshot protected update <snapshot> false

但有一個很重要的坑： protected flag 不會隨 Sync job 一起同步到另一台 PBS。也就是說，你在本地保護了快照，異地拉過去後，異地端不會自動帶著「protected」。:contentReference[oaicite:18]{index=18}

因此建議的落地做法是：

本地 PBS：依 retention 正常 prune（以容量為優先）
異地 PBS：挑關鍵週期（例如每月第一個完整備份、季度節點）手動或排程標記 protected（以防勒索/災難為優先）:contentReference[oaicite:19]{index=19}

7) 🔑 加密與金鑰：Client-side Encryption 的實務要點

若你要把「異地」當成真正的防線，建議把備份做成 client-side encryption（由客戶端管理加密）。 Proxmox VE 文件也提到：PBS 的加密是由 client side 管理，甚至同一個 datastore 可同時存放未加密與已加密備份。:contentReference[oaicite:20]{index=20}

重點提醒：

金鑰務必離線保存（至少要有「異地」與「多人可取回」的流程）
不要把唯一金鑰只放在同一個被備份的環境內（否則等於勒索一來金鑰也一起沒了）

8) ✅ 上線檢查清單（建議照這份逐條驗）

[ ] PVE → 本地 PBS 帳號：只給備份寫入，不給 prune/delete（最小權限）:contentReference[oaicite:21]{index=21}
[ ] 本地 PBS：Verify job 已排程（且可重驗週期有設定）:contentReference[oaicite:22]{index=22}
[ ] 本地 PBS：Prune job 與 GC job 分時段排程:contentReference[oaicite:23]{index=23}
[ ] 異地 PBS：以 Pull Sync 拉取（並確保 Remote 權限最小化）:contentReference[oaicite:24]{index=24}
[ ] 異地 PBS：同步後也有 Verify（落實 3-2-1-1-0 的「0 errors」概念）:contentReference[oaicite:25]{index=25}
[ ] protected 策略：知道「protected 不會被 sync 帶過去」，異地端另行保護關鍵快照:contentReference[oaicite:26]{index=26}
[ ] 加密金鑰：有離線備援與取回流程:contentReference[oaicite:27]{index=27}

FAQ

Q1：我把 retention 設在 PVE 就好，還是設在 PBS？

PBS 端的 prune 是獨立機制；如果你兩邊都設，兩邊都會套用。實務上要抗勒索，我會傾向把 retention/prune 交給 PBS 端做，並讓來源端帳號不具刪除能力。:contentReference[oaicite:28]{index=28}

Q2：Verify 很吃效能，要不要做？

Verify 的目的就是偵測 chunk 檔損壞或遺失；不做就等於相信儲存層永遠正確。建議至少在異地端做，因為那是你最後一道防線。:contentReference[oaicite:29]{index=29}

Q3：protected 可以當成真正 immutable 嗎？

protected 能防 prune/手動刪除，但本質仍是權限與流程問題；更穩的是「分權 + Pull Sync + 異地 protected + 驗證」，把風險分散到不同層。並且要記住：protected 不會透過 sync 自動保留，需要在目標端另外設。:contentReference[oaicite:30]{index=30}

💬 留言聊聊：你的 PBS 異地備份怎麼設計？

我通常會先問三個問題，因為它們會直接決定你的防勒索強度：

✅ PVE 連 PBS 的帳號，有沒有 刪除/Prune 權限？
✅ 異地備份是 Pull 還是 Push？遠端權限怎麼切？
✅ 你有沒有固定跑 Verify，確保「需要還原時真的還原得回來」？

你也可以貼你的排程邏輯（備份/Sync/Verify/Prune/GC 的時間點），我可以幫你一起把衝突點與風險點找出來。

⬇️ 在下方留言區分享你的配置或踩雷經驗，讓更多人少走彎路。

💾 Proxmox Backup Server (PBS) 深度實作：異地增量備份與勒索軟體防護策略

💾 Proxmox Backup Server (PBS) 深度實作：異地增量備份與勒索軟體防護策略

📌 目錄

1) 📌 目標與威脅模型

2) 🧱 推薦架構：本地 PBS + 異地 PBS（Pull Sync）

3) 🔐 最小權限：讓來源端「只能備份、不能刪除」

4) 🌍 異地增量：Sync Job（Pull/Push）怎麼選、怎麼排程

4.1 Pull vs Push：我的建議

4.2 Sync Job 設定重點（維運角度）

5) 🧰 Verify / Prune / GC：維護工作排程與最佳實務

5.1 Verify：把「可還原」變成可量測

5.2 Prune 與 GC：兩件事，不要混為一談

6) 🧊 近似不可變（Immutable）策略：protected 快照與注意事項

7) 🔑 加密與金鑰：Client-side Encryption 的實務要點

8) ✅ 上線檢查清單（建議照這份逐條驗）

FAQ

Q1：我把 retention 設在 PVE 就好，還是設在 PBS？

Q2：Verify 很吃效能，要不要做？

Q3：protected 可以當成真正 immutable 嗎？

💬 留言聊聊：你的 PBS 異地備份怎麼設計？

🔗 延伸閱讀

沒有留言: