Gardener Backup Restore – Cross‑Provider Targeting Not Supported
0 reputation · 17 Sept 2021, 04:56 UTC
Goal and Constraints
The objective is to restore a Gardener backup to a cluster that uses a different control‑plane provider or is located in another region. Gardener’s backup feature creates a full etcd snapshot and stores it in an object‑storage bucket. The snapshot is tied to the original infrastructure configuration, and the restore operation can only target a freshly created cluster; it cannot be applied to an existing cluster or to a cluster on a different provider.
Verification Gap
Gardener records an MD5/SHA checksum in the backup metadata, but it does not automatically validate that the restored etcd data matches the original snapshot. Additionally, there is no built‑in mechanism to confirm that all cluster resources (Secrets, ConfigMaps, etc.) are present after restoration.
Unresolved Decision
Whether Gardener should allow restoring a backup to a cluster on an alternative provider or region remains an open design question. This limitation could lead to orphaned resources or API incompatibilities if a cross‑provider restore is attempted.
Questions
- What changes to the Gardener restore workflow would be required to enable targeting clusters on different control‑plane providers or regions?
- How can a checksum verification step be incorporated into the restore process to ensure data integrity without manual intervention?
- What mechanisms could be added to automatically verify that all cluster resources are present and correctly reconciled after a restore?
