So we're going to talk about backup strategy.
So, you can see out of the window, on the other side, we're talking about electronic invoicing.
This is quite an important subject.
You're going to need it by the end of the year.
So, if you want to change rooms, there's still time.
Here, we're just going to talk about backup strategy.
Little mess.
And it's not a very, very important subject.
And today, it's just something you're going to have trouble with legally .
if you don't have to restore your customer's site .
It falls, in fact, under the RGPD,
. which effectively requires you to give your customers access,
. to the data you have on these customers .
But it also means that you, as the person who maintains the site ,
can, in fact, restore access to this data.
And that's going to get even stronger.
Because today, we're talking about RGPD, so, all of a sudden, we have to restore.
We don't really know how, but we have to restore.
And we're going to have NIS2 coming this year.
So, normally, it only concerns critical and large companies.
But, in fact, there's a ripple effect.
All these companies' subcontractors will also have to apply NIS2.
and so on for their subcontractors.
And so, chances are, you'll be affected by NIS2.
The NIS2, in fact, is going to give the CNIL a resilience plan.
Resilience, sorry.
A resilience plan is what I call a backup strategy.
It's really a document that explains how you're going to restore the site.
So that's the difference, in fact, between the two.
Now that we've explained the legal consequences,
we'll start with a little survey.
Who here has simply backed up their site in the last month?
That's pretty good.
And now, who has already opened this backup?
. or restored it, to see what was inside?
Quite simply, it corresponded to the site in question.
And that's a lot less people.
And that's exactly what we're going to talk about.
The backup strategy won't be to make a zip,
and put it on Dropbox, and that's it, we're done talking about it.
In fact, you're going to have to make sure that the day it crashes, in fact, the site ,
we can restore something.
So, to do that, we're going to have to take a number of steps upstream
. to make sure we're not out of pocket on the big day .
So that's what I'm talking about, because ,
since I joined WP Umbrella,
so that was about six months ago,
well, I worked quite a bit on the backup part,
and I feel like I've come on board as a bit of a panic expert.
Why is that? Because there are quite a few people
who confuse backup with backup strategy.
And at Umbrella, what we have ,
. is a big difference with you in the agencies,
is that what is a statistic for you ,
. basically, something that has a chance of happening,
for us, we have so much backup that it becomes a percentage.
It's going to happen.
We're bound to have some of our customers' sites hacked.
We're bound to have sites that go down.
And since not all technology is 100% reliable,
. backups are bound to fail.
And the problem with backups is that ,
when you make a backup, you have an illusion of security.
In fact, a backup is like a safe.
So your service provider fills it up.
Then he closes the zip.
And from then on, you can't see what's inside.
And the only way to check what's inside,
. is simply to open it.
And that may sound very silly,
. but in fact, check the contents at least once.
of what you've got in the zip.
We retrieved data from WP Umbrella
to see roughly what the ratio was.
simply of people opening backups
we were doing on the sites.
And we came across a figure that was a bit frightening.
In fact, we have 17 times as many projects.
than backup downloads.
In other words, at the most, we have one site out of 17 .
for which the agency or the customer
verified that the backup had what was inside.
And we're really talking about a high estimate,
not the low estimate.
And for me, in fact, check that we have the files,
it's not the right way, in fact.
It's quite complicated to know exactly
which files are important in a WordPress.
And it's easy to miss something.
And so, to check the integrity of a backup ,
. the best way is to transform it into a restore.
And that's what we're going to talk about at the end of this talk.
And so, all of a sudden, we've seen what we call integrity.
For me, this is the first of the fivepillars of a good backup strategy.
Sorry about that.
And so, what we're going to do now,is we're going to look at the other four.
So, the first one we're goingto look at is redundancy.
Redundancy will answer two questions.
What tool am I going touse to make the backups?
And where will I store my backups?
And the answer to that is notgoing to be the name of a tool.
Actually, it's going to be a very simple sentence, it's that nothing is reliable.
And so, given that nothing is reliable,
we're going to apply a rule called the 3, 2, 1 rule.
Basically, we'll always have at least three copies of our website,
i.e. three backups, simply to make sure that one of them works.
We'll use two tools, if possible, at different levels.
For example, a tool for the website, which will then make the backup,
and a server-level tool, like Duplicity,
which, in turn, will also back up the website,
but at a different level, so that if one crashes ,
. it won't crash for the same reasons as the second.
You're always one of the two providing a valid backup.
And finally, the last thing, which is quite important,
. and OVH has shown you that,
is that you always need support outside the server.
If your server burns down, it's better to have backups.
And that it's not on the server.
Then, I don't know if you've seen ,
we talked about storing backup images directly on the server.
Do you know what an updraft backup is?
I doubt it.
Do you know what an updraft backup in a backup migrator is?
I think there are always people who will answer yes, surely.
Have you seen what an updraft backup is in a backup migrator?
in a backup backup?
And we'll stop there, because with OVH, we've actually seen a particular customer,
. who had seven iterations of backups one inside the other.
So, please, exclude the backups into each other.
We're not all at that level, but it can save you from going from 20 MB of backup to 20 gigs.
Now that we've talked about howto store, let's talk about governance.
Governance is really about when Imake my backup and how often I do it.
As far as the beach is concerned,it's more likely to be at night.
I say at night because, generally speaking,night is when you have the least traffic.
A backup is still an operation that'sgoing to take up a lot of your resources,
so avoid doing it when you need your server resources most.
If you have a site that runs at night, I'm not sure what you're doing on the site,
but it would be better to do the backup during the day.
Then, if you have several sites on the same server, avoid doing all the backups at the same time.
We had a customer with 50 sites, and he did all the backups at the same time, but it didn't work.
And finally, be careful with the server backup.
Your hosting company often offers you backups.
We looked at Ombrella again, and it's normally done between midnight and 5 a.m. for most hosts.
So, by default, you can avoid this time slot, or if not, you can simply ask your host to do so.
when they do their backups.
This will prevent two of them from overlapping and causing problems.
And lastly, if possible, spread out the backups.
I know we often talk about the speed of backup tools, but whenyou actually make the backup, it's not really the problem.
If every evening, you have a backup that runs in 5 minutes, butyour site is down for 5 minutes, that's not really what you want.
It might be better to have a backup thatlasts 30 minutes, but keeps your site online.
In terms of frequency, this is a point where I can't giveyou a precise answer, because it really depends on the site.
There are really two things to remember.
First, it really dependson the type of site.
If you're running a showcase site, onebackup per month won't be a problem.
You can tell me that a daily backup on ashowcase site could be just as interesting.
But the important thing to remember is that the resources you'renot using, you'll be able to use to make backups on other sites.
For example, you may have an e-commerce site next door on your server,which, as an e-commerce site, would like to make one backup per day.
And an e-commerce site, if you sell a lot, you're notgoing to make a backup of the whole site every hour.
The critical part of ane-commerce site is the orders.
So what you can do is set a backupfrequency that depends on the data.
Make a backup of the command tables every hour,and then make a backup of the rest once a day.
Because normally, itdoesn't move that much.
The next pillar is security.
A backup is great, it allows us to restore, but there's also adownside, which is that all our information is in the backup.
We've got the source code,we've got the database.
So if someone tries to access the backup illegallyand manages to recover it, that's the royal road.
So, in this section, we'll be focusing on who canaccess the backup, and where we're going to store it.
The easy answer is to give only the technical teamaccess to the backup, and not the whole company.
In fact, the more access you have, the more likely you are to haveaccess that is forgotten, that is not maintained, and that can be hacked.
Why the whole technical team? I'll explain in the restoration section.
But basically, everyone who can restore needs to have access, so there's no blockage at that level.
And finally, if possible, in fact, what you need to do is store it off-server.
Because it is possible to store your backups on the server, to set up an Apache rule, to set up an NGNX config rule,
but it's also very easy to make a change on the server and forget to put it back.
And so, if it's on an external server, not accessible via the web,
well, you can be sure that they won't have access in any case, even if you forget this NGNX rule.
And finally, if you've succeeded in the other four pillars, you'll come to the last part, which is restoration.
Restoration is, let's say, the completion of the backup strategy,
and that's when you find outwhether you've failed or succeeded.
And often, when you fail, since it's at thecatering stage that you fail, it's too late.
So, on the subject of restoration,we're going to focus on three points.
First, how to bring the siteback, that's the most important.
Secondly, how to reduce the timeit takes to get the site back online.
Because the customer next door mayhave an e-commerce site, once again,
and the moment the site goes down, it loses sales,
and so, all of a sudden, we have to reduce this time.
And finally, the last thing is how to reduce errors.
Restoration is a time when you have to move fast,
it's a time when the customer, once again, loses sales,
so it's a stressful time.
And when you're stressed, it's easier to make mistakes.
So I'd advise you to have an internal document first.
Simply because you're going to need it later, for NIS 2,
to give it to ACNIL.
This internal document should explain, quite simply, the restoration procedure.
It would be a sort of checklist with steps,
. for which all you have to do is follow the instructions on the document,
and any normal member of the IT team should be able to do the restoration.
But then, you don't need a document, in fact, that you write and that remains at the back of the cupboard.
And that's why something that's not bad and that can work in most agencies,
is simply to integrate it into the onboarding of the IT team.
It will depend, of course, on your turnover,
. but if you recruit quite frequently ,
. it means that every time someone joins the company, ,
to two people in the company, to be able to learn, for one, the catering strategy, sorry,
and for the other, to revise it.
And finally, the last two points are mainly to reduce errors,
and to reduce time, is to automate .
Automate, standardize if possible between your customers,
so that there are as few differences as possible,
. and the fewest possible errors, in fact, manipulations.
Then, personally, what I like to do is ,
is to automate restoration,
using the same script as for staging restoration.
What's interesting is that, as a result, we're going to have a script .
script that won't run once when the disaster occurs,
but rather a script that will run daily.
So, the advantage of that is ,
is that I'll know the script,
I'll be able to manipulate it a lot more,
and therefore, if there's an error in the script,
if there's anything I need to watch out for,
since I've handled it a lot more ,
I'll know to pay attention to it when I have to restore the production.
And finally, in the same way ,
staging, in fact, is supposed to be similar to prod,
so the customer's site that people see ,
and so, as a result, I'll also be able to manipulate the environment
. to get to know it,
and know if there are any problems .
Oh, I've been much too quick!
If there are any problems with the site,
. or special features you need to know about.
So, for me, at my level ,
. automate this system,
basically, I use a system where ,
basically, I have an AWX,
which is basically something that lets you run Ansible scripts,
and what I'm proposing, quite simply, for you,
to make this system simpler,
is to use a crone instead.
The difference between the two is that in WX,
when the job goes south, he'll let me know.
And, as a result, if I can't restore a site ,
I'll know that I've failed to restore it.
So, on that front ,
. I'll be informed .
The script will, therefore, take my backup ,
which is normally a zip,
it will unzip it,
. and install it on the staging,
so that the staging has the version
version inside the backup.
And then, simply to check,
that my important pages work,
what I'm going to do is simply ,
I have an uptime tool
which will check that all my pages are in 200.
Yes, it's not perfect.
In other words, we're not going to test logic.
which could be like submitting forms.
We could go further.
We could use a playwright script.
But when you look ,
. most people today ,
haven't opened a backup.
So, in and of itself, just having that ,
you're already much safer
. than if you had nothing at all.
And that leads me to conclude
that, in fact, a successful backup strategy ,
. isn't about going all the way.
It's not going to be about going all the way to today,
. trying to create a script to restore.
But it's already going to be to start checking, in fact,
that you have everything in place.
Basically, take a first look,
because what the numbers tell me ,
is that today, for most people ,
this is not the case.
For the first time ,
. go and see what you've got inside your ZIPs,
. what you have inside your backups,
. matches what you've got,
. your website.
Then, pay attention ,
because all backup technologies ,
they all have one thing in common,
is that they're not 100% reliable.
There's always a reason
why your backup technology
. miss a backup .
At Umbrella, at Updraft,
. any technology,
we'll never have a success rate
that will be 100% ,
simply because ,
. we do IT,
and in IT ,
there will always be bugs.
And so ,
. respect the 3, 2, 1 rule,
will already allow you to
. a lot safer.
And the same,
. for the platforms that host you,
you've seen it with ,
OVH,
you're never 100% safe
that you no longer have access
. from one day to the next,
because, for example ,
. the server has burned down.
And last but not least ,
. a backup ,
. is supposed to be a technology ,
. it's supposed to be your lifeline.
It's not supposed to be what sinks you.
So, please ,
protect your backups.
And it's over.
Thank you, Cyril.
We're going to have a little time
for questions,
. if you have any.
Yes.
Thank you for the presentation.
Very interesting.
I have several questions.
I'll pass the mike,
and maybe he'll come back to me later.
Already, in terms of integrity ,
you mentioned automation.
Do you have any concrete examples
or examples to share with us?
to automate the process of making sure
the integrity of the data we've backed up?
Today, in fact,
. what I'm proposing,
because it's simpler,
is to move towards restoration.
And it's the slide from before, in fact .
This system, in fact ,
allows you to simply
. to check your restaurant
. that the site is fully functional.
Have figures on files
in backups,
is something,
in real life, it's satisfying.
But in the end, really ,
you may have a missing file
and this file is critical, in fact.
I don't know if I've answered the question.
More or less.
But that's just it,
we do restoration.
But moreover ,
we'll still have a...
Today, in our agency,
we necessarily have a manual check.
It is possible to be domatized
This verification?
Do you have any cases ,
where you can automate
these verifications?
For integrity?
Yes, for the moment,
what I have is .
With certain customers,
I have Playwright scripts,
that's what I was talking about,
that run
and going, in fact ,
. validate certain forms .
But then ,
I wasn't
much further than that.
How do you write Playwright?
. it's Microsoft technology.
I think it's P-L-A-Y.
And then,
W-R-I-G-A-H-T.
Basically, it runs in a browser...
Well, it controls the browser.
And then, from there,
. what happens ,
. is that in normal ,
I use a script...
Finally, I simply use AI
to generate the script.
And then, from there ,
. it's up to the AI to determine a little .
the code to be written
. in relation to the flow
. that I gave him .
Are there any other questions?
Hello.
Thank you for this conf.
We were talking about backup frequency
for a showcase site
monthly or weekly ,
. for a daily e-commerce site,
. or even more finely.
It's not bad, by the way.
For a training organization,
for example,
with Zoom sessions
morning and afternoon sessions,
what would you recommend
. frequency?
The question will mainly be
what are you prepared to lose?
It's...
Basically,
when you choose the frequency ,
. it's a risk
compared, let's say ,
. to a cost ,
which is the backup procedure.
And the question is
what's important to you
in these sessions?
If the session ,
is the same as the last one,
we can perhaps do
a backup every day,
. every day,
and it won't be a problem.
Yes, it will,
each session is different ,
you may have to do
. two backups per day
. just after the session in question .
Yes, depending on the criticality of .
. that's right.
Good, good.
Thank you very much.
Hello.
Thank you for the very interesting conference.
I had two questions.
One about retention,
unless I'm mistaken,
I did not see this topic
in your slides.
Basically,
what do you recommend
. in terms of frequency
retention?
And also on location
of backup systems .
I understand that you don't like
a VH in Strasbourg ,
I'm from there,
so I know perfectly well
what you're talking about .
But do you have any suppliers
where I'd say more time
at the moment ,
preoccupation ,
. is countries
in which we're going to store the data .
Do you have any recommendations
in relation to this?
Basically,
I was supposed to be talking about
countries to stock,
but when I had done my rehearsals
. talk ,
. I went much more slowly .
As a result,
. it didn't last 20 minutes.
Basically ,
. me ,
what I like ,
. is scale-way buckets.
I don't know if you've heard of them.
And it keeps them
in fact in the EU.
And us ,
. in France,
in fact ,
which is going to be especially important ,
is always ,
when we stock them,
to have at least two servers,
you can use the
server of the website
if you want to reduce costs.
But if not ,
. which is always better,
is to have two places
. where they're stored .
. me,
. what I do ,
. is on scale-way,
I store it on one side in France,
. so it's on the bucket in France.
And on the other side ,
I have another bucket in Amsterdam.
. like this,
I'm sure that if there's a problem ,
. they really are physically separate .
And then ,
the other question,
was about retention,
was it?
So about retention ,
I've really been ,
well, that's a point I passed over rather quickly
with the 3, 2, 1 rule.
So I say at the very least ,
. have 3.
. then ,
. itself,
the better ,
. is to keep
. the everyday ones ,
. let's say ,
. for the week .
And behind ,
keep maybe 1 from last week ,
1 on ,
. finally ,
1 on the last weeks of the month,
let's put it this way.
and then,
maybe 1 a month .
And little by little ,
. actually ,
. have less granularity .
Because in fact ,
3 quarters of the restorations we do ,
. often ,
it's the site that planted
. and the customer ,
. saw the site .
. and so ,
. as a result ,
we often need
backups from 2 days ago ,
. from 3 days ago.
but very little is needed,
. in fact ,
. backups from 6 months ago .
One last question,
perhaps?
Yes.
There are 2 people.
Hello,
thank you for the conference.
Have you ever been impacted
. by ransomware
. or things like that ,
where I know it can have
impact on backups ,
because then ,
. intrusion ,
can also
disrupt backups
and render them unusable?
Is this something
you encounter today?
What are you doing today
. to counter this?
. today ,
. in fact ,
. we have .
We won't be going home
in the sales pitch.
But basically,
in normal,
. when there's ransomware ,
we backup from before,
. simply.
In normal,
when the ransomware arrived ,
. it blocked everything.
. so ,
we just need to find the backup
which was the previous ,
at the time the virus was present.
As a result,
. it was pretty much the same thing.
It was ,
do you enjoy
making your backups
. to check the integrity
. of your site ,
take a look at
? Is it worth it?
. to make a backup?
Or is it?
do I go straight to
launch an alert?
And it's a human
who will come and check
. and see what's what?
As a result ,
. me ,
on my system ,
. is .
by default,
is automated.
And then ,
when there's an alert
. is lifted ,
. then ,
or I can't
to restore ,
. simply ,
or I have an uptime
. that screws up,
,
it's going to be human
to check.
So,
in 90% of cases
not to have
to do it by hand .
. and then ,
there are still small cases
where, for example ,
there is an Elementor
which has been updated,
it spit out a page
. or something like that,
that goes behind
force us
. to go by hand .
Thank you, Siri.
Good,
we'll have to stop here.
Thank you very much.