CloudCasa for Velero Restore Guide

When you need to do a Velero restore, you may not be having a very good day and you are likely to be in a hurry. CloudCasa makes the restore process as painless as possible. This restore guide will walk you through it.

Step 1 - Create your cluster if necessary

First, does the cluster you wish to restore to still exist or do you need to create it? If it exists, and is registered in CloudCasa, you can go on to step 3. If it doesn’t, you will need to create a new cluster. If your backup used snapshots of persistent volumes (PVs) rather than copies, you will need to create it using storage that has access to your existing snapshots, and the CSI driver will need to have the same name as before so that your snapshots can be accessed.

If you wish to create a cluster in the cloud, and you have linked your Azure, AWS, or GCP cloud accounts under Configuration/Cloud Accounts, CloudCasa will give you the option of automatically creating an AKS, EKS, or GKE cluster to restore to. In this case, skip ahead to step 3.

See also

See Cloud Accounts

Step 2 - Register your cluster if necessary

If you had to manually create a new cluster, you will need to re-install Velero and re-register the cluster with CloudCasa before you can start to restore. First, install Velero. Be sure to use a version the same as or newer than the version you used to create your backups.

To re-install the CloudCasa agent, just log in to the CloudCasa UI, click on the Clusters tab and select Clusters Overview. Now select your cluster in the list on the left. If the CloudCasa agent isn’t running on the cluster the state will not be “Active”.

If you previously installed the agent using a Helm chart, operator, or marketplace like Rancher or Digital Ocean 1-click, just make a note of the displayed cluster ID and re-install the agent as you installed it before. If you previously installed the agent using kubectl, note the kubectl command displayed at the bottom of the Cluster details tab. This is the same kubectl command that you used to register your cluster the first time. Run it against your cluster again now to re-register it.

Within a few minutes, the cluster state should change to Active in the Configuration/Cluster page. If it doesn’t, verify that the agent pod has started in the cloudcasa-io namespace, and that your network configuration allows outgoing TCP connections from your cluster to the CloudCasa service (agent.cloudcasa.io) on port 443.

See also

See Overview of Clusters for more information about registering clusters.

Once Velero and the CloudCasa agent are installed, you will need to re-discover your recovery points since Velero stores these locally. Go to the Configuration/Storage page and add the BSL(s) that contain the backups for your cluster.

See also

See Storage for more information about registering Velero BSLs.

Step 3 - Choose a recovery point

Go to the Clusters tab, select Clusters Overview, and then select the cluster you wish to restore from. Next select the Recovery Points tab, find the recovery point you wish to restore from, and click the Restore icon.

See also

See Cluster Recovery Points for more information about recovery points.

Step 4 - Create and run a restore job

The Restore wizard will now open to the resource selection page. You can choose whether you want to restore all namespaces in the backup, or only selected namespaces. If you choose the latter, you will be given a list of namespaces from which you can select. Remember that only namespaces included in the backup will be shown. You can also rename namespaces during the restore later in the process. Next, you can select specific resources for restore using labels or by resource type. Labels are entered as key:value pairs, and will not be validated by the UI. You can add them one at a time or add multiple pairs at once, separated by spaces.

Next you need to choose whether or not to restore persistent volumes. If you toggle off the Exclude Persistent Volumes option (it is off by default), PVs will be restored using the snapshots or copies associated with the recovery point you’ve selected. Remember that if you have selected specific namespaces or labels for restore, only PVs in the namespaces or with the labels you’ve selected will be restored.

Finally, you are given the option of whether to restore cluster-scoped resources. The options are Yes, which means they will always be restored, No, which means they will never be restored, and Auto (the default) which means only cluster-scoped resources related to restored namespace-scoped resources will be restored.

Click Next, and you’ll be presented with destination options. You can restore to the existing source cluster, or you can automatically create a new EKS, AKS, or GKE cluster to restore to (assuming you have one or more linked cloud accounts). If you choose the “Create new cluster” option, you will be prompted to select the type of cluster to create, and the cloud account to create the cluster in. You will then be prompted for the various cluster creation options available for the type of cluster you’ve selected.

See also

See Cloud Accounts and Cluster Restore Wizard for more information about linking cloud accounts and creating cloud-based clusters during restore.

On the next page of the restore wizard you’ll be prompted for Restore Transforms. These options allow you to rename namespaces, choose to preserve automatically assigned node ports, and choose to overwrite existing resources. By default, namespaces will not be renamed, automatically assigned node ports will be assigned anew, and existing Kubernetes resources will NOT be overwritten.

Remember that if you choose to rename namespaces by adding a prefix and/or suffix, ALL restored name-spaces will have the prefix or suffix added. If you want to rename only specific namespaces, you should instead use the “Set new names” option.

The next page of the wizard will prompt you for post-restore application hooks. These allow you to execute application-specific post-restore command for special applications that might require it, such as databases. Unless you used application hooks when creating the backup, you can probably ignore this.

See also

See App Hooks for more information of application hooks.

Finally, the wizard will show you a summary of the options you’ve selected and prompt you to name the restore job. Restore jobs have names so that you can more easily track the status of them. The system will also save the job using its name so that you can re-run it later. You can name it whatever you want. Nobody will judge you.

Now click Restore and CloudCasa will do the rest! You can watch the progress of your restore job in the Dashboard’s Activity panel. You can also re-run a restore by clicking on the “Run now” icon. Note that this actually creates a new duplicate restore job, since Velero does not allow an existing restore to be re-run.

See also

See Cluster Restore Wizard for more information on the restore wizard.