Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

When a VM hosting your Tanzu Kubernetes cluster crashes, your recovery strategy can make or break application availability. Traditional VM backups often miss Kubernetes-specific data, leading to incomplete or inconsistent restores. This guide walks you through a reliable recovery process using CloudCasa, ensuring you restore both infrastructure and application state with confidence.

For years, backing up virtual machines has been a necessary evil — a dull, repetitive chore hidden deep inside IT maintenance schedules. It’s the sort of thing that keeps enterprise workloads safe but rarely excites anyone. You’d spin up VMs, configure snapshots, cross your fingers before a restore, and hope that your “incremental forever” backup didn’t quietly break somewhere along the way. But lately, something has started to shift.

Building resilient infrastructure is a must for modern organizations operating across hybrid environments. As applications move between on-premises and the cloud, ensuring data protection and continuity becomes a key priority. Red Hat OpenShift offers a consistent platform for running containerized and virtualized workloads across hybrid environments.

CloudCasa for Kubernetes just got more versatile. In addition to object storage targets such as Amazon S3, Azure Blob, and other S3-compatible platforms, CloudCasa now supports NFS (Network File System) as a backup destination. This enhancement gives organizations even greater flexibility when choosing how and where to store their Kubernetes backups — whether in the cloud, on-premises, or both.

As Kubernetes adoption accelerates, more organizations are running virtual machines (VMs) inside Kubernetes using platforms like OpenShift Virtualization, SUSE Virtualization, KubeVirt, Mirantis k0rdent Virtualization, and Spectro Cloud VMO. This hybrid approach consolidates container and VM workloads on a single infrastructure, improving flexibility—but it also introduces new challenges for backup and recovery.

CloudCasa by Catalogic and SUSE have partnered to deliver a new disaster recovery solution for Kubernetes and SUSE Virtualization environments. This joint approach combines CloudCasa’s Kubernetes-native backup and recovery platform with SUSE Storage (a.k.a. Longhorn) and its Disaster Recovery Volumes feature. This provides a resilient, storage-driven DR strategy that reduces cost, complexity, and recovery times.

If you’ve ever worked with Rancher projects, you know they’re a handy way to group namespaces, manage RBAC, and keep your Kubernetes world a little less chaotic. But what happens if a project or its namespaces vanish? That’s where CloudCasa comes in. It makes restoring Rancher projects and their workloads surprisingly simple. Let’s break it down into the three main situations you might run into.

If you’re running MYSQL or PostgreSQL in Tanzu, you may have wondered, are my backups really enough? With stateful apps becoming more common in Kubernetes environments, relying on traditional VM snapshots just does not work anymore. To truly protect your data, you need a Kubernetes -native approach that ensures consistency, fast recovery, and compliance with enterprise standards. In this guide, we’ll explore.

Kubernetes regulated industries—such as finance, government, and healthcare—operate under strict data protection and compliance mandates. While Kubernetes enables agility and scalability, its dynamic and ephemeral nature makes safeguarding data more complex.

Modern platforms demand modern protection. As organizations adopt Kubernetes, OpenShift, and hybrid cloud environments, legacy backup tools—designed for static, VM-only systems—fall short. Today’s applications span containers, VMs, and dynamic cloud-native services. Protecting OpenShift Virtualization requires more than basic snapshots or namespace-level restores—it requires precision.