在前面的章節中，我們討論的焦點大多集中在機密性（C）與完整性（I）——例如防止資料外洩與阻止未授權的篡改。然而，資安三要素中的最後一個——可用性（Availability），卻往往是企業在面對災害、勒索軟體或硬體故障時最直接的生命線。

當伺服器突然硬碟壞軌、資料中心大淹水，或是營運資料庫遭勒索軟體加密時，團隊能在多久時間內讓服務重啟？又會損失多少筆交易資料？這就是營運持續計畫（BCP）與備援機制要解決的核心課題。

什麼是 BCP、RTO 與 RPO？

提到營運中斷風險就一定要知道BCP、RTO 與 RPO

• RTO (Recovery Time Objective, 復原時間目標)：
  從災害發生（服務中斷）到系統完全恢復正常服務所能容忍的最大時間 limit。RTO 越短，代表服務必須越快拉起來（例如 RTO < 15 分鐘）。
• RPO (Recovery Point Objective, 復原點目標)：
  系統復原後，資料可以容忍丟失的最大時間跨度。這取決於你的資料備份頻率（例如每日備份一次，RPO 就是 24 小時；即時同步備份，RPO 趨近於 0）。
• BCP (Business Continuity Plan, 營運持續計畫)：
  企業面臨重大災害（如地震、資安入侵、主要機房停電）時，確保核心業務不中斷或能迅速恢復運作的全盤策略與標準作業流程（SOP）。

核心原理與危害：常見的備援機制漏洞

許多團隊看似有做備份與備援，但在真實災害發生時，系統卻依然全面崩潰。常見的漏洞包含：

• RTO / RPO 估算錯誤或未與業務部門對齊：
  IT 團隊以為「每天半夜 12 點備份一次」就夠了，但在營運高峰期的下午 5 點資料庫損壞時，意味著今天整整 17 個小時的訂單資料全數消失（RPO = 17 小時），企業根本無法承受。

• 「冷備份（Cold Standby）」沒有演練，導致 RTO 爆炸：
  以為只要有備份檔存在雲端就好，等到系統崩潰時，才發現光是下載好幾 TB 的備份檔、重新設定伺服器環境、安裝套件與驗證資料，就花了整整很多天，RTO 遠超預期。

• 備份檔遭到連帶加密（備份未隔離）：
  在勒索軟體攻擊中，攻擊者進入內網後，會先尋找掛載在同一個網域內的備份伺服器並將備份檔加密或刪除。沒有隔離的備份等於沒有備份。

實務情境

情境：資料庫備份與災難復原設計

無備份隔離、無監控與未演練

# 錯誤：簡單的 crontab 每日備份，備份檔直接存在同一台主機或無權限隔離的本地 NAS 上
0 2 * * * pg_dump -U postgres company_db > /mnt/nas/backup/db_backup.sql

# 危害：
# 1. 備份檔與正式環境同網域，一旦主機遭勒索軟體橫向移動攻陷，備份一併被刪除。
# 2. 只有備份腳本，完全沒有驗證備份檔是否損壞或完整（即備份寂靜失效）。
# 3. 未實施備份還原演練，還原步驟全憑工程師記憶。

3-2-1 備份原則 + 離線不可變備份 + 演練

# 正確：備份檔自動上傳至具備「不可變性 (Immutability / Object Lock)」的異地雲端空間
# 搭配腳本執行完後自動觸發離線備份與資安告警機制

# 1. 執行本地備份並加上雜湊驗證 (Integrity Check)
pg_dump -U app_backup -h localhost company_db | gzip > /tmp/db_$(date +%Y%m%d_%H%M%S).sql.gz

# 2. 使用具備 Write-Once-Read-Many (WORM) 功能的 S3 Object Lock 上傳異地
aws s3 cp /tmp/db_*.sql.gz s3://isolated-dr-backup-bucket/ --object-lock-mode COMPLIANCE --object-lock-retain-until-date "2026-12-31T00:00:00Z"

# 3. 備份完成後寄送健康狀態 Log 至獨立監控平台，並抹除本地暫存檔

如何正確建構高效能的復原機制？

1.落實「3-2-1 備份原則」

• 3： 至少保存 3 份資料（1 份正式資料 + 2 份備份）。
• 2： 使用 2 種不同的儲存媒介。
• 1： 至少有 1 份放在異地，且該異地備份必須實施隔離。

2. 區分備援層級（Hot / Warm / Cold Standby）

• Hot Standby (熱備援)
• Warm Standby (溫備援)
• Cold Standby (冷備援)

3. 定期進行災難復原演練