Backaps和災難恢復

Bacaps和Disaster Recovery

1）定義和目標

備份是用於後續恢復的數據/配置的統一副本（來自隨機刪除，錯誤，密碼處理器，災難）。
DR（災難恢復）是在發生重大事故（火災，區域損失，大規模破壞）後將基礎設施/服務恢復到SLO工人的過程。
RPO（恢復點目標）-時間允許的最大數據丟失（例如15分鐘）。
RTO（恢復時間目標）-服務恢復時間目標（例如30分鐘）。

關鍵原則：復制≠備份。復制可以快速「塗抹」所有副本的錯誤和加密。備份是一個孤立的，經過驗證的，可能不變的副本。

2）數據分類和臨界水平

• Tier-0（重要）：交易數據庫、付款、資產負債表會計、秘密/PKI。
• Tier-1（關鍵）：服務組合，隊列，CI/CD工件，容器註冊表。
• Tier-2（重要）：分析、報告、次索引、日誌歸檔。
• Tier-3（輔助）：緩存、時間數據（可以通過重建恢復）。

對於每個類,定義RPO/RTO、保留期、不變性要求和位置。

3）存儲策略： 規則3-2-1-1-0

3份數據副本（prod+2備份）。
2種不同的介質/存儲類型。
1份官方站點副本（其他區域/雲）。

1 immutable/air-gap (WORM/Object Lock/Tape).

恢復檢查（常規測試）中有0個錯誤。

4）備用類型

Full是完整副本。緩慢/昂貴，但所有策略的基礎。
Incremental-與最後一個備份的區別。最佳體積。
Differential-與最後一個完全不同。恢復速度更快，空間更多。
Snapshot是卷/磁盤的即時映射（EBS/ZFS/LVM）。需要App consistent snapshots （quiesce）。
PITR（點對點恢復）是用於回滾到精確時間/LSN的基本備份+雜誌（WAL/binlog）。
對象/文件/圖形-適用於特定數據類型（VM映像、S3對象、DB轉儲）。

5）備用的一致性

Crash-consistent：突然關閉後如何-適合無狀態/可日誌化的FS。
應用程序一致性：應用程序「凍結」操作（fsfreeze/pre-post scripts） →保證完整性。
DB一致性：備份工具API （pgBackRest, XtraBackup）,熱備份模式,檢查點凍結。

6）加密、密鑰和訪問

對所有副本進行at rest和in transit加密。
KMS/HSM中的密鑰，按策略輪換（90/180天），按周圍環境分開的密鑰。
職責劃分：誰創建/刪除備份≠誰可以解密/讀取它們。
不要在與目標副本相同的信任域中保留解密密鑰。

7）不可更改的副本和ransomware保護

Object Lock/WORM （Compliance/Governance）帶有還原和法律保留。
空中差距：隔離/離線存儲（磁帶、離線雲/帳戶）。
「延遲激活」刪除策略，MFA-Delete，備份箱的獨立帳戶，禁止公眾訪問。
在安裝前對惡意軟件/損害指標進行驗證。

8）頻率，時間表和重播

GFS（Grandfather-Father-Son）：白天增量，每周滿員/多夫，每月滿員，長期存儲。
RPO規定了增量和WAL/binlog存檔的頻率（例如，每5-15分鐘）。
存儲：關鍵-≥ 35-90天+每月12-36個月（法律要求）。
季節性高峰是單獨的控制點（在促銷/發行之前）。

9） DR模型和腳本

Active-Active：兩個區域都為流量服務。最小的RTO，數據捕獲需要嚴格的沖突策略。
Active-Passive（熱/熱）：熱-展開和同步（RTO分鐘）,熱-部分準備（RTO時鐘）。
冷：存儲副本和Terraform/Ansible/映像,我們按需提起（RTO 24+）。
DRaaS：其他區域的VM/網絡/地址提供商編排。

10）failover編排和恢復優先事項

啟動優先級：網絡/VPN/DNS → 秘密/KMS →基地/群集→ 隊列/kesh →應用程序→ 外圍/CDN →分析。
自動化：腳本/運行手冊操作,Terraform/Ansible/Helm/ArgoCD的DR環境配置文件。
數據：DB PITR → reindex/replica → warm緩存→啟動帶有電路兼容性標誌的服務。
DNS/GSLB：提前TTL降級,驗證切換方案。

11）恢復測試（備份驗證）

定時還原測試：N%後備樣本、「沙箱」部署、電路自動驗證/不變量。
完整的DR-drill（遊戲日）：禁用區域/AZ、RTO/RPO檢查實時流量（或陰影流量）。
完整性測試：哈希目錄、校驗和,嘗試讀取所有圖層（full+chain）。
基準報告：時間、步驟、異常、目標差距大小、修復。

12）核心技術的實踐

數據庫

PostgreSQL：基於backup+WAL歸檔（PITR），pgBackRest/Barman工具；復制插槽，「lsn」控制。
MySQL/MariaDB：Percona XtraBackup/Enterprise Backup，binlog存檔。
MongoDB：用於邏輯拷貝+大型集合snapshot的「mongodump」；PITR的Oplog。
Redis：關鍵的RDB/AOF（如果Redis不僅是kesh），而且更常見的是從原點+snapshot進行邏輯重建以應對事故。
Kafka/Pulsar：元數據備份（ZK/Kraft/BookKeeper），磁盤快照，拓撲/標誌鏡像。

Kubernetes

用於資源/卷的etcd snapshot+Velero（CSI snapshots）。
秘密備份/PKI分開（Vault snapshot）。
單獨的映像註冊表：文物存儲策略（immutable tags）。

VM和文件系統

ZFS：「zfs snapshot」+「zfs send | zstd | send-recv」增量，檢查「scrub」。
LVM/EBS快照，帶有前/後腳本（app-consistent）。
對象存儲：版本+對象鎖。

13）對備份版本進行編目和控制

目錄（元數據編目）：何處、何時完成哈希、KMS密鑰、所有者、保留期。

Метки/теги: `env=prod|stage`, `system=db|k8s|vm`, `tier=0|1|2`, `retention=35d|1y`.

金色檢查點（Gold）： 在遷移/DDL/大規模發布之前。

14）可觀察性和指標

工作成功率：成功率/被淹沒率，原因。
備份/恢復時間，窗口寬度。
RPO事實：期刊檔案（WAL/binlog）p95。
完整性：驗證鏈的比例,哈希對賬錯誤。
成本：按類存儲量、重復數據消除/壓縮比。
DR準備：演習的頻率和結果（通過/失敗）。

15）訪問策略和合規性

備用存儲的單獨帳戶/項目；基於NaC原理的訪問（不允許從prod帳戶中刪除/加密）。
訪問/更改邏輯（audit trail），大規模刪除/重復更改的差異。
法規遵從性：GDPR（刪除權vs歸檔），PCI DSS（加密，密鑰和細分），本地監管機構。

16）反模式

「有復制品-這意味著不需要備份。」

沒有immutable/air-gap： 一個錯誤/verodonos擦除一切。
Backaps與prod位於同一帳戶/區域。
從不檢查恢復（備份「在驗證之前就已死亡」）。
沒有編目和版本控制→事故中的混亂。
所有環境共享加密密鑰。
沒有DB應用程序一致模式的snapshots。
後備窗口與峰重疊（影響p99和SLO）。

17）實施清單（0-60天）

0-10天

系統/數據清單，臨界類。
按等級列出RPO/RTO目標。
啟用full+incremental for Tier-0/1，WAL/binlog存檔。
釋放備份：一個單獨的區域/帳戶+啟用KMS加密。

11-30天

為關鍵副本配置可變性（Object Lock/WORM）。
輸入編目，標簽，報告；等於日記的失誤和失誤。
第一個DR-drill：在孤立的環境中恢復單獨的後備服務。

31-60天

自動化運行手冊：Terraform/Ansible/Helm DR配置文件。
定期還原測試（每周/每月）+季度full DR腳本。
優化成本：重復數據消除/壓縮/存儲生命周期。

18）成熟度量

還原測試：≥ 1/ned for Tier-0（有選擇），≥ 1/mes-完整腳本。

Immutable coverage для Tier-0/1 = 100%.

RPO實際p95 ≤目標（例如，≤ 15分鐘）。
DR演習≤目標的RTO實際（例如，≤ 30分鐘）。
編譯目錄=100％（描述並驗證了每個備份）。
事件恢復：從檢測到啟動恢復的時間。

19）示例（snippets）

bash base backup once a day pgbackrest --stanza = prod --type = full backup archive WAL every 5 minutes pgbackrest --stanza = prod archive-push restore to time pgbackrest --stanza = prod restore --type = time --target =" 2025-11-03 14:00:00 + 02"

bash xtrabackup --backup --target-dir=/backup/full-2025-11-01 xtrabackup --backup --incremental-basedir=/backup/full-2025-11-01 --target-dir=/backup/inc-2025-11-02 xtrabackup --prepare --apply-log-only --target-dir=/backup/full-2025-11-01 xtrabackup --prepare --target-dir=/backup/full-2025-11-01 --incremental-dir=/backup/inc-2025-11-02

yaml apiVersion: velero. io/v1 kind: Backup metadata: { name: prod-daily }
spec:
includedNamespaces: ["prod-"]
ttl: 720h storageLocation: s3-immutable

json
{
"Rules": [{
"ID": "prod-immutable",
"Status": "Enabled",
"NoncurrentVersionExpiration": { "NoncurrentDays": 365 }
}]
}

20）通信和運營角色

Incident Commander, Comms Lead, Ops Lead, DB Lead, Security.

Stakholder/調節器/用戶的消息模板。
後遺癥與動作：他們失去了分鐘，在哪裏可以改善自動化。

21）結論

可靠的備份和DR回路不是"復制"，而是循環：RPO/RTO的分類→目標→多級和可修改的副本→自動運行手冊"，並→定期的恢復和練習。堅持3-2-1-1-0，將復制與備份分開，加密和隔離密鑰，記錄和驗證。然後，即使是「黑天鵝」也將變成一個可控制的過程，可預測的停機時間和最低的數據丟失。