關於 kubernetes disaster recovery ，我們在網路上蒐集到這些相關的討論、資訊與評價

ref: https://blog.devgenius.io/disaster-recovery-on-kubernetes-98c5c78382bb

作者認為即使那些知名的託管K8s服務(AKS/EKS/GKE)本身有提供各種機制來強化系統的存取性，但是作為一個正式生產環境的 Kubernetes 勢必還是要有一套災難復原的機制，因為有些災難並不是底層架構導致，有可能是人員的操作錯誤導致叢集內發生問題(譬如刪除整個 namespace).

隨者愈來愈多的團隊會將跨地區當作解決方案的一個考量時，要如何能夠找到一個簡單的備份還原機制來面對 Kubernetes 則是一個複雜的問題。 而本篇文章將會探討如何使用 Velero 來針對 Kubernetes 叢集進行備份，還原甚至是災難復原等操作，透過這類型的機制實際上也可以做到遷移 Kubernetes 叢集。

文章開頭作者提出了一個很值得注意的論點，就是高可用性(HA)的環境並不代表該環境擁有備份與還原機制。

HA 用來確保單一底層架構出現問題時整體服務不受影響，還是有能夠繼續存取既有的服務。但是假如遇到資料損毀或是其他意外刪除的，HA 的機制並沒有辦法讓這些服務可以復原。

所以就算系統是運行到 HA 的環境下，對於備份相關的解決方案還是需要準備，而且最重要的是這類型的解決方案不能只有準備，而是需要真的練習，嘗試復原，確保團隊熟悉整個還原的步驟，否則當問題發生時有可能會變成不知道要如何從備份資料來進行有效還原。

文章後半部分探討關於 Velero 的架構與使用，同時也列舉其他相關的專案，如

kube-backup
Cohesity
Kasten 10
Portworx PX-Backup]
Rancher Longhorn

對於 Kubernetes 備份還不熟悉或是團隊尚未導入的讀者可以嘗試使用看看 Velero

#備份 #Velero #etcd

今天這篇文章是作者分享其維運 Kubernetes 叢集中關於備份還原的經驗
對於 Kubernetes 來說，其控制平面由幾大元件組成，分別是 API Server, Controller, Scheduler 以及 ETCD。其中的 Controller 更是整個叢集狀態維護的推手，使用者透過各種方式，不論是 API，Yaml 或是其他方式來新增資源，其實背後的深層目的都是告訴 Controller，我想要達到什麼狀態，而 Controller 透過永無止盡的迴圈與檢查，確保叢集當前的狀態可以符合使用者預期的狀態。

作者工作的經驗中，遇到了想要對 Kubernetes 進行備份與還原的需求，因此思考如何將所有運行狀態的資源狀態給取出，並且當還原時可以將前述備份的資料都寫回去。

作者這邊採用的是一個名為 Velero 的開源工具，透過該工具去還原與備份 Kubernetes ETCD 的資料，並且可以將資料給同步到遠方的儲存空間，譬如 S3, GCS 等

如果對於 ETCD 的備份與還原有興趣的人，可以參考這篇文章，看看別人用 Velero 這個工具來處理，同時也可以想想目前團隊中有沒有這方面的解決方案

https://adrafiq-52.medium.com/kubernetes-backup-and-disaster-recovery-88d6cb8c5bf7