Broadcom has donated Velero to the CNCF, and that matters more than it sounds. Velero is a backup and restore tool for Kubernetes, and moving it under...
Broadcom has donated Velero to the CNCF, and that matters more than it sounds. Velero is a backup and restore tool for Kubernetes, and moving it under community governance changes who steers the project, how trust is built, and how long operators can rely on it. I’m Ermenildo V Castro, and I’ve seen enough platform software to know this kind of handoff can either clean up a mess or expose one.
Key Takeaways
- Velero is now under CNCF community governance.
- Kubernetes backups are about restore speed, not just file copies.
- Vendor control can slow trust; community control often improves it.
- Teams should still test restores, because backups that fail on recovery are just expensive decorations.
- Operators should review storage, snapshots, and disaster recovery plans now.
What is Velero and why does this move matter?
Velero is an open source tool for Kubernetes backup, restore, and disaster recovery. It helps teams save cluster state, persistent volumes, and app resources so they can recover after outages, bad deploys, human mistakes, or cloud trouble. The donation to the Cloud Native Computing Foundation (CNCF) shifts the project from company control to neutral community stewardship, which usually lowers fear among users and contributors.
That sounds dry. It is not.
In real operations, backup tools live or die on trust. I learned that the hard way years ago when I helped untangle a messy cloud recovery plan at scale. The docs looked fine. The demo looked fine. The first real restore was where reality showed up wearing steel boots. The job was not to copy bits. The job was to bring a service back without making the outage worse.
That is why Velero matters. It sits in the ugly middle between Kubernetes control planes, persistent storage, cloud snapshots, and disaster recovery drills. If the tool is brittle, your recovery plan is brittle. If the governance is shaky, the community slows down, and operators start asking whether they should trust the project for the next five years.
CNCF governance changes the tone. It means more shared ownership, clearer rules, and less chance that one vendor can yank the wheel. For enterprise users, that matters a lot. For small teams, it matters even more. Nobody wants their backup plan tied to a single company’s roadmap, especially when uptime, compliance, and customer trust are on the line.
Here’s the kicker: most teams say they have backups, but few test restores often enough. That gap is where Velero earns its keep. For a deeper view on how cloud-native systems are managed, see the CNCF’s own project pages at CNCF Velero project overview and the broader governance model at Cloud Native Computing Foundation.
Core benefits of Velero under CNCF governance
The biggest benefit is simple: neutral stewardship. That is not a fancy phrase. It means the project is less likely to be shaped by one company’s sales plan, and more likely to follow the needs of users, maintainers, and contributors.
I have worked on platforms where the backup tool looked solid until the vendor changed strategy. Then roadmaps shifted, docs got stale, and the support emails started sounding like legal paperwork. Not fun. Community governance does not fix every problem, but it does reduce the odds of being trapped by corporate mood swings.
Other benefits are practical:
- Better long-term trust — Operators want tools that survive management changes and product pivots. CNCF backing gives Velero a clearer home.
- Stronger ecosystem fit — Velero works with cloud snapshots, storage plugins, and Kubernetes resources. Community review helps keep compatibility issues visible.
- Healthier contributor model — More maintainers can mean more patches, better issue triage, and cleaner releases. That matters when bugs hit production at 2 a.m.
- Clearer enterprise comfort — Security teams and compliance folks often like neutral governance. It helps when tools are part of audits, retention rules, and disaster plans.
- Real backup discipline — Velero pushes teams to think about restore paths, not just backup creation. That mindset is where mature operations begin.
Most guides talk as if backup is just storage. It is not. Backup is a promise about human responsibility. If we store customer data, we owe them a sane recovery path. That sounds moral because it is. Work should serve people, not just dashboards.
Broadcom’s donation also sends a signal to the cloud-native world. Not every useful project has to live forever inside a vendor’s house. Some tools do better when they belong to the commons. That idea has roots older than tech: stewardship, accountability, and shared duty. Frankly, that is how durable systems are built.
For a broader view on CNCF project governance, the CNCF project process is worth a look, and for Kubernetes backup patterns, the Kubernetes administration docs remain a solid anchor.
How to evaluate and implement Velero in a Kubernetes cluster
If you are planning to use Velero, do not start with features. Start with recovery goals. That sounds backward, but it is the right order.
I’ve watched teams buy tools first and ask questions later. Bad habit. The restore drill always reveals the truth, and the truth is usually messy.
Use this process instead:
- Define what must come back — List namespaces, deployments, config maps, secrets, and persistent volumes. Decide what must be restored in minutes, hours, or days.
- Map your storage backend — Velero can use object storage and snapshot plugins. Check whether your cloud supports the exact snapshot path you need.
- Test restore paths early — Run restore drills in a staging cluster. Do not trust a backup until you have restored from it at least once.
- Check plugin and version support — Kubernetes moves fast, and plugin mismatch hurts. Read release notes before upgrades.
- Automate backup schedules — Scheduled backups reduce human forgetfulness. Humans are good, but they miss things under pressure.
- Document the recovery runbook — Put restore steps where on-call engineers can find them. Keep it short, clear, and boring.
- Validate retention and security rules — Make sure encrypted backups, IAM permissions, and retention settings match policy. If your organization handles sensitive data, this is not optional.
When I worked on large-scale systems, the best teams treated backup as part of system design, not an afterthought. They had clean runbooks, frequent drills, and a habit of checking assumptions. The weak teams trusted screenshots. Screenshots do not restore a cluster.
If you need a deeper technical base, the official Velero documentation explains setup and backup workflows, while the Kubernetes backup and restore guidance helps frame the broader recovery model.
Velero vs. proprietary Kubernetes backup tools
A fair comparison helps. The biggest competitor here is a proprietary backup suite from a cloud vendor or enterprise software company. Those tools often promise tight integration, polished dashboards, and bundled support. Fine. Sometimes that is useful. Sometimes it is just a pricey seatbelt with bad fit.
| Feature | Velero | Proprietary backup suite |
|---|
| Governance | CNCF community | Vendor-controlled |
| Lock-in risk | Lower | Higher |
| Kubernetes focus | Strong | Varies |
| Extensibility | High via plugins | Depends on vendor |
| Cost model | Open source, infra costs still apply | License fees plus infra |
| Community visibility | Broad and public | Limited to vendor channels |
| Long-term roadmap control | Shared | Centralized |
| Ideal user | Cloud-native teams | Teams wanting one throat to choke |
The plain truth is this: proprietary tools can be easier to buy, but harder to trust over time. Velero may require a bit more operator skill, but it gives teams more control over how they back up and restore their clusters.
That tradeoff matters in Kubernetes because there is no magic box. Your data lives across volumes, objects, secrets, and control-plane state. A tool that understands that shape is worth more than a glossy sales deck.
Still, let’s be real. Open source is not free. You pay in staff time, testing, and operations discipline. That is normal. Good tools do not remove responsibility; they make responsible work possible.
When I was at Microsoft and later at Amazon, I kept seeing the same pattern: teams that owned their runbooks moved faster during incidents than teams that outsourced their thinking. That is the dirty secret of platform work. Skill beats packaging.
For more on Kubernetes operational planning, the CNCF blog often covers cloud-native operations, and vendor-neutral architecture guidance from Google Cloud’s Kubernetes best practices can add useful context.
Common mistakes teams make with Kubernetes backups
Most backup failures are self-inflicted. That is the annoying part.
People think the hard part is writing files to object storage. It is not. The hard part is knowing what a restore really needs, then proving it under pressure.
Here are the mistakes I keep seeing:
- Skipping restore tests — Teams create backups and assume success. That is lazy, not safe.
- Ignoring application consistency — File copies are not enough for some databases and stateful apps. App state and storage state must match.
- Forgetting secrets and config — Restores fail when config maps, secrets, or CRDs are missing. Small misses cause big headaches.
- Using weak retention rules — Keep too little, and you lose recovery points. Keep too much, and storage bills climb.
- Treating backup as storage only — Backup is also process, security, and documentation. It is a system, not a bucket.
- Not matching backup scope to business need — Some workloads need full cluster recovery. Others only need namespace-level protection.
Most advice online says, “Just automate backups.” Sure. That helps. But automation without proof is just fast failure. I have seen that movie, and it ends with tired engineers and awkward postmortems.
The better habit is to tie backup policy to service value. Customer-facing services need tighter recovery goals than internal tools. High-value data deserves more frequent backups and clearer ownership. That is basic justice in system design: protect what matters most, and do not pretend all workloads are equal.
A practical way to avoid mistakes is to use a drill schedule, not a wish. Monthly restore tests are better than yearly theater. Pair that with a short checklist and a known-good recovery namespace. Boring? Yes. Effective? Also yes.
For extra reading on backup and restore patterns, the Kubernetes StatefulSet docs and Velero backup reference are useful starting points.
Frequently Asked Questions
Is Velero only for cloud environments?
No. Velero is most often used with cloud object storage and cloud snapshots, but it can still fit hybrid or on-prem setups if the right plugins and storage targets are in place.
Does Velero back up Kubernetes applications automatically?
It backs up Kubernetes resources and, when configured, persistent volumes and snapshots. The catch is that each app still needs a restore plan that matches its data shape.
Why does CNCF governance matter for open source tools?
Because it reduces vendor control, improves public oversight, and gives users more confidence that the project will not vanish with a product strategy change.
What is the first thing to test after setting up Velero?
A restore. Always the restore. A backup you cannot restore is just a warm feeling in a log file.
Final Thought
Broadcom’s donation of Velero to the CNCF is a good move for Kubernetes users who care about trust, continuity, and clean recovery paths. I say that as Ernie Castro, and also as someone who has watched too many teams learn the hard way that backup plans are only real when the restore works. The software may be open source, but the duty is old-fashioned: do honest work, keep your word, and leave systems better than you found them. That is stewardship, plain and simple.
If you run Kubernetes, this is your cue to review your backup plan, test your restores, and ask whether your tools serve your people or only your org chart. The best systems are built with humility. They expect failure, prepare for it, and recover without drama. That is not flashy. It is wise.