{"id":1467,"date":"2023-05-23T10:27:38","date_gmt":"2023-05-23T10:27:38","guid":{"rendered":"http:\/\/patriciocerda.com\/?p=1467"},"modified":"2023-05-26T09:54:34","modified_gmt":"2023-05-26T09:54:34","slug":"openshift-etcd-backup-and-restore-with-kasten-k10","status":"publish","type":"post","link":"https:\/\/patriciocerda.com\/?p=1467","title":{"rendered":"OpenShift ETCD backup and Restore with Kasten K10 – Part 1"},"content":{"rendered":"

Hi all and welcome back.\u00a0 In this blog post I\u2019ll talk about the need (or not) of backing up ETCD in a Kubernetes cluster, and how to do it.<\/p>\n

Kubernetes is an orchestration tool whose tasks involve managing application container workloads, their configuration, deployments, service discovery, load balancing, scheduling, scaling, and monitoring, and many more tasks which might spread across multiple machines across many locations. Kubernetes needs to maintain coordination between all the components involved.<\/p>\n

To achieve that coordination, Kubernetes needs a data store that can help with the information about all the components, their required configuration, state data, etc. \u00a0\u00a0In Kubernetes, that job is done by ETCD. \u00a0\u00a0ETCD is a key-value data store used to store and manage the critical information that distributed systems need for their operations. It provides a reliable way of storing the configuration data.<\/p>\n

So, in simple words, in a Kubernetes cluster, the expected state for every Kubernetes component (Pods, Deployments, Secrets, PVCs, etc), is stored in the ETCD instance running in the Kubernetes Control Plane.<\/p>\n

So, in theory we could just backup this ETCD instance to protect the entire cluster and being able to restore it whenever it\u2019s necessary.\u00a0\u00a0 This could be correct, but it\u2019s not the best approach for a Data Protection and Disaster Recovery strategy for multiple reasons such as:<\/p>\n