1:01:01 Webinar
Everpure & Veeam: Hardened Backups, Faster Recovery
In this webinar, Everpure and Veeam show you how to build a resilient backup strategy using hardened Linux repositories, immutable object storage, and isolated restore tiers to keep your backups clean, available, and ready when you need them.
This webinar first aired on 23 April 2026
The first 5 minute(s) of our recorded Webinars are open; however, if you are enjoying them, we’ll ask for a little information to finish watching.
Click to View Transcript
Today, data is the lifeblood of every organization. It needs to be instantly accessible to the right person at the right time, and always protected from the moment it's born. And given the significance and scale of AI, your data needs Kontxtual and intelligence so your business can thrive.
So how are you managing your data? Everpure, data management so simple it feels like second nature. Hello, and welcome to this expert-led demo webinar in April 2026.
I'm happy that we're here together with my friend Marvin. I think we're going to introduce ourselves a bit here. Marvin, I'll let you start. Thank you very much. Thanks for having me, Falco. Yeah. My name is Marvin Michalski.
I'm a systems engineer at Veeam Software. I support customers and partners to improve their overall backup and cyber resilience strategy inside, yeah, Veeam, inside backup. Thanks. It's, it's great to have you here, Marvin, and my name is Falco Banaszak.
I'm a principal field solutions architect here at Everpure, and I'm focusing on all things cyber resilience. And today we want to dig in a bit what the layer resilience approach is with Everpure, and why this webinar is called Hardened Backups and Faster Recovery, because there's many, many things and many layers you can achieve in terms of, hardening, in terms of resiliency.
And a faster recovery doesn't necessarily mean that you have a good speed in terms of recovery, but a faster recovery can also mean that you have a layer which is quicker than a traditional backup and restore. And I think we can, we can start with this, why are we all doing this? We're doing everything of this because of one thing and one key metric, and that key metric
is the work recovery time. If there's a disruptive event happening, for example, the time you take to get things back up and running to normal operations, you really want to significantly shrink this. And combining forces with Veeam and Everpure, for example, we can really achieve a smaller recovery time because we can use different functionalities and different features, but
also different ways in hardening our complete backup and our, disaster recovery stack. And, and that's basically why we're here. And furthermore, why, why now is, is storage important for that whole cyber resilience topic? It, it's basically four things which we stripped down here. The first two I'm going to cover is basically
the data resilience. So threat actors and ransomware or professional hackers, they will actively seek to destroy your backup and your snapshot data because obviously they know that you do backups, they know that you do disaster recovery, integrations. They know all that stuff, and what they want to do is they want to actively delete it.
So it means storage is not only a necessity anymore, but storage is really crucial when it comes to the data resilience topic in general. Furthermore, when you talk about SIEM or UEBA integrations, you need a fast performance storage system to detect those things normally faster probably. It, it really makes sense because the increasing attack, volumes we can see, it's,
it, it's really interesting because nowadays storage is not only the GB and terabytes we need to, to store backups, but also it's also a performant kind of piece in the whole architecture stack to make you quick and really, really fast when it comes to all those threat detections. I feel- Definitely. Yeah. I can also give you some insights when I talk with customers and partners about the point,
th- three and four because, when we talk about-- When, when I talk about, w- or with partners and customers, we talk about a lot of stuff. The backup server itself, the, the proxy, the repository. Talk about the software appliance, how we can improve the security overall, how we can improve the backup infrastructure itself.
And, you need to think about storage as a, another layer of cyber resilience because it is a crucial part nowadays that you should include the storage, primary storage into your backup infrastructure or your strategy at all, because you can do pretty much cool stuff with it. Backup from storage snapshots. You can reduce your RPOs, your RTOs.
You can reduce the overall load from your hypervisor environment. And you can do, you can do even more of that. And of course, you don't do backups for fun, you do backups for the recovery itself, and we will dive more into that. Just keep in mind it is another layer we need to do that in the strategy overall.
Yeah, and, and perfect segue here, Marvin, because when we talk about layers, we normally talk or I talk about this AI picture I really like because w- what it basically says is, as much layers as you have, it's harder it gets for an attack to get to your really important data which is in the middle here. And, and that's why the whole layered resilience architecture really makes sense,
especially with you as our partner, together with Everpure. I think y- you can spend some minutes, whole, whole layered resilience arch here and, and what we basically want to achieve. Definitely, because I love this high-level architecture in here because it's great. It's a perfect recommendation if someone or some customers try to improve the overall
strategy of the backup itself. Basically, we have three data centers in here. We have data center one. Inside data center one we have the FlashArray, which does some snapshots, some backup from storage snapshots.And also important, Safe Mode is enabled for this kind of snapshots.
We also got the primary backup server, let's say in data center one. We got some primary repository in data center one. In this use case, it is a FlashBlade, basically an S3. Object lock is enabled for the immutability, and SafeMode also very important. And we have data center two.
There is another FlashArray. We can do a replication between those. It could be synchronous or even isochronous. It really depends on your needs. And of course, free to run rule, just keep that in mind.
We have another repository, let's say backup copy repository for long time archiving. Also object lock and SafeMode is, here enabled. And nowadays, of course, you need a disaster recovery, recovery strategy. You need some kind of business continuity management. And of course, we got a third data center for this use case, which is called in here secure
isolated recovery environments. In this third data center, we got the Veeam Recovery Orchestrator, which can, da- or which can, do, the disaster recovery for you, which can do the automated testing, the documentation for you. And also we included another FlashArray here because when you do FlashArray on the first
site and you do snapshots, you can offload or synchronize the snapshot to the secured isolated environment also to do recoveries from that. So just imagine all the capabilities we can do with FlashArray, with the backup replication itself. Also, it's pretty, it's pretty cool.
That's why I like this high architecture in here. And immutability is not enough. Even if you use object lock, you need even more. That's why this is the perfect transition for you, Falco. Yeah. We need more than immutability, right?
E- e- exactly, and that's what we are trying to show today because, we'll come to that in a minute. What I want to say as well here, and, and thank you for explaining this because what it essentially is also saying, backups anymore. We protect the data from the very first beginning. So from, from the very first bit ever written
on the first data center throughout all those, layers which you can see here. And that means we don't only protect backups, which is very important. In terms of immutability, there's one thing I really like to highlight here, picky, it may be due to naming conventions, but immutability and indelibility is not the same thing. Immutability, for example,
protects you from modification. That's why it's called immutability. But it doesn't protect you from the deletion, and that is a very important, thing just to be aware of. Most people mean both when they say immutability, but actually it's two different things.
Immutability is no modification, but it can be deleted. Indelibility is that no modification and deletion is possible before a policy or a mechanism expires. That's what we at Everpure do. That's what we call our SafeMode functionality because you cannot get rid of the data anyhow. It's not feasible unless the policy expires,
which is a good thing. That means even though if you have full administrative rights on a system, it's not feasible for you. And this also protects you from man-in-the-middle attacks. It also protects you from credential scattering. So we all know when a hacker, for example, tries to get in your environment, the first
thing they literally do is, where are the backups? Can I delete them? If not, where's the domain controller? How can I get administrative privileges? How can I get access to the most crucial important systems like Active Directory, like storage systems, like backup servers?
And, and how-- and can I delete it? And that, that's the most important thing. That's what's really, is important to understand, that there's a difference between both. Even object lock, like you just, teased, Marvin, object lock only protects object
inside the bucket. Object lock doesn't necessarily take care about the bucket itself and about its configuration. Adjust the objects in the bucket, which we'll come to later. And that's probably a good thing to, to introduce what SafeMode really does. Many customers already know, but SafeMode is our functionality to basically protect your
volumes, snapshots, your file systems, but also S3 buckets from accidental deletion. It could be an accident, a false automation, but also from, really hacker or from a, bad actor. And this is a cool thing because the feature itself is included at no charge. There's no extra license for that.
You can simply enable it. Literally we ship those FlashArray systems with AP group auto right now, which is basically the protection by, by, by installation. And it's interesting to see that it's so much out there because it really is to, to, to get this thing up and running.
All those policies we create in terms of SafeMode, they can only be modified by an authorized company with, at least two persons. And when you want to lower it, it's not feasible. You always have to include our technical support services. On a FlashArray, we talk about twenty-four hours, which is the default
to thirty days of retention. On the FlashBlade, we talk the same, twenty-four hours to three hundred days, four hundred days retention, sorry, which gives us the flexibility which we need in terms of restoring also from a longer period, seven days or fourteen days, but maybe for thirty days.
And Marvin, maybe you can explain a bit how it really works. What, what, what's behind that? Yeah, I can show you a bit, behind the curtains, what's actually SafeMode doing in the background. Because actually, as you already mentioned, SafeMode delays data and snapshots, from being manually deleted, destroyed, corrupted,
or even eradicated Forever for a specific certain of time. And basically, just think about two layers. You have the first layer on the Flash Array, on the FlashBlade itself. If you try to delete this, it not get, it get not deleted immediately because this data gets moved into some kind of recycle bin.
It's called eradication bin, actually, and that's the functionality behind SafeMode because the data resides there for a specific amount of time that's currently settings, which you can do. We-as Falka already mentioned, it can be on a FlashArray from one to 30 days from one to up to 400 days.
So just keep that in mind. It's just a second layer, like a recycle bin, and you can even do not delete this stuff if it's there for a specific amount of time, even if you have full admin privileges. We just-- Or we just will show this in, in a couple of minutes when we do a quick that, on both systems, actually. Yeah.
And, and that, that, that's perfectly fine because, this basically also sums up what we're trying to achieve today. Since this webinar is called, Hardened Backups, Faster Recovery, we always have to talk about backup targets. Not focusing on, on the storage snapshot integration from the front end today, we're focusing really on the target options.
And from an Everpure perspective, there's two ways in using a backup target within Veeam. It's basically a block for a hard loose repository. Or if you go the object storage way, it's S3 on FlashBlade. Those are all the systems we can, we can offer right now. Every one of those systems, speak of Flash Array or FlashBlade, has SafeMode enabled
snapshots available, has object SafeMode enabled, or has the opportunity to really get that inde-indelibility feature, not only immutability in place. What we see is a bit of a trend, and that's also why Veeam in version 13 has basically, I would say, completed its object storage offering from a target perspective. That means you can now save and store everything what Veeam has to offer on S3, on
object storage. It, it makes sense, we'll come to it later. But also for the customers, looking into block storage, looking into hard loose repositories, a FlashArray is also a very, very good thing to do because you basically gain two layers of immutability. And I think that's also something which Marvin, he likes to talk about.
Yeah. Thanks. That's why, just keep that in mind, it's just my own wording and my own world. That's why I love to talk about Linux hardened repositories on FlashArray or as a Linux hardened repository on steroids because, we have two layers of security, as you already mentioned.
What is a hardened Linux repository? It is probably the most affordable repository a customer can get. It gets you really good backup speeds, it gets you really good recovery speeds. But what is it actually in the background? It's just a Linux system in the background, which is using the XFS file system.
And in this F-XFS file system, we are using, yeah, the native immutability, we-- which we can get from the file system itself. So it's pretty good. We have immutability as a first layer. We have another benefits, another advantages. For example, we can use block cloning, basically saves you a lot of space because
only unique blocks can, get right down on this repository. The first layer is the immutability, and if you enable also on the FlashArray the SafeMode SafeMode functionality, the, the feature as we already mentioned, you get the layer of, security because then you get two immutability, the indelibility, actually. And just think of it as another layer, as two log-ins, if you like to.
The first login is into the Linux system, the second login is into the FlashArray, and that's why I love to call this combination, yeah, Linux hardened You can use it as a standalone repository or you can even use it as a scale-out backup repository. That really depends on your needs.
Yeah. And, and on top of that, the FlashArray system was always known for do deduplication. So even though when Veeam duplicates and compresses data, on that XFS file system, we still can get some data reduction out of it on the FlashArray itself. That means you, you basically win everywhere.
And i-it's a very good fit, and especially for smaller to, to mid deployments, something which everyone really likes and everyone needs to use. When we look ahead as well, we can also talk about S3, and we talk about FlashBlade. And this is particularly interesting because FlashBlade enables you to think differently in your whole architecture. S3 and object storage as a
protocol is, is stateless. That means you don't need to mount a fiber channel or iSCSI volume on a Windows repository or a Linux repository in, in Veeam speech. S3 and object is stateless. That means with different connection, you can just simply connect over a gateway server or
directly through Veeam, to that bucket and store your data NetApp. And you can also do everything what you can do on block and file. That means you can do instant recoveries, you can mass restore. However, by the time being, it was only compression. Now with DeepReduce, whichever Pure announce, we can both-- do both on FlashBlade.
That means we can do compression and deduplication. But FlashBlade was really built for a Rapid Restore. That means it was built for massive parallelism, it was built for, not only restoring one or two VMs, but you can do twenty, thirty, forty, fifty, depending on your network. And it really gives you one cool thing, which
is basically immutability by design. And maybe we can talk about this again, Marvin, why object storage for Veeam? And, and I wanna see, hear your Yeah, sure. So we got a lot of reasons why we should or even include object storage, yeah, repositories for possible Veeam infrastructure
or Veeam design itself. First of all, pretty much every workloads we need to cover can be stored in an object storage repository. That's pretty much, that is pretty good. Think about virtual machines, think about physical machines, cloud, that's no problem at all.
Do you like to use object storage because you can reduce the, the amount of data that is being written into an object storage, but you cannot use cloud object storage? Think about object storage on-prem. That's a perfect solution for that. We even got workloads where object storage is best practice and recommended.
Let's think about M365 backup, Veeam backup for Microsoft 365. S- there, there is a best practice that's probably above four or five hundred users, you should consider-That you backup on an object storage repository. So pretty much every workloads can be written into an object storage. Think about enterprise plugins.
That was not, able to do We are not able to do that in version thir- version 12. Right now in version 13, this is possible, so please consider that into possible new designs. It is secure by design, as we already mentioned, because we don't have that much of ports we need to open, so the firewall team will be happy and you also will be happy. You can do a little bit of hardening, but it is not that much hardening required because
Object Lock and SafeMode saves you in pretty much every matter. You also got Or there's another advantage because S3 performance, scales up automatically in the back end, so you don't need to consider that as well. And what I really, really like, you can target every workload into one bucket, into multiple buckets.
You can expand this in, in the background because otherw- in other words, you don't need to expand it manually. Think about a bucket which is endless. You- the storage just need to handle this specific bucket or even more buckets. So if you have one buckets, if you have multiple buckets, that doesn't really matter.
You just need to consider the vendor that's behind of this, because some vendors has some limitations. We will dive more into that, into the specific, topic in the n- next slides. But the FlashBlade, for example, doesn't have any limitation on object size, on at all, but let's talk about that in a couple of seconds.
Back to you, Falco. Thank you. Thank you. So when we talk about why object storage in general for Veeam, we also have to talk about why FlashBlade. And why we're emphasizing FlashBlade a bit today is as well because S3 is our best practice.
We just see the most growth when it comes to S3 and object storage and all those architectures around, our customer base. But also Veeam has really put high effort into developing features and the whole stack around object storage to make sure you can use object storage everywhere. That means if you think of 2026, you can literally backup from object storage to
object storage in one, two, three, or more data centers. You can use all the backup copy features you want to. Everything is, is built and designed for object storage. And, and that, that's a good thing because it normally makes life easier for administrators as well. Think of optimization, for example.
It, it's, it's really good to, to automate object storage in S3 because it's REST API calls over Ethernet. It just makes the life more easier. So why FlashBlade now? Of course, by the nature of the architecture from FlashBlade, you have with 10 blades in it, and every blade, that's why the name's FlashBlade, is a
the I/O. That means you literally get the fastest backup and restore which you can think of on an S3 platform. And the Flash, the DFM modules we built in those systems are really, really good. We don't wanna talk about the DFM module here, but it really means you don't have any artificial limits in the FlashBlade platform, and that's what it makes so, so easy to deploy
as well. Think of FlashBlade as an appliance. You put it in a data center, you connect over info to it, and it just works. And I think "it just works" was a, a slogan from Veeam some, some time ago, apply this here as well. Furthermore, it's not only immutable with Object Lock, it's also indelible, and we will show this in the demo.
That means you cannot get rid of the data. That, that's very important. And like Marvin was, was teasing as well, it comes to limitations, we often have a that some vendors have limitations. For FlashBlade and for Everpure, it's just the capacity to sum it up really quickly.
There are some best practices which Marvin will talk about in, in terms of Veeam, but generally speaking, there's no limitation from a FlashBlade perspective. You could, if you would and if you want to, put five petabytes in one single bucket. Why that doesn't make sense, Marvin will tell you in a second, but you could do that. And, and that's what it means with
That's what it means when you talk about FlashBlade as the target repository for quick and fast restore. And you don't have to, and that's the most important thing, you don't have to adjust your current architecture to that solution. Think of adjusting backup jobs from 4 MB to 1 MB, for example. That's not the case here. You can simply deploy a FlashBlade, leave
everything as is, and run it on S3. Maybe, Marvin, back to you around the whole, best practices around S3 with Veeam. Definitely, yeah. So there are some best practices we need to consider when we design, yeah, like a backup infrastructure, like a repository, when we click some settings inside of Veeam.
Just keep in mind that there are some vendors which work with object storage some limitations. We encountered that in a couple of projects. That's why we learned the hard way actually. But, yeah, it makes totally sense maybe to work with more buckets because maybe you have one bucket for virtual machines, we have one bucket even for your M365 backup.
It makes sense to split this separate data actually. But it really depends on your infrastructure at all. So, yeah, to sum things up, there are some best practices from Veeam side. We will show that in a couple of seconds or minutes when we go deeper but, no afraid, to use object storage as a primary or even secondary repo.
It's a great resource because object storage is, yeah, the, probably the best way to handle big and large amount of objects of data, to summarize this. Yeah. I think, I think that that's also a very good segue to, to not only talk about theory a- and really show what, what we mean with that. For that, I'm gonna stop sharing my screen right now, and then we are going to start with
the first demo today, which is the FlashArray and then we will head over to FlashBlade. We are not afraid of live demos, but can happen, so that's why we recorded it and do a live voiceover, which is probably even harder than a live demo. But still, everything has been tested, and we will show this to you in a second.
So- But we make it look like a live demo, so we, uh- It will. Correct. All right. Let's start with the, the FlashArray demo. And what we have here is I think you can see it already. No, not right now. You need to share it.
Yep. I shared it. By the way, if you have any questions, just put your questions into the chat, do a DFM to Falco or to me directly. That's not a problem at all. If you'd like to anonymize, some, information, so, feel free. Put all of your questions in the chat.
I got you covered in here. Correctly. Furthermore, we will also hand out all the, information around the integrations with our Pure1 Veeam afterwards, as well the presentation you just saw, can be downloaded, I think. And here we are with the demo.
You should see it as of now. Yes. What you can see is a very famous Veeam console. And what we basically want to show you today is how snapshot functionality, how SafeMode works inside Veeam, together with a Linux repository, a hard Linux repository, or a
Windows repository. For the sake of easiness around the demo, we are focusing more on the Windows and Linux side and not only, snapshot integration. We could do this again, but it would probably take the whole webinar hour. And I think let's just start right here. I start with showing you here that we have two repositories in there, a FlashArray Linux hard
repository and a Windows one. And also, you can see inside the storage infrastructure part in Veeam that two FlashArrays are connected. FlashArray one is hosting the source data. FlashArray two is serving the volumes for the repositories, meaning the volumes for the
FlashArray for the hard Linux repository and also for the Windows repository. Inside Veeam, we have two backup jobs. One backup job to the Linux hard repository and one backup job to the let's have a quick look in here. You can see there's one virtual machine in there, and that we are targeting the Linux
hard repository. Let's finish this one and let it run because we want to do things with it. Second R- job is the Windows one. Basically the same setting, just that we're posting it to a Windows ReFS repository, and that we have the same machine in there.
And let's just start this job here as well. We need those backups just to make sure we can show something when we do around the FlashArray part. And furthermore, we can see here is the FlashArray//One. This is the dashboard. If you go into storage volumes, you can see that it's hosting the data store for VMware.
And if you look at the FlashArray two, you can see it's the two volumes for the Linux VM har- Veeam Hard repository and for the Windows repository. Those are the ones we are playing with today and what we're, trying to achieve with immutability. If you look into protection, you can see that there are protection groups already.
That's what I meant with the P group auto. P group auto is the one we are shipping with, where you can see that retention lock is ratcheted. But we are going to just do this as if it would be completely new, and then we call this new protection group backup repo protection.
What we want to achieve with this is we want to create a policy, and you could rename it or destroy it if you want to, which doesn't make sense. But let's just go into that repository and that protection group and add members to it. Members can be hosts, groups, but also volumes. In our case, it's a repository.
That's why we take volumes. Let's add those volumes in there, and you can see that there's a snapshot schedule. That snapshot schedule defines basically when and how you want to create snapshots out of these volumes. I'm going to set, setting this to do a snapshot every five minutes and retain all those snapshots on the source for one day, but
also retain one snapshots per day for fourteen days. This gives you the flexibility you need when you come to those restore requ-requirements. You can, of course, do application as well. That means, let me pause that here for a second. This means it's only protecting the source, and if you wanted to connect a secondary
FlashArray in another environment, another data center, you could use the target option here to connect another FlashArray and then replicate those snapshots even to another system in another data center. All right. Very important, SafeMode, as you can see here, is unlocked as of now.
We need to ratchet that one. That means you cannot get rid of the data, which we'll show in a bit. So SafeMode has been enabled on the protection group. That means that protection group backup repo protection has now two members, the backup repositories from the Veeam perspective.
And you can see there's been already some snapshots created. Two, basically, one for the Veeam one, one for the hard Linux repository one, and one from the Windows repository one, and this is important. Now, both jobs have been finished, so they protected the, the virtual machine. That means we will have some data on that repositoryAnd if we now look back into the
backup repro protection group and look into the snapshots, you can see those two snapshots are there. That means we know a baseline has been created, and based on that snapshot schedule will trigger and do its thing. Next up, we're heading to the storage part under Volumes, and we are
going to send maybe this repository. No. What we're going to do is we're creating a manual snapshot, because not only the scheduler can do it, but also we can do it manually. That's important because the manual snap is not part of protection group.
That's why we're showing it here. That means that manual snap has been created manually, of course, by hand from myself right now. And you could send this to a FlashArray. That's what we're doing. You could set this to FlashArray one.
And if you send this over to Pure1, because it had been connected already, you can go under the FlashArray protection, go into the snapshots and see, hey, there's a manual snap from FlashArray two. And this is important now because the manual snap can be copied into a volume, attached to a Veeam server again, and used as a copy, but also used as a secure
disaster recovery environment. That means for disaster recovery purposes, you can use that. And that's pretty interesting because it gives you the flexibility. Normally, and that's also why I stop here. Normally, you would need to create a backup copy job to get your backup data from one data
center to the other one. But in this case, you're using the storage technology where the backups are already on it, and the backups are application-aware consistent because Veeam has written them finished on that repository. And this, this makes just more sense.
So what if I would go and create a copy on the FlashArray two because it has the host attached on it? Let's do that. Let's create a volume from that snapshot. And if you go to Volumes again, you can see it's called vol from snap, and that snap-- that volume hasn't got connected to a host.
So let's just use the Veeam host here. And before we connect it, let's just jump into Disk Management and see if everything looks correct. You can see there's one volume in there. Let's rescan that. It shouldn't show anything because it has not
been connected yet. And if I hit Connect, the host has a connection to that volume we just copied from a snapshot, basically. And that snapshot can be an immutable and indelible SafeMode enabled snapshot. That's the most important thing here. You can see here there's an offline volume.
Let's put that one online. It has the D letter assigned. And if you look in the Windows Explorer here, if you look at D, you can see, yeah, there's the backup folder, there's the Veeam backups, which have been written there. And that is very, very important.
Okay. So what we're gonna do now is, and we're basically simulating DR as of now. We are using the repository wizard again, Marvin, right, to, add that repository back again. Yeah. Basically just, stuff you are pretty much
familiar with. You just add, your repository as a new repository. Just, make sure that you click on the letter D because, V is the original one. And just click Next, Next, Finish. Important, click this checkbox, search the repository for existing backups and import
them automatically. Because otherwise you got a repository which was added into the VBR, setup, but, the VBR doesn't, or is not aware of any backups because you unchecked that box in here. So really, really important in here. Yeah. And, the REST API is pretty
simple, straightforward. Next, Next, Finish. Just wait until the configuration is being saved, into the database from Veeam, and, then you are ready to go to use that repository or, even more important, to restore from that repository. So yeah, that's the magic behind of this.
Exactly. And un- unless this doesn't finish, but it does because we recorded it, you can see here the backup repository has been saved successfully. And if I hit Finish and go to the Home tab inside Veeam, you can see a new tab popping up, Backups Disk Imported.
And that's the snapshot. That's the snapshot from the original volume. And there's that virtual machine, which I just backed up before. And I can use that machine and restore data because it has been all, registered again in this, application-aware. All right. Let's get back to the FlashArray system.
Let's get back to the protection groups and look into the protection group, because what we just showed is basic XAN functionality, we know that. But look here, we have several snapshots in here. Let's delete one of the snapshots. You can see here, that's what was-- Marvin was explaining.
This is now the destroyed part of the FlashArray. You can see the destroyed protection group snapshots. This is what we call the eradication bin. This is where SafeMode applies. Also worth mentioning here is I have full administrative rights on this array.
This is a array I'm using in our test drive environment. That means I have full administrative rights. I can do and delete anything, everything basically, except SafeMode. That means even if someone gets the credentials of my FlashArray system and tries to log in there, you can see on the right side, I'm trying to get rid of
and it is not working. It's not functioning. You cannot delete it. Eradicate protection group snapshot is not clickable, not feasible. You cannot get rid of the data. And that's what elevates that Han Ling repository from XFS immutability, combined
with the SafeMode functionality here to an indelible backup repositoryIf you look at the eradication configuration status, you can see disable delay, which is eight. We just saw this in the demo. When you delete a snapshot, it sits in the eradication bin for eight days, and you cannot simply get rid of the data, and that is the most important thing.
So let's destroy that manual snap just for comparison. You can see the manual snap, has not of the protection group, and obviously the recycle bin, is visible here, and you delete that one because it was not by SafeMode. That's what's important to show the between a manual snapshot and a protection group snapshot, which
here again, destroy, destroy, it's not feasible. And that is what is the most important about the whole discussion around SafeMode. All right, let's do the same thing for Linux one. So what we can do here, and forgive us please, but for the sake of the nature repository, it would make sense to show you the SSL's connection, which
is, here in a lab environment. Of course, don't do this at home. We're not connecting with route to the system. But what we do is we take that snapshot from the Linux handler repository, and we restore it. We simply override it again on that volume.
And that is the most important thing here. So let's click that button, say restore, and override that volume. Are you really sure? Yes, I'm sure, because I know that Veeam has stored those backup replication aware and consistent on that XFS file system. You can simply revert it with a snapshot, which is enabled with SafeMode and indelible.
So you can see it has been overwritten already, and the only thing we need to do as of now is go into Veeam again and rescan that handler repository, and everything should be fine, right? Correct. Yeah. And keep in mind, you have with the Linux handler repository, the immutability inside the file system, the indelibility from the,
yeah, the, the FlashArray itself, because on ReFS, you don't have native immutability. You just have the protection layer from a FlashArray. Just keep that in mind. Exactly. And you can see also the backup file immutabilities have been synchronized as well. And that, that, that, that means the whole data on that Linux repository is still very
valid and con- and all the metadata is there. And, and this basically elevates the whole discussion on the handler repository combined with a FlashArray system just to make it, indelible in this case. So I think that's it. Really just to emphasize again, the most important thing is when you go into protection,
protection groups and your protection group which protects your storage volumes, the retention lock and the SafeMode has to be set. This is what enables the indelibility. This is what enables you to not get rid of the data at all. And in a disaster event, the only thing which really counts is that you have at
data, not immutable data, but you have some data which you can hopefully restore. And that's what we try to achieve here. And that's also what it's meant with faster recovery. A recovery can be fast, can be fast in terms of speed, but a recovery can also be fast in terms of, oh, there's not a layer.
Oh, there's not a snapshot. Oh, there's something which I can use before I have to build up everything again. And that's what we want to emphasize. All right, I'm stopping the share here because we have another demo to show, and this time it's around object storage.
Um- Definitely. Just one information for you. I saw your question, Cedric and Thomas. We will come to that in the end of the webinar, so stay tuned. Yes. Perfect. So let's share this, and let's start with the FlashBlade demo.
It is there already. This time we're working dark mode like a true hacker. Very important thing here. Let's start off, what, what, what do we have here in this environment? First off, we have a FlashBlade.
And also you can see I am array admin here again. That means I have full rights. I can do whatever I want in the system. I can delete stuff. I can create stuff. Anything basically from a role perspective is feasible with this user.
So what we want to do here is let's go into the object storage part, and then an account specified, which is called Veeam Webinar, which is this one. And you can see access keys have been created to access that object storage bucket, and the secret key is also here. By the time the webinar takes place, these keys have been used already, so don't think of
stealing them. And also, we have some buckets here. So And we want to show you the difference between object lock and immutability here. So we have an object lock protection bucket, but also we have a Veeam S3 bucket, which is our best practice from Everpure to create a S3 bucket and then put it inside Veeam. So first off, I think, yeah, what we do, Marvin, is, is, and you can talk to this a bit,
we add that object storage repository, right? Definitely. It's just a, an normal procedure. You just add an new app object storage repository. In this case, it's an S3 compatible object storage. Just give it a name and a description.
It really, doesn't matter, just for naming purposes in your environment. Very important, we do not check box the concurrent task limit. So we leave it unchecked actually because the storage can handle it, because the FlashBlade can handle it. We need to give it a service point. It could be an FQDN.
It could be a s- yeah, just an IP address. Really depends, on the region. We don't have like a cloud region, just point in some region because it doesn't really matter. We just connect to the service point. And give it the access and the secret key.
That's just the credentials you need toTo connect to this S3 buckets. You can do, do a direct connection like Falco already mentioned, or you can, let that through go to, some gateway service to control the network traffic. And we do that to demonstrate something, in, in the future in a demo. We have some, illustration of, top views for you.
So just keep that in mind. You can do direct and you can do gateway. Of course, connection is not secure because we have some certificate issues. Self-signed certificates are not best practice. Keep that in mind. Do not work with that.
Then we select the object lock protection bucket, actually. We uncheck create new buckets automatically because, we don't want that in our demo environment and, you can work with it with just one bucket. It really depends on your configuration. This was a newly introduct- introduced feature in the late, in the last versions, but we
don't do that here in this specific demo. Right. After that, after you, after you that automatic bucket creation, just, create a new folder because you need a inside a bucket which we call, in this case, backups. There will be the backups stored for a certain amount, like re- retention periods.
Keep that in mind. And very important, check that box immutable. Otherwise, it's not immutable inside the bucket. You can give it, immutable duration. We do fourteen days for this example the newly introduced immutability version thirteen. Just keep that in mind.
Immutability is a setting configured inside the backup repository, not in the backup job itself. Yeah, Windows, and Linux mount server really depends on your source, which cover into a backup. Next, next finish. It's just basic story, basic stuff you are
pretty much familiar with, I guess. Yeah. And now we just need to wait until this configuration is being stored into the database. And then we can do, yeah, a new backup job. Definitely. Exactly.
So while this proceeds, we'll hit the Finish button, and now we have a new repository in here. And it will connect to those two gateway servers I just connect-- just, assigned in that backup job. And what we'll do here is we run a beautiful top command, which is a very cool, addition to the top command in Linux.
It basically shows you a graph, and a very good individual way how processes work and how the CPU and RAM utilization is. Just wanna see this because during the backup, obviously, we can have some performances custom around that. So what we do is, with the newly created backup repository, we create a new backup job, obviously.
And in this case, and that's one of the most important things, give it a name. It's very, very descriptive. It's very important. Just give it a name. In this case, it's object lock protection. Say Next, and then add your virtual machines.
We have some Linux dumps in here, which is basically a Linux box with say Next. And now we come to the important part, which backup repository, obviously, the new one we just created, the object lock protection one, and also set the retention policy to fourteen days.
Now it's aligned with the immutability period. And if you go to the advanced job settings, and that's the cool thing, just leave everything as is, click OK, and click Next. Some vendors, some S3 systems require you to use 4MB. We don't. You can simply create your backup jobs or use
the existing ones and just point to a new repository. Say Apply in this case, and then I also want to run this backup job. So this backup job starts running. As you can see here, it kicks up pro- and protects the virtual machine. And now we're speeding this up a bit.
As you can see here, the baseline's still zero on both gateway servers. They have nothing to do. And as soon as the job starts, it's happening. All right. What we do as well now is we created 1touch object storage repository with object lock. Now we're using the second bucket with our best practice settings around immutability and,
most importantly, indelibility. So we do the same thing over again. Hit the service point. Get that region in there. Speed this up a bit as well.
Choose the right secret keys and access keys. Choose the gateway servers. Obviously, this is a lab environment. Do not do this at home or in your environment. Don't use self-signed certificates and, and so on.
And now we create a folder called indelible backups. In those folder, all those backups will be placed. Now it's validating. Let's speed this up a bit because it's the same process as you just saw. As you can see here, we do the same fourteen days.
Wait until that repository has been finished. And you can see here the job we kicked off started, and the btop commands show some data being flown over that gateway service. Veeam uses direct or gateway. You can do both. I like to use the choose a gateway server
option because it gives you the flexibility to know how your data flows, but also it gives you flexibility to assign that gateway role, which can be any managed server in, in Veeam's speech, to the proxy. One thing the proxy has in common is the proxy has to be placed as near as possible always to the source that you want to protect.
That means you're saving some hops from a network's perspective. And if you recapWe know that Ethernet object, it, it's, it's a stateless But when you have to hop over different networks and when you have to route the whole traffic, it can get somewhat difficult or just complicated. That's why a proxy can surely be a server when properly sized, of course.
So what we do in this case is we just wait until this job is finished, and let's speed this up again a bit. Yeah, let's speed it up a bit. And we're looking at the percentage. Also keep in mind, this is a lab environment which is shared, so we around speed. We just show all about the recovery and
immutability, indelibility features. But still one GB of processing speed for a single virtual machine is pretty good. We talk about the one gigabit network, the maximum throughput is 1.25 GB/s second, so with some overhead, this is pretty extensive. All right. Now that this job has been created and
finished, let's create another job with the indelible backups. So hit next again, add your virtual machine. In this case, it's the same virtual machine again. And basically, it's the same job setting, so that's why we speed this up a bit here as well. Yeah, same procedure as, the last job, actually.
All right, now to the fun part. So we are Veeam administrator. You can see when you hit the backup properties of that job, and that's feature in version 13, right, Marvin? Yes, that's right, because, in version 12, you are not able to view how long is my backup
immutable for a certain amount of time. You just to f- yeah, you have to think about it, how you, designed it actually in the, in the job and in the repository settings. In version 13, you got the date in here, you can exactly look how much or how long is this backup immutable.
And, that's pretty much cool. That's a version 13 feature, which was introduced. Yeah. And for the next bit, don't do this at home, what you see right now. You see I'm the local administrator. If you go into the user manager, you can also see that I'm part of the local administrators
group, which is basically this user. And this new environment has been set up in a way nobody should have it, if you can see the users and roles I'm clicking right now, you can see that there's only a single administrators group whereas my administrator are part of. Do not ever do this in a productive environment.
It's a lab purpose. But what this needs to be shown here is I have all the rights I need to destroy anything I want to. And that's why I'm showing you right now here, if you look inside that job, I want to delete that virtual machine. It's basically not functioning. It's not working. Yeah.
It will just process, a couple of seconds. The backup server will try to delete the backup itself, but immutability is this backup, so it just will say in a of seconds, "Oops, I'm not able to kind of backup until this specific date you previously saw. And that enables me to have immutability out of the whole backup environment, which
is great because when someone gets access to your Veeam environment, you cannot get rid of the data, which is very important. Let's wait for that second job to finish now because then we can jump into the FlashBlade system and look in the whole indelibility. Okay, let's hit F5 here.
You can see that bucket. It's called object lock protection. There's some data in it. And if you look at the settings, a very important thing, there's two things in here. Diverging is enabled and object lock has been enabled, which is mandatory for Veeam, and
everything else has not been set on that bucket. And that's what we meant with listen carefully and, and be aware of. Immutability does not mean indelibility. If you delete that bucket, and you can do that because, object lock from an AWS API call is simply a object inside a bucket, but you can surely delete that bucket.
It's the same for handling repository. When you have a handling repository on a X eighty-six box and log into that out-of-band management, you can also delete that rate set if you want to. The immutability is just part of that file system on the XFS one. In this case, immutability and object lock is only part inside that bucket, but not outside.
You also have to think about protecting the outside. As you can see here, twenty-four hours is the default setting. After that, that bucket will get eradicated, or I'm an administrator, I can eradicate it now. And that's also why SafeMode is important because on this bucket, only object lock has
been set and not SafeMode, not the indelibility feature. So I'm just recovering this bucket again and do not delete it here. And now we are heading into the Veeam S3 bucket. This is the one we should use in production, and this is the one where you can see two more settings being done. First off, the versioning is enabled, the
object lock is enabled, but also the lock underneath is set to registered. We've seen that before in the FlashArray demo. It's the same wording. Registered means it's basically locked. You cannot get rid of it. And also, the eradication mode is retention-based.
What does that mean? That's an interesting one. Retention-based means every object, for example, we just saw fourteen days in that Veeam environment. Every object inside that bucket can only get deleted after that retention has expired. So if you put a one-year retention with object lock inside that bucket, that bucket will not
get deleted unless the one year has gone away. Yeah. That will probably answer your question, Cedric. Otherwise, please let us know in the chat.All right. Now, we explained it already, but what we can do is we cancel out in this case and just
wait until this backup job has been finished. Speed it up a bit. 10. And when it's, as you can see here, it's still writing some data. It's a big VM, actually. It's called dump, but it has probably one TiB of data, so yeah. Exactly.
So the VM has been, that the VM has been backup, and now the same applies to that one. If you want to delete it, it's not it's not working because you cannot delete inside the Veeam environment when object lock is enabled. That's what immutability is all about. And that's also the first step of, of having a good and resilient architecture.
Even if someone gets access to your environment, to the Veeam environment specifically, you will not get rid of the data, which is why very important. Yes, you can see the date in here. Perfect. And for the final step, let's head over to the FlashBlade again.
Hit refresh. You can see the same amount of GB has been saved in that repository as well. If you want to delete that bucket now and say destroy, it gets placed in the eradication bin, Marvin explained, but the recycle bin icon is grayed out. You cannot delete it. And you can also see that the time remaining
is not 24 hours like before. It's in calculating mode. That means when you have a repository with a 10-year immutability period, for example, that bucket will, after it has been calculated, get deleted after 10 years. And that's why it makes really completely indelible, because the only thing you can do
right now here is doing physical damage to the repository. And I think that sums up the demos. Do we have some more questions in the chat? We have some questions. One was already answered by your demo, so, yeah, we are good to go.
We got a second question, which is off-prem, to Thomas. He ask, about, endpoint protection and, Microsoft 365 backups, actually. It's, yeah, it's not that complex, Thomas, but I would recommend to you, you deploy a Veeam server, on-prem or even in the cloud, it really depends. Because then you can use or can get use of, a Veeam agent for Windows or even Linux to get
deployed, managed by the backup server. Then you can protect your endpoints. And if you like to protect your M365, I would recommend you, because you are to- only having 30 users, go with the Veeam Backup Clouds for Microsoft 365. That's a backup as a service solution that would perfectly fit for your needs in here.
Any more questions off topic or related to demo, to Falco, to me directly, feel free to put it in the chat. I even got a question I like to ca- take care, via DM, actually. Immutability is kind of, yeah, the foundation for everything. So, the, the question was, is it, included in, advanced, premium and the orchestrator?
Basically, immutability, we, we only give the logic to the storage. The storage must be capable of doing immutability and indelibility, here in this case. And, yeah, the feature immutable is in probably in every version. If you have rule, then it's included.
If you have sockets, you probably need to have enterprise. I'm not quite familiar. It should be even in standard. I need to look that up. Yeah. But it is included in pretty much every version.
There's one more question for you, Marvin. Can you explain again why it makes sense to use a FlashArray with a home repository, not a single server with just drives or SSDs in it? Yeah, sure, because, we already saw in the, in the demo, with the Windows RFS repository. Let's say we have a Windows RFS.
Windows has not natively immutability enabled. It cannot just make use of it because it does not have immutability at all. So just think about if you like to work with Windows, if you like to use FlashArray in the back end, you don't have immutability at all. You need to use the SafeMode functionality from the FlashArray itself.
And, think about, good performance repository for backups and for restores. You are really good to go with FlashArray in the back end. Anything you would like to add, Falco? I think that perfectly sums it up, and we're already perfectly on time with the f- top of the hour of our webinar.
And if there are no more questions, I think we can, we can close this up. And Marvin, thank you very much for, for being here and for helping the hand here and then for doing this, this great session with me together. If there's any more questions, feel free to reach out to us all directly.
You will get all the material from us. Thank you all, and have a great afternoon, evening, wherever you are.
Falko Banaszak
Principal Field Solutions Architect, Everpure
Marvin Michalski
Systems Engineer, Veeam
Backups are your last line of defense—but if they’re not hardened, they’re also your biggest blind spot when ransomware hits.
In this webinar, Everpure and Veeam show you how to build a resilient backup strategy using hardened Linux repositories, immutable object storage, and isolated restore tiers to keep your backups clean, available, and ready when you need them.
You’ll learn:
- How to turn Linux repositories and secure object storage into a hardened, immutable backup layer with Everpure and Veeam.
- Practical ways to shrink Work Recovery Time by optimizing backup, restore, and data mobility workflows.
- Real-world best practices from Everpure and Veeam experts to strengthen cyber resilience without adding operational complexity.
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.