Cluster Restore Wizard
The Restore Cluster wizard allows you to create and run a Kubernetes cluster restore definition. The data can be restored to the source cluster or to a different cluster. In the case of latter, you can choose an existing cluster or create a new one in any cloud provider account you have registered with CloudCasa.
The Restore Cluster wizard can be reached from many places in the UI, including: Protection/Restores, Protection/Recovery Points, Protection/Backups, the Cluster dashboard, the Cluster dashboard backups, restores, & recovery points tabs, and the Dashboard “Cluster Backups” tab.
Restoring a Kubernetes backup
Depending on how you reached the Restore Cluster wizard, the source cluster and recovery point may already be selected for you.
In the Source Cluster step, select the cluster to restore.
You can choose only one cluster for each restore job.
In the Recovery Point step, select a recovery point from the list. You can use filters and sorting to help you to quickly find the best one.
In the Select Resources step, you will choose which resources to restore.
- Select namespaces to restore
Select All Protected Namespaces to restore resources in all namespaces. Choose Select Namespaces in order to to include specific namespaces. Note that only namespaces which were included in the backup will be displayed. If you choose All Protected Namespaces, you can select the Exclude namespaces option to exclude specific namespaces from the restore.
- Select labels (optional)
Leave this this option off to restore all resources regardless of their labels. Enable it to selectively restore resources based on their labels by entering key-value pairs, for example, “product: life-insurance”.
- Select resource types (optional)
Leave this option off to restore all resources regardless of type. Enable it to select one or more resource types to restore. You can select common resource types from the drop-down list, or type in the names of custom resources.
- Exclude Persistent Volumes
Select this option to skip restoring persistent volumes.
Note that the filters applied by this page are additive. For example, if you select namespace “alpha”, select label “color:red” and select resource type “secret”, only resources from namespace alpha with the type secret and having the label “color:red” will be restored. Also note that resources which already exist in the destination cluster will not be overwritten.
- Advanced Options
Opening the Advanced options section will allow you to set the following options. Modifying these settings from the defaults should not be necessary in most cases.
- Concurrent streams
The number of PVs, and the number of files in each PV, that will be restored in parallel. By default, 2 PVs and 8 files per PV will be restored in parallel. The maximum values that can be set are 16 PVs and 32 files per PV. Increasing parallelism can increase the speed of the restore at the expense of more memory and bandwidth usage. Using large values may necessitate increasing the Data mover memory limit (see below).
- Data mover memory limit
The maximum amount of memory in MB that the data mover pod will be permitted to allocate during the restore process. This limit is set in order to protect the cluster. If the mover pod exceeds this limit, the pod will be killed and the restore will fail. The allowed range is 512MB to 8GB, with a default of 768MB.
Click Next to proceed.
In the Destination step, select the destination cluster for the restore:
- Select destination
By default, your cluster resources will be restored to the same cluster from which the backup was taken. You can select another registered cluster as the destination, or automatically create a new EKS, AKS, or GKE cluster if a cloud account has been registered. If you wish to automatically create a new cluster, see the Creating a new cluster during restore section below.
In the Restore Transforms step, you can choose transformations that will be applied to the restore. These include:
- Rename Namespaces
Enabling this option will allow you to rename restored namespaces by either adding a prefix and/or suffix, or applying a mapping.
- Add prefix/postfix
Add a prefix or postfix to the restored namespace(s). For example, if there were namespaces “sales” and “services” in the original cluster and you add a suffix, “-dev”, to the namespaces, the restore job will create the namespaces “sales-dev” and “services-dev” in the destination cluster.
- Set new names
This allows you to create a set of mappings from old namespace names to new namespace names. Names left unmapped will be restored unchanged.
- Change Storage Classes
Gives you the option to remap storage classes at restore time. When selected, the UI will display the storage classes used by PVs/PVCs in the backup, and allow you to enter new storage classes to substitute for each during the restore. By default, the same storage classes will be used.
Make sure that a target storage class is compatible with the source storage class with regards to properties such as supported access modes. Note that this option is only available for restores of copy backups, not snapshot backups.
- Preserve node ports
If selected, automatically assigned node ports for services in the source cluster will be preserved upon restore. Make sure that these ports are available in the target cluster.
Note that any manually assigned node ports are not affected by this option and are always preserved on restore.
- Overwrite existing resources
Enabling this option will cause the restore to overwrite existing Kubernetes resources. By default, existing resources will not be overwritten.
In the App Hooks step, you can add specify application hooks used to invoke application-specific commands after PVs have been restored. For more information about this feature, see App Hooks.
In the Summary step, you can review the summary of the new cluster restoration job. You must also enter a name for the job here, which will be used to identify it in the activity view and on the restores page.
Click Restore to create the new cluster restore job.
Creating a new cluster during restore
A restore can be performed to an existing cluster or to a new cluster created by CloudCasa. If the “Create new cluster” option is selected when selecting a destination, you will be presented the options to create an EKS, AKS, or GKE cluster during the restore job.
Select the cloud account that will be used to create the cluster.
The option for each cloud cluster type will only be available if the related cloud account has been registered with CloudCasa.
Click Next to update the configuration for the new cloud cluster. If restoring to the same cloud account as the source cluster, some fields will be automatically filled with the configuration stored in the backup. During the restore job, CloudCasa will first create the cluster using parameters from the backup and the configuration provided and then proceed with restoring the Kubernetes resources and any persistent data. The parameters required to create the cluster may be different for each cloud provider:
Creating an AWS EKS cluster
The following fields are used by CloudCasa to create an EKS cluster on AWS:
Cluster name: the name for the newly created cluster. This must be a name unique to the AWS region.
AWS user: the user that will have access to this cluster once the restore is complete.
Region: the AWS region where this EKS cluster will be created.
EKS Cluster IAM role: the IAM role that will allow the cluster to make calls to other AWS services.
For information on how to find or create an EKS cluster IAM role see:
VPC Configuration: Select the VPC and subnet groups which will be used by the EKS cluster. Also select any security groups to associate with the cluster, or leave this field empty to allow Amazon EKS to create a security group for you.
Node Pools Config: the configuration for each EKS node group. Click Add Node Pool to create nodes of different configurations.
Node IAM role: the IAM role that will allow the cluster nodes to make calls to other AWS services.
For information on how to find or create an EKS node IAM role see:
VM Size: the instance type to use for each node.
For view a list of all the available instance types see:
TMP Disk Size (system): the root device disk size (in GiB) for each node.
Worker node auto-scaling: the minimum, maximum, and desired number of nodes for this configuration.
Creating an Azure AKS cluster
The following fields are used by CloudCasa to create an AKS cluster on Azure:
Cluster name: the name for the newly created cluster.
Resource group: select an Azure resource group that will be associated with the cluster.
Region: the Azure region where this AKS cluster will be created.
Client ID: the client ID credential used when creating the AKS cluster.
Client Secret: the client secret credential used when creating the AKS cluster.
Node Pools Config: the configuration for each AKS node pool. Click Add Node Pool to create nodes of different configurations.
VM Size: the VM size to be used by each node.
For view a list of all the available VM sizes see:
Node pool mode: can be set to either “system”, to host critical system pods, or “user” for general applications.
Node count: the number of nodes to be created by this node pool configuration.
Restoring a Kubernetes Velero backup
Defining a Velero restore job using CloudCasa for Velero is nearly identical to the above procedure. The differences are the following:
In the Select Resources step, the additional option “Include cluster scoped resources” is provided.
In the Destination step, you must select either the original cluster or “Create new cluster”. Restores to alternate existing clusters are not supported.
In the Summary step, the Edit YAML button allows you to edit the YAML for the restore definition before saving it.
You cannot edit existing restore jobs.