Kubernetes can restart failed containers, replace Pods, and reschedule workloads, but those actions are not a backup or a disaster-recovery plan. For clusters running both containers and KubeVirt virtual machines, recoverability also depends on protecting persistent data, preserving application and network dependencies, and proving that a restore works. KubeVirt v1.8 and v1.9 add incremental VM backup and migration improvements; their scale figures and release features need to be understood in the context of the workloads and versions tested.
What Kubernetes self-healing does—and what it leaves to you
Kubernetes works to maintain the desired state declared for a workload. Depending on its configuration and the failure, it can restart a container under the Pod’s restart policy, replace a failed Pod to maintain Deployment or StatefulSet replicas, reschedule workloads after node loss, and remove failed Pods from Service endpoints. In some cases, a PersistentVolume can be reattached to a replacement Pod. The exact behavior depends on the workload, storage system, and failure; reattachment is not guaranteed for every volume or incident. Kubernetes’ self-healing documentation describes these mechanisms and their limits.
As an Amazon Associate I earn from qualifying purchases.
| Failure or need | What Kubernetes may do | What still needs a recovery plan |
|---|---|---|
| Container process exits | Restart the container according to the Pod’s restart policy. | Diagnose and fix the application fault; a restart does not correct a software bug, corrupted state, or bad configuration. |
| Pod fails | A controller can create a replacement to maintain the declared replica count. | Confirm that the replacement can reach required storage, services, secrets, and traffic paths. |
| Node is lost | Eligible workloads may be rescheduled elsewhere. | Determine whether the volume and its data are available at the destination, and recover storage if needed. |
| Persistent volume becomes unavailable | Kubernetes may support recovery behavior in some situations. | Storage failures may require explicit recovery steps; an orchestration action is not a substitute for a protected copy of the data. |
A healthy control plane or a Running Pod therefore says little by itself about whether an application’s contents are correct, recent, or recoverable. Treat self-healing as one layer of resilience, not as proof of data protection.
Recommended Free Tools
What a Kubernetes backup and disaster-recovery plan must restore
A usable recovery needs the pieces that make an application work together: Kubernetes resource definitions, persistent-volume bytes, application consistency, and the configuration and network path that lets clients reach the restored service. Restoring resource objects alone can leave an application pointed at an empty volume; restoring data alone can leave no workload or traffic path to use it.
#1 Best Overall
In a September 10, 2026 article, CNCF Ambassadors Saiyam Pathak and Saloni Narang summarize the problem: “Recovery fails at the joins between the layers: a restored cluster with no data, restored data with no traffic path, an application definition that provisions an empty volume.” Their guidance from three reproducible failure scenarios emphasizes checking the transferred volume data, application consistency, infrastructure changes, and the restored contents—not just whether a backup job completed.
Protect application-consistent data
For stateful services, a snapshot or file copy taken while writes are in progress may not represent a usable application state. Plan how the application will flush or quiesce writes, including any required hooks, and whether related volumes must be captured together. A backup system’s completion status cannot establish that the application will accept the restored data.
Restore dependencies as well as data
Map the resources an application needs, including VM or Pod definitions, PVCs, storage classes, configuration, and the route by which traffic reaches the service. A recovery to a different cluster or storage class may need transformations. Test those changes rather than assuming that an object manifest or volume snapshot is portable unchanged.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Verify the result at the data and application layers
After a restore, verify that volume data actually arrived and inspect application contents or perform an application-level check appropriate to the service. Test both the recovered workload and its traffic path. CNCF’s article reports a roughly two-minute restore for its specific lab workload: a four-row PostgreSQL example after namespace and PVC deletion. That is a demonstration result, not a recovery-time expectation for other clusters or data sizes.
What changed in KubeVirt v1.8 and v1.9
KubeVirt’s recent releases address VM backup and migration as well as control-plane behavior. These are project changes, not a guarantee that a particular cluster can meet a recovery objective; compatibility and behavior still need to be checked against the deployed Kubernetes, storage, and KubeVirt versions.
| Release | What’s new | Version context |
|---|---|---|
| KubeVirt v1.8 | Changed Block Tracking (CBT) for incremental VM backups; networking/controller work intended to reduce API calls and address a VM activation performance bottleneck; a published control-plane scale exercise. | Announced March 25, 2026; aligned with Kubernetes v1.35. |
| KubeVirt v1.9 | Migration data-stream compression using zstd, migration stall detection that can trigger post-copy or stop-and-copy, and earlier visibility of filesystem-freeze status in VirtualMachineBackup. | Release notes give July 22, 2026 as the release date, target Kubernetes v1.36, and state support for the previous two Kubernetes versions. |
The v1.8 announcement describes CBT as using QEMU and libvirt backup capabilities to capture changed data, avoiding reliance on specific CSI drivers. Incremental capture can reduce the data that must be copied for a backup, but it does not remove the need to protect the full backup chain, coordinate application consistency, or test a restore. The release also reports networking/controller work to reduce API calls associated with a VM activation bottleneck. Read the project’s KubeVirt v1.8 announcement for the release details and qualifications.
Rank #3
For v1.9, migration stall detection and zstd compression affect VM migration behavior, while earlier filesystem-freeze status visibility can help operators see backup progress. Release notes are not a substitute for checking the current compatibility matrix before deployment: consult the KubeVirt release notes for version and support information as it changes.
How KubeVirt backup and restore fits together
KubeVirt backup is not simply a disk-copy operation. Its backup and restore integration documentation describes building a dependency graph of Kubernetes resources, quiescing applications, snapshotting PVCs, saving resource definitions, and restoring PVC data alongside sanitized resource definitions. The documented manual scenarios include restoring both stopped and running VM cases and verifying the data afterward.
- Map the workload. Identify the VM, its PVCs, and the Kubernetes resources and services it depends on. Decide which related volumes and definitions must be recovered together.
- Choose a consistency method. Establish how the guest or application flushes or quiesces writes before capture, and confirm how the workflow reports filesystem-freeze status.
- Protect the data and definitions. Capture the required PVC data and resource definitions using a workflow compatible with the cluster’s storage and KubeVirt versions.
- Restore into the intended environment. Account for storage-class differences, resource changes, networking, and any transformations needed for the target cluster.
- Prove recovery. Restore representative stopped and running VM scenarios, check the actual data, and confirm the application and traffic path work.
The integration documentation’s examples are useful patterns, not evidence that every storage backend, cluster pairing, or migration path behaves identically. Validate compatibility with the storage classes and versions in the environment you intend to recover.
How to interpret KubeVirt’s published scale figures
The v1.8 announcement compares a test with 100 real VMIs against one with 8,000 KWOK VMIs. It reports average virt-api memory rising from 140 MB to 170 MB and virt-controller memory rising from 65 MB to 1,400 MB. The announcement estimates incremental control-plane memory at 3.89 KB per VMI for virt-api and 173.04 KB per VMI for virt-controller.
These numbers describe that project exercise, not a production capacity guarantee. KubeVirt maintainers explicitly label the per-VMI figures estimates and warn that measurements may be incorrect; the real-VM and KWOK workloads are also not interchangeable evidence of every cluster’s behavior. Use the measurements to frame capacity questions, then measure your own mix of VM sizes, operations, and control-plane resource limits.
How backup concurrency changes performance
Backup and restore throughput depends on the amount and shape of protected data, concurrency, and available resources. More parallel work can shorten a window in some workloads, but can also compete for CPU, storage, network, or ephemeral storage. A completed backup rate measured on a small test set is not a sound basis for estimating a large production restore.
Best Value
Velero’s file-system backup documentation says that, by default, one PodVolumeBackup or PodVolumeRestore request per node is handled at a time, with concurrency configurable. It also notes that file-level parallelism and CPU limits can affect throughput in some configurations, and recommends tuning against the data being protected. Timeouts, cache behavior, and ephemeral-storage constraints may also affect a restore.
- Measure backup window and restore time using representative data volumes and file distributions.
- Record concurrency, resource use, and the effective recovery point for each workload.
- Test restores under realistic CPU and storage limits, including the failure conditions the recovery plan is meant to address.
- Increase concurrency only after observing whether the bottleneck is parallelizable and whether shared resources remain within limits.
A practical way to validate resilience before an outage
Use a repeatable recovery exercise to expose gaps between the Kubernetes objects, persistent data, and application dependencies. Set recovery objectives for each service, then check that the evidence from a restore supports those objectives.
- Inventory the recovery unit. Record the cluster resources, VM or Pod, PVCs, storage class, application dependencies, configuration, and ingress or Service path that must return together.
- Define consistency and scope. Specify which data must be captured, how writes are quiesced or flushed, and whether a recovery to another cluster or storage class is required.
- Run a backup and inspect its evidence. Check more than the job’s success indicator: determine what data and definitions were included and whether the application reached a consistent capture point.
- Restore into a realistic target. Exercise the planned failure scenario, including any infrastructure transformations and network or configuration changes.
- Validate bytes, behavior, and access. Verify restored data and application contents, start the workload, and test the path clients use to reach it.
- Measure and adjust. Record the recovery point, restore duration, concurrency, and resource consumption. Tune the workflow and repeat until the result is acceptable for the service.
This approach separates the questions that are easy to conflate: whether Kubernetes can restart or reschedule a workload, whether its data and definitions were protected, and whether the complete service can be restored and used.
Free tools Windows power users keep installed
One-click scans. No signup required.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
