Velero, Kasten K10, Kanister — the backup tool debate misses the real problem. When your underlying storage changes shape between environments, every backup strategy has to be rebuilt. Here's what a portable infrastructure layer actually fixes.
Ask a handful of platform engineers what's working for backing up mid-sized, globally distributed Kubernetes clusters in production, and you'll get a tour of the whole ecosystem — Velero, Kasten K10, Longhorn, volsync with restic, Kanister for application-aware snapshots, Commvault for the enterprise crowd, and a firm insistence on "just use the database's native tool" for anything stateful like Postgres.
None of these choices are wrong on their own, which is exactly what makes the pattern underneath them worth paying attention to.
The same five requirements, every time
Strip away the brand names, and the same five requirements keep surfacing, over and over:
Back up PVC data reliably. Stay provider-agnostic across on-prem and multi-cloud. Support flexible retention (hourly, daily, weekly, monthly). Manage it all as code, YAML preferred. And restore fast enough that an incident doesn't turn into a weekend.
The popular tools are good at the first, third, and fourth of these. Velero is genuinely excellent at orchestrating backup schedules and talking to a storage API through a plugin. Kasten K10 is genuinely excellent at application-aware, policy-driven recovery. But both of them have a quiet dependency baked in: they're only as portable as the storage and cloud APIs underneath them. It's common to see Velero running against a single hyperscaler's blob storage, simply because that's what the cluster happens to sit on. Velero's own PVC backup plugins rely on the underlying cloud backup functionality for whatever storage class provider is in play — meaning the tool travels, but the moment you move clusters between a cloud provider and an on-prem datacenter, your backup plugin, your snapshot semantics, and often your retention config have to be rebuilt from scratch.
That gap belongs to the infrastructure underneath, and it just happens to surface through whichever backup tool is running on top of it.
Where the gap lives
The most honest warning in any backup discussion tends to center on scale: once you've got twenty different apps each with their own backup mechanism, keeping track of what's being protected, and verifying it restores, turns into a bit of a circus.
App-native backup (WAL shipping for Postgres, CNPG's plugin, raft snapshots for a vault) is the right call for consistency. But it multiplies the number of places your retention policy, your storage target, and your restore procedure all have to line up and if the underlying block storage or object storage changes shape every time you switch environments, that circus gets a lot harder to run.
This is the layer most backup conversations skip past, because it's assumed to just be there. It usually isn't, consistently, across on-prem and multiple clouds.
What a portable infrastructure layer buys you
This is squarely the problem VEXXHOST's Atmosphere platform is built to remove. Cinder-backed block storage, with CSI integration and snapshot management, runs on the same OpenStack APIs whether your cluster is in VEXXHOST's public cloud, a dedicated hosted environment, or fully on-premise.
And that consistency isn't limited to the Ceph RBD default; the same portability extends to the other backends Atmosphere supports, including Dell PowerStore, Pure Storage, and StorPool. Automated backup support is enabled per-backend through Cinder's configuration rather than switched on globally out of the box, but it's the same Ansible inventory setting across every edition, so it's configured once and carried forward rather than re-learned each time you change environments.
A Velero deployment (or Kanister, or your own restic job) still needs an OpenStack-specific plugin to talk to Cinder snapshots — that setup work doesn't disappear — but it's the same plugin and the same configuration pattern regardless of which edition or backend sits underneath it.
The same goes for the backup target. VEXXHOST's Object Storage service speaks both S3 and Swift APIs with bucket policies and encryption at rest, so it can sit behind Velero or restic as the destination repository without tying you to a single hyperscaler's object storage. Pair that with the Key Management service, which handles encryption keys, rotation, and HSM support on Hosted and On-Premise editions, and the backup data itself is protected with the same rigor as production data, from the start.
Because the whole stack runs on OpenStack and CNCF-certified Kubernetes underneath, the environment itself is defined as code — Heat templates, Terraform, or Ansible — so the infrastructure your backup tooling depends on is versioned right alongside the YAML manifests for Velero schedules or K10 policies. And when a restore needs to happen under pressure, Ceph RBD's copy-on-write design makes volume-level snapshot restores fast in practice, with 24/7 support from VEXXHOST's OpenStack engineers behind every edition — Cloud, Hosted, and On-Premise alike.

What this doesn't replace
Worth saying plainly: none of this makes Velero, Kasten K10, or Kanister unnecessary. Those tools do the job most backup debates are about namespace-aware scheduling, retention policy engines, application-consistent snapshots, restore orchestration. VEXXHOST doesn't compete with that layer. What it removes is the tax you pay every time your backup tooling has to be re-plumbed because the cluster moved between a cloud provider and a datacenter, or because the object storage target changed shape.
Pick your backup tool based on what your applications need. Just don't let the infrastructure underneath it be the reason that choice stops working the moment you change where the cluster lives.
Running Kubernetes across on-prem and cloud and tired of your backup strategy breaking every time the environment changes? Talk to our team about how Atmosphere's storage layer fits underneath the backup tools you already trust.