Documentation for version v0.11.0 is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the latest version.
Etcd’s backup/restore tooling is good for recovering from data loss in a single etcd cluster. For example, it is a good idea to take a backup of etcd prior to upgrading etcd itself. For more sophisticated management of your Kubernetes cluster backups and restores, we feel that Velero is generally a better approach. It gives you the ability to throw away an unstable cluster and restore your Kubernetes resources and data into a new cluster, which you can’t do easily just by backing up and restoring etcd.
Examples of cases where Velero is useful:
Yes, with some exceptions. For example, when Velero restores pods it deletes the nodeName
from the
pod so that it can be scheduled onto a new node. You can see some more examples of the differences
in
pod_action.go
We strongly recommend that you use a separate bucket per cluster to store backups. Sharing a bucket across multiple Velero instances can lead to numerous problems - failed backups, overwritten backups, inadvertently deleted backups, etc., all of which can be avoided by using a separate bucket per Velero instance.
Related to this, if you need to restore a backup from cluster A into cluster B, please use restore-only
mode in cluster B’s Velero instance (via the --restore-only
flag on the velero server
command specified
in your Velero deployment) while it’s configured to use cluster A’s bucket. This will ensure no
new backups are created, and no existing backups are deleted or overwritten.
To help you get started, see the documentation.