高可用與災難復原
從 RTO / RPO 定義出發，逐層理解 Snapshot、跨站複製、雙活架構到不可變備份的設計邏輯。通用概念適用各品牌，具體示範以 IBM 環境為例。
本篇範圍說明#
本章的設計概念與原則（RTO/RPO、Snapshot 原理、同步/非同步複製邏輯、雙活設計、不可變備份思維）適用於各品牌儲存環境。
具體示範以 IBM SVC / FlashSystem 環境為主，包含 FlashCopy、Metro Mirror、Global Mirror、HyperSwap、Safeguarded Copy 等 IBM 功能名稱與操作邏輯。
使用其他品牌設備的讀者：通用概念直接適用，IBM 專屬功能請參照各節提供的跨品牌對照表，找到對應品牌的做法。
| 標籤 | 意義 |
|---|---|
| 通用概念 | 適用所有品牌，核心邏輯不變 |
| IBM 示範 | IBM 環境的具體功能名稱或做法 |
| 跨品牌對照 | 其他主流品牌的對應功能 |
5.1 HA 設計原則#
RTO 與 RPO：兩個最重要的指標
在討論任何 HA 或 DR 方案之前，必須先釐清 RTO 和 RPO，因為這兩個數字直接決定了需要哪種技術方案，也決定了成本。
例：RTO = 4 小時，代表系統最多可以停機 4 小時，超過就違反 SLA。
例：RPO = 1 小時，代表最多可以接受遺失 1 小時內的資料。RPO = 0 代表零資料遺失。
HA 不等於 DR
| 概念 | 保護對象 | 典型場景 | RTO / RPO |
|---|---|---|---|
| HA（High Availability） | 單一設備或元件的故障 | 控制器故障、磁碟故障、網路路徑中斷 | 秒級 / 零 |
| DR（Disaster Recovery） | 整個站點的災難 | 機房火災、淹水、斷電、地震 | 分鐘～小時 / 秒～小時 |
N+1 vs 2N 設計
- N+1：N 個運作中的元件，加上 1 個備援。成本較低，但備援元件閒置。例：2 個控制器中 1 個故障，另 1 個接手全部負載。
- 2N：所有元件都有對等備援，任何一個故障都不影響容量或效能。成本較高，但保護能力更強。例：雙控制器 Active-Active，故障後另一個承擔全部 I/O 且效能不衰減。
儲存 HA 的典型保護層次
| 層次 | 保護對象 | 技術手段 |
|---|---|---|
| 磁碟層 | 單顆磁碟故障 | RAID / DRAID |
| 控制器層 | 控制器故障 | 雙控制器 Active-Active |
| 網路層 | 路徑中斷 | 雙 Fabric + MPIO |
| 站點層 | 整個機房災難 | 跨站複製 / 雙活架構 |
| 資料層 | 資料誤刪 / 勒索加密 | Snapshot / 不可變備份 |
5.2 Snapshot / FlashCopy#
Snapshot 的基本原理
Snapshot（快照）是某個時間點的資料狀態記錄。建立 Snapshot 的瞬間極快（通常毫秒內完成），因為它不是複製資料，而是記錄「哪些 Block 在這個時間點是什麼狀態」的 Metadata。
Copy-on-Write vs Redirect-on-Write
| 機制 | 運作方式 | 優點 | 缺點 |
|---|---|---|---|
| Copy-on-Write（CoW） | 有新寫入時，先把舊資料複製到 Snapshot 區，再寫入新資料。Snapshot 保存舊資料。 | 原始 Volume 不需要改變位置，讀取效能影響小 | 每次寫入需要額外的讀取+寫入操作（寫入放大） |
| Redirect-on-Write（RoW） | 有新寫入時，直接寫到新位置，Snapshot 指向舊位置。原始指標不動。 | 寫入效能更好（無需先讀再寫） | Snapshot 越多，讀取時需要追蹤的指標越複雜 |
IBM FlashCopy
IBM SVC / FlashSystem 的快照功能稱為 FlashCopy，特點是建立的是可讀寫的完整副本（Full Copy 或 Space-efficient Copy），而不只是唯讀的時間點記錄。
- Space-efficient FlashCopy：只記錄差異，不佔用完整容量，適合短期快照和備份前的一致性快照
- Full Copy FlashCopy：完整複製資料到目標 Volume，完成後兩個 Volume 完全獨立，適合長期保存或測試環境
- Incremental FlashCopy：只複製自上次 FlashCopy 以來變更的 Block，減少複製時間和網路頻寬
Snapshot 和原始資料存放在同一台設備上。如果儲存設備本身故障（控制器損壞、陣列遭勒索加密），Snapshot 和原始資料會同時消失。
完整的資料保護需要：Snapshot（快速回復誤刪）+ 跨設備備份（設備故障保護）+ 跨站複製（站點災難保護）。
| 品牌 | Snapshot 功能名稱 | 特色 |
|---|---|---|
| IBM | FlashCopy | 可讀寫副本，Space-efficient / Full Copy 可選 |
| NetApp ONTAP | Snapshot | RoW 機制，幾乎零空間佔用，可快速還原 |
| Dell PowerMax / PowerStore | TimeFinder / Snapshot | TimeFinder 為企業級完整副本；PowerStore Snapshot 為輕量快照 |
| Everpure（Pure） | Snapshot | 所有 Snapshot 共用資料縮減，不額外佔用空間 |
| HPE Alletra / Nimble | Snapshot / Volume Collection | 支援多 Volume 一致性快照 |
5.3 同步 / 非同步複製#
為什麼需要跨站複製
Snapshot 保護資料不被誤刪，但無法應對整個站點的災難（火災、地震、淹水）。跨站複製（Replication）將資料即時或定期複製到另一個地理位置的儲存設備，讓站點災難發生時有資料可以恢復。
同步 vs 非同步的核心取捨
| 比較項目 | 同步複製 | 非同步複製 |
|---|---|---|
| RPO | 零（資料不遺失） | 秒～分鐘（有資料缺口） |
| 寫入延遲影響 | 主機每次寫入需等備援站確認，延遲增加 | 主機寫入後立即確認，備援站背景同步 |
| 距離限制 | 有（延遲超過 ~5ms 會嚴重影響效能） | 無（透過 WAN 長距離傳輸） |
| 適用場景 | 同城雙活、金融核心系統 | 跨城市 / 跨國 DR 站 |
| 成本 | 高（需要低延遲專線） | 相對較低（可用一般 WAN） |
IBM Metro Mirror vs Global Mirror
| 功能 | 複製類型 | RPO | 典型距離 | 用途 |
|---|---|---|---|---|
| Metro Mirror | 同步 | 零 | < 300 km（延遲 < 2ms） | 同城雙活基礎，配合 HyperSwap |
| Global Mirror | 非同步 | 秒級 | 無限制 | 跨城市 / 跨國的遠端 DR 站 |
| Global Mirror with Change Volumes | 非同步（一致性增強） | 秒級 | 無限制 | 需要多 Volume 一致性的跨站 DR |
| 品牌 | 同步複製 | 非同步複製 |
|---|---|---|
| NetApp ONTAP | SnapMirror Synchronous | SnapMirror（非同步） |
| Dell PowerMax | SRDF/S（Synchronous） | SRDF/A（Asynchronous） |
| Everpure（Pure） | ActiveDR（同步模式） | ActiveDR（非同步模式） |
| HPE Alletra / 3PAR | Peer Persistence（同步） | Remote Copy（非同步） |
| Hitachi VSP | TrueCopy（同步） | Universal Replicator（非同步） |
5.4 雙活架構（HyperSwap 與同類產品）#
從複製到雙活的演進
同步複製（Metro Mirror）讓備援站有即時一致的資料，但當主站發生災難時，切換到備援站仍需要人工介入或自動化流程，這段切換時間就是 RTO。
雙活架構（Active-Active）更進一步：兩個站點同時對外服務，主站發生災難時，備援站無感知地繼續服務，RTO 趨近於零，主機層完全不需要切換。
雙活的核心挑戰：腦裂（Split-brain）
雙活架構的最大風險是腦裂：兩個站點因為網路中斷而互相失去聯繫，各自以為對方故障，同時接受寫入，造成資料不一致。解決方案是引入第三個節點（Quorum / Witness），作為仲裁者決定誰有資格繼續服務。
IBM HyperSwap
IBM HyperSwap 是建立在 Metro Mirror 基礎上的雙活架構，主機看到的是單一 Volume，底層同時寫入兩個站點。站點故障時主機無感知，I/O 自動切換到存活站點。
- Quorum 機制：需要部署 Quorum 磁碟（Quorum Disk）或 Quorum 應用程式，作為第三個仲裁節點
- 距離限制：基於同步複製，距離通常限制在 300 km 以內（延遲需 < 2ms）
- SVC 版本要求：HyperSwap 需要 SVC 特定版本以上，且兩端 SVC 版本需相容
- 切換方式：主站故障時，SVC 自動切換 I/O 路徑，主機不需要重新掛載 Volume
| 品牌 | 雙活功能 | Quorum 機制 | 特色 |
|---|---|---|---|
| IBM SVC | HyperSwap | Quorum Disk / App | 基於 Metro Mirror，主機無感知切換 |
| Dell VPLEX | VPLEX Metro | Witness（雲端或本地） | 跨異構儲存設備雙活，Dell 生態強 |
| NetApp ONTAP | MetroCluster | Mediator | SAN + NAS 均支援，整合度高 |
| Everpure（Pure） | ActiveCluster | Mediator | 設定最簡單，Evergreen 整合 |
| HPE Alletra | Peer Persistence | Quorum Witness | 支援 VMware VAAI，vSphere 整合好 |
5.5 不可變備份（Safeguarded Copy 與同類產品）#
勒索軟體的威脅模型
傳統的 HA 和 DR 設計，都假設「資料本身是正確的，只是設備或站點出了問題」。勒索軟體改變了這個假設——攻擊者會主動加密資料，而且會針對備份和快照下手，讓傳統保護機制失效。
- 入侵系統，潛伏數週到數月，了解備份架構
- 刪除或加密 Snapshot 和備份資料
- 加密主要資料，索取贖金
Air-gap 與不可變備份的概念
應對勒索軟體需要「不可變（Immutable）」的備份：無論攻擊者取得多高的系統權限，都無法刪除或修改這些備份。實現方式有兩種：
- 物理 Air-gap：備份完成後將備份媒介（磁帶）物理離線，攻擊者無法透過網路存取
- 邏輯不可變（Logical Immutability）：備份資料寫入後，在設定的保留期間內任何人（包括系統管理員）都無法刪除，由儲存設備的韌體強制執行
IBM Safeguarded Copy
IBM Safeguarded Copy 是 IBM FlashSystem / SVC 的不可變快照功能。建立後在保留期間內無法被任何使用者或應用程式刪除，即使取得儲存設備的最高管理權限也無法繞過。
- 保留期間：可設定 1 天到數年，到期前任何刪除操作都被拒絕
- 觸發方式：可手動建立，也可排程自動建立（如每天建立一份，保留 30 天）
- 還原流程：發現勒索攻擊後，從 Safeguarded Copy 建立可讀寫的複本，確認資料完整後切換回服務
- 容量影響：每份 Safeguarded Copy 只記錄差異（Space-efficient），不佔用完整容量
| 品牌 | 不可變備份功能 | 機制 | 特色 |
|---|---|---|---|
| IBM | Safeguarded Copy | 邏輯不可變快照 | 韌體強制，管理員也無法刪除 |
| NetApp ONTAP | SnapLock | WORM（Write Once Read Many） | 符合 SEC 17a-4 等法規要求 |
| Dell PowerMax / PowerStore | Cyber Recovery / SnapVX | 隔離 Vault + 不可變快照 | Cyber Recovery Vault 物理隔離 |
| Everpure（Pure） | SafeMode | 管理平台層不可變 | Pure1 雲端控制，本地管理員無法關閉 |
| Cohesity / Rubrik | DataLock / Immutable Backup | 備份平台層不可變 | 獨立備份平台，不依賴主儲存 |
單一技術無法完整應對勒索軟體威脅，建議的分層防護：
- 端點防護（EDR）— 阻止攻擊者入侵
- 網路隔離 — 限制橫向移動
- 不可變快照（Safeguarded Copy 類）— 提供乾淨的還原點
- 離線備份（磁帶 Air-gap）— 最後防線，確保至少一份資料無法被網路攻擊