Du coup, nous, on va parler de stratégie de backup.
Donc, on peut voir par la fenêtre, de l'autre côté, on parle de facturation électronique.
C'est un sujet qui est assez important.
Vous allez en avoir besoin d'ici la fin de l'année.
Donc, si vous voulez changer de salle, il y a encore temps.
Ici, nous, on va juste parler de stratégie de backup.
Petite merdouille.
Et c'est un sujet qui n'est pas très, très important.
Et aujourd'hui, c'est juste quelque chose sur lequel vous allez avoir des problèmes légalement
si vous n'avez pas à restaurer le site de vos clients.
Ça tombe, en fait, sous le coup de la RGPD,
qui demande, effectivement, de donner un accès à vos clients,
aux données que vous avez sur ces clients.
Mais, du coup, ça inclut aussi que vous, en tant que personne qui maintienne le site,
vous puissiez lui restaurer, en fait, l'accès à ces données.
Et, du coup, ça, ça va encore se renforcer.
Parce qu'aujourd'hui, on parle de RGPD, donc, du coup, il faut restaurer.
On ne sait pas trop la méthode, mais il faut restaurer.
Et on va avoir la NIS2 qui va arriver cette année.
Donc, ça concerne, en normal, que les entreprises critiques et les grosses entreprises.
Mais, en fait, il y a un effet de ricochet.
Tous les sous-traitants de ces entreprises vont devoir aussi appliquer la NIS2
et ainsi de suite pour leurs sous-traitants.
Et donc, du coup, il y a de fortes chances que vous soyez concernés par la NIS2.
La NIS2, en fait, ça va être donné, en fait, à la CNIL un plan de résilience.
De résilience, désolé.
Un plan de résilience, c'est un peu ce que j'appelle une stratégie de backup.
C'est vraiment un document qui va expliquer comment est-ce que vous allez restaurer le site.
Donc, c'est la différence, en fait, entre les deux.
Maintenant qu'on a expliqué les conséquences légales,
on va commencer par un petit sondage.
Qui, ici, a tout simplement déjà fait un backup de son site dans le mois dernier ?
C'est plutôt pas mal.
Et du coup, maintenant, qui a déjà ouvert ce backup,
ou déjà restauré ce backup, pour regarder ce qu'il y avait à l'intérieur du backup ?
Ça correspondait bien à ce qu'il avait backup, tout simplement, le site en question.
Et ça fait nettement moins de gens.
Et c'est exactement ça dont on va parler, en fait.
La stratégie de backup, ça ne va pas être faire un zip,
et je le mets sur Dropbox, et c'est fini, on n'en parle plus.
En fait, il va falloir s'assurer que le jour où ça plante, en fait, le site,
on puisse restaurer quelque chose.
Et donc, pour ça, en fait, on va devoir faire des étapes en amont
pour s'assurer de ne pas être sur la paille le jour J.
Donc, je vous parle de ça, parce que du coup,
depuis que j'ai rejoint WP Umbrella,
donc c'était il y a à peu près six mois,
et bien, j'ai travaillé pas mal sur la partie backup,
et j'ai l'impression d'être venu un peu l'expert panique à bord.
Pourquoi ? Parce qu'il y a pas mal de gens
qui confondent, en fait, du coup, faire un backup et stratégie de backup.
Et chez Umbrella, ce qu'on a,
c'est une grosse différence avec vous dans les agences,
c'est que ce qui est pour vous une statistique,
en gros, quelque chose qui a une chance d'arriver,
pour nous, on a tellement de backup que ça devient un pourcentage.
Ça va arriver.
On aura forcément des sites qui vont se faire pirater chez nos clients.
On a forcément des sites qui vont tomber en rade.
Et comme toute technologie n'est pas 100% fiable,
on aura forcément des backups qui vont rater.
Et le problème des backups, c'est qu'en fait,
quand on fait un backup, on a une illusion de sécurité.
En fait, le backup, c'est comme un coffre-fort.
Donc, du coup, votre prestataire le remplit.
Ensuite, il ferme le zip.
Et à partir de là, on ne voit plus ce qu'il y a à l'intérieur.
Et le seul moyen de vérifier ce qu'il y a à l'intérieur,
c'est tout simplement de l'ouvrir.
Et ça peut paraître très bête,
mais en fait, vérifiez au moins une fois le contenu
de ce que vous avez dans le zip.
Nous, on a récupéré des données au niveau de WP Umbrella
pour regarder à peu près c'était quoi le ratio
tout simplement de personnes qui ouvraient les backups
qu'on faisait sur les sites.
Et on est tombé sur un chiffre qui était un peu effarant.
En fait, on a 17 fois plus de projets
que de téléchargements de backups.
C'est-à-dire qu'au grand maximum, on a un site sur 17
pour lequel l'agence ou du coup le client
a vérifié que le backup avait bien ce qu'il y avait à l'intérieur.
Et on parle vraiment d'une estimation haute,
pas de l'estimation basse.
Et pour moi, en fait, vérifier qu'on a les fichiers,
ce n'est pas la bonne manière, en fait.
C'est assez compliqué de savoir vraiment exactement
quels fichiers sont importants dans un WordPress.
Et c'est facile de louper quelque chose.
Et du coup, pour vérifier l'intégrité d'un backup,
la meilleure façon, ça va être de le transformer en restauration.
Et c'est ce dont on va parler dans la fin de ce talk.
Et donc, du coup, là, on a vu ce qu'on appelle l'intégrité.
C'est le premier, pour moi, des cinq piliers d'une bonne stratégie de backup.
Désolé.
Et du coup, ce qu'on va faire là, c'est qu'on va aller voir les quatre autres.
Donc, le premier qu'on va voir, c'est la redondance.
La redondance, ça va répondre à deux questions.
Quel outil est-ce que je vais utiliser pour faire les backups ?
Et où est-ce que je vais stocker mes backups ?
Et la réponse à ça, ça ne va pas être le nom d'un outil.
En fait, ça va être une phrase très simple, c'est que rien n'est fiable.
Et donc, du coup, vu que rien n'est fiable,
on va appliquer une règle qui s'appelle la règle des 3, 2, 1.
En gros, on va toujours avoir au moins trois copies de notre site web,
donc trois backups, pour être sûr qu'il y en ait un qui marche, tout simplement.
On va utiliser deux outils, si possible, à un niveau différent.
Par exemple, un outil au niveau du site web, qui va, du coup, faire le backup,
et un outil au niveau du serveur, comme Duplicity,
qui, lui, va, du coup, faire aussi le backup du site web,
mais à un niveau différent pour que, si l'un, du coup, plante,
il ne plante pas pour les mêmes raisons que le deuxième.
On est toujours un des deux qui nous fournissent un backup valide.
Et enfin, la dernière chose qui est assez importante,
et ça, OVH vous l'a démontré,
c'est qu'il faut toujours un support qui est hors du serveur.
Si votre serveur brûle, c'est mieux d'avoir des backups.
Et qu'il ne soit pas sur le serveur.
Ensuite, je ne sais pas si vous avez vu,
on a parlé, du coup, de stocker des images de backup directement sur le serveur.
Est-ce que vous savez ce qu'est un backup updraft ?
J'en doute.
Est-ce que vous savez ce qu'est un backup updraft dans un backup migrator ?
Je pense qu'il y a toujours des gens qui vont répondre oui, sûrement.
Est-ce que vous avez vu ce que c'est un backup updraft dans un backup migrator,
dans un backup backup ?
Et on va s'arrêter là, parce qu'avec OVH là, en fait, on a vu un client particulier,
qui, du coup, avait sept itérations de backup les uns dans les autres.
Donc, pitié, excluez les backups les uns les autres.
On n'est pas tous à ce niveau-là, mais ça peut vous éviter de passer de 20 MO de backup à 20 gigas.
Maintenant qu'on a parlé, du coup, de comment stocker, on va parler de gouvernance.
La gouvernance, ça va vraiment être quand est-ce que je fais mon backup et à quelle fréquence est-ce que je le fais.
Pour la plage, ça va se faire plutôt dans la nuit.
Je dis dans la nuit parce que dans le cas général, la nuit, c'est le moment où vous avez le moins de trafic.
Un backup, c'est quand même une opération qui va vous prendre pas mal de ressources,
donc on évite de le faire au moment où vous avez le plus besoin de vos ressources serveurs.
Si vous avez un site qui marche la nuit, je ne sais pas trop ce que vous faites sur le site,
mais du coup, ça serait mieux de le faire la journée, le backup.
Ensuite, si vous avez plusieurs sites sur le même serveur, évitez de faire tous les backups en même temps.
Pareil, on a un client, il avait 50 sites, il a fait les backups en même temps, ça n'a pas marché.
Et enfin, faites attention au backup serveur.
Souvent, votre hébergeur vous propose des backups.
On a regardé chez Ombrella encore, en normal, ça se fait entre minuit et 5h du matin pour la plupart des hébergeurs.
Donc, vous pouvez par défaut éviter cette plage, ou sinon, vous pouvez tout simplement demander à votre hébergeur
quand est-ce qu'il fait ses backups.
Ça évitera qu'il y en ait deux qui se chevauchent et que ça puisse faire des problèmes.
Et le dernier point, c'est, si possible, étaler les backups.
Je sais souvent, on parle de rapidité sur les outils de backup, mais au moment où vous faites le backup, ce n'est pas vraiment le problème.
Si tous les soirs, vous avez un backup qui tourne en 5 minutes, mais que votre site est down pendant 5 minutes, ce n'est pas réellement ce que vous voulez.
Il faudrait peut-être plus un backup qui va durer 30 minutes, mais du coup, qui va garder le site en ligne.
Au niveau de la fréquence, là, c'est un point où je ne peux pas vous donner de réponse précise, parce que ça va vraiment dépendre du site.
Il y a vraiment deux choses à retenir.
C'est que ça va vraiment déjà dépendre du type de site.
Si vous êtes sur un site vitrine, un backup par mois, ça ne pose pas de problème.
Vous pouvez me dire qu'un backup par jour sur un site vitrine, ça pourrait être aussi intéressant.
Mais ce qu'il faut retenir, c'est que les ressources que vous n'utilisez pas, vous allez pouvoir les utiliser pour faire des backups sur d'autres sites.
Si ça se trouve, sur votre serveur, à côté, vous avez un site e-commerce qui, lui, un site e-commerce, voudrait bien faire un backup par jour.
Et un site e-commerce, si vous vendez beaucoup, vous n'allez pas faire un backup de tout le site toutes les heures.
La partie qui est critique sur un site e-commerce, c'est les commandes.
Donc ce que vous pouvez faire, c'est une fréquence de backup qui dépend de la donnée.
Faire un backup des tables de commandes toutes les heures, et à côté, faire une fois par jour le backup du reste.
Parce qu'en normal, ça ne bouge pas tant que ça.
Ensuite, sur le pilier suivant, ça va être la sécurité.
Un backup, c'est super, ça nous permet de restaurer, mais il y a aussi une contrepartie, c'est qu'on a toutes nos informations dans le backup.
On a le code source, on a la base de données.
Et donc du coup, si quelqu'un tente d'accéder illégalement au backup et arrive à récupérer le backup, c'est la voie royale.
Et donc, dans cette partie-là, on va surtout s'intéresser à qui peut avoir accès au backup, et où est-ce qu'on va aller stocker.
Et pour ça, on va y répondre assez facilement, c'est de donner seulement accès à l'équipe technique au backup, et pas à toute la compagnie.
En fait, le plus d'accès que vous allez avoir, le plus de chance que vous allez avoir d'avoir un accès qui, du coup, est oublié, qui n'est pas maintenu, et qui peut être piraté.
Pourquoi toute l'équipe technique ? Je l'expliquerai au niveau de la restauration.
Mais en gros, il faut que toutes les personnes qui puissent restaurer aient accès et qu'on n'ait pas de blocage à ce niveau-là.
Et enfin, si possible, en fait, ce qu'il faut faire, c'est le stocker hors serveur.
Parce qu'effectivement, c'est possible de stocker sur le serveur vos backups, de mettre une règle Apache, de mettre une règle config NGNX,
mais c'est aussi très facile de faire un changement sur le serveur et d'oublier de la remettre.
Et donc, du coup, s'il est sur un serveur qui est externe, qui n'est pas accessible par le web,
et bien là-dessus, vous êtes sûr que dans tous les cas, ils n'auront pas accès, même si vous oubliez cette règle NGNX.
Et enfin, si vous avez réussi les quatre autres piliers, vous allez arriver sur la dernière partie, qui est la restauration.
La restauration, c'est, on va dire, l'achèvement de la stratégie de backup,
et c'est là que vous allez voir si vous êtes planté ou si vous avez réussi.
Et souvent, quand vous vous plantez, vu que c'est à la restauration que vous vous plantez, c'est trop tard.
Donc, là-dessus, sur la restauration, on va s'intéresser à trois points.
D'abord, comment faire revenir le site, c'est le plus important.
Ensuite, comment réduire la durée pour remettre le site en ligne.
Parce que le client à côté, il peut avoir un e-commerce, encore une fois,
et lui, le moment où le site, il est down, c'est un moment où il perd du chiffre d'affaires,
et donc, du coup, il faudrait réduire ce temps.
Et enfin, la dernière chose, c'est comment réduire les erreurs.
La restauration, c'est un moment où il faut aller rapidement,
c'est un moment où le client, encore une fois, il perd du chiffre d'affaires,
donc c'est un moment où on est stressé.
Et quand on est stressé, on fait plus facilement des erreurs.
Et donc, du coup, pour ça, je vous conseillerais d'abord d'avoir un document en interne.
Tout simplement parce que vous allez en avoir besoin derrière, pour la NIS 2,
pour le donner derrière à l'ACNIL.
Ce document en interne, il devrait expliquer, en fait, tout simplement, la procédure de restauration.
Ce serait une sorte de checklist avec des étapes,
pour lesquelles, du coup, il suffit de suivre ce qui est à marquer sur le document,
et n'importe quelle personne normale de l'équipe IT devrait pouvoir faire la restauration.
Mais après, il ne faut pas un document, en fait, que vous écrivez et qui reste au fond du placard.
Et c'est pour ça que quelque chose qui est pas mal et qui peut marcher dans la plupart des agences,
c'est simplement de l'intégrer à l'onboarding de l'équipe IT.
Ça va dépendre, bien sûr, de votre turnover,
mais si vous avez des recrutements assez fréquents,
ça permet à chaque fois qu'il y a quelqu'un qui rentre dans la compagnie,
à deux personnes dans la compagnie, de pouvoir, du coup, apprendre, pour l'un, la stratégie de restauration, désolé,
et pour l'autre, de la réviser.
Et enfin, les deux derniers points, c'est surtout pour réduire les erreurs,
et réduire le temps, c'est d'automatiser.
Automatiser, uniformiser si possible entre vos clients,
pour faire en sorte qu'il y ait le moins de différences,
et le moins d'erreurs possibles, en fait, de manipulations.
Après, personnellement, moi, ce que j'aime bien faire,
c'est automatiser la restauration,
en utilisant le même script que pour restaurer un staging.
Ce qui est intéressant, c'est que, du coup, on va avoir un script
qui ne va pas tourner une fois au moment où on a la catastrophe,
mais plutôt un script qui va tourner quotidiennement.
Donc, ce qui a ça comme avantage,
c'est que je vais connaître le script,
je vais le manipuler beaucoup plus,
et donc, du coup, s'il y a une erreur dans le script,
s'il y a quelque chose auquel je dois faire attention,
vu que je l'ai manipulé beaucoup plus,
je saurais y faire attention au moment où je vais devoir restaurer la production.
Et enfin, de la même façon,
le staging, en fait, est censé être similaire à la prod,
donc le site du client que les gens voient,
et donc, du coup, ça me permettra aussi de manipuler l'environnement
pour, pareil, le connaître,
et savoir s'il y a des problèmes...
Oh, j'ai été beaucoup trop rapide !
S'il y a des problèmes au niveau du site,
ou des spécificités à connaître.
Du coup, pour moi, à mon niveau,
automatiser ce système,
en gros, j'utilise un système où,
de base, j'ai du coup un AWX,
en gros, c'est quelque chose qui permet de lancer des scripts Ansible,
et ce que je vous propose, tout simplement, pour vous,
pour rendre plus simple ce système,
c'est d'utiliser à la place une crône.
La différence entre les deux, c'est qu'à WX,
quand le job va rater, il va m'avertir.
Et, du coup, si je n'arrive pas à restaurer un site,
je serai au courant que je n'ai pas réussi à faire la restauration.
Donc, de ce côté-là,
je serai, du coup, au courant.
Le script va, du coup, prendre mon backup,
qui est en normal un zip,
il va le désipper,
il va l'installer, du coup, sur le staging,
pour faire en sorte que le staging ait la version
qui est à l'intérieur du backup.
Et ensuite, pour vérifier, tout simplement,
que mes pages importantes marchent,
ce que je vais faire, c'est simplement,
j'ai un outil d'uptime
qui va, du coup, vérifier que tous mes pages sont en 200.
Effectivement, ce n'est pas parfait.
C'est-à-dire qu'on ne va pas tester de la logique
qui pourrait être comme soumettre des formulaires.
On pourrait aller plus loin.
On peut utiliser un script playwright.
Mais quand on regarde,
la plupart des gens, aujourd'hui,
n'ont pas ouvert un backup.
Donc, en soi, rien que d'avoir ça,
on est déjà beaucoup plus sécurisé
que si on n'avait rien du tout.
Et du coup, ça me permet de conclure
qu'en fait, une stratégie de backup réussie,
ça ne va pas être d'aller jusqu'au bout.
Ça ne va pas être d'aller jusqu'à aujourd'hui,
aller tenter de créer un script pour restaurer.
Mais ça va être déjà de commencer à vérifier, en fait,
que vous avez bien tout qui est en place.
En gros, allez voir déjà une première fois,
parce que ce que me donnent les chiffres,
c'est qu'aujourd'hui, pour la plupart des gens,
ce n'est pas le cas.
Pour la première fois,
allez voir si ce que vous avez à l'intérieur de vos ZIP,
ce que vous avez à l'intérieur de vos backups,
correspond bien à ce que vous avez, du coup,
au niveau de votre site web.
Ensuite, faites attention,
parce que toutes les technologies de backup,
elles ont un point commun,
c'est qu'elles ne sont pas fiables à 100%.
Il y a toujours une raison
qui peut faire que votre technologie de backup
rate un backup.
Chez Umbrella, chez Updraft,
n'importe quelle technologie,
on n'aura jamais un taux de réussite
qui sera à 100%,
parce que simplement,
on fait de l'informatique,
et dans l'informatique,
il y aura toujours des bugs.
Et donc, du coup,
respecter la règle des 3, 2, 1,
ça va vous permettre déjà
de vous mettre beaucoup plus à l'abri.
Et pareil,
pour les plateformes qui vous hébergent,
vous l'avez vu avec, du coup,
OVH,
vous n'êtes jamais 100% à l'abri
que vous n'ayez plus accès
d'un jour à l'autre à vos backups,
parce que, par exemple,
le serveur a brûlé.
Et enfin, dernière chose,
un backup,
c'est censé être une technologie,
enfin, c'est censé être votre bouée de sauvetage.
Ce n'est pas censé être ce qui vous coule.
Donc, s'il vous plaît,
protégez vos backups.
Et c'est fini.
Merci, Cyril.
On va avoir un petit peu de temps
pour des questions,
si vous en avez.
Oui.
Merci pour la présentation.
Très intéressant.
J'ai plusieurs questions.
Je passerai le micro,
et peut-être qu'il reviendra vers moi plus tard.
Déjà, au niveau de l'intégrité,
tu as parlé d'automatisation.
Est-ce que tu aurais des cas concrets
ou des exemples à nous partager
pour automatiser le fait de s'assurer
de l'intégrité des données qu'on a backupées ?
Aujourd'hui, en fait,
ce que je vous propose,
parce que c'est plus simple,
c'est surtout d'aller vers une restauration.
Et c'est la slide d'avant, en fait.
Ce système-là, en fait,
vous permet tout simplement
de vérifier en restaurant
que le site est bien fonctionnel.
Avoir des chiffres sur les fichiers
dans les backups,
c'est quelque chose,
en vrai, c'est satisfaisant.
Mais à la fin, en fait,
vous pouvez avoir un fichier qui manque
et ce fichier, il est critique, en fait.
Je ne sais pas si j'ai répondu à la question.
Plus ou moins.
Mais justement,
on fait la restauration.
Mais d'ailleurs,
on aura quand même une...
Aujourd'hui, dans notre agence,
on a forcément une vérification manuelle.
Il est possible d'être domatisé
cette vérification ?
Est-ce que toi, tu as des cas,
déjà, où tu peux automatiser
justement ces vérifications ?
Pour l'intégrité ?
Oui, pour le moment,
ce que j'ai, c'est...
Chez certains clients,
j'ai des scripts Playwright,
c'est ce dont j'avais parlé,
qui tournent
et qui vont, en fait,
valider certains formulaires.
Mais après,
je n'ai pas été
beaucoup plus loin que ça.
Comment tu écris Playwright ?
c'est la technologie de Microsoft.
Je crois que c'est P-L-A-Y.
Et après,
W-R-I-G-A-H-T.
En gros, ça fait tourner dans un navigateur...
Enfin, ça contrôle le navigateur.
Et après, à partir de là,
ce qui se passe,
c'est qu'en normal,
j'utilise un script...
Enfin, j'utilise tout simplement l'IA
pour générer le script.
Et après, à partir de là,
c'est l'IA qui détermine un peu
le code qui va être écrit
par rapport au flow
que moi, je lui ai donné.
Est-ce qu'il y a d'autres questions ?
Bonjour.
Merci pour cette conf.
On parlait de fréquence de backup
pour un site vitrine
mensuel ou hebdo,
un site e-commerce quotidienne,
voire plus finement.
C'est pas mal, d'ailleurs.
Pour un organisme de formation,
par exemple,
avec des sessions Zoom
matin et après-midi,
qu'est-ce que tu pourrais préconiser
comme fréquence ?
La question, ça va être surtout
qu'est-ce que tu es prêt à perdre ?
C'est...
En gros,
quand on choisit la fréquence,
c'est un risque
comparé, on va dire,
à un coût,
qui est la procédure de backup.
Et la question, c'est
qu'est-ce que tu as d'important
dans ces sessions ?
Si la session,
c'est la même que la dernière,
on peut peut-être faire
un backup tous les jours,
enfin, tous les jours,
et ça ne posera pas de problème.
Si, par contre,
chaque session est différente,
il faudra peut-être faire
deux backups par jour
juste après la session en question.
Oui, suivant la criticité de...
C'est ça.
Bien bien.
Merci beaucoup.
Bonjour.
Merci pour la conférence très intéressante.
J'avais deux questions.
Une première sur la rétention,
sauf erreur,
je n'ai pas vu ce sujet
dans tes slides.
En gros,
qu'est-ce que tu recommandes
en termes de fréquence
de rétention ?
Et aussi sur la localisation
des systèmes de sauvegarde.
J'ai compris que tu n'aimais pas
un VH à Strasbourg,
je viens de là-bas,
donc je sais parfaitement
de quoi tu parles.
Mais est-ce que tu as des fournisseurs
où je dirais plus de temps
en ce moment,
la préoccupation,
c'est les pays
dans lesquels on va stocker les données.
Est-ce que tu as des recommandations
par rapport à ça ?
À la base,
j'étais censé parler justement
des pays où faire le stockage,
mais quand j'avais fait mes répétitions
du talk,
j'allais beaucoup plus lentement.
Du coup,
ça ne tenait pas dans les 20 minutes.
En gros,
moi,
ce que j'aime bien,
c'est les buckets scale-way.
Je ne sais pas si tu connais.
Et ça permet de les garder
en fait dans l'UE.
Et nous,
en France,
en fait,
ce qui va être surtout très important,
c'est toujours,
quand on les stock,
d'avoir au moins deux serveurs,
on peut utiliser le serveur
du site web
si on veut réduire les coûts.
Mais sinon,
ce qui est toujours mieux,
c'est d'avoir deux endroits
où ils sont stockés.
Moi,
ce que je fais,
c'est sur scale-way,
je le stocke d'un côté en France,
donc sur le bucket en France.
Et de l'autre côté,
j'ai un autre bucket à Amsterdam.
Comme ça,
je suis sûr que s'il y a un problème,
ils sont vraiment physiquement distincts.
Et après,
l'autre question,
c'était sur la rétention,
c'est ça ?
Donc sur la rétention,
j'ai vraiment été,
enfin, c'est un point que j'ai passé assez rapidement
avec la règle des 3, 2, 1.
Donc je dis au minimum,
en avoir 3.
Après,
en soi,
le mieux,
c'est d'en garder
ceux de tous les jours,
on va dire,
pour la semaine.
Et derrière,
en garder peut-être 1 sur la semaine dernière,
1 sur,
enfin,
1 sur les semaines dernières du mois,
on va dire ça comme ça.
et après,
peut-être 1 par mois.
Et petit à petit,
en fait,
avoir moins de granularité.
Parce qu'en fait,
les 3 quarts des restaurations qu'on fait,
souvent,
c'est le site qui a planté
et le client,
il a vu le site.
Et donc,
du coup,
on a souvent besoin
des backups de il y a 2 jours,
de il y a 3 jours.
mais on a très peu besoin,
en fait,
des backups d'il y a 6 mois.
Une dernière question,
peut-être ?
Oui.
Il y a 2 personnes.
Bonjour,
merci pour la conférence.
Est-ce que tu as été déjà impacté
par du ransomware
ou des choses comme ça,
où je sais que ça peut avoir
un impact sur les backups,
parce que du coup,
l'intrusion,
peut aussi
perturber les backups
et les rendre inutilisables ?
Est-ce que c'est quelque chose
que tu rencontres aujourd'hui ?
Qu'est-ce que tu fais aujourd'hui
pour parer à ça ?
Aujourd'hui,
en fait,
on a...
On va éviter de rentrer
dans le discours commercial.
Mais en gros,
en normal,
quand il y a un ransomware,
on backup d'avant,
tout simplement.
En normal,
quand le ransomware est arrivé,
ça a bloqué tout.
Donc,
il faut juste trouver le backup
qui était précédent,
au moment où le virus était présent.
Du coup,
c'était à peu près la même chose.
C'était,
est-ce que tu profites
de faire tes backups
pour regarder l'intégrité
de ton site,
regarder un petit peu
? Est-ce que ça vaut le coup
de faire une backup ?
Ou alors,
est-ce que je vais directement
lancer une alerte ?
Et c'est un humain
qui va venir vérifier
et regarder ce qu'il en est ?
Du coup,
moi,
sur mon système,
c'est...
Par défaut,
c'est automatisé.
Et après,
quand il y a une alerte
qui est levée,
du coup,
soit je n'arrive pas
à restaurer,
tout simplement,
soit j'ai un uptime
qui merde,
là,
ça va être à l'humain
d'aller vérifier.
Donc,
ça permet dans 90% des cas
de ne pas avoir
à le faire à la main.
Et après,
il reste des petits cas
où, par exemple,
il y a un Elementor
qui a été mis à jour,
ça a fait cracher une page
ou des choses comme ça,
qui va derrière
nous forcer
d'y aller à la main.
Merci, Siri.
Bon,
on va devoir s'arrêter là.
Merci beaucoup.