Blog

The facts are hard to ignore. The number of virtual machines running on Red Hat OpenShift Virtualization grew 417% in 2025. Red Hat has assessed more than 1.46 million VMs through its migration engagements. Global banks, government agencies, telcos, and manufacturers are now running production workloads on the platform.

Migration momentum is real, but it’s only part of the story.

What doesn’t get talked about enough is what happens after the move. The moment your team realizes the backup strategy that worked for your old hypervisor doesn’t carry over when those same VMs run on OpenShift, it’s no longer a minor operational detail. For production workloads, it’s a risk that shows up fast.

Why the Data Protection Gap Exists

Consider what this looks like in practice. A large retailer in the Asia-Pacific region recently migrated several thousand edge locations off VMware and onto OpenShift Virtualization, running mixed workloads of container applications and three to five VMs per site. The requirement was fully remote execution: No on-site technician visits, new hardware, or interruption to the AI-driven applications running at each site.

Veeam Kasten performed a full restore of both VMs and containerized applications across all locations remotely, avoiding millions in costs by eliminating on-site migration visits. No competing solution could meet the mixed workload requirement without a hardware redesign.

That scenario is becoming common. Here’s why the data protection gap exists in the first place.

Red Hat OpenShift Virtualization, built on the open-source KubeVirt project, runs virtual machines inside containers on Kubernetes. That’s a fundamental architectural shift from traditional hypervisors, and it changes how data protection works.

In a traditional virtualization stack, VMs live on a hypervisor that backup tools were purpose-built to communicate with. Those tools understand hypervisor-level snapshots, guest OS quiescing, Changed Block Tracking, and how to move data to backup storage. They were designed for that environment.

When that same VM moves to OpenShift, it becomes a Kubernetes workload. It runs in a pod, with storage in persistent volumes managed by Kubernetes. Its network identity is controlled through NetworkAttachementDefinition rather than vSwitches. The VM looks the same to the OS and applications inside it, but from the infrastructure layer up, it’s a cloud-native resource.

Traditional backup tools don’t recognize that. If you point a legacy hypervisor backup agent at an OpenShift Virtualization cluster, you’ll either get nothing or something incomplete that leaves you with a false sense of protection. That’s the gap.

And it’s not just a migration problem. OpenShift-first teams hit the same wall once they start running VMs alongside their container workloads.

Mixed Workloads Demand a Unified Protection Strategy

This problem isn’t limited to teams migrating from legacy hypervisors. Organizations that already use OpenShift as their primary platform, and now run KubeVirt VMs alongside container workloads, face the same challenges.

A single OpenShift cluster today might run containerized microservices in one namespace, stateful databases managed by an operator in another, and KubeVirt virtual machines in a third. Those workloads have different recovery requirements, operational owners, and compliance considerations. Managing data protection across that environment with separate tools for each workload type creates exactly the kind of complexity, consistency, and coverage gaps that lead to real incidents.

The question isn’t just, “How do I back up my VMs and containers?” It’s, “Can I protect everything on this platform with a consistent policy framework, and can I prove it?”

Veeam Kasten protects VMs and containerized applications through the same policy engine. Schedules, retention rules, export targets, and immutability requirements are defined once and applied consistently across workload types.

As part of the Kasten v9.0 release, label-based VM policies make that even more practical at scale: Administrators can now dynamically group and protect VMs using Kubernetes labels rather than managing VM-by-VM policy assignments. New VMs with the right label are automatically picked up by the right policy, eliminating coverage gaps as environments grow.

For teams running OpenShift across multiple clusters, Kasten’s integration with Red Hat Advanced Cluster Management (ACM) centralizes data protection observability across all managed clusters, using the same console you already use to manage the clusters themselves. Protection status, backup failures, and SLA compliance are visible in one place rather than requiring cluster-by-cluster checks.

That addresses the mixed workload problem, but for VM-heavy environments, backup efficiency at scale is its own challenge.

What Application-Aware Backup Actually Means for KubeVirt VMs

The term “application-aware” gets used broadly. Let’s talk specifically about what it means when a VM runs on OpenShift.

A KubeVirt VM isn’t a self-contained unit. It has a VirtualMachine resource, one or more disk images stored as persistent volumes, network configuration objects, secrets, configuration maps, and potential dependencies on other Kubernetes resources. Protecting the VM correctly means capturing all those components in a consistent state, not just having a disk snapshot.

Veeam Kasten discovers KubeVirt VMs automatically, treating them as first-class workloads. When a backup policy runs against a namespace containing VMs, Kasten captures the full workload context: The VirtualMachine spec, persistent volume data, and supporting Kubernetes resources. It can freeze the guest filesystem before the snapshot to ensure consistency, then unfreeze after the snapshot completes. MAC addresses are preserved on restore, which matters in environments where network identity is tied to MAC. Partial restore also lets you recover individual VM volumes without rolling back the entire VM state.

The result is the same application-consistent, Kubernetes-native protection that containerized applications already rely on, now extended to VM workloads running on the same platform.

Consistency? Check. The next question is efficiency, especially as VM counts grow.

Incremental Backup at VMware-grade Efficiency

One of the persistent limitations of Kubernetes-native VM protection has been backup efficiency. The first generation of approaches required reading entire VM disks to determine what has changed since the previous backup to implement incremental backup. That can work at smaller scales, but as VM environments grow, it creates long backup windows and significant compute overhead.

Veeam Kasten v9.0 changes that. The Veeam and Red Hat engineering teams partnered (again) to develop a storage-agnostic approach that uses hypervisor-level Changed Block Tracking to identify exactly what’s changed since the last backup. Instead of scanning entire disks, Kasten reads only the changed blocks, improving backup efficiency and reducing overhead at scale. This capability is available as tech preview support in v9.0.

The practical outcome: Dramatically shorter backup windows, lower compute overhead during export operations, and the ability to confidently protect large numbers of VMs on a single cluster. Organizations running OpenShift Virtualization at scale now get backup efficiency on par with what they had on legacy hypervisors, without the legacy constraints.

Shorter backup windows and lower overhead change what’s operationally possible at scale. And that changes the protection posture across the entire platform.

Security and Immutability Built In

Running mission-critical workloads on OpenShift, including virtual machines carrying sensitive data from legacy infrastructure, means ransomware resilience isn’t optional.

Veeam Kasten supports immutable backups to S3-compatible object storage and Azure Blob, and it also adds support for AWS-backed Veeam Data Cloud Vault (new in v9.0). Once a restore point is locked, it can’t be deleted or modified, which helps protect against ransomware and malicious/errant actions, even if an attacker gains cluster-level access.

In addition, Kasten includes its own disaster recovery (DR) mechanism to protect the Kasten platform itself (including metadata such as the restore-point catalog), so your recovery capability can persist even if a cluster is compromised.

With v9.0, Kasten pods run with read-only root filesystems by default, aligned with NIST 800-190 guidelines. Even if a pod is exploited, attackers can’t install payloads, modify binaries, or tamper with backup infrastructure components.

For organizations in regulated industries, that posture supports CIS benchmarks, zero-trust frameworks, and Kubernetes Pod Security Standards, usually without additional configurations.

Red Hat Recommended

Red Hat names Veeam as a supported data protection partner for OpenShift Virtualization. That reflects a tested, validated integration across the OpenShift platform and the broader Red Hat ecosystem. It’s also a testament to the technical collaboration between Veeam and Red Hat engineering behind capabilities like the Incremental Backup API, which was built specifically for OpenShift Virtualization at production scale.

For teams evaluating their options, that distinction matters. A solution built on the Kubernetes API, validated on OpenShift, and developed in partnership with Red Hat is a different proposition from a legacy backup tool adapted for a new environment.

Getting Started

Most teams discover the data protection gap during a recovery test, or worse, while experiencing an actual incident. The better time to identify and close it is before migration completes.

If you’re running KubeVirt VMs on OpenShift, or planning to, Veeam Kasten deploys into your OpenShift cluster via OperatorHub or Helm, and a free tier is available to get started without a purchase commitment.

Explore Veeam Kasten for Red Hat OpenShift or find the Veeam solution in the Red Hat Ecosystem Catalog.

The post You Migrated Your VMs to Red Hat OpenShift. Now How Do You Protect Them? appeared first on Veeam Software Official Blog.

from Veeam Software Official Blog https://ift.tt/IL8BY4n