既然是寫給維運同行的資深戰友們，我們就不聊那些基礎的「外接硬碟」或「手動上傳」了。在 3 月 21 日世界備份日這天，我想針對現代分散式架構與高度自動化的環境，聊聊比經典 3-2-1 更進階、更能應對勒索軟體與大規模區域失效的 3-2-1-1-0 備份架構。
在 SRE 的視角裡，備份不只是資料的搬移，而是 RTO (復原時間目標) 與 RPO (復原點目標) 的極致追求。
🚀 從 3-2-1 演進至 3-2-1-1-0
傳統準則已不足以應對現代的「勒索軟體」與「同步污染」。身為資深人員，我們應追求：
1. 原本的「1」：進化為 Air-Gapped / Offline (物理隔離)
一般狀況下，一份異地存放的資料，就已經可以滿足大多數的安全需要。但是在某些高強度、高風險的環境中，單純的異地，還是不夠的。如果是純雲端的環境，這意味著需要完全獨立的備份帳號 (Vault Account)，與生產環境（Production）做物理或邏輯上的嚴格隔離，甚至不建立任何常態性的網路連線，僅在備份視窗透過受控的 API Trigger 進行傳輸。
2. 額外的「1」：Immutable Offsite Storage (不可變異地存儲)
除了異地備份，這份副本必須是不可變 (Immutable) 的。利用 S3 Object Lock (Compliance mode) 或 WORM 檔案系統，確保在特定時間內，即使是擁有 Root 權限的帳號也無法刪除或修改備份。這是應對勒索軟體橫向移動後的最後一道防線。
3. 關鍵的「0」：Zero Errors (零錯誤驗證)
這是 DevOps 的精髓：Automated Recovery Validation。
備份完成後，必須自動觸發 CI 流程，在隔離環境（Sandboxed environment）中自動掛載備份、啟動服務並通過 Health Check。沒有通過自動化還原測試的備份，其可靠性應視為 0。
🛠️ DevOps 進階實踐清單
● Infrastructure as Code (IaC) 的一致性
備份不只是 Data，還包含 State 與 Config。確保你的備份包含所有 Terraform 狀態檔、K8s Manifests 與 Secret 管理邏輯。若環境無法從代碼一鍵重建，備份再多 Data 也是徒勞。
● 跨區域 (Cross-Region) 與跨雲備份
針對 CSP (Cloud Service Provider) 的區域性大停擺（Regional Outage），應配置跨區域複製（CRR）。針對極端情況，重要 Metadata 甚至應考慮跨雲存儲（如 AWS 備份至 Azure Blob）。
● 定期進行災難演習 (Chaos Engineering)
不要等真的出事才翻文件。將「還原演習」納入年度或季度的災難演練計畫中，驗證在失去核心資料庫時，團隊可以即時應變與系統的自動切換資料來源路徑。
備份策略矩陣 (DevOps Edition)
希望這套進階準則能讓各位維運夥伴們的夜晚可以睡得更安穩。如果你在實踐 Immutable Backup 或 Cross-Account Vault 有更好的架構設計，歡迎在留言區分享你的看法！
從3-2-1到3-2-1-1-0
#WorldBackupDay #DevOps #SRE #DataResiliency #32110Rule
