Spring has just begun at most of Catalogic’s locations around the world, and outside plants are just beginning to sprout. But the CloudCasa team has been busy through the winter growing a bumper crop of new features and, to stretch the metaphor maybe a bit too much, now we’re ready to harvest them! We think you’ll be impressed with the new additions to CloudCasa in this release. Among other things, we’ve made some significant improvements to our core Kubernetes backup and restore capabilities, added new features for users of KubeVirt VMs (including OpenShift Virtualization and SUSE Virtualization), and introduced a new reporting feature.
File-level restores
CloudCasa now gives you the ability to select specific files/directories from a PVC for restore. They can then be restored to the same PVC, to a different PVC, or even to an entirely different cluster.
File-level restore is performed using the new Files tab in the Select Resources step of the cluster restore wizard. Choose the source PVC, click Select Files, and a file browser will open allowing you to make selections.
You can also choose to restore the files to a different target directory in the destination PVC. If a hierarchy of directories is selected, the target directory will serve as the root of the restored hierarchy.
The maximum number of file/directory selections (not individual files) is currently limited to 128.
Resource selection for restores
There is now an easy way of selecting specific resources for restore, including VMs and PVCs, using the new resource browser. This is done by selecting the new Specific resources tab in the Select Resources step of the cluster restore wizard.
Clicking Select resources will then open the resource browser. After that, just click on the resources you want to select them. No more trying to figure out what combination of namespace, labels, and resource type will yield the resources you need, although you can still select them that way in cases where it’s easier.
Note that selecting a VM will automatically include all resource related to it, making restore of individual VMs simple.
The maximum number of resources that can be individually selected in this manner is 128.
Selection of specific VMs or PVCs for backup
We’ve also added an easy new way to select specific VMs and PVCs for backup. In the Selections step of the Cluster Backup wizard, choose the new VMs/PVCs tab. You can then open the resource browser by clicking on Select resources, and choose specific VMs or PVCs for backup. When selecting KubeVirt VMs for backup using this method (including OpenShift Virtualization and SUSE Virtualization VMs), all associated resources are also automatically selected.
The resource browser has three views available:
- Choose Namespaces to select from a tree view of namespaces, showing both VMs and PVCs as children. The Search box will filter by namespace.
- Choose PVCs to select from a table view of PVCs, sortable by PVC name or Namespace name. The Search box will filter by PVC name.
- Choose VMs to select from a table view of VMs, sortable by VM name or Namespace name. The Search box will filter by VM name.
Of course, you can still choose to simply back up the whole cluster, or select VMs, PVCs, and other resources based on namespace and labels as before. Just use the default Standard selections tab instead, which provides all the same options that were available in the Selections step before.
Additional options for VM restore
As we continue to improve the data protection experience for users of containerized VMs on Kubernetes, we’ve added a new section called VM options to the Restore transforms step in the cluster restore wizard. The new options are:
- Clear MAC address(es) – Specifies that MAC addresses for restored VMs should be cleared and new addresses should be assigned. This defaults to on. Disable it to preserve the saved MAC addresses for restored VMs. Do this only if you are sure that it will not result in duplicate MAC addresses on your network.
- Generate new firmware UUID – Specifies that new firmware UUIDs should be generated for restored VMs. This defaults to off.
- Run Strategy – This field controls whether and how restored VMs are started after restore. You can select any valid Run Strategy option or select “Use strategy from backup” to retain the run strategy for each VM from the backup. If you are uncertain, we recommend selecting “Halted” and booting VMs manually after restore.
A note on Firmware UUIDs
In virtualized environments, each Virtual Machine (VM) is assigned a unique firmware UUID (Universally Unique Identifier) that serves as a distinct identifier for the VM’s hardware components. This UUID is utilized by various software systems, including licensing servers, system management tools, and certain applications, to uniquely recognize and manage individual VMs. In KubeVirt VMs, the firmware UUID is specified within the VirtualMachineInstance (VMI) spec.
When restoring a VM using CloudCasa, if the original firmware UUID is retained, it can lead to conflicts, especially if the original VM is still active. By generating a new firmware UUID on restore, CloudCasa can ensure that each VM maintains a unique identity within the infrastructure, thereby avoiding conflicts and ensuring seamless integration with licensing systems, management tools, and applications.
For more information on VM restore options see VM Restore.
Reports tab (Preview)
We have added reporting features to CloudCasa in the form of a new Reports tab. This release is just a preview of the reporting system, but already there are several reports that we think you’ll find useful. These include reports that show backup success rates over time, by cluster or by job, and reports that show the last successful backup time by cluster or by job. Click on the Reports tab to see the available reports. At release, these are:
- Success rate by cluster
- Success rate by job
- Last successful run by cluster
- Last successful run by job
Note that reports currently apply to backup and replication jobs. Both clusters and jobs can be filtered in reports using tag values, so now would be a good time to go through your cluster and backup definitions and start setting meaningful tag values.
For success rate reports, the options available are start and end time, aggregation period, and tag selection. For last successful run reports, the only option is currently tag selection.
Job completion data (i.e. Activity data) was formerly retained for 30 days. Since this data is used by the new reporting feature, we have extended the retention time for it.
Caveats:
- The tags used for filtering in reporting come from job activity records. These are copied from the cluster and job definitions at the time the job is run. So changing the tags assigned to a cluster or backup job definition will not immediately change the selection in reporting. It will only affect records of NEW jobs runs.
- The system sometimes reports job completion status as “SKIPPED” when it should really be “FAILED” for purposes of reporting. We will address this in a future update.
- The job completion data retention period has only been increased with this release, so at first you won’t see data older than approximately 30 days.
Catalogic has long-standing expertise in backup reporting, so rest assured that we will be enhancing CloudCasa’s reporting features in future releases. We’re also interested in hearing your opinion on what reports and reporting features would be most useful to you.
Updates to the dashboard
We have moved the Activity tab on the dashboard from the small pane on the right to the larger pane on the left. This allows more room for important activity messages, and allows you to view the Activity and Alerts tabs at the same time. Dashboard tab selection is now “sticky”, so whatever tab you chose last will be selected by default when you return. So if you would rather see the Cluster Backups tab by default as you did in the past, just select it!
Recovery point resource browser
You now have the option of browsing recovery points and seeing all of the resources included in the backup using the resource browser. This can be done by going to the Clusters/Recovery Points page and selecting “Browse” from the recovery point actions. This is an easy way of finding out exactly what is in a given recovery point if you aren’t sure how the backup was configured when it was run.
Introduction of CloudCasa Rancher Extension
Our new CloudCasa Rancher Extension was released separately on March 6th. It allows SUSE Rancher and Rancher Prime users to perform common CloudCasa functions directly in the Rancher UI. If you are using SUSE Rancher to manage your clusters, installing the CloudCasa extension makes it even easier to monitor your protection status and manage CloudCasa backups. We encourage you to give it a try!
See Rancher Extension for more information.
Note: Free accounts are now allowed to generate 1 API key. API keys were previously available only to premium plan users. This allows Free plan users to make use of the Rancher Extension, among other things.
Restores to existing PVCs
CloudCasa now supports restores to existing PVC, rather than forcing users to create a new PVC. Just select the Overwrite existing resources option when restoring. When using the new file-level restore feature, restore will always be to an existing PVC.
Restore of unattached PVCs
Previously, when you selected the PVC type under Select resource types when defining a restore, “pods” was automatically added as well because CloudCasa could only restore PVC data in the context of a pod. Now that limitation has been removed. If you want to restore only PVCs, you can do it using either resource type selection or by selecting specific PVCs in the new Specific resources tab. This can be useful if you want to, for example, restore data on a PVC and then let an operator bring up the workload using the data.
New Advanced Options for Agent Configuration
In the Add Cluster wizard, we have replaced the Resource config section under Advanced Settings with the new Customize agent installation parameters section. This provides a more generic mechanism for configuring labels, annotations, requests, limits, etc. that must be applied to the agent pods or namespaces for site-specific requirements. It is necessary to inform the Agent Manager of these so that they are properly applied when agent components are updated/redeployed. The new Customize agent installation parameters section allows administrators to configure these properties using YAML.
See Advanced Agent Configuration for more information.
Activity details changes
There were some changes made to the PV progress display for migration, replication, and restore jobs in the Activity details view. For migration and replication jobs there are now three PV status tabs, one for snapshots, one for copies, and one for restores. For restore jobs, the PV status tab was just renamed from PV Details (Copy) to PV Details (Restore).
Navigation changes
The Activity and Alerts pages are now accessible directly from the Dashboard tab menu.
Kubernetes agent updates
In this update we’ve again made several changes to our Kubernetes agent to add features, improve performance, and fix bugs. Some new product features will not work with older versions of the agent. However, manual updates shouldn’t normally be necessary anymore because of the automatic agent update feature. If you have automatic updates disabled for any of your agents, you should update them manually as soon as possible.
Notes
With some browsers you may need to restart, hit Control-F5, and/or clear the cache to make sure you have the latest version of the CloudCasa web app when first logging in after the update. You can also try selectively removing cookies and site data for cloudcasa.io if you encounter any odd behavior.
As always, we want to hear your feedback on new features! You can contact us using the support chat feature, or by sending email to support@cloudcasa.io.
Da Li