Sooner or later, an attacker will go after your recovery points. Take away your ability to recover, and they hold all the leverage. If you're moving workloads from VMware to OpenStack, you have a rare chance to build protection so that day doesn't end in a negotiation. Plenty of teams are making that move. Gartner predicts that by 2029, 55% of enterprises will start proofs of concept for alternatives to their VMware deployments, up from 25% in 2026. OpenStack is high on the list for teams that want to keep running their own cloud.
Most VMware Exits Happen in Stages
In a CloudBolt survey of 302 North American IT decision-makers, 86% said they're actively shrinking their VMware footprint, and most are doing it gradually.
That means running two platforms side by side for a long time. The new OpenStack cloud comes online fast while the team is already stretched, so protection often defaults to whatever OpenStack provides natively. That's where the exposure starts.
What Native OpenStack Protection Gives You
OpenStack gives you native options: snapshots of Nova instances and Cinder volumes, plus an optional Cinder backup service. They're handy for a quick rollback before a patch. As a resilience strategy, they leave gaps.
All of them keep the copy inside the same platform and administrative domain as production. Instance backups have no built-in scheduler, so teams often script them with cron jobs. And none of them give you an air-gapped copy outside the environment for disaster recovery.
One Stolen OpenStack Credential, Two Losses
Now picture an attacker with Keystone admin credentials. Keystone controls identity and access across your OpenStack environment. With admin rights, the attacker can delete your instances, then delete the snapshots you'd use to bring them back.
Your production workloads and your recovery points share an identity system, a control plane, and a failure domain. One compromise takes out both.
Stolen credentials aren't the only risk. Weak management of non-human identities, such as service accounts that run scheduled backups, was a root cause in 41% of identity breaches. AI agents are the newest members of that group. Teams are giving automation and agents API access to infrastructure, and an agent with broad OpenStack permissions can delete snapshots as easily as an attacker can, through a bad instruction or a hijacked prompt. If your backups sit inside the same environment, they're within that agent's reach.
Many traditional backup approaches carry the same weakness in a different form. They keep backup servers and storage in the same data center as production, within reach of anyone who gets far enough inside. Others add a different burden: without native OpenStack support, they need an agent in every instance.
Three Questions to Ask About OpenStack Backup
Moving to OpenStack is the right moment to fix this, before scripts and habits harden. Ask these of any approach you evaluate:
Where do the recovery copies live?
Who can delete them, and with which credentials?
What happens to them if an attacker takes over your OpenStack environment?
If the honest answer to the last question is "they're gone too," your backups share a blast radius with the systems they protect.
How Druva Keeps OpenStack Recoverable
Druva now protects OpenStack instances as part of its cyber resilience platform. Backup is the capability. Recovery after an attack is the outcome, and the design starts there. Learn more about Druva's approach to cyber resilience.
1. Agentless, with nothing to install in your instances
Druva uses standard OpenStack APIs and Keystone authentication for image-level backup of Nova instances and their persistent Cinder volumes. A lightweight proxy runs in your project, takes a native Cinder snapshot, and sends the data outbound to Druva over HTTPS, so you don't open any inbound ports. The snapshot is only a staging step; the recovery copy lives outside OpenStack. Because Druva is a fully-managed SaaS, there are no backup servers or storage repositories for you to run.
2. Air-gapped recovery copies
Every backup goes to Druva's air-gapped cloud on AWS or Azure, outside the OpenStack security domain. Backups are encrypted with AES-256 at rest and TLS in transit. Access to them runs through a separate Druva identity, so no OpenStack credential can modify or delete them.
3. Immutable storage with guardrails
Druva writes backups to immutable storage. Druva Data Lock helps protect backup data against unauthorized modification or deletion, and Self-Service Rollback and Safe Mode add further recovery protection.
4. Efficient backups and full instance recovery
Backups are forever-incremental. Druva identifies changes by checksum comparison and applies global source-side deduplication, so you store and move less data over time. When you need to recover, you can restore full instances to their original location or an alternate one.
5. One console for VMware and OpenStack
If you already protect VMware with Druva, your OpenStack workloads show up in the same console with the same workflows. During a migration that lasts years, that's one less tool to run. Visit Druva’s VMware protection page for more information.
What About the Proxy's OpenStack Credentials?
Security teams will ask, so let's answer it directly. The proxy needs Keystone credentials to take snapshots and run restores, as any backup tool would. Those credentials stay on the proxy inside your project, and Druva never stores them in its cloud.
They also stop at the edge of your OpenStack environment. Credentials compromised inside OpenStack cannot modify, delete, or reach the backup copy, and the same holds for an over-permissioned agent. Your recovery points sit in Druva's immutable, air-gapped storage, managed through a separate identity. An attacker who breaches OpenStack could damage production, but they couldn't touch the copies you'd use to recover it.
Get Started with Druva for OpenStack
Moving off VMware is a chance to modernize more than the hypervisor. Druva is qualified for Canonical OpenStack. Running a different distribution? Contact us.
Planning your move? Schedule a live demo to see how Druva protects your OpenStack instances.
For a closer look, visit the Druva for OpenStack page or download the datasheet.