Kubernetes (kubo-deployment) backup is using the BBR. The backup contains only the ETCD database: https://github.com/cloudfoundry-incubator/cfcr-etcd-release/tree/master/jobs/bbr-etcd
For the time of the restore the
kube-apiserver is temporarily stopped: https://github.com/cloudfoundry-incubator/kubo-release/tree/master/jobs/bbr-kube-apiserver/templates.
In general backing up the ETCD is the easiest and the only possible way to backup the Kubernetes cluster. It does come with certain risk on restore operation when the cluster on which restore is done is very different to the backup source cluster. The database does not only contain information about workloads, but also cluster configuration: tokens, secrets, certificates, registered nodes IP addresses, DNS cache.
This issue is explained more deeply here: https://github.com/cloudfoundry-incubator/kubo-release/issues/288
The recomended solution for that risk is to follow
git ops approach, when the state of the cluster can be quickly restored using preconfigured yaml files and CI/CD pipeline. It does not only mitigate the risk with cluster not being fully stable after the restore (if one of the risks described above occurs), but also allows to restore or move the workloads to different cluster.