When your storage array replicates volumes to a second site, CloudCasa uses that copy to bring your Kubernetes workloads and VMs back up on a standby cluster there. It fails over the replicated volumes, rebuilds the workloads and their Kubernetes configuration on the standby cluster, and moves them back when the primary site is ready. Nothing is restored from backup.
Restoring a site from backup is slow. With storage-integrated disaster recovery, your storage keeps the data current at the recovery site, and CloudCasa brings the workloads and VMs up on the standby cluster there, without waiting for a full restore.
The same four steps for Kubernetes applications and virtual machines.
Create a DR Plan. Choose the primary and standby clusters, then select whole namespaces or individual Deployments, StatefulSets, and VMs.
Your storage array replicates the protected volumes to the recovery site, along with a small inventory volume that records the Kubernetes resources.
Run a failover job. CloudCasa fails over the replicated volumes, then rebuilds the workloads, PVCs, and VMs on the standby cluster from the replicated inventory.
When the primary site is ready, run a failback job. CloudCasa moves the workloads and their data back to the primary cluster.
Lower recovery times, less manual work, and one operational model across containers and virtual machines.
The data is already at the recovery site, so failover does not wait for a restore from backup. Recovery typically takes seconds to minutes, depending on the array and how quickly the workloads start.
The storage array keeps the recovery site up to date. RPO depends on the replication mode and schedule configured on the array.
Protect KubeVirt virtual machines and container applications under one consistent operational model.
Failover and failback run as CloudCasa jobs between the primary and standby clusters. By default, CloudCasa stops the workloads on the source side first, then brings them up on the other side.
CloudCasa restores the Kubernetes resources around your data, including PVCs and custom resources. Optional transforms adjust resources during recovery, and VM options can reset MAC addresses and firmware UUIDs.
Backup data is encrypted in transit and at rest. Immutable backups use S3 Object Lock or Azure immutable storage that you provide.
Your storage replicates the data to the recovery site. CloudCasa rebuilds the Kubernetes side on the standby cluster, so recovery does not depend on restoring from backup.
PowerStore synchronous or asynchronous replication moves the data, while CloudCasa rebuilds Deployments, StatefulSets, and KubeVirt VMs on the standby cluster.
See the Dell PowerStore page →HPE Remote Copy replicates the volumes between HPE Alletra MP B10000 or Alletra 9000 arrays, while CloudCasa rebuilds the Kubernetes workloads and KubeVirt VMs on the standby cluster.
See the HPE Alletra DR page →Longhorn Disaster Recovery Volumes replicate the data, while CloudCasa rebuilds the workloads and KubeVirt VMs on the standby cluster.
See the SUSE Storage DR solution →Manage protection and recovery for all your clusters from one central console, with role-based access for teams.
Adjust Kubernetes resources during DR recovery with uploaded transforms. Namespace renaming and storage class remapping are available for backup restores.
CloudCasa checks each storage system connection and its replication targets before you build a DR Plan. A recurring inventory job maps PVCs to array volumes and records replication status.
Protect whole namespaces or individual Deployments, StatefulSets, and VMs in each DR Plan.
Each cluster runs a single CloudCasa agent, and the backup catalog lives in the central control plane. DR adds one small inventory volume.
Run CloudCasa in your own environment or use it as SaaS, to meet regulatory and data sovereignty requirements.
Guided workflows handle the storage failover and the Kubernetes rebuild together, so there are fewer manual recovery steps.
The CloudCasa API lets teams automate protection and standardize DR processes without building separate tooling for every cluster or site.
Storage-integrated DR shortens recovery time: the data is already at the recovery site, and CloudCasa brings the application layer up around it.
The result is one repeatable way to move applications, virtual machines, and persistent data to a second site and back, with fewer manual steps and less room for error.
Run failover and failback between your own clusters and storage. Measure recovery time before you need it.
Dell PowerStore customers are running more of their production estate on Kubernetes, often with virtual machines migrated onto KubeVirt …
Dell PowerStore customers are running more of their production estate on Red Hat OpenShift, increasingly alongside virtual machines …
As Dell PowerStore customers scale their production estates with SUSE Rancher Prime and SUSE Virtualization, a critical gap …
Download Solution Brief CloudCasa DR for Kubernetes delivers low-RPO, low-RTO inter-cluster disaster recovery for Kubernetes applications and KubeVirt VMs, integrated …