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 initiated from many places in the UI, including: Clusters/Restores, Clusters/Recovery Points, Clusters/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.

  1. In the Source Cluster step, select the cluster to restore.


    You can choose only one cluster for each restore job.

  2. 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.

  3. 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.


    Resources which already exist in the destination cluster will by default not be overwritten. See the Overwrite existing resources option below.

    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.

  4. 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.

    See also

    If you wish to automatically create a new cluster, see Creating Clusters With CloudCasa.

  5. 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. It will do this by attempting to update existing resources to match the corresponding resources from the backup. This update is subject to resource update semantics. For example, pod resources don’t allow updates, but most others do. Any resources that cannot be updated will generate a warning in the restore log.

    Also note that for existing PVCs, the contents of the PVs will not be modified even if this option is selected.

    By default, existing resources will not be overwritten. The exception to this is ServiceAccount resources. Resource data from backed up ServiceAccounts will be merged into existing ServiceAccounts regardless of the overwrite setting.

  6. 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.

  7. 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.

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.