The integrated backup and restore capability uses Velero as the engine. Please review the considerations below to understand constraints and limitations to help with your design and planning.
Objects that already exist in the Kubernetes cluster will not be overwritten.
Only a single set of credentials per provider are supported.
Volume snapshots are limited by where your provider allows you to create snapshots. For example, AWS and Azure do not allow you to create a volume snapshot in a different region than where the volume is located.
It is not yet possible to send a single backup to multiple backup storage locations at the same time, or a single volume snapshot to multiple locations simultaneously. However, users can set up multiple backups manually or schedules that differ only in the storage locations.
Cross-provider snapshots are not supported. For example, if you have a cluster with more than one type of volume (e.g. NFS and Ceph), but you only have a volume snapshot location configured for NFS, then snapshots will be taken only for the NFS volumes.
Restic data is stored under a prefix/subdirectory of the main Velero bucket and will go into the bucket corresponding backup storage location selected by the user at backup creation time.
For recovery, ensure that the Kubernetes version is exactly the same as the original cluster.
When performing cluster migration, the new cluster number of nodes should be equal or greater than the original cluster.