Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Kubernetes backup sounds straightforward until you look closely at what a real application includes. A production workload usually spans Kubernetes resources, cluster configuration, persistent volumes, secrets, service accounts, network policies, and external dependencies such as cloud databases or object storage. Protecting one of those layers helps. Protecting all of them in a coordinated way is what makes recovery practical.

DevOps engineers running OpenShift know the platform well. They know how to build on it, scale on it, and operate it under pressure. What they often hit unexpectedly is the question of backup and recovery, especially once OpenShift Virtualization enters the picture. Most of the tooling that exists today wasn’t built with Kubernetes in mind. It was built for something else and extended toward it.

A practical guide to VM-aware data protection for VMware-to-OpenShift migrations VMware exits rarely fail because engineers cannot move bits. They fail because the organization discovers, mid-flight, that it cannot reliably recover those bits once they land somewhere new.

Kubernetes applications often rely on Persistent Volume Claims (PVCs) to store critical data, from databases to user uploads. Losing this data due to cluster failures or accidents can be catastrophic for DevOps teams. In this post, we’ll walk through how to safeguard your Kubernetes PVCs using CloudCasa, a backup-as-a-service platform.

When Amazon Web Services’ US-East-1 region went down recently, a long list of global apps and services went with it. For most companies, that meant a few hours of frustration. For APRA-regulated financial institutions in Australia, an outage like that is something much more serious — a compliance and operational-resilience test under CPS 230, which is now in force as of July 2025.

When AWS’s US-East-1 region went down again this month, it reminded the industry of an uncomfortable truth: even the most trusted cloud platforms can fail. From streaming services to SaaS providers, many businesses were caught off guard, not because they lacked backups, but because they lacked redundancy. In a Kubernetes world, redundancy isn’t just about having data snapshots.

The latest CloudCasa Feature Update introduces a range of powerful new features and improvements that every user should know about. This release delivers major advancements in Kubernetes disaster recovery and backup flexibility, helping organizations recover faster, simplify management, and protect workloads across diverse environments.

Running Kubernetes on VMware Tanzu gives you flexibility, scalability, and strong enterprise integration. But when it comes to protecting applications and data, many teams still rely on traditional VM backups. At first glance, it seems logical: if you back up the VM that hosts your cluster, you should be safe. Unfortunately, that’s a dangerous assumption. VM backups capture the virtual machine state—but they don’t understand Kubernetes.

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.