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 latter case, you can choose an existing cluster, or create a new one in any cloud provider account that 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.
In the Source Cluster step, select the cluster to restore.
Tip
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 can choose which resources to restore using the following options. You can also set several advanced options related to restore performance.
- 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.
- Choose whether to restore all cluster-scoped resources
If anything other than “Full cluster” was selected for restore (i.e. namespaces were selected or excluded), you will be given the option to include all cluster-scoped resources. If selected, the system will attempt to restore all cluster-scoped resources. Otherwise, only cluster-scoped resources associated with selected resources (e.g. PVs associated with PVCs) will be restored
- 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. You can also toggle the “Exclude” option to restore all resource types except for the selected types. “Include” is the default.
- Include all cluster-scoped resources
If enabled, the system will attempt to restore all cluster-scoped resources. Otherwise, only cluster-scoped resources associated with selected resources (e.g. PVs associated with PVCs) will be restored. Full cluster restores aways restore all cluster-scoped resources, but when selected namespaces are being restores this is optional. This option defaults to off. This option is only shown if full cluster restore has not been selected (i.e. namespaces are selected or excluded).
- Exclude Persistent Volumes
Select this option to skip restoring persistent volumes.
Tip
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.
Tip
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 usually be necessary. Note that these options are available only when restoring from object storage, not when restoring from snapshots.
- Concurrent PVs
Select the maximum number of PVs that will be restored up at once. The allowed range is between 1 and 16. The default is 2 PVs.
- Total Concurrent files
Sets the number of files that will be restored concurrently across ALL PVs. The default is 24.
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).
- Max transfer rate per PV
Specifies the maximum transfer rate for the data transfer between each PV and the destination storage during the backup job, in MB per second. Leave this field blank to set no limit. The default value “Unlimited”.
- Data mover pod timeout
Time that the agent will wait for the data mover pod to start. The default is 15 minutes. This should only need to be changed from the default in special cases.
- 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 1024 MB.
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 one or more cloud accounts have been registered.
See also
For options associated with creating a new cluster, see Creating Clusters With CloudCasa.
In the Restore Transforms step, you can choose transformations that will be applied during 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.
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.
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.