Restore CAPI cluster objects in a better order

Restoring CAPI workload clusters without this ordering caused the
capi-controller-manager code to panic, resulting in an unhealthy cluster
state.

This can be worked around
(https://community.pivotal.io/s/article/5000e00001pJyN41611954332537?language=en_US),
but we provide the inclusion of these resources as a default in order to
provide a better out-of-the-box experience.

Signed-off-by: Nolan Brubaker <brubakern@vmware.com>

pkg/cmd/server/server.go

@@ -444,6 +444,9 @@ func (s *server) veleroResourcesExist() error {
 //	 have restic restores run before controllers adopt the pods.
 // - Replica sets go before deployments/other controllers so they can be explicitly
 //	 restored and be adopted by controllers.
+// - CAPI Clusters come before ClusterResourceSets because failing to do so means the CAPI controller-manager will panic.
+//	 Both Clusters and ClusterResourceSets need to come before ClusterResourceSetBinding in order to properly restore workload clusters.
+//   See https://github.com/kubernetes-sigs/cluster-api/issues/4105
 var defaultRestorePriorities = []string{
 	"customresourcedefinitions",
 	"namespaces",
@@ -463,6 +466,8 @@ var defaultRestorePriorities = []string{
 	// to ensure that we prioritize restoring from "apps" too, since this is how they're stored
 	// in the backup.
 	"replicasets.apps",
+	"clusters.cluster.x-k8s.io",
+	"clusterresourcesets.addons.cluster.x-k8s.io",
 }
 
 func (s *server) initRestic() error {