This blog is based on a fireside conversation hosted by Philippe Ensarguet, VP Cloud & Software Engineering at Orange and Sylva Project Governing Board member, with Julien Mangeard, CEO and co-founder of Plakar, and Victor Coisne, GTM Leader at Plakar, on why recoverability, open source trust, and sovereign data resilience are becoming essential parts of the Sylva stack.
Welcoming Plakar to the Sylva Community
For multiple years, Sylva has been hardening almost every layer of the telco cloud, the platform, the networking, the lifecycle, and the validation. There is one layer we have been quieter about: the one meant to survive everything else,Recovery!
In a cloud-native Telco stack, we obsess over uptime. We rarely ask the harder question: when something goes wrong, and at some point it will, can we bring it back, fast, intact, and on our own terms?
Backup has long been a part of the stack everyone owns, and no one really trusts. You pay for it, you tick the auditor’s box, and you find out whether it actually works on the worst day of the year. A platform’s maturity is not measured by how well it runs. It is measured by how well it comes back.
That gap is exactly why we are glad to welcome Plakar to the Sylva community. To mark their membership, I sat down for a fireside chat with Julien Mangeard, co-founder and CEO of Plakar. We talked about why backup is a trust problem before it is a feature problem, why deduplicating before encrypting changes the economics of protecting everything rather than just the critical 20-ish%, and why sovereignty is an architecture you can prove and not a slogan you bolt on.What data resilience should mean for a telco cloud now carrying AI workloads to the edge.
My hope coming out of this conversation is simple: that recoverability becomes a default property of the Sylva stack, not an afterthought each operator resolves alone.
Here is what Julien had to say.
Julien, let’s start by explaining who Plakar is?
What problem were you living with that made you start Plakar?
For most of my career I was on the operator side, most recently as CTPO at Veepee. The thing I kept living with is that backup is the part of the stack everyone owns and no one trusts: you pay a fortune, you tick the auditor’s box, and the day you need it, recovery is slow, partial, and scattered.
And the problem is accelerating. Breach is no longer a risk you manage down; it is a certainty you plan around. Ransomware has industrialized, and attackers hit the backups first, because that is what stands between you and paying.
AI sharpens both sides at once: attackers exfiltrate data faster than anyone can trace, and defenders build pipelines on data they cannot afford to lose or leak, which makes resilience critical to any sound AI strategy. So the gap I lived with is widening, not closing. Plakar started from one conviction: backup is the last line of defense.
Why did you conclude the answer had to be open source rather than another proprietary backup product?
Because backup is a trust problem before it is a feature problem. You are handing a vendor the one copy of your data meant to survive everything else, yet with most products you cannot read the code, review the cryptography, verify the recovery path, or get your data out without the vendor’s blessing.
If the recovery path runs through a black box, it is not a last line of defense, it is a dependency. Open source fixes the incentive: you can audit the crypto, prove it against your own data in days, fork it if you like, and keep your data in a documented, portable format whatever happens to the company. A proprietary product asks you to trust a promise. Open source lets you verify it.
What is Plakar, and where does Kloset stop being “yet another backup tool” and start being something different?
A backup tool copies bytes somewhere and hopes you can read them back. Kloset is a data store, not a copy job. It splits your data into deduplicated, compressed, encrypted chunks, addresses each chunk by a content fingerprint, and stores them in an immutable, self-contained, portable format. Because it captures the maximum context around your data, not just the bytes, you can query and browse it at fine granularity. That single design choice changes what you can do with it. It stops being “yet another backup tool” because it is queryable, browsable, immutable, zero-knowledge, and storage-agnostic. So Kloset is closer to a verifiable, queryable container for data than to a backup file. Backup is one thing you do with it
Plakar’s team has been contributing for decades to critical open source projects, so what did building infrastructure that thousands of people depend on teach you that you’ve carried into Plakar’s design?
My co-founder Gilles Chehade wrote OpenSMTPD and was an OpenBSD core committer for years, and several of us come from that world of software that quietly runs critical infrastructure for a very long time. A few lessons carried straight into Plakar:
- Boring, auditable, and stable beats hype. Infrastructure people deploy things they trust. So our format is documented, the crypto is reviewable, and the behavior is predictable. Trust is hard to win and easy to lose.
- Formats outlive vendors. Email is still readable decades later because the format is open and stable. A backup you cannot open in ten years is not a backup. Kloset’s on-disk format is open and portable on purpose.
- The community is part of the security model. Code that thousands of people read and run gets hardened in ways a closed product never does. We design Plakar to be inspected, contributed to, and verified, not just consumed.
I’m really curious about what makes you unique?
In the backup ecosystem, most tools force a choice between deduplicating data and encrypting it. You do deduplication before encryption, on data that’s already zero-knowledge. Why does that ordering matter, and what does it unlock that legacy tools can’t reach?
Encryption normally kills deduplication: good encryption makes identical inputs produce different outputs, so an encrypted blob looks unique even when the data is a duplicate.
Legacy tools make you choose, encrypt and watch storage bloat, or deduplicate and leave data readable, and most teams pick “encrypt the critical stuff, dedup the rest” and do neither properly. We do it in the right order: chunk and deduplicate first, then encrypt, at the source of zero-knowledge data, so only the missing chunks get encrypted and sent. The result is high dedup density on fully encrypted data: we backed up 12 months of English Wikipedia dumps into a single Kloset store, where around 1.35 TB of logical data occupied just 463 GB on disk, a ~66% smaller footprint.
You describe Kloset as “a container for data”, self-contained, immutable, queryable. What follows from immutability and queryability that an operator wouldn’t get from a conventional snapshot, especially when ransomware is the threat model?
96% of modern attacks target backups first (Veeam 2024 Ransomware Trends Report): the attacker deletes your recovery copies, then hits production. So the question is not “do you have a backup,” it is “can the attacker already inside also destroy your recovery path.” Two properties answer that.
Immutability means a snapshot cannot be silently altered or deleted, and a tampered chunk fails its hash, so you do not trust the backup is intact, you prove it.
Queryability is what most people miss mid-incident: with a conventional snapshot, finding what was hit, when it was last clean, and which point is safe means restoring candidates and inspecting them, which is slow when you have no time.
A Kloset snapshot is a navigable, content-addressed filesystem, so you diff across recovery points without a full restore, find the last clean state, and recover exactly that. Immutability guarantees a clean copy survives, queryability lets you find it fast. Conventional snapshots give you a sealed box and a prayer.
You’re engineered for exabyte-scale with a small footprint, and you’ve shown S3 backups going from minutes to seconds. What’s the architectural decision behind that, rather than just “we parallelised it”?
Parallelism is the easy part everyone claims. The real decision is content-addressed, deduplicated state: every chunk is addressed by its content hash and the store knows what it holds, so a backup run reduces to “compute what is new and send only that.” On an S3 dataset that barely changed, you are not re-shipping it, you are reconciling hashes and moving the few genuinely new chunks. That is the minutes-to-seconds difference: the work is proportional to the change, not the size.
The small footprint comes from the same root: the metadata and chunk index are designed so you never hold the whole dataset in memory, so Plakar scales vertically and horizontally on limited RAM and reaches exabyte-scale without a machine as large as the data. One idea, content addressing, paying off as speed, storage efficiency, and scale at once.
Julien, we are really proud and happy to have you, but could you elaborate on why Plakar decided to join Sylva?
Sylva exists to harden cloud-native infrastructure for telco and edge. Where does data resilience sit in that picture today, and what gap did you see that made Sylva the right home rather than the broader CNCF landscape?
CNCF is where the general-purpose cloud-native conversation happens, and we are part of it too. But Sylva is where the specific requirements live that make our architecture matter: distributed edge with thousands of clusters and constrained footprints, sovereignty and compliance as first-class needs, telco-grade hardening.
Those are exactly what Plakar was built for: zero-trust, small footprint, storage-agnostic, recoverable on your own terms. Sylva is the right home because the problem we solve is a named gap in a stack that is otherwise mature, not a generic “backup is good” pitch.
Sylva was born partly from a sovereignty conviction, privacy, security, and keeping European networks in European hands. As a French open source company with zero-knowledge encryption at the core, how much of your decision to join is technical and how much is shared values?
They are the same decision, and that is the point. Sovereignty in infrastructure is not a slogan you bolt on, it is an architecture you can prove. Zero-knowledge encryption, an open portable data format, no vendor-mediated recovery path, the ability to run on European or self-hosted infrastructure: those are exactly what “keeping European networks in European hands” requires once you get past the press release.
A backup layer that ships your recovery copies through a US-controlled SaaS control plane fails to test, whatever the marketing says. So the engineering is how you honor the values: French company, European engineering team, open source core, reviewable crypto, the operator keeps the keys. We did not adopt zero-trust because Sylva asked, we built it because we believe what Sylva believes.
What conversation or moment convinced you Sylva was where Plakar should put its effort?
Honestly, it came out of a conversation with you, Philippe. We were talking through Kubernetes backup strategies, specifically how we were approaching the backup of the clusters themselves and the applications running around them. That’s when it clicked for me that Plakar was a great fit for Sylva, and Sylva a great fit for Plakar.
I remember I was at Cloud Native Days that day, and we spoke over the phone. I thought to myself: who better than telecom operators running demanding production environments to pressure-test our thinking on how to deliver the best possible resilience layer for the cloud native stack?
Finally, could you share with us what Plakar brings to the community
How does Plakar fit a Kubernetes-native, CNCF-driven stack, backing up stateful workloads, cluster state, and the data that 5G Core and edge functions depend on?
It fits the way everything else in that stack fits: declaratively. With the Plakar Kubernetes Operator, teams declare their whole backup strategy as native CRDs, sources, storage, schedules, retention, replication, verification, that live in Git and reconcile continuously, so a BackupPolicy is just a YAML resource you kubectl apply, and the same policy runs through the Plakar API, a Terraform provider, or Ansible. No separate console for resilience, it lives behind the control plane you already have.
That covers the three things a CNF stack needs protected: the stateful workloads behind 5G Core and edge functions, the cluster state, and the application data those functions depend on, with edge-grade policies like a 15-minute schedule, 30-day immutable retention, and replication across third parties like OVH and Scaleway.
And because Kloset is storage-agnostic, zero-trust, and small-footprint, the same model runs at a central cluster and a constrained edge node, no heavyweight appliance per site, just one declarative resilience layer from core to edge.
Telco infrastructure is increasingly carrying AI workloads, and you pitch backups as active assets for AI pipelines rather than dead storage. What does that look like concretely for an operator running inference or training at the edge?
Start with the cost: AI workloads store the same weights and checkpoints over and over, and Kloset’s dedup across encrypted checkpoints means you stop paying to store the same multi-gigabyte artifact twelve times, which alone makes AI-at-the-edge affordable. But “active asset” means more than cheap storage. Because every snapshot is immutable, content-addressed, and queryable, it becomes a usable surface in the pipeline: reproducibility and governance (pin which dataset and model state produced a result and prove it later, which for regulated telco AI is the difference between “we think” and “we can show”), gating (train or promote only on a verified, immutable snapshot), surgical restore (spin a known-good checkpoint into an ephemeral environment without a full extraction), and agent-drivable policies (an agent manages posture, triggers a restore, or gates a training run with the same primitives a human uses). For an operator at the edge, that is a backup layer that participates in the AI workflow instead of dead storage you hope you never touch.
What do you actually want to contribute, code, integrations, validation work, a reference pattern, and what do you hope to get back from the Sylva community in return?
We want to bring a reference pattern for data resilience on Sylva, how to protect stateful CNFs, cluster state, and edge data in a sovereign, zero-trust way an operator can adopt rather than reinvent, plus the validation and conformance work so members can trust Plakar in a production-grade stack.
In return, we hope to get real edge and telco requirements from operators at scale, the constraints that keep us honest about footprint, distribution, and sovereignty, a community that reviews and hardens the work, and a shared definition of “resilient” for telco cloud so resilience becomes a default expectation, not a per-operator scramble. If we help make recoverability a default property of Sylva, that is the win for everyone.
What Comes Next
A few things stay with me. Backup is a trust problem before a feature problem, and trust is proven, not promised. Sovereignty is the same: not a label, but an architecture you can audit, with the keys in the operator’s hands. And resilience, done right, stops being dead weight and becomes an active, queryable asset, all the more as our networks carry AI workloads to the edge.
So the work now is simple to state: make recoverability a default property of the Sylva stack, not an afterthought each operator resolves alone. Welcome aboard, Plakar and Julien. Let’s build it!
