What does it actually take to build a backup system from scratch?
Not just slap together some Arsing scripts and call it a day, but engineering
something that handles deduplication, encryption, compression, indexing,
and restoring in one cohesive tool.
Well, today I'm joined by Julian and Gilles, the CEO and CTO of Plakar,
a new company, but built on nearly a decade of R&D in building open
source backup systems from scratch.
I am excited about this one because Plakar goes beyond just backing
up your typical workloads like databases, file systems, and S3.
It also can back up connectors like Google Drive, iCloud Drive, OneDrive, and even
things like Notion Dropbox and imap.
Yeah.
You remember imap?
Well, they've recently joined the CNCF, so we talk about their
upcoming Kubernetes integration, obviously a part of this channel.
And on the show I suggested that they build the ability to back up to Docker
images, basically to OCI registry storage really is what I was asking about.
And then like within a couple of weeks they went off and built
that, uh, as a new integration.
That's pretty dope.
This is the one backup tool that I've seen in really, maybe ever, but
definitely recently that not only looks useful for work and server workloads and
clusters and clouds, but is something that I think I want to try to back
up my own personal iCloud and Google Drive and notion and all those things.
Which I, I've found historically are, is actually very problematic, challenging to
find a free tool that isn't just cobbled together with a bunch of different things
and something that's reliably able to be restored in a reasonable amount of time.
So I'm, I'm excited about this tool 'cause I feel like it, it affects multiple parts
of my job and life and it's open source.
So let's get into it.
We're going to talk about backups.
We've talked about that before, but there's so much more to backups.
We're going to get into it.
I'm excited.
you all started a company.
how long ago?
We can give two answers on this one, the first one is that the company
has been incorporated in 2024.
Yeah.
it's a quite new company to support this project, but this project is, quite, old
in the sense that Gilles did a lot of R& D, in the past 10 years on it, so.
Yeah.
What I was noticing as I was digging through the project was there are a lot of
foundational things when you're creating a backup product that you have to define
that a lot of us don't think about.
I, the only thing I can think I can equate it to not being a developer
of a backup product is similar to creating a new database product because
you had to create a file format.
You had to create a streaming, backup format.
You had to go, I would imagine, much more low level than the typical application
developer has to go because you had all these underlying fundamental
concepts of, you know, things like the backup file, the caching of the
backups, all that stuff that, yeah,
yesterday I was at a meetup and I was presenting the product.
Someone, asked me like, why did you go into backup?
That seems like a very boring, area.
yeah, and it's, if you take it from a developer perspective, it goes from
very low level to very high level.
It trusts all, like many fields of, computer science that
you might be interested in.
If you have, like a high appetite for tech.
So you have to know about how a fast system works.
You have to know how, how to manage your memory, how to manage high concurrency,
how to manage, like file formats.
In our case, we kind of developed a database in a sense
because you have a bit tree.
You have a sense of how to manage, match your bit tree to something.
So yeah, it's very, complete as a project to, to dive into technical topics.
I was like, Oh, this is going to be a small project, small side project.
And then you realize that, Oh, you end up doing cryptography, you end up
doing compression and stuff like that.
And you, like any area you look at, you're going to find ways to
improve it and go further into tech.
Yeah, I can only imagine how much time is spent, on like the engineering
fundamentals of a giant file that you need to do various things with,
because most of us don't deal with terabyte sized files on a daily basis.
to me, the biggest files I have to deal with are model files,
like open source model downloading and uploading, like that's the
biggest thing I have to deal with.
maybe if I was in an enterprise, I'd have big backups and stuff like that.
I used to manage backups at a Government Enterprise, about 7, 000 users.
That was 15 years ago.
And I had two dedicated staff that worked for me.
All they did was manage the storage and backups.
Their entire job was ArcServe, I think we were either using ArcServe
or NetBackup, but we had, you know, Windows machines, Macs, we had, Linux
machines, we had mainframes, and it had to handle all of that stuff.
And this was pre cloud, so we didn't even have to worry about How do I
back up cloud storage or what we didn't even have S3 at the time.
That wasn't a thing that much in the early 2000s, but it was so time
consuming and such a nerve wracking effort to deal with recovery,
which most people don't talk about.
Like we don't spend a lot of time.
when you're talking about backups, everyone's concerned
about the backup part.
And I always focus more on the recovery part.
And I get more excited about the recovery.
Like how easy is it?
How fast is it?
how fast can I discover the thing that I need to recover?
Because often that's the, trick.
If you're backing up hourly and daily and monthly and weekly, and you've
got all these incrementals all the traditional backup terminology, like
sometimes you're like, well, we, that person needs to recover that file.
But it needs to be the one that's not today, because that
one was corrupted or whatever.
So then you end up Like sleuthing through a giant caching system trying to find
the one file or the one directory on one server somewhere amongst a thousand
servers that you had to back up that day.
And how do you do all of that reliably and in a way that you get,
that two people can handle the data.
And now I don't know any, I don't know any customers of mine or anyone
who has two people managing backups.
It's like a part time job for one person.
So, Something has changed.
When you tackle that issue of how do you find the proper thing to restore in a
fast way, you end up realizing that you have to develop some kind of database.
It's not just a backup, it's not just like gluing files together into some kind
of archive that's going to be efficient.
You have to actually have indexes, find things in an efficient way, be able
to generate diffs between versions of files and do it in a way that can scale.
Because it's not really just a volume sync.
It's more, how many files am I going to have to look into?
And, like a large volume of small files is as problematic as, I
think to back up huge files,
Also the performance, lots of small files isn't exactly performant on a lot of
systems, but I mean, since I was stopped managing backups, we now have SSDs.
So like I lived in a world where we had spinning disks and things were super
slow and, you know, if you had gigabit networking, you were actually doing
great, and, but times have changed.
So when I look at this, like where's the elevator pitch that when I looked at the
website, the thing I took away from it.
It was one open source, run on my own hardware, on prem, wherever I want to run
it, and it has this idea of integrations, which is not new, like most backups.
You have to have like compatible, like it has to be compatible with this database
file or this type of storage or this NAS or this, iSCSI thing or whatever,
but in your case, it looks like the integrations are more cloud focused.
So they're dealing with HTTP, but specifically different APIs.
Like I saw Notion in the list, which I'm a huge Notion fan.
I never thought about backing up my notion like that.
Then now that I know that it exists, I'm now like obsessed about, maybe
I should be backing up my notion.
Like, why are the, how did this happen?
how did the integration list happen the way it does?
maybe to start and let you complete, Gilles, but, um, you realize that most
of the SaaS provider right now, they are on a shared model responsibility.
So it means that you are in charge of the backup.
In the case of Notion, for example, they are not providing any kind of backup,
and you have to do it by yourself.
And when you look on all the SaaS that you are using for personal use are.
Even for, you know, enterprise usage, you see that a lot of, you have a lot of all
in your, resilience, or in the protection of your data and I think it was important
to have, software that is able to, manage, I would say, the legacy tasks like, you
know, backuping files, et cetera, but also be able to back up any kind of data.
including, of course, everything coming from SAS.
So I think at some point in the product, we decided, okay, it's not, a backup
solution that is supposed to backup only files, but a backup solution that is, so
it should be able to backup any kind of data and maybe you can tell a bit more
about, you know, how did you do that?
the, just to mention about the open source part, the main driver initially
was to avoid having, vendor locking.
Because, you don't have that many solutions that can back up many
sources and that are not closed today.
you have hacks, you have scripts that bundle a bunch of solutions, but you don't
have one solution that you can trust.
And, and it so happened that a friend of mine who has like a
degree in computer science, so he's like fairly educated on the topic.
He managed to lose all his data because he used a set of scripts
that did not behave correctly.
And, he did not realize because, everything seemed to be okay
until the day his server crashed.
And he had to rely on the restore part that everyone overlooks now.
and the thing is, if he had a solution that was not a glue of multiple script
and rsync and blah, blah, blah, they would, this would not have happened.
and now you end up having to look at what solution allow you
to, a backup multiple source.
And you end up Having to go generally towards commercial solutions,
that will provide support for multiple sources without hacks.
And they will usually have, some kind of closed format.
So you have to trust that they will not go away or they will not
bump their prices and that you can trust them on the long run.
And what I wanted was to initially have a well documented format that
We are going to be fully open with a license that prevents closing the code.
if we decided to go wrong, someone would just fork the
code and it will go that way.
so that, that's a safeguard against ourselves going wrong.
Yeah.
And then you have, what do you do with that?
how do you manage multiple sources?
And you realize that most of the open source solution, either there
are, there are three, Fairly targeted at, at doing synchronization like
rsync and they are twisted into doing backups through hard links, like
tricks,
or they have a high, file system, like they're highly built around
the concept of file system.
So you can actually do a backup of an S3 bucket, for example, but
that's using a trick to map the S3 bucket on your file system.
So they have, limitations And, they do not work well when you break this
limitation, if you create a bucket and put 2 million objects in it and try
to mount it to the file system, that's not going to work very well for you.
There was a, like a disruption in how do you model this?
How do you model this issue that you want to import various sources, you don't
know these sources yet, and you want to be extensible and have a plugin system,
so you don't even know what plugins will be written in a year from now, and make
it fit in a model that will scale if you have flat, flattened data at the root.
Designing this model, we came up with something abstract enough that you can
kind of prove that anything can go in.
And ourself, we work with that abstraction so that, like they all benefit from
the same, same deduplication, same encryption, same, like same features
without, Like when you write a plugin yourself, you would not have
to think about all the details.
You would just have to think about how do I get the data
from this point to this point.
It will do the work once it's there and in a very simple API.
So our most of the work was done on that.
Finding that abstraction that allows us to work efficiently, but assuming
a wide variety of, of sources.
And most of the integration that we have are, some are tagged stable
and some are tagged beta because we are a bit hard on ourselves because
beta does not mean it does not work.
It means that, we want to show it works.
And depending on the, how people are interested in that backend,
we might drive that one, further in terms of, projection readiness.
but they all work, to some extent.
I can imagine like little edge cases of a lot of this stuff, especially
when you're pulling and pushing from an API that isn't exactly.
I have interesting questions.
It's like, okay, with the notion, how exactly does that recovery work?
And what if there's duplicate data, do you, where do you know, we all can
conceptually, we've all, most of us have all dealt with file based backups, right?
Same single system, same host.
Easy, easy day, right?
you're not even dealing with remote storage.
And then, like, people tend to evolve into a, okay, now I'm doing, like, SMB mounts
or something to put some files elsewhere, I'm doing low tech rsync or something.
and then there's, this giant chasm, I feel like, which is, there's all
those little utilities that are very niche and very composable, but you're,
like, you're saying, you're building your own scripts, you're building your
own, orchestration, essentially you're designing the orchestration yourself.
And then from there to a complete cohesive strategy that uses one
or two products maximum, you suddenly jump into like enterprise.
There's a lot of enterprise backup garbage out there, I feel like,
like there's a ton of stuff that.
Especially when it comes to cloud APIs, I do this every year.
Every year I have, I'm a small business of, you know, three to five people,
depending on what year we're talking.
And I, so I have some business needs.
But mostly they're the sim the backup needs I have are like what a person
would ha an individual would have.
I have iCloud, I have, you know, Google Drive, I have Dropbox, I
probably have STP FTP somewhere.
I have Notion, I might have some S3 buckets, and I have Macs, and I
need to, manage all these things.
I have a an Ubuntu server in the closet, There are things and places, I would
honestly love my GitHub Git repos to be backed up automatically just in
case GitHub goes down and I need to move to, you know, GitLab or something.
And when I look at, just for Google Drive or iCloud or OneDrive, any of the sort of
top three cloud file drives or whatever you want to call them, They're really,
I couldn't find a single product on the internet that I could buy for one person.
It seemed like all the products out there that were like, yeah, we'll back up your
company's Google Drive, because that's, you know, I have the company version of
Google Drive and the company version of OneDrive and Those don't always work with
all the consumer stuff, or if you're using CyberDuck or some other little utility.
I was looking into backing up three people's Google Drive, and I was
looking at possibly having to spend 500 a month on an enterprise piece
of software because their minimum License purchase was like five users
or 10 users or something like that.
And I gave up.
I eventually just gave up.
I couldn't figure out a scenario that didn't require.
A bunch of weird scripts with, you know, running cron jobs that would
probably never notify me in a failure that would run certain things.
And it just was a mess.
So you guys show up and suddenly I'm like this, I could do this in an
afternoon and it would cost me nothing.
Like it would cost me pennies with, Plakar.
Yeah.
and
the nice thing also about the, like our open source dimension, 'cause we
are an open source first, company.
Clearly whatever we do is open source.
Unless it's strategically not good to do it on purpose,
but that's the default thing.
it's to provide enough libraries and examples to empower users to
actually extend the integration.
Our goal right now would not be to be like, we handle all
the integrations ourselves.
That would be more like, an integration that's fairly critical to companies.
We would do it.
to provide some kind of level of quality, then if users want to implement
specific integration, we would like help them, get them forward because,
like if you want to use one tool to back up everything, you have to have the
manpower to do everything, which is not
going to happen.
and by making like some of the tasks we did today with my team was how
do we simplify the API even further?
So, so.
People are less likely to even shoot themselves in the foot while trying
to do something simple because that lowers the bar to being able to
actually, instead of spending your time writing a script, that's not going
to be very good, write an integration because it's as simple as that script.
And it's going to be like a reviewed and you're going to get help from others.
It's going to fit into one thing that actually tackles the difficult part.
And that's where I would like to reach in terms of open source.
How does this work?
in terms of the development are I mean, all the integrations are open
source, but what, how many of those integrations are created by the
community versus the core team is it, I'm assuming this is led by feedback.
Like people are asking for things.
So then you're motivated to make a, integration for them.
in terms of, how many were done by the community,
I'm just curious, like the ratio.
And now currently it's currently all of the integration were done by ourselves.
And
we have pushed, a few months ago, we have pushed the SDK and we are
trying to provide example and, you know, Simplify even further.
but it's the community that's driving the decision about which
one we do currently, for example.
Like people have been asking for IMAP and gcloud and stuff like that.
We're going to go spend more time doing that.
but yeah, the idea is to start growing the developer community, not the user
community, but the developer community into extending their own integration.
Yeah.
we reached a right level right now, a right level of, easiness, difficulty,
depending on how you see it, of writing on integration because it's, it boils down
now to writing one function that scans and allows you to enumerate your data.
And provides you an accessor to the data to actually read it.
Once you have that, it can plug into what we have and you get all the,
benefits behind.
Which means that some of the integration, like the Google Cloud integration
was done in half an hour, unplanned.
So one of the developers was like, Oh, well, I have a half an hour.
I'll do that.
And that's Okay.
He has the knowledge, but you can assume that someone who does not have
the knowledge will take more time, but he's not going to go from 30
minutes to a month doing that task.
You're not reinventing the wheel every time you want to back up
a different product and, cause I'm here for the Docker backups.
I'm here for, I'm here for, image registries to be a, from and to.
And for me, so I actually.
years ago, I created a small script called Docker Backup,
Volume Backup is like the name.
And it kind of took off a little bit and then Docker ended up adding it
as an extension into Docker Desktop.
And then eventually they just made it a default feature in Docker Desktop.
And so now like in the Docker community, volumes were never really
meant to be moved around as images, but they're just files, right?
So, I get more requests for fixing that shell script, if that's all it
is, and working on that than just about every one of my other examples, and
there's clearly a need for developers to have, to move or backup volumes on
their local Docker system, or whether it's Docker or Containerd or Cryo or,
whatever, it doesn't really matter.
Podman, the developer sometimes wants.
To move, you know, the database files that are on that Docker volume somewhere else.
And there's not really a move option.
Right.
And there's no easy way you kind of have to learn all these different
commands for extracting it out.
Do you put it in a tarball?
Do you put it in a container image?
Like all that stuff.
So I'm here for that integration.
So sign me up.
I'm going to make you laugh.
two days ago, I was having my sleepless night
of wondering what I was going to do.
I was looking into Docker because, we had a discussion a long time ago about, how
could we benefit from our deduplication to, lower the size of storage for
images instead of, layering layers, each of the layers could be deduplicated.
And so I looked into it because I had never looked into how the
backup of this stuff worked.
And they use tar as a format,
yep.
And we have a tar importer.
Which actually can extract a tar and back up what's inside the tar, which means
that you could back up all your images and have the duplications through them.
And I look into how it's happening with containers and we can back up
containers the same way, actually.
and metadata, That's all it is.
we have an integration that's not, not, you're ready yet because, it's
a small experiment, but something we could push forward, which is, okay,
we have already a tar integration, So
we can create a Docker integration, which is actually, an integration that talks to
the Docker API to get a stream of the tar that gets passed into the tar integration.
And then boom, you have a new thing that's packaged and not using a
script on the side, which is the goal.
So really that's the point of the, of, of, Plakar initially is
to allow doing this in ways that, oh, that stuff is not backed up.
How can I actually back it up, you know, in a clear way without too much effort?
Obviously, there's some dev here, but once it's done, it's
no longer dev for other people.
So, so there's that, but the idea is that then you, if you trust the tool,
you trust that your Docker backup is working the same way as your SQL
backup or your file system backup.
yeah, there's even a scenario where, You could use, cause you
know, a container registry is nothing but an object store really.
And there's a, there are in the cloud native community, there's sort of a
consensus around the container registry being the artifact of all things,
like the storage of all artifacts.
And so now we have all these different types, container images, it's just
one type for an OCI registry, but there's all these other now file types.
We can store Helm chart data in there.
We can still compose files in there.
Each one is its own.
It's not a container image, it's just a registry artifact, and there's even
utilities now that we use to, if we have a new type of object that we want to store
in the registry, we can use tool utilities to create the metadata for all that.
I'm not sure that necessarily a registry is a great backup storage location.
Like maybe an S3 storage system would be better.
cause all the clouds already have that, but they all also
already have image registries.
And so a lot of times when I'm working with teams, like if we're going to
implement some sort of new backup or some sort of new replication system,
or like we, if we need storage for something, it's a lot easier for
me to use what they already have.
What my ultimate back end storage, I mean, file storage and S3 storage probably
makes the most sense for the two types of storage for backups, but there's
probably other scenarios like container registries, and I love the idea that when
I'm on the site, the integrations can let me, it kind of clues me into which ones
are inputs and outputs and which ones are both, and it made, and just staring at
the options that you had made me think like, Well, you know, do, can I store, you
know, Google Drive backups in OneDrive?
And then, also store OneDrive backups in Notion.
Like, I started to wonder, what's my, what's, what is my, I have a
document that's the path of where all the things I need and where
they all go for backups, right?
If we're all talking about 3 2 1 storage for backups, like we've, we
often as backup engineers, even of your own software, your own, stuff at
home, you often forget a year later what you did with all it and how often
it backups and where is it going.
I tend to forget.
And I know I'm using Backblaze in some places and I'm using a
different cloud in other places.
And I have to document all of that for my own sanity because every year
I think I should check my backups and see if they're still working.
And then I forget, I don't know where my backups are, how they work.
And I have to go and redo all that research.
So the idea that I could maybe Get closer to having this in one product
is something that, I might have to, I might have to do and make a video on.
So, let's get some Docker stuff in there.
a break
think the only managed service that we are providing to the community right now
is to, you know, send some email if you have issue with your backup and a summary
of, you know, what you are backing up.
maybe we can cover this one because it will be always in your mailbox,
you know, what kind of backup you have and where it's stored.
So that could be nice.
Yeah.
And at this point, you know, once, once we have the image registry stuff,
then you start talking about Kubernetes and can we run this on Kubernetes?
let's talk about the storage for a little bit and get into the weeds of it
because I'm going to, I'm going to pick, bring this up and hopefully this isn't,
hopefully I'm not, trolling your issues.
But I brought, I was looking to deploy this before the show so that I could
come to the show and have feedback or experience to talk about and say,
yeah, I got it to work last night.
the first thing I go for being a Docker guy is I want to deploy the Docker image.
There's an issue open that's asking for the Docker image and, I think someone
replied and said, Oh, we're not ready yet.
We've got caching, we've got other things we've got to worry about and we need to
come up with a more cohesive strategy.
So I'm here for that cohesive strategy.
Let's talk about that.
what are the challenges that you're seeing?
And do you have a plan?
Because we mentioned, we talked a little bit before the show, but it
sounds like there's stuff coming.
So, not to spoil anything, but let's talk about it.
It's just that the feature requests came very early.
we had, like our first, server release that happened a few months before this.
we had, the first user feedback and we were trying to find the
priority, things to tackle.
and this came and requires some, Thinking from the team about what it
means to have a Docker image for this, because you have to actually mount
your volumes, within the Docker image.
You will not run this as an agent in most cases, or is it what users want?
That's an open question.
That's not an answer.
That's, you have to think about how are they going to use that?
Because the Docker image you're going to ship as an official one, you're
going to have to support it in some way.
You can't just.
say, okay, we just raised the Docker image and it's not doing anything useful.
And we had users saying, oh, well, we need to have a, this
is going to be run from a CI.
So it.
loses its state every time.
So you need to rebuild state.
Okay.
Well, that's going to be an issue because we need to have some persistence
out of the Docker image for this.
Some people saying, oh, I'm going to use this from a machine.
Yeah.
but that means you could have installed Plakar on your machine rather than
Docker, because it's going to be a, like a lot of work for us to support
a use case that's not that useful.
Whereas you could launch Docker as an agent with Plakar in it to go query the
other things because Plakar is flexible enough that you can run it as a, I'm
doing my job from the Plakar instance.
on my machine, but also as this is controlling the
backups from other machines and transferring data here and there.
I mean, depending on what direction you take, you would not
build that image the same way.
And that wouldn't, I don't know which one you would advertise the most.
Yeah.
Without having user feedback on this.
It needs to have discussion and we need to have users from the community telling
us that's what we need in the ary image.
And that's what, Is going to drive the development.
Um, that's
more, most of
the issues there,
is there a concept of backing up the system itself, like the configuration
and the plugin list, is it got an internal backup command that allows
me to save, essentially save state of the whole system outside of the
individual integration backups?
Well, there's two, things.
The first thing is that none of the state is, mandatory When you
run instance, you wipe your, cache, folder is going to rebuild the, state.
Yeah.
So you are going to lose the plugins that were installed.
But you can just click and reinstall.
so that would be the idea is if you did not have backup for this, you are not
in the last case because you just, you could go from a blank machine, you point
to the repository, it will synchronize again, and you will get a state that's
a working state for your backup.
If you need to have backup because you want to avoid having to re
synchronize or you want to avoid having to reinstall, well, you can
just backup the cache directory and you get a snap, a Plakar snapshot
with the configuration of your Plakar.
there's no particular, like things that you would have
to do to make this possible.
It's just, there's just a standard way of using Plakar basically.
Yeah.
on the infrastructure side of the storage.
you mentioned encryption, so it sounds like you, do you
support encryption of backups?
Is
that?
we have out of the box, the snapshots, the backups.
we talk in terms of snapshots, in terms of
a snapshot is a view of what the, whatever you imported as data,
all these snapshots, they are compressed and encrypted by default.
You have to actually, say, I don't want the encryption.
I want to work with plaintext
have to turn it off.
Oh, okay.
That's nice.
Secure by default.
I love it.
it's end to end encrypted, so you don't have, you don't
have a server, for example.
you're going to run it from your machine, and you're going to say, my import bucket
is on S3, and my storage is on gcloud.
yeah.
Yeah.
you don't have a server running at AWS and you don't have a server running at gcloud.
So all of this setup is stored in the configuration
of the store that you create.
It is standalone.
And we don't want to trust AWS or gcloud with keys.
And we don't have a third party that would hold the keys to
encrypt, decrypt with the strip.
So we act with them as if they were what we call dumpsters.
They don't do anything besides passing packets that they see and storing
them, that kind of storage layer.
Yeah.
So at the lowest level, what if I do it?
If I do the simplest thing, if I do the simplest deployment because I'm
an imp, I'm like, I'm primarily an implementer, you know, an operator.
So I often think about, okay.
is it going to look like when I have this thing set up?
what were the pieces of the puzzle sitting and what do I have to run
long term and what are the ports I need and how do these things connect?
So I'm guessing that there's a daemon or I don't know what you're calling
it, the server part, but like a daemon that runs somewhere all the time and
it has an, like an API that I'm like, I can use a local CLI to control it.
there's two parts to it.
There's the, let's say the client part, which is you running Plakar to import
data from a source and push it somewhere.
And there's whatever storage you have, which may be a local disk or
which may be an S3 bucket or which may be actually anything that,
that can actually, take a key value, object, store, yeah.
So that would be AWS and you don't have a server in between.
You have Plakar operating as a client to, to your AWS bucket, for example.
so everything from the duplication, compression, encryption is done on the
client side on the machine running Plakar.
So when the traffic leaves the machine, you know that it can be
tampered with without being detected.
it can be decrypted without having the keys that have not left your machine.
yeah.
that's the most simple case.
That's what you would do, on your home setup.
You would install Plakar on your desktop and you would run it from the
desktop saying the storage is there.
It's on my S3.
Then you have a different mode, which is, through the integration, you could
have a server, you could have the Ubuntu machine you said you had on your,
in your closet that could be running Plakar and taking care of connecting
through SFTP to all the machines on your network and doing the backup.
Then we have the non open source version, which we're working on,
Plakar Enterprise, which provides a server that extends Plakar.
So Plakar becomes the open source client to an enterprise.
Product, but same tool as you would use at home and the enterprise version
would provide a server that has additional features, like maintaining,
privacy of the credentials for all of your storages, for example.
So your clients at home would connect to your, your client on the workstation
at work, yeah, they would connect to the Plakar server of your enterprise.
And then that server would hold, the credentials, to the actual
storages, to not link them through the company, for example.
So you
have all these different ways of working that allows you to have very
flexible setups that go from, yeah, I have a mono machine and it's going
to connect directly to my store too.
I have.
segregated traffic and isolated machine that have different privileges
and cannot access that S3 bucket, but they could access this one.
And I can't trust them to do that.
So I have to have some layer of validation, as it's at a enterprise level.
Yeah.
is that allowing for like.
Multihop backups or, I'm trying to think of some of my more enterprise
challenging, like we had so many backups happening that, you know,
one server couldn't do them all.
So for bandwidth purposes, so we ended up with, in one scenario where
there was like a main orchestrator.
Server, and it had multiple backup, we just call them agent boxes, but they,
their purpose was to back up the data and create the snapshots, but the, but they
weren't necessarily backing up themselves.
They were backing up other machines that also had agents, but the middle tier
of fan out.
need to back up certain amount of terabytes every 24 hours.
if at the time, this was 20 years ago, but at the time we were limited
to one gigabit network connections.
So we were literally creating new servers in the middle tier because we
were saturating pipes and we couldn't get enough backups from all the
different systems in a 24 hour period.
So we had to add more middle tier, but there needed to be a central
orchestrator that managed the jobs that it was distributing to
the individual middle tier stuff.
But there, you know, there's a lot of small shops that I deal with where
one person is saddled with DevOps, and ops, and backups, and recovery,
and like monitoring, and logging, and storage, and cloud infrastructure.
Like they're just having to do it all.
I actually call them solo DevOps.
that's the label I give to these unfortunate individuals that are
given way too much, work to do.
Maybe AI will help them.
maybe we can, rely a little bit more on AI to help us with the advice on that.
But it's just, it ends up being a whole lot.
Right.
And I saw that you had a demo on the website, but yeah, I'm just curious
about how big does this get today?
And like, where's your vision for where the enterprise product
that you're building is going?
now, ransomware attacks are first targeting the backup system
of, you know, any companies.
So, for different kind of reason, encryption is required.
And you need to be sure that your storage And the backup server doesn't have
your credential of the encryption key.
Otherwise, if your backup system is falling, at some point, the attackers,
they have all your data in one.
So, end to end encryption is key.
Clearly becoming a kind of prerequisite for, you know,
securing your backup right now.
If we step back a bit you know, the issues that you mentioned about the
size of the backup, we solved that in the past with deduplication,
mainly on the, on the, filers.
So basically it was the storage that was, optimizing the space.
Duplicating the data, but it's work only with unencrypted data
because with Uncrypt data, you are of course losing, the duplication.
So today we are in, in a situation where we have companies that.
want to have end to end encryption on their data, but, they cannot,
you know, in that case, using the deduplication of the filers.
And so storing the backup will have a crazy cost to make it happen.
A lot of, vendors basically created kind of alternative with proprietary formats.
where they are still optimizing the space, but at the end they
have still the encryption key.
And what we are trying to do with Plakar is to solve this issue.
So basically, because we are doing the encryption, the compression, and the
duplication at source, it means that, all around the path where the backups are
going, they are already super optimized in terms of storage and in terms of space.
we have, almost, 15, 000, cycle of backups that we did, snapshot
that we did, on this machine.
the logical size is 24 terabytes.
So, we I have here a huge amount of data, but the space that we
are using is only 159 gigabytes.
Even if everything is fully encrypted and unencrypted, the storage has no
knowledge about the encryption key.
And I think It's a game changing thing of this technology, because it allows you
to move your backup everywhere you want.
You know, in any cloud provider, on premise, where you want, even if
you don't fully trust this provider.
And, but you can do that with an optimized, network cost because, you
know, sometimes if you want to synchronize data between cloud provider, you have
to pay egress cost, which is super expensive with huge amount of data.
And because you, with Plaka, you will just pay that at the first, for the
first backups that you are doing.
And all the snapshots that will follow will only transfer to your server.
the few blocks that were not backed up before.
So the storage optimized, and it's fully end to end encrypted.
today, I don't know so much, option to make that happen right now.
Yeah.
So it's doing incremental backups after the first, or
incremental snapshots, I guess.
there's,
I will let Gilles, but
we differential or incremental?
Yeah.
when you have a, an incremental backup, you actually create a chain of
dependency between all your snapshots.
The thing is, you get as, the more your chain goes without going
through another day zero of sync.
The more you increase the likelihood that you will have a
corruption at some point that will
break your thing.
And you, Yeah.
so you have a higher risk and you have to test everything very often
because you want to limit that risk.
Like you, you don't want to do, to go through the hassle of doing the
incremental backup, just to not test it and test it in a week and realize
that, oh, you have one week worth of.
Deltas that are trashed, basically.
Yeah.
And the idea is that, you can also take an approach that is a index reference
based, where basically what you're doing is not saying I'm building a delta
against what happened right before, it's building a delta against what's in the
store as a global storage repository.
So, Your backup actually benefits from any of the previous ones doing
anything, and you don't have a chain of dependency in the sense that you can
delete the one that happened yesterday.
It's not going to break any dependency with the one you have today.
as long as your store is, reliable, you can do any kind of removal that you
want with the granularity that you want.
And we can consider them as being, autonomous in the sense that each
snapshot is, autonomous by itself.
Does not require any other one.
the thing is you have to trust the storage anyways.
You're going to store your data there.
If you
don't trust it, well, you have to do something that's called three to one
backup to actually ensure you don't have one copy of your backup and you can
restore your broken backup from another backup.
that's the idea.
we have a cool way to manage it.
And so this allows you to have all the benefits of incremental backups
without the risk of incremental backup.
Yeah.
That's nice.
with the sync command right now, you can actually super easily, synchronize
a ClosetStore in several locations.
So basically you are pushing one backup in a ClosetStore.
And you can have two, three closet stores that are, replicating
those data in different locations.
So, yeah, for the, having all your backup in one closet.
will be too risky.
Of course, you need to have a backup strategy on top of it.
And we are providing a cool way to make it by, you know, having this
way to synchronize, with a again, low cost on storage and bandwidth, this
closed store in several locations.
So you are pushing in one place, and you are able to have two, three copies,
even in cold storage, to be sure that your data, are remaining safe.
If the first storage has some issue, but yes,
with different granularities, because, you might say, oh, since it's encrypted,
you may, you need to have the exact same copy, but that's not happening
because the snapshots are individual.
So you can actually, say, oh, I have one store, like on my NAS near my machine.
I will back up on my machine in the local disk, just to have user error
reparation, because I did it something, I have it immediately available.
But I might synchronize one snapshot per hour to the NAS and have that
one, span again, like one copy into AWS and one copy into Google cloud,
for example, and the synchronization, it's not doing another backup.
It's really pushing a copy of the snapshots through different, sources
Possibly have different, encryption keys as well.
it does, like trans, transformation between one, one to the other so
that in the end, each one has its own encrypted copy of the same data.
and, this saves from cases where, for example, you would have your machine,
you want to back it up to two places.
Yeah.
You would run like natively.
You would do, oh, I'm going to do a backup to AWS and I'm going to
do a backup to, to Google Cloud.
Yeah.
But in between.
Something may have changed.
You're not backing up the same thing.
When you're doing the sync, what you're doing is getting the info from one of the
stores and transferring it to the other.
So at the end, they have the same data, which has its benefits.
like if you lose something, it has benefits.
And we repair the store, also, if we have a
corruption,
repairing the stores as well.
if
you break something, you can actually repair it from the other one.
yeah.
And you can also, of course, run some check on the store to check, you know,
if the data is still, what you expect, in the store on two different way, right?
And we have R&D, projects about, error correcting codes to auto repair,
maintenances and stuff like that.
just wish to be clear, the crypto, we did not do it ourselves.
it's We are a team of people who have worked in security a lot.
We have been facing specs a lot about crypto in banking and stuff.
So we kind of had a hunch about what should be done on where.
And we had an external, independent auditor with a famous corp. Cryptographer,
where the book I have behind myself, was, okay to actually audit this with
no buyout because it has no interest validating something that will be broken.
So that was, just to have a third party.
We managed to put cryptography in every layer as validation concept.
You have HMAC everywhere, so if you flip one bit somewhere, it's going to
completely break in the nice sense.
It's going to tell you there's a corruption there.
It's in that specific file, and this is collapsing because there's that
file and that file that also shared that data, so they are all corrupted.
So we have already the detection part in a very, granular way, in
the sense that it can pinpoint very specific chunks and objects.
And having that plus the ability to synchronize, we can, build upon, tools
that would, that we are allowed to do a very, like pinpointed reparation.
Without having to repair everything because that's costly too, we're going
to be able to say, Oh, I have one chunk it's broken and I can fetch it from there.
I'm going to fetch just that, that amount of data.
We have, well, as I said, the error correcting codes, because since we
can detect all that is broken, we can have on top error correcting
code that could repair, auto repair.
You know, in the same way, like repair in a buffer, verify that it's correct.
You can check with other repository.
Oh, it's very correct.
So Yeah.
do repair for real, apply this.
So we have all these paths of, possibilities that we can implement
that are not like that far away because we have branches that are working.
They're not prod branches.
Working right.
now,
but they're working enough that you can actually say, it's not just, an idea.
It's something that you can actually, that was the focus, next month
it would be there because there's enough, enough bricks to prove that.
And, and we,
have a ton of these ideas of, like what would be the tools to make it
more reliable, in the sense that it's reliable that you would detect something
is corrupted, but how can you make it.
so reliable that people will not be stressed if that happens?
But that's the goal in the, in the idea.
I've been, as an architect in the past, I've been in so many incidents room over
Slack with people that are, they lose their mind when they're have, they have
an incident and the backups are hard to
manage.
Cause that's not, we know we have backups.
Now we have to go into the backups and we never do that.
So now we have to figure out how we go into that.
how we, and if, One of them is corrupted, then, yeah, it's, it's, stress plus plus.
You're going to a high level of stress.
And we want
to be into the session where they don't do not face that.
they, okay.
There's a corruption, even your backup.
Well, there are ways to get out of this.
And most of them are automated.
As you manage backups, like there's these three phases of the DevOps, the operations
engineer that's managing backups, there's the implementation, which is obviously
very time consuming, and you're learning the product, and you're testing backup and
restore, so you can believe they'll work.
And then once you kind of get there to your, the projects implemented,
and you feel like everything's going to work in a recovery.
You tend to leave it alone, right?
Like you're checking to make sure things are going like, as new
infrastructure shows up, you're adding or removing jobs or whatever.
And so you're kind of in maintenance mode, but then there is that incident day.
Where they call the backup person and they're like, okay, we need to
bring you into the incident room or into the Slack team or whatever,
because we now need a recovery.
And typically, most of the teams I work in, like not everyone
that can restore, right?
There, there's only one or two people that can restore tool.
And so in that moment.
As I can viscerally remember being the manager of the people
managing the backups and worried, starting to doubt everything, right?
Like they're about to test the restore and I'm doubting like, did we, when
was the last time we verified this type of this particular integration?
Like we've had three major version upgrades and we've never tested
since we did the initial deployment.
So we don't even know if this restore will work.
We recently had to replace three of the drives in that.
So, is there a potential for some sort of disk corruption that we
didn't know about because the files just sit there and they never get
touched and they die slowly over time?
there's so many, moments in that where I'm worried that someone's going to
get in a lot of trouble or fired.
And then the recovery happens and it works.
Maybe it doesn't.
there was one time where we ended up having corrupted files.
And we had to go to offsite tape from like a month ago, because we had this
process where we would go to tape once a month that would go to an offsite,
it was going to a different data center in a different part of the state.
So it was like a 300 mile, the goal was that no storm, if the storm took out the
data center, that's the, of the three, two, one, that's the third copy, right?
Like it's a state away.
It's been driven there by one of our staff.
We know that it's physically there.
And we had to go pick those tapes up and they actually worked.
But It took like a week.
It was after a hurricane and we had a flood and we had servers underwater.
And so we had to go to the offsite storage, And that whole week, I was
just so nervous that these things weren't going to get restored.
We were like, basically going to start from six month old data at best.
And luckily, luckily it worked.
But those kind of things, we don't talk about those kind of horror stories enough.
you know,
one of the reasons I think people are stressed is because, partly most of the
companies, they don't have a backup team.
They like the big ones have a backup team.
The other
ones have, they don't have, a backup team.
People who are given the task to do backups, it falls on them, as
part of a long list of other things to do, and they have to get rid
of it, fairly fast and it's not a topic that they are interested in.
they just like, yeah,
you have to do backup before, before Friday.
Okay.
what do I have?
There's only enough, there's a list of 10 tools.
None of them seems appealing.
I'm going to take.
One that's popular because no one's going to get fired over a popular tool.
That's going to be the decision driving.
but then, if they don't have to use these backups and if it was like a task
following up on them, they're not going to have a look at the backup once it's done.
Like they will check that it happens, on the regular basis, because
it's supposed to run every day.
Well, they will check that it happens every day, but they will
not inspect the data every day.
Cause that's, they have other things to do here.
The other thing is that in most tools, the backups are kind of dead data in the sense
that they are meant to be backed up and no other use than being backups, you know,
when we design stuff, we're more interested in how do you actually
use the data, because what's going to happen is you're going If you
have no use for data, for that data, you're not going to look into it.
If that data that you backed up is actually usable in a very usable
way, and you actually use it every day, then you have a fair confidence
it's not corrupted because you've been using it the last few days.
The demo website, that's just the open source version, okay?
So that's not a company use that you would have of it, but we have previews of files.
Within these files, you can preview the photos, but you can preview
the videos, you can preview audio.
If you actually use that snapshot, which is a backup, it's a backup
stored on the screen, for example, you actually use it in a way that
you would use your Google Drive.
Every day, looking into things that you actually manage and, Oh, I want
to look at the content of a file, but I'm going to use a snapshot, not
a copy that I have on my machine.
Well, you know that it works because you actually viewed it, recently.
yeah.
And it becomes immutable data in the sense that you can't alter it.
it's like a read only data, but it's read only data that's, that's you
actually use and it makes that the data a bit less dead and a bit more lively.
I think if you have a use case that way, you enter into an incident, you
have to restore something that you've been looking, like you've been actually
using the snapshot every day through a web interface or through mounting
on your system as a local directory.
Well, you're not as stressed because you know that, that works actually, which is,
you've removed the, the painful part of the question of checking your restores.
Yeah.
is the check similar to a, like mock restore?
Yeah.
It's, it's an in memory restore that discards the data after doing?
the cryptographic checks.
So it's actually, if you restored in RAM and you validated all the checksums, but
we do it in a stream way so you don't have to actually hold the memory for the
snapshot.
For the whole, yeah.
yeah.
Okay.
Yeah.
Cause it has to de, de dupe.
Yeah.
has to read the data
we have a couple questions I don't even know if this is a thing.
Is there a plugin for Cyber attack detection.
And I asked, is that, are you talking about like ransom, like detecting
ransomware from encrypting everything?
yes, is there something like that?
is that a thing?
And what is, what do you think about ransomware?
Like, how do you do anything for ransomware or do you just
We do some, no, no, we do something, but, the, like the position, the posture that
people should have is the data is tossed.
You have to have a copy elsewhere and you have to have a copy that's,
not, reachable by ransomware.
Well, you have to have data that's offsite and not on the network.
And that's the only way that you're sure that, well, sure, relatively
sure that your SMR is not going to
affect you.
other provider?
And then we have, okay, once we have tackled this and we have said to
people, don't trust anything else than this solution, then there's all the
solutions that are like, best effort.
like for example, we have, we have, entropy compute, compute, the entropy of
files and directories and we store this as part of the metadata of each snapshot.
So you could actually use a diff, like a paper diff, way to, To compare
if the entropy drastically changed between two snapshots, for example,
this directory that had that low entropy before has a very high entropy now.
The thing is the stores that are pushing the They're Right.
on this.
So, so you're not, ever editing something in the source.
So they can be, actually you can have warm and forced, at a, at your provider level.
If you have entropy checking, plus, the offsite copies,
offline copies, you kind of have.
Like a fairly good, situation because things that would not completely trash or
store, you can still manage to say, Oh, I had the machine that has the ransomware.
It's pushed back up with ransomware, but the others, the snapshots
are not affected and it can actually, remove the broken one.
Because they're immutable.
Then if that did not work, then you can go back to, oh, I have a
offline copy, I have a offsite copy.
You, so you have to manage this for you.
You just can't trust a software solution to take over somewhere.
Yeah, I like the entropy idea though.
Like, you're basically talking about if the change rate on this particular backup
is normally 10 percent a day, having something that notifies you when it's,
you know, double that, 20 percent change this today or whatever, and some sort of
Yeah.
that your
And you will probably have an alert on the size also, because of course
if you know everything is encrypted, usually, you know, you can do with Plakar
something like 10, 000 cycles without increasing the size of the storage.
You know, you can, yeah, increase the frequency because we are just storing,
you know, a few metadata, only the changes between two snapshots, so,
and so you can virtually make your backup from, you know, every day to
every hour, every minute, depending on the size of what You, are making.
if you have a ransomware, you will have an alert on the size because it
will double at some point the size of your storage and it's, something that,
should never happen, so.
Yeah.
you have that, and you have, you have the idea that we, as I said, like very
early in the interview, we have built some kind of database in some sense.
So we have multiple indexes.
we can look up images or videos because we also index MIME types and stuff like that.
And the MIME types, they should be aligned, in some way to the entropy
of the data, if you have a text plan
file and it has a high entropy, you're going to raise alerts.
That's not, that's not great.
So you have many, many, these are the few that come to my head right now,
but there are many, other ways, other heuristics that you can use to actually
detect some kind of a fishy scenario that
that would gradually, take place because you're, if it's already, if the ransomware
is already there, you should know, because you are asked to give money.
But if you're in the middle of the attack and you have.
a backup that's happening in this app that have half the data corrupted,
half the assets are corrupted.
You're going to detect it through entropy, metrics like this.
I feel like if I had to make something myself, it would end up being
something that was so stupidly simple.
Like I'd create a monitoring solution that watches a plain text file.
That's like, don't encrypt me.
txt or something that I put on every single file share, every single server.
And if any single one of them ever changes.
I get an alert, like I have some sort of agent that somehow detects all
of them and it's the first level.
it doesn't even wait for backups to happen.
It's just like, Oh, this file just changed.
cause the way I've seen these things roll out, these ransomwares is it
starts small and then just spirals.
So there are early indicators in the early hours, because If you've
got terabytes of file storage, like that doesn't all happen at once.
And it doesn't, and not everybody has permissions to everything.
So it typically starts in little places.
So I'd probably like seed all these little files everywhere.
besides the smartness of the discussion, There's only the offline
backup that's going to save you.
There's
no other way that you be, it's, it takes only one miss, to,
the ransomware, if you misdetect and you let it happen, it's already done.
you don't have the luxury to, to try and see if it works.
Yeah.
so you have to have your own offline backup.
That's the only solution.
And then the, everything else is nice to use that you could have.
But it should not be a blocker to have the most annoying part, which is
the offline backend, which is the one that takes the most effort to produce,
Yeah.
Well, I like those read only S3 buckets.
Those are something that I like to use for, ensuring that files can't be deleted.
My backups can't be changed.
you know, did you hear about the Unisuper incident where Google, they just deleted.
All the complete az, and region of UniSuper, and they lost everything
because they, you know, basically they dropped the billing accounts of the
client and it cascaded everywhere.
So, yeah, I would not rely on S3.
It's,
Oh, for sure.
I just mean, unlike a normal file server or any, any drive storage or
anything like I can more easily ensure.
Things that are written to, buckets don't get changed later.
Whereas like everything on a file server is, you know, up for debate
on whether, what can access it.
but yeah, good advice.
one other question.
Gartner recently introduced the cloud native infrastructure recovery category
in their latest hype cycle for backup and data protection technologies.
Where would you position Plakar in.
Cares, I guess that's the acronym for Cloud Native
Infrastructure Recovery something.
Let's say that we announced, last week or this week that we are joining, you know, a
sponsor, Linux Foundation and CloudNative, Direct Initiative, I don't know, yeah,
so basically we are joining those two
Sandbox maybe?
Are you going to go for Sandbox?
when you donate, are you donating or are you just becoming a member?
we are, donating basically to, yeah, be part, of the foundation, and because
why, it's the first step, you know, to, who to put there and to understand
how you know this ecosystem is working right now because we have to admit that
Jill is coming from the BSD world and I don't have so much experience on this
one so it's we have to you know figure out how we can be integrated and it was
the first step but yeah we are working currently on the support of Kubernetes.
we hope, for Cloud Native Paris, the 3rd of February that we have
something that will be, usable.
and, yeah, we really think that at some point, a layer is missing
in the, in Cloud Native about, you know, residency and backup.
and that, you know, with Plakar, we will try to contribute, you know, try to bring,
up This, layer and be sure that, whatever, the data that you have to back up, you
will be able to relay on this layer.
My previous job, you know, I was managing quite large team with a
big e commerce company in Europe.
And I was fighting every quarter to be sure that all the team
made their backup at some point.
But the things I never achieved is to be sure that all the team has 3 to 1, Eclipse
3 to 1, you know, encrypted everything.
I think what is game changing with Plakar right now is that we decoupled,
the storage, from, the technology to store basically your backup.
and you can store your backup anywhere.
without trusting your provider.
So what does it change?
you could imagine, and it's what we are releasing right now, a protocol
where you can push your backup to a provider, and the provider is managing
the resilience of your data without any kind of knowledge of your encryption
key, while we are maintaining low network cost and low storage cost.
And I think it's, you know, the kind of layer that is missing right now.
Be able to backup, all your objects, basically, whatever is it.
just pushing it to a third party that could be, you know, your own company.
It could be a team in your company that is managing, the backup.
But today the issue is that pushing all your data to one team in your
company with the encryption key, etc.,
to optimize the storage, it's a big bottleneck in terms of security.
So, yeah, what we are enabling with this new protocol is being able to,
you know, asking to every team, make your backup, push this backup to a
third party, internal third party or external third party, And this
third party will manage resilience without any knowledge about your data.
So being able to make two copies in two different cloud providers,
for example, one offline, etc. And doing it on a clean way.
and I think it's, the kind of contributions that we
can bring to the ecosystem.
But, yeah, of course, we want to, do something to solve
all this resilience issue.
the way you're describing that, I can't help but think that an OCI registry
would be a good option for that because it's content addressable, it's SHA
hash guaranteed, unique identifiers, it's read only, so you can be ensured
that there is integrity, it's got all the metadata to it, so, I'm going to
put my vote in for that, but it sounds like you're building something custom.
So, so I was going to ask as we end this up, cause we're running a little long.
what was next?
It sounds like what's next is Kubernetes initial Kubernetes support.
When you say Kubernetes support, are you talking about running it on Kubernetes?
Or are you talking about backing up like Kubernetes volumes or is it both?
we had a discussion about what was the proper way to integrate into
Kubernetes because, it's one of our developers that's working on it.
It was like, should I do one integration that works?
That covers everything.
And I said, no, we have to decouple, control plan and the data plan.
You have to be sure that, I want to be able to back up all the
YAMLs from my configuration.
And I want to be able to selectively back up, some of my volumes.
I don't want to have, no option, but to back up everything or nothing.
So, so these are either two, two separate integrations or one integrations
operating in two different modes.
but the idea is to tackle all of them and, we were looking into his,
looking into, Valero integration.
and
it's tempting to go your own way always, let's do our own integration, but there's
also a pragmatic way, which is, no, if we can adapt to, to be run by Valero.
through Valero.
Then you get all the possibilities.
You can get, first our simple integration to back up the kube configuration, which
can also, be used through Valero to, to fit into the existing, setup of people.
They can just swap between different solution.
They can test us while retaining their old solution for whatever they're using.
Valero, then we can have a third way of doing it, which is our own,
but that would come last basically.
But Yeah.
just to say we're planning on not doing, being just a session that runs
within kube, but more as a session that also manages to backup your kube.
Yeah.
That's one of the challenges I've been seeing in the industry is like, You've got
like the traditional backup vendors that, that have the plugins or integrations
or whatever they want to call it.
and, you know, you're paying lots of money and they make you pay
for certain things like maybe the Oracle integration is costing extra
and you know, that kind of thing.
And they're all closed source.
And then you have these open source things like Valero and.
But the challenge with it is it's just Kubernetes.
it's great at Kubernetes, but it's just Kubernetes.
And typically, I don't really work with any teams that are only Kubernetes.
I mean, even if they're Kubernetes first and they're container first,
they're going to have other things.
And so then they have to have a completely different set of tools for that stuff.
And those, then these two things don't meet, right?
So, so Valera's backing up to whatever storage you want to put on the plug in
on the back end, and then this other system is completely separate, and
you've got, and, not that we can ever, I mean, you know, at this point it
feels like all my clients have multiple CIs, multiple backups, multiple clouds,
like there is no just one thing.
They've, they're doing everything multiple times, multiple types
of databases, multiple different database providers, and, So the
challenge I always feel like isn't to get to one universal backup system.
It's to get as just as few as possible so that you can maintain
yeah, that, that, that's the goal.
But if you were like, okay, imagine you have 10, 10 separate tools, because that's
what I saw at some previous companies.
They have, like many teams, none of them have, came up to a consensus
about what were the proper solution.
Each one came up with its own, you end up with 10.
Even if we just reduced to three, that's a net win over having to manage
10, 10 different solutions.
And in our sense, You can do something very stupid, like stupid, stupidly, easy.
I mean, you can say, oh, I want an integration that actually backs up to
another system, another backup system.
So you end up having everything falling into Plakar through the
system of integrations, being able to ingest data from whatever solution.
So there's also this, I'm saying it's a possibility through the integration
system, but that means that you have also a way to progressively de plug.
Unplug, older solution as you manage to have integration written, but
still, be able to have everything from day one into Plakar.
you know, you want to back up some solution.
We don't have that integration from that, but we have the
integration for your backup system.
Well, you
can back up through the other tool.
We back up the result of your backup.
Progressively as we have the integrations to, to manage your tool natively,
you get, some tools out of the way.
So
the idea is to allow people to do that.
obviously we're not enough people to write the hundreds of
integration that we would need,
but having simple SDKs, providing good examples and starting to do the
most, like the most popular ones, will lead us there ultimately, that's
the idea.
yeah.
And that's how tools like CyberDuck, CyberDrive, like that whole, you know,
Project ecosystem, you know, like dozens of different storage integrations.
I like using those tools because they've got GUIs, they're user friendly.
They're really great for like personal backups, personal file management.
and that tool, the magic of that tool is that it works with like everything.
it, like every cloud storage scenario you could think of,
it's got a plugin for that.
And so I feel like the integration or the plugin ecosystem is is a lot of, in a lot
of ways, the magic of what makes a backup product or a backup project, and really
interesting is the ways, all the different things that I can backup up just in case.
I didn't see a GI repo option for GitHub.
that's maybe more of a, maybe a, maybe we, instead of doing it with,
I guess if you do it with Git, then you could do any of the GI providers.
But it might be better to actually do it through the GitHub API and do it.
it depends what you want, because on GitHub, what you would want
is probably not just the code.
It would be all the issues and all the,
right.
that's where
like two levels, right?
Yeah, it's like I need the code, but I also could really
use all this other stuff.
Yeah.
well, this is great.
We could talk forever and I really appreciate your time.
You've both been very generous with your time.
we cover lots of topics in this hour, and I'm, I am excited to start
playing with it and get started.
I am excited to hear about, what you're going to do, what you're going
to announce on the Kubernetes side.
That's where I live.
So the Docker and Kubernetes stuff, I'm going to subscribe to any issues that
have those words in them, so that I can keep track of what the status is.
how do people find you?
So We've got the website,
are
on discord.
So and then you got the GitHub repo.
you got socials, looks like you have a discord server.
So everybody that wants to get involved.
We work on Discord.
we are, as I said, all remote.
We're all working remotely and we work transparently on discord.
So you can just come to our discord.
you can actually attend all of our meetings.
You will be muted, , but you can actually, look into any discussion, technical
discussion that happen, in the open.
Except the daily,
you can come.
and talk with us during the daily
yeah.
all right.
So we know what's next.
We know you're going to be at KubeCon.
People can follow you individually.
I guess you guys are on socials, on LinkedIn.
I think in the YouTube description, all the links are below for how to
follow these two fine gentlemen.
Well, thank you for, for having us.
This was, pretty great.
very much.
you.
All right.
Well, thank you both for being here.
And we will see you next time here on, DevOps and Docker talk.
Ciao everybody!
Cheers.