🔰 引言
傳統的災難復原 (DR) 方案通常需要人工介入：
管理者接到告警後登入系統、選擇備份、手動還原。
這樣的方式雖可行，但在真正的緊急狀況下（例如主機室斷電、勒索病毒攻擊），
反應時間長、流程不一致、容易出錯。
因此，現代企業開始導入 自動化災難復原 (Automated Disaster Recovery, ADR)，
讓系統能依據事件自動啟動復原動作、同步資料、甚至在異地自動重建服務。
本文將介紹：
1️⃣ ADR 架構與流程設計概念
2️⃣ Proxmox + PBS + API + Ansible / Terraform 整合方式
3️⃣ 真實實戰範例與自動化工作流設計
🧩 一、自動化災難復原 (ADR) 架構概觀
架構示意圖
┌──────────────────────────────────────────────────────┐
│ 監控層 (Monitoring Layer) │
│ Prometheus → Grafana → Alertmanager → Webhook/Slack │
└───────────────┬──────────────────────────────────────┘
│ 事件觸發
┌────────────────┴────────────────┐
│ Orchestration 層 │
│ Ansible / Terraform / N8N / AWX │
└──────────────┬───────────────────┘
│ 執行自動化動作
┌────────────────┴────────────────┐
│ 執行層 (Execution Layer) │
│ Proxmox VE + PBS + API + Ceph │
└──────────────────────────────────┘
🧠 二、自動化復原流程概念
| 階段 | 觸發來源 | 行為 | 工具 |
|---|---|---|---|
| 1️⃣ 偵測事件 | Prometheus / Grafana Alert | 發現主機節點或 PBS 掛線 | Alertmanager |
| 2️⃣ 通知階段 | Webhook / Slack / Email | 通知管理者與自動化系統 | Alertmanager / Webhook |
| 3️⃣ Orchestration | 自動執行 Playbook / Script | 驅動復原流程 | Ansible / Terraform |
| 4️⃣ 資料復原 | 從遠端 PBS 或雲端備份復原 | 重建 VM、網路、服務 | Proxmox API + PBS |
| 5️⃣ 驗證與回報 | 驗證系統可用性、發送報告 | 自動確認完成狀態 | API + Grafana Alert |
⚙️ 三、Proxmox API + Ansible 整合實戰
Proxmox 的 REST API 幾乎涵蓋所有操作，可與 Ansible 搭配實現自動化復原。
1️⃣ Ansible 連線設定
在 /etc/ansible/hosts 加入：
[pve_cluster]
pve-node01 ansible_host=10.0.0.11
pve-node02 ansible_host=10.0.0.12
設定變數：
proxmox_api_url: "https://10.0.0.11:8006/api2/json"
proxmox_user: "root@pam"
proxmox_token_id: "dr-automation"
proxmox_token_secret: "xxxxxxx"
2️⃣ 自動化復原 Playbook 範例
---
- name: Proxmox Automated VM Recovery
hosts: localhost
gather_facts: no
tasks:
- name: Restore VM from remote PBS
uri:
url: "{{ proxmox_api_url }}/nodes/pve-node02/qemu"
method: POST
headers:
Authorization: "PVEAPIToken={{ proxmox_user }}!{{ proxmox_token_id }}={{ proxmox_token_secret }}"
body_format: json
body:
vmid: 301
restore: "pbs:remote-pbs/vm-301"
unique: 1
pool: "production"
register: restore_result
- name: Print restore job status
debug:
var: restore_result
此 Playbook 可直接由 Alertmanager 或 AWX 觸發，
在異地自動還原指定的 VM，整個流程無需人工操作。
☁️ 四、Terraform 自動化建置範例
Terraform 可用於在異地或雲端自動建立 Proxmox VM 環境。
Terraform 範例設定
provider "proxmox" {
pm_api_url = "https://10.0.0.11:8006/api2/json"
pm_user = "root@pam"
pm_api_token_id = "dr-automation"
pm_api_token_secret = "xxxxxxx"
}
resource "proxmox_vm_qemu" "dr_vm" {
name = "dr-webserver"
target_node = "pve-node02"
clone = "ubuntu-template"
cores = 4
memory = 8192
disk {
size = "40G"
storage = "local-lvm"
}
network {
bridge = "vmbr0"
}
}
執行自動建置：
terraform init
terraform apply -auto-approve
此流程可作為「備援 VM」的自動佈署流程，
可在 PBS 同步完成後，快速在異地重建服務。
🧮 五、Alertmanager + N8N 自動化工作流實例
工作流程圖
[Prometheus]
↓
[Grafana Alert]
↓
[Alertmanager]
↓ (Webhook Trigger)
[N8N / Ansible Playbook]
↓
[Proxmox API → PBS → Restore VM]
↓
[Slack 通知 / 報告上傳]
範例 Webhook 觸發流程
當 Prometheus 偵測節點離線時，Alertmanager 發送：
{
"receiver": "proxmox-dr",
"status": "firing",
"alerts": [
{
"labels": {
"alertname": "PVE_Node_Down",
"instance": "pve-node01",
"severity": "critical"
},
"annotations": {
"description": "Proxmox node pve-node01 is unreachable"
}
}
]
}
N8N 或 Ansible 解析此事件後，觸發自動化復原流程。
🧰 六、自動化驗證與回報
完成自動還原後，可自動驗證 VM 狀態：
pvesh get /nodes/pve-node02/qemu/301/status/current
若回傳：
{"status":"running"}
則代表復原成功。
接著透過 API 回傳至 Grafana 或 Slack：
✅ VM 301 已成功從 remote PBS 還原並啟動。
🧠 七、延伸應用：雲端多區域 Orchestration
在混合雲環境中，可將 DR 自動化拓展至多地區：
| 雲端區域 | 任務 | 工具 |
|---|---|---|
| AWS | 建立 EC2 臨時節點，掛載 PBS S3 備份 | Terraform / CLI |
| Azure | 自動開啟 Blob Snapshots 作為備份來源 | Azure Functions |
| GCP | 使用 Cloud Run 執行 DR 任務自動觸發 | API / N8N |
| On-Prem | Proxmox 節點自動復原 / 重啟 | Ansible / API |
✅ 結語
透過 Proxmox VE + PBS + API + Orchestration 工具 的整合，
企業可以打造出一個：
- 自動偵測異常
- 自動化復原
- 跨區域同步
- 多雲協作
的智能化災難復原平台。
這不只是節省人力，更代表企業 IT 架構的彈性與可持續性大幅提升。
💬 下一篇將進入系列最終章：
「Proxmox 企業級應用與治理框架」，
彙整從虛擬化、備援、安全到雲端整合的全貌，
打造企業級開源虛擬化治理藍圖。