S03EBONUS · Les stratégies de backup & de reprise

0:11 Hello tout le monde, on vous propose de réécouter l'intervention de Quentin Adam, CEO de Clever Cloud, interviewé par Youn Cheney, activiste chez Tech.Rocks et codeur en scène. La room a été animée par Siam Alali, CTO de chez Arte. Bonne écoute! Merci à tous de répondre présent sur cette room. C'est extrêmement important pour moi d'être dans la communauté TechRock et je suis ravie en tout cas d'avoir mes pairs aujourd'hui qui puissent pouvoir lancer des sujets extrêmement intéressants. Donc, alors, l'intitulé de cette room, c'est stratégie de backup et reprise par Quentin Adam. Donc, merci Quentin d'être là. Alors, quelques questions se posent à nous aujourd'hui avant d'adopter ces stratégies, ces fameuses stratégies, les déploiements, les évolutions de la stratégie de sauvegarde dans le cloud privé et public. On se pose énormément de questions, par exemple, sur tout ce qui est format, typologie de données, localisation, les rythmes de sauvegarde, les modèles, les stratégies adoptées, etc.

1:21 Tant de questions et tant de questions qu'on aimerait vous poser à tous les deux. Et donc, je vous présente aujourd'hui Youn, activiste chez TechRock. Et puis Quentin, Adam, CEO de Clever Cloud, on est ravis de vous avoir aujourd'hui parmi nous et de pouvoir partager avec vous vos expériences et votre expertise justement sur le sujet. Donc, Youn, à toi la parole. Merci. Je voulais faire juste un petit avant-propos parce que c'est trop mal lieu, parce qu'il y a eu le sinistre OVH et ce n'est pas du tout un moment anti-OVH et tout ça. Au contraire, c'est très difficile pour eux, ça souffre beaucoup. Donc, je voulais leur faire de gros bisous avant de commencer à toutes les équipes techniques et pas techniques. Ils sont en train de tout gérer là-bas. Et cette crise, mine de rien, a été un miroir grossissant de toutes les pratiques ou les manques de pratiques sur les backups et surtout la restauration, la reprise, la reprise d'activité. Qui sont souvent négligés dans les parties, quand les boîtes naissent et tout ça.

2:25 Et juste pour l'anecdote, il y a un ou deux ans, Seb, j'étais en mode SaaS et il nous a envoyé, la masse qui faut, reçoit un mail pour dire que dans trois semaines, il n'y a plus de mode SAS. Et donc là, on s'est mis à la recherche d'un prestataire. Donc, s'il faut, on revient avec 2-3-2-1, elle me demande de les relire. Et là, je regarde à la début, il n'y a rien sur les backups. Oui, mais si le commercial, il m'a dit que c'était bon. Non, mais si légalement, il n'y a rien sur le bon de commande et sur les conditions particulières et tout ça, il n'y a pas de backup. Si tu n'as pas de backup sur ta compta, Si on réussit un sinistre, on va être embêté. Et du coup, on a dû... On demandait, mais genre 3, 4, 5 fois avant d'avoir des devis corrects. Et tout ça pour montrer qu'il y a un léger manque de culture sur ces sujets-là. Et je voulais profiter de ta présence, Quentin, parce que vous êtes une plateforme as a service, vous hostez des données, des bases de données. Du coup, je voulais que tu commences, et après on va dérouler les questions. Comment ça se passe tout ce qui est backup et restauration de données chez Clever pour vous et pour vos clients?

3:30 C'est peut-être des stratégies différentes. Oui, en fait, c'est des stratégies qui sont multiples parce que je pense que quand on parle de backup, il faut avoir conscience qu'on est sur un sujet qui est… qui est beaucoup plus compliqué que ce que les gens imaginent au prime abord. C'est-à-dire qu'en général, les gens se disent« et on fera des backups» et ne déterminent pas très bien ce qu'ils veulent dire par là. Et en fait, la notion de backup, elle est multiple. Chez Clever, la backup est gérée dans un système qu'on appelle la backup API. Chez nous qui gère différentes typologies de backup en fonction de ce qu'on veut faire et leur monitoring. D'abord, on peut peut-être se poser la question pourquoi on fait des backups. Les raisons pour lesquelles on fait des backups sont différentes en fonction des use cases des clients. Tu peux faire des backups soit pour prévenir des défaillances hardware, autrement dit, tu as cramé un disque dur. Il faut savoir qu'un disque dur, notamment les disques durs tournants, ils s'usent et ils finissent par mourir. Et les disques durs de type NVMe, ils finissent par ne plus être capables. les SSD qui vont être utilisés en NVM ou quoi que ce soit, ils vont être plus capables d'écrire au bout d'un moment.

4:36 Donc, vous avez ce genre de phénomène où les disques meurent dans le temps. Alors après, il y a des cas extrêmes, effectivement, incendie du data center. Mais en fait, vous avez un premier cas de... Comment on prévient une défaillance matérielle? Comment on prévient une défaillance logicielle? Là, typiquement, vous êtes en train de parler d'une base de données qui aurait craché et vous avez essayé de... de la reprendre et potentiellement vous n'êtes pas capable de remonter l'OS sur lequel il était. Et après, vous avez d'autres types de demandes que de la défaillance. Vous avez prévenir une erreur humaine, c'est-à-dire que vous avez des backups, ils existent pas parce qu'on pense que le système va planter, mais parce que quelqu'un pourrait supprimer de la donnée. Et on pourrait en avoir besoin derrière. Donc, c'est peut-être des fois le backup, il existe plus pour donner une sorte de délai dans la suppression qui permet d'être sûr que s'il y a une erreur de fait, on va être capable de réagir. Et après, il y a des contraintes légales aussi. Certains backups existent pour des contrats extrêmement légals.

5:38 De choses. Et je pense qu'en fonction de la question qu'on pose, on ne doit pas y répondre de la même façon. Tu as l'impression que je loupe un bout, Youn? Si on peut peut-être... C'est la raison que je suis une mairie, j'ai un site web, j'ai de l'information qui est mise à jour tous les jours, tous les deux jours, toutes les semaines. Qu'est-ce que tu conseillerais dans ce cas-là? Quelle stratégie de backup tu conseillerais? Dans ce cas-là, très précis, j'aurais deux stratégies. J'aurais une stratégie très contenu humain, d'effaçage, qui est une stratégie avec un backup faiblement accessible depuis la cible de backupage, qui est vraiment un backup qui permet de se donner 12-24 heures. Sur la moindre action et d'être capable de récupérer de la donnée si jamais je suis parti en cacahuète pour une raison x, y. Et j'aurais... une deuxième stratégie de backup qui est là pour prévenir une défaillance matérielle. Mais je ne vais pas nécessairement lier les deux stratégies de backup. Et je m'explique à ce niveau-là.

6:41 Toute stratégie de backup, en fait, c'est une stratégie d'assurance. Donc, à chaque fois que vous avez déterminé une stratégie de backup, vous avez un coût que vous mettez en face d'un risque. Et en fait, la question, c'est quel est le risque de perdre de l'argent et comment vous mesurez ce risque-là et vous vous assurez qu'en fait, ce risque-là, le coût financier est tellement fort que ça vaut le coup d'investir dans du backup. Et je pense que c'est un point qui est très important. Et donc, en fait, parfois, avoir plusieurs stratégies de backup du même sujet n'est pas nécessairement une mauvaise idée. Je ne sais pas si j'ai été clair dans ma façon d'exprimer. Est-ce que tu peux être peut-être un peu plus précis sur les différentes stratégies de backup? On a été fait ce que c'est en termes de localisation, en termes de fournisseurs, etc. En fait, sur les stratégies, du coup, je détermine. Pourquoi tu veux backuper? Est-ce que tu essaies de backuper une défaillance ou est-ce que tu essaies de backuper un problème humain? Et en fait, après, pour moi, tu as deux grands types de backup.

7:44 Tu as les backups de données structurées et les backups de données non structurées. Je m'explique. Quand on a, par exemple, des machines qui tournent sur du cloud, elles ont un disque dur virtuel. On pourrait décider de backuper le disque dur virtuel. Et en fait, si vous... Vous maintenez un backup du disque dur fait par exemple tous les jours à minuit. Ça veut dire que vous êtes capable de relancer la machine. Par contre, ça, c'est de la donnée non structurée. En fait, vous ne savez pas ce que vous backupez du tout. Vous faites un snapshot et vous priez pour que la donnée que vous backupez ne soit pas corrompue. Et vous priez pour qu'au moment où vous backupez, ce soit la bonne donnée. Parce qu'en fait, comme vous n'avez pas structuré votre stratégie à ce moment-là, ça permet en théorie de repartir, mais c'est très difficile de tester ce que vous avez fait. Parce qu'en général, dans la machine, il y a plein d'autres trucs qui font que si vous la lancez à côté pour faire du test, vous allez flinguer le système. Donc, vous avez juste l'inchatté de disque dur. Ou alors, vous pouvez backuper de la donnée structurée. Et backuper de la donnée structurée, ça veut dire que c'est une donnée où vous allez être capable de l'introspecter pendant votre backup.

8:51 Et en fait, quand on a une stratégie de backup, ce que je recommande toujours, c'est de monitorer le backup. C'est-à-dire qu'en fait, quand tu fais un backup, tu le fais, mais en fait, il peut se produire plein de choses à ce moment-là. D'abord, le système avec lequel tu backups peut se planter. Et se planter silencieusement. J'ai eu une engueulade. Au mairie il y a quelques années avec un fournisseur de bases de données, dont le système de backup, en fait, quand il plantait, il plantait de façon silencieuse. Et donc, du coup, tu ne savais pas que tes backups étaient corrompus. Donc, c'était complètement débile. Et la seule solution pour savoir si les backups étaient corrompus, en fait, c'était de remonter les backups. Je trouve que c'était un truc qui ne backupait des terres. Il y aura au côté de données, c'est un peu débile leur modèle, mais en fait, si tu veux, tu as un truc à te dire. Si tu fais un backup, tu dois t'assurer que ton backup marche. Et pour t'assurer que ton backup marche, en fonction du truc que tu vas backuper, Si tu backups de la donnée non structurée, tu ne seras pas capable de le faire. Est-ce que je suis clair? Pas du tout, là, à la gueule. Juste pour vulgariser un peu ce que tu appelles la donnée structurée, ça va être un export de base de données, par exemple.

9:57 Exactement, tu fais bien de le dire. Donc effectivement, Dans le cas, par exemple, prenons le site de la mairie. Il tourne sur un cloud computing quelconque dans une VM. Tu peux backuper la VM. Et ça, c'est cool. C'est si jamais le hardware qui fait tourner la VM meurt, tu relances une VM avec le même disque dur. Ça devrait fonctionner dans la majorité des cas. Sauf que... Tu couvres une différence matérielle, le serveur qui casse pour X ou Y, c'est ça? C'est ça. Mais tu ne sais pas si ton backup fonctionne. Tu n'as aucun moyen de savoir si ton backup est bon. Tu fais du test bit à bit, mais voilà. Et en fait, si jamais ton backup a été fait avant, par exemple, un vérolage un peu discret, tu ne sais pas facilement remonter jusqu'à ce moment-là. Et en fait, tu ne sais pas réextraire de la donnée de ton backup. Comme par exemple, j'ai effacé une page par erreur. Remonter la VM du disque, enfin, snapchoter la VM du disque, remonter la VM du disque pour aller extraire la page, ce n'est pas simple.

11:00 Alors que si tu couples ça à une deuxième chose qui est le site de ta mairie, là, il est en PHP, enfin, c'est un WordPress, Tu vas backuper le MySQL et les fichiers du WordPress de façon séparée. C'est facile d'aller introspecter ce backup-là, de juste le restaurer dans une base de données pour aller récupérer la page qui te manque et éventuellement dans le file system des assets. Et surtout, ce sera facile de faire des tests sur cette base. de données pour savoir ce que tu as back-upé. C'est-à-dire que si ton backup, tu fais tourner des tests dessus, en fait, tu es capable de restaurer le backup dans une base. Donc, tu es capable tous les jours de savoir qu'en fait, ton backup, c'est réellement un fichier pas corrompu, mais un fichier fonctionnel. Et tu es capable de faire des métriques, comme par exemple le nombre de lignes qu'il y a dans une table, de vérifier que la source de ton backup et que le backup ont le même nombre de lignes dans une table, te permet de garantir que ton backup est réellement bon. Et du coup, tu as une chose qui est à peu près propre à ce niveau-là.

12:02 Et en fait, c'est comme ça que tu vas faire en sorte de couvrir d'un côté la défaillance fonctionnelle et de l'autre côté une défaillance qui peut être humaine. Sachant que tu peux couvrir une défaillance humaine avec ton backup structuré. Donc une défaillance humaine, c'est quelqu'un qui va bousiller de la donnée, qui va bousiller des pages de manière non intentionnelle, contrairement à un pirate. Et c'est de ça qu'il parle. Oui, c'est ça. Il faut illustrer. Et si actuellement, il y a pas mal de cloud providers, donc le cloud, c'est magique, qu'est-ce qu'ils font pour moi en termes de backup? Est-ce que je vais en liste tantôt sur Google, Amazon, OVH, Scaleway et Azure? Est-ce que mes backups sont couverts ou est-ce que je dois quand même faire des choses? Parce que là, les incendies de data center, c'est moins… c'est plus ou moins ton problème. Le fait qu'une région soit coupée, c'est plus ou moins ton problème. Qu'est-ce que tu dois faire? Qu'est-ce que tu ne dois plus faire? La question est forcément naïve, je suis mon temps. La première chose, c'est que s'il n'y a rien de défini dans votre contrat, par défaut, le cloud ne sait rien.

13:11 Et ça, c'est un truc qui est très important à comprendre, c'est que ce n'est pas parce que vous êtes en cloud que vous avez des backups inclus. Les backups, ils ne sont pas gratos. c'est toujours une option qu'il va falloir prendre. Donc après, si par exemple vous allez sur un produit structuré, donc chez CleverCloud, les databases as a service, chez AWS, les RDS, etc., vous avez ici le moyen d'avoir clairement d'identifier, là on fait des backups. Et là, c'est le moment où il faut rentrer dans les petites lignes. On fait des backups, OK. Ils sont stockés où? Parce que s'ils sont stockés dans la même salle, ça prévient une défaillance de la machine, ça ne prévient pas une défaillance de la salle. Et après, la salle peut être par terre et réactivée, ou elle peut être par terre et détruite. Il n'y a pas que les incendies qui détruisent les salles. Un avion qui se crache, par exemple, la salle, vous ne la relèverez pas. Et pour le coup, autant mettre des sprinklers dans les data centers, c'est un truc qui se fait, autant c'est compliqué de parer un avion. Un avion, c'est un avion.

14:13 Donc, il faut prévenir la défaillance de la salle. Et en fait, pour ça, c'est le moment où vous devez vérifier que c'est mis sur un autre AZ. AZ, c'est un terme qui a été utilisé d'abord par Amazon et qui s'est généralisé. C'est un data center qui est différent du data center. Center dont vous parlez, deux AZ différents, sont censés être deux data centers différents dans une zone géographique proche, moins de 100 km en clair, mais quand même théoriquement distant d'au moins 4 km. Sachant que des data centers très grandes vont prendre des... Non, je... On disait sur les différents data centers, ça s'appelle aussi les régions en fonction du provider et tout ça. Oui, sachant que tu peux avoir des azettes différents dans les mêmes régions. Mais l'idée, c'est de dire, tu vas essayer de te prémunir, sachant qu'une région entière peut tomber, et notamment ça peut arriver chez Amazon, c'est déjà arrivé, pas sur la totalité des services, mais ça peut arriver. Et dans ces cas-là, ce qui peut être utile, c'est effectivement d'avoir du multiple région, parce que là, tu vas étendre ton risque au maximum.

15:21 Donc, par défaut, aucun cloud provider, encore une fois, ne vous fournit des backups, sauf sur des produits sur lesquels c'est explicitement mentionné. Et ça, c'est un truc qui est très important, c'est de vérifier tous les produits que vous utilisez. Et après, en général, la capacité à backuper en multi-AZ ou en multi-région, c'est une option. Pourquoi? Parce que c'est des data transfer et c'est de la copie de data. Et ça coûte de l'argent. Et donc, en fait, comme il y a une chasse au coût, tous les fournisseurs fournissent des produits un peu, je dirais, ras des pâquerettes. Et en fait, du coup, vous vous retrouvez avec des produits où il faut aller rajouter des options si vous voulez ces options-là. Parlons un peu de clair. Comment vous faites chez vous? Si je mets une base de données ou quelque chose sur votre CELAC, la donnée va être dupliquée automatiquement? Est-ce qu'il faut que je paie une option? C'est sur combien de data centers? Est-ce que vous faites du stockage sur bande? Comment ça se passe? Dans la mesure de ce que tu peux nous révéler. Alors, sur Clever, si tu mets de la data dans CELAR, par exemple, chez nous, qui est notre équivalent à Amazon S3, toute donnée que tu mets là-dedans, ta data est découpée en petits morceaux.

16:30 Donc, on fait des petits blocs qui sont répartis sur des serveurs. Et en fait, pour chaque bloc... Il va être répliqué trois fois et ces métadonnées sont répliquées six fois. Donc la question est de savoir, les métadonnées, c'est comment réassembler les fichiers. Ce cluster-là, chez nous, il est à l'échelle d'une région. Donc, par exemple, la région de Paris, qui fait que c'est réparti entre deux data centers. Pour l'instant, c'est là, bientôt un troisième. Et ce qui fait que ta copie entre deux serveurs, si on perd la moitié de la région de Paris, on ne perdra pas ta donnée. Et donc, on ne pourra plus écrire dans le cluster si on perd la moitié du truc, mais on pourra toujours aller lire et ta donnée ne sera pas perdue. Et il se trouve que c'est là, c'est le système dans lequel nous, on backup tout le reste. Donc, c'est notre système de backup. Donc, quand tu prends une bache de données PG chez Clever, en fait, ce qui va se passer, c'est qu'on va en créer un fichier du backup, donc un fichier structuré, et on va le... Ce qui fait que si on perd un data center entier à Paris, il n'y a pas de question, ton fichier sera back-upé.

17:40 La question, elle est par contre, comment on vérifie que ce backup est bon? Et si tu veux, ça, c'est une question qu'on peut voir un peu plus tard. En fait, c'est une question hyper importante. En fait, il y a énormément de boîtes qui ont des backups. C'est des tables d'après. Mais en gros, c'est de la backup sur des disques durs qui sont sur différentes localisations géographiques. C'est ça. C'est ça. Par défaut, on va toujours backuper en différentes localisations géographiques dans la même région. Vous avez du backup sur bande ou sur DVD ou même chez un prestataire externe? Alors, pour l'instant, nous, on ne le fait pas, ça, parce que le backup sur bande, ça n'est rentable qu'à partir d'une quantité en pétaoctets extrêmement forte. Et aujourd'hui, on ne fournit pas. L'intérêt du backup sur bande, pour que tout le monde comprenne, une bande, ça s'écrit très lentement et ça se lit très lentement. Donc en fait, le backup sur bande, c'est génial quand tu veux être sûr de pouvoir retrouver ta donnée un jour ou quand tu as de l'archivage légal à faire. Mais si tu veux pouvoir manipuler ta donnée ou par exemple faire un retour sur un incident, ce n'est pas la meilleure stratégie.

18:44 Parce qu'en fait, ça coûte assez cher à petit volume. Il faut avoir vraiment des gros volumes pour que ce soit rentable la bande. Et en fait, ça peut être assez pénible à faire. C'est beaucoup de mécanique. Il faut donner un ordre d'écriture, donner un ordre... de lecture, etc. Par contre, ça peut être la dernière ligne de défense. C'est-à-dire que c'est bien de faire un backup sur bande pour aller récupérer la donnée du mois dernier. Si vraiment on a tout perdu et qu'on a eu un enchaînement de catastrophes, c'est bien parce qu'au final, la rétention sur bande, elle ne coûte pas très cher. Mais nous, pour l'instant, on n'en fait pas. Du coup, on va passer à la reprise. Parce que juste pour entendre le cabinet, on va parler de PRA, de prendre reprise d'activité. C'est-à-dire qu'on va reprendre l'activité de manière dégradée sous un certain délai. Ou le plan de continuité d'activité, où là, il faut le minimum de coupure entre les deux. Donc, on a backuppé, mais si on ne backupe pas, si on n'a jamais testé le backup et que le jour où on l'a insinué, ça ne marche pas, tout l'usure est sur nous et c'est bien bête.

19:44 Donc, comment on fait pour tester et sans que ça coûte une blinde précise au budget de chaque entreprise? Alors, encore une fois, soit vous prenez un service managé, donc sur des bases de données ou des choses comme ça, vous avez des services managés de backup qui vont vous faire les tests. Il faut souvent pousser les fournisseurs dans leur retranchement. Moi, je n'en connais pas, dès qu'ils font les tests eux-mêmes pour l'instant. Je pense que ça va se généraliser. Nous, on le fait de plus en plus chez Clever. Là, c'est une bêta privée pour l'instant, cette fonctionnalité-là, où en fait, tous vos backups seront restaurés dans une DDD tous les jours et recheckés avec le compte de ligne, etc. Pour s'assurer de ça. Pour l'instant, le monitoring par défaut, on vérifie que les tailles de backup sont cohérentes. Mais en fait, à ce moment-là, on ne s'est pas prémuni sur une inversion de bit ou un truc comme ça. Et ça, factuellement, la seule façon de vérifier qu'un système de données structurées est toujours fonctionnel après son backup, c'est de prendre le backup et de le restaurer en test tous les jours. La seule solution pour que ce ne soit pas cher, c'est qu'il faut l'automatiser, l'automatiser, l'automatiser.

20:48 Sinon, vous en avez pour une fortune en temps humain. Mais la meilleure solution, c'est que ce soit hyper automatisé. Et en vrai, c'est la seule solution pour que ce soit propre. Vous pourrez prendre toutes les précautions du monde. Nous, on a déjà eu des backups corrompus. Où le système de backup qui testait la non-corruption du backup nous avait dit que le backup était bon, on l'a stocké, et quand on s'en est resservi, on s'est rendu compte qu'il était corrompu, parce qu'en fait, c'est la même lib qui faisait le backup et qui faisait le check du backup. Et en fait, la corruption, elle était dans la lib. Et c'est hyper con, en fait. Et en fait, vous pourrez... jamais avoir une meilleure confiance qu'en restaurant le système tous les jours. Et quand tu dois constituer un plan de reprise d'activité, c'est quoi pour toi les étapes essentielles? La checklist, ne surtout pas oublier. Donc d'abord, vous avez votre runtime. Est-ce que votre infrastructure, elle est très automatisée? L'infrastructure as code ou l'utilisation de plateformes as a service, ça a plusieurs intérêts, dont celui d'être capable de dupliquer son infrastructure très rapidement.

21:58 Et en fait, c'est pour ça que quand on fait un plan de reprise d'activité, une partie du truc, c'est cette capacité à dire, j'ai perdu mes serveurs, ce n'est pas grave, c'était du cattle et pas du pet. Je ne sais pas si vous avez déjà entendu parler de ce truc-là, la différence entre pet et cattle. La différence entre pet et cattle, c'est vraiment de dire, Si vous êtes face à un incident, si vous êtes face à votre infrastructure, est-ce que chaque serveur a son nom? Vous en avez pris soin, vous avez donné des commandes SSH dedans et il a été installé à l'animal. Et dans ces cas-là, on va l'appeler PET, c'est-à-dire que c'est votre animal de compagnie, vous le connaissez bien. Ou CATOL, CATOL c'est le bétail, c'est-à-dire que vous en prenez un ou vous en prenez 10 000, c'est la même chose. Et en fait, si votre infrastructure a ce code ou l'utilisation d'un platform as a service existe, ça veut dire qu'à partir de votre repos de code, on est capable de reproduire votre infrastructure. Et ça, en fait, c'est la chose la plus importante pour repartir vite. Et après, vous avez votre problème de backup.

23:00 Mais si vous n'êtes pas capable de faire repartir facilement et qu'en fait, vous avez une équipe infra qui a tout installé à la mi-mine, En fait, pour prendre leur temps homme pour installer tout à la même mine, en admettant qu'ils le font une deuxième fois, et en admettant qu'ils l'ont fait la dernière fois il n'y a pas trop longtemps et qu'ils s'en souviennent bien, ils iront un peu plus vite, mais en fait, ils vont quand même se prendre mur sur mur. Et ça, c'est un truc qui est hyper important à comprendre, c'est théoriquement, il n'y a pas d'humain sur la prod. Donc, si vous gérez encore votre infra à la main, Dans votre plan de reprise d'activité, je dirais que le premier point, c'est de l'automatisation. Que ce soit en faisant de l'infrastructure as code ou en utilisant du platform as a service. Pour moi, c'est la même chose. Ou du container as a service. À condition que ça ne coûte pas trop cher d'installer votre système de container. Donc ça, c'est la première chose. C'est comment vous faites votre reprise logicielle. Et la seconde chose, si vous avez des backups structurés bien testés, vous téléchargez votre backup, vous le réinsérez dans votre nouvelle base de données, et là, ça repart. Et là, globalement, le dernier truc qui va vous emmerder dans votre PRA, c'est des notions de network, de DNS, de choses comme ça, un peu pénibles, où là, la question, elle est...

24:10 Quels sont les TTL, où est-ce que vous avez vos DNS, est-ce que vous êtes capable d'aller dans le pas trop lent pour votre plan de reprise d'activité, parce que si par exemple votre TTL de vos DNS sont de 4 heures, vous changez d'idée. Quentin, est-ce que je peux juste demander de dire les abréviations en entier? Mes excuses, le TTL c'est le Time To Leave. En fait quand vous faites du DNS, Les entrées dans le DNS, elles ont un temps que vous mettez en cache. Aujourd'hui, de plus en plus, les gens vont vers des TTL, donc des Time to Leave, de temps d'autorisation de cache, de garder cette information-là en cache courte, parce que tout simplement, sinon, Quand tu fais ta propagation DNS, elle va prendre plus de temps. Et si concrètement le serveur que vous aviez en face d'une IP, pour une raison x, y, que vous ne pouvez pas récupérer son IP parce que c'est une région... différentes et que vous avez un incident sur une région entière, redirigez votre trafic, vous pouvez remonter la totalité de votre infrastructure de l'autre côté, si votre nom de domaine ne pointe pas dessus, en fait, ça ne sert à rien.

25:14 Et je voulais faire une dernière question et après on va commencer à faire monter les personnes pour les différentes questions. Sur le point là-dessus, une bonne stratégie de PRA, c'est très compliqué à évaluer en interne. Parce qu'en fait, quand vous vous le faites, vous ne vous rendez pas compte. De tout ce que vous faites naturellement, de tout ce qui était là avant et sur lequel personne ne pose de questions. La meilleure façon de vérifier que votre PRA a du sens, c'est 1. S'il n'est pas écrit, c'est que vous avez un problème. Parce que le jour où vous aurez un incident, si vous devez réfléchir, vous allez perdre du temps. Donc un PRA théoriquement il est écrit, il existe, c'est une procédure, elle est régulièrement revue. Et moi j'aurais tendance à dire qu'un bon PRA ça se voit en externe. Quand je dis ça se voit en externe, vous n'êtes pas obligé de payer des consultants. Si vous avez une autre boîte tech avec qui vous vous entendez bien, vous le faites l'un l'autre.

26:17 Vous prenez les tags de la boîte d'en face et vous leur expliquez votre temps de reprise d'activité. Et s'ils vous disent ça, ça et ça, c'est des zones d'ombre, on ne sait pas le remonter, c'est que vous avez un problème. Ou vous pouvez également vous servir de vos... aux nouveaux arrivants. En fait, vous faites checker le plan de PRA par des nouveaux arrivants chez vous. Ça permet d'avoir une idée de comment fonctionne l'infra et ça vous permet d'avoir cet audit externe sans pour autant le payer. Il y a des façons pas chères de faire de l'audit externe. Et donc, tout ça, ça coûte du temps, ça coûte de l'argent. C'est quoi tes meilleurs conseils pour les jeunes et plus anciens CTO ou DSI pour vendre ça à ses collègues de la direction? Là où le CFO, là où le CEO, etc. Parce que mine de rien, c'est du budget qu'on prend qui ne sont pas pour du gain de marché. C'est pour gérer les risques. C'est quoi tes meilleurs conseils? Et après, on pourra passer aux questions de tout le monde et faire monter les gens.

27:22 Je pense que sur le... Le meilleur argument, d'abord, c'est ce qui vient de se passer chez OVH. Clairement, avec des boîtes qui n'avaient pas de backup et qui le regardaient de très loin, cette histoire-là, c'est un argument. Et je pense qu'il y a suffisamment de boîtes qui vont couler là ou qui vont juste disparaître, en fait, pour dire... Le point, c'est toujours le risque. En fait, c'est de dire... Toi, CEO, toi, commerce, toi, CFO, toi, légal, tu t'engages sur des choses dans notre produit contractuellement. Aujourd'hui, factuellement, on ne sait pas réellement s'engager dessus. Et donc, ça veut dire qu'on est en train de prendre des décisions. engagement qu'on ne peut pas tenir. Et ça, c'est dangereux. C'est dangereux légalement pour la boîte, c'est dangereux si on a un audit. Et donc, il faut donner un budget. La sécurité et la résilience, c'est des budgets qui sont virtuellement infinis. C'est-à-dire qu'il y aura toujours moyen de se garantir, de se garantir, de se garantir.

28:24 Moi, ce que je faisais, parce que maintenant, c'est moi qui ai la voix, donc c'est moi qui décide de mettre la limite, mais ce que je faisais, c'est toujours expliquer en interne la vision idyllique qui coûte très cher et de dire... Là, je suis pour transiger et dire on fait ça. Ça veut dire qu'il y a telle et telle zone d'ombre par rapport à ce que je ne vais pas faire. Mais en faisant ça, on a dépensé un argent raisonnable qui fait qu'on a diminué notre risque. Le risque zéro n'existe pas, et ça on le sait tous. Mais par contre, il y a une différence entre être exposé à un risque de 10-15% et être exposé à un risque tellement fort qu'on ne sait même pas le chiffrer. Vous voyez ce que je veux dire ou pas? Oui, il est en train, mais si tu es autre, tu n'auras pas beaucoup de mal à les convaincre. Après, c'est des batailles de direction pour obtenir un amortissement de budget qui vont permettre de le faire au fur et à mesure. D'avoir ce pourcentage de budget chaque fois, si je résume.

29:28 Oui, mais en fait, sur la bataille de budget, elle est de dire, pour finir, ça ne coûte pas si cher contre le plan de survie de l'entreprise. La boîte, elle a une RC, elle a des bureaux aux normes alors qu'on pourrait ne pas avoir des bureaux aux normes. Elle dépense de l'argent dans plein de sujets pour assurer sa survie et sa pérennité. Ça, en fait, c'est un sujet qui assure la survie et la pérennité parce qu'en fait, une boîte qui coule sur un disque dur cramé, moi, j'ai déjà vu ça et c'est terrifiant. Et je pense que c'est un sujet qui... Il faut regarder en étant… Si vous n'êtes pas capable de faire un plan de PR à clair, au moins mettez plusieurs stratégies de backup en place et dites-vous que s'il y a un échec, votre plan de reprise sera un reprise à 48 heures, mais vous n'aurez pas tout perdu. Et aujourd'hui, je pense qu'il y a beaucoup de gens qui sont dans un flux de boulot où ils n'ont pas du tout le temps de traiter ce dossier-là. Et donc, du coup, ils ne le traitent pas du tout. Aujourd'hui, si vous n'avez pas le temps de le traiter, pas le temps de l'ouvrir, juste mettez plusieurs stratégies en place à la rache.

30:31 Back-up vos machines virtuelles et vos bases de données et votre code. Vous voyez, vous faites un peu un truc comme ça en vrac, où vous lancez plusieurs perches dans l'eau. Et si jamais vous avez un incident à jour, au moins vous aurez plusieurs jokers pour essayer de répondre. Je ne dis pas que vous aurez la réponse, mais vous avez plus de chances d'avoir la réponse si vous en avez plusieurs stratégies que si vous ne l'avez pas. Et au pire, faites des backups sur une machine chez vous. Vous pouvez très bien imaginer que si vous n'avez pas le temps de checker comment sont construits les backups de quelque chose, et que vous n'avez factuellement qu'une seule base de données, que vous n'avez pas une grosse infrastructure chez vous, et que la backup a fait 40 ou 50 gigas, acheter un disque dur externe, le brancher derrière une box, chiffrer le tout et backuper avec un Raspberry Pi dans votre salon de façon chiffrée. Vous l'écrivez quelque part, la fuite de... de données puissent être comprises si jamais elles existent.

31:32 Mais si vraiment vous n'avez pas le choix et que vous avez des besoins économiques, ça peut être la manière de sauver la boîte. Très bien. Donc, s'il y a des personnes qui veulent le monter, n'hésitez pas. Et Noémie qui voulait dire un mot. Oui, tout à fait, Youn. Je fais une petite page de pub très rapide. Juste pour vous dire, on a un club Tech.Rocks. Merci d'être là. En fait, je refais cette petite annonce parce que je n'étais pas forcément là au début. Et donc, entre le moment, l'interview et la session de questions-réponses, juste pour vous dire, il y a un club Tech.Rocks. Si vous voulez nous rejoindre, n'hésitez pas. Chaque mardi, on se retrouve de midi et demi à 13h30 pour parler soit de tech, soit de problématiques managériales. Et je vous laisse lever la main pour rejoindre la scène et poser vos questions à Quentin. Merci, Nathalie. Du coup, Youn, je vais peut-être continuer avec les premières questions à Quentin. N'hésitez pas à lever la main pour venir partager votre expérience sur cette partie de stratégie backup dans vos entreprises. Et puis, si vous avez des questions pour Quentin.

32:35 Quentin, tout à l'heure, tu parlais justement de cette reprise de données et cette documentation qui est extrêmement importante parce que tu ne documentes pas aujourd'hui. Ce n'est pas suite à un incident que tu commences à documenter et puis corriger ton incident. Quels sont les conseils que tu pourrais nous donner sur cette documentation? D'après toi, quels sont les points importants à mettre dans cette doc? Je pense que les points importants, c'est toujours... En fait, très souvent, les gens, quand ils voient une doc, ils voient un truc très complet, très propre. Et du coup, ils prennent peur et pour finir, ils ne le font pas. Une bonne doc, en fait, c'est une série de points d'entrée. C'est dire, le code va se trouver là, le backup du code est à tel endroit. La base de données, ça, son rôle est primordial. Théoriquement, elle est back-upée là et back-upée là. Et ces backups sont à tel endroit. Et donner l'ordre dans lequel les choses doivent être remontées en disant, il y a des comptes, les comptes pour accéder au système sont là, là, là et là. Et là, encore une fois, après, je dis des choses qui, des fois, ne sont pas applicables quand on a une toute petite boîte.

33:39 Mais nous, par exemple, on a un gestionnaire de mot de passe centralisé chez Clever avec des coffres forts identifiés par team. Ça, chez nous, on utilise un service tiers qui s'appelle One Password. On fait confiance à leur capacité à ne pas tomber. Et en fait, c'est un bon endroit. Tout le monde sait que les mots de passe sont dans One Password. Et en fait, du coup, ça veut dire que dans la doc de reprise, il y a le lien vers le mot de passe à aller chercher dans One Password pour accéder à certaines choses. Et ça, ça permet d'être très clair. Et en plus, ça permet de ne pas casser le système de droit. C'est-à-dire que le mot de passe n'est pas dedans. C'est un lien vers un safe. Et si tu n'as pas accès au safe, tu n'as pas accès au safe. Le système de droit est respecté. Vous voyez ce que je veux dire? Pour moi, il faut rationaliser le truc. Il faut faire un document. Ça peut être un doc, Google Doc, appelé en majuscule et facile à trouver dans votre organisation. Vous n'êtes pas obligé de faire un truc très compliqué. C'est juste genre, il y a un drame, qu'est-ce qui se passe?

34:42 On a perdu tous les serveurs, alors? Et à ce moment-là, il faut lister. Et c'est le moment où, effectivement, quand on écrit ce doc-là, on se dit, là, il y a peut-être des trous, par exemple, qu'il n'y a que sur des serveurs à nous qu'il y a des backups. Peut-être qu'il faut... Il faut les backuper en plus sur un service de stockage distribué, quitte à les chiffrer, encore une fois. Oui, chiffrer des backups, ce n'est pas un problème. Chiffrer des backups à l'envoi, les déchiffrer à la réception. De toute façon, le temps de transfert que vous avez est tellement long que votre CPU s'emmerdera à les chiffrer, déchiffrer. Donc, ce n'est pas un problème d'aller chiffrer vos backups et les mettre chez quelqu'un d'autre. Et si vous avez beaucoup, beaucoup de stockage, vous avez des services de stockage comme B2 de BlackBase, c'est extrêmement peu cher. C'est lent, mais ce n'est pas cher. Et du coup, ça vous permet de backuper en infrastructure externe en faisant un peu de chiffrement. Et c'est facile. Et vous avez des très bons outils en ligne de commande pour faire le chiffrement à l'entrée et à la sortie. Et en gratuit, vous utilisez Keybase pour stocker vos clés.

35:46 Je ne sais pas si je suis clair dans tout ce que je dis là, mais en vrai, les systèmes pour chiffrer des backups externes et les stocker chez d'autres gens qui ne vont pas défaillir en même temps que vous de façon probabilistique, c'est facile à faire. Merci, Quentin. Dis-moi, j'avais une autre question concernant la réplication à distance. On en avait déjà parlé. Aujourd'hui, la réplication à distance, elle est synchrone ou bien tu as une réplication asynchrone? Tous deux offrent des options complètement différentes pour la protection des données informatiques d'une entreprise. Et il est important aujourd'hui, je pense, de comprendre la différence et les effets potentiels sur ton réseau pour assurer une sécurité. données dans ton entreprise, d'après toi, est-ce que oui ou non, il y a une stratégie, enfin, quelle est la meilleure stratégie de réplication, finalement, asynchrone ou synchrone? De façon claire, tout le monde rêve du synchrone. Parce qu'en fait, du coup, tu te poses zéro question et à ce moment-là, tu n'as même pas tellement de plan de reprise d'activité, mais tu as plutôt de la continuité d'activité.

36:54 Et c'est génial d'être synchrone. Par contre, des fois, avec le volume de data ou le volume de transactions que vous allez avoir en local, Le fait d'être synchrone, si vous devez demander l'acquiescement de la transaction également de l'autre côté de la réplication, donc en multirégion de l'autre côté, ça peut devenir lent. Et là, en fait, c'est… C'est le moment où se pose la question métier. Je donne un exemple. Si vous faites du bancaire, si vous perdez une région, s'il y a une transaction qui manque sur cette région-là, c'est grave. Parce que potentiellement, il y a un paiement carte bleue qui n'a pas été pris en compte avec une soustraction sur le compte qui n'a pas été prise en compte. Ce qui veut dire que votre stratégie de réplication doit être synchrone et consistante à distance pour être capable de, en cas d'arrêt de l'activité, pouvoir garantir que la qualité de données est bonne et consistante par rapport à tous les messages que vous avez émis. C'est-à-dire que quelqu'un qui a émis un virement ou qui a émis un paiement CB, vous pouvez garantir que son paiement s'est bien passé.

38:00 C'est la première chose. La deuxième chose à dire sur ce modèle-là, c'est si jamais vous avez un blog très visité avec beaucoup de commentaires, si jamais vous perdez tout, est-ce que les deux derniers commentaires, vous pouvez vous en passer? De façon un peu cynique pour vos contributeurs, oui. Et donc, en fait, là, c'est mieux d'avoir une stratégie de réplication légèrement asynchrone, qui fait que vous êtes capable de vous dire, je ne vais pas perdre le temps d'obtenir l'acquiescement du copie de la donnée dans la région distante. Mais normalement la donnée sera copiée et au pire je perdrai un peu de données si jamais je dois faire un plan de continuité ou de reprise, ce n'est pas nécessairement extrêmement grave. Et ça, je pense que c'est un point qui est important, c'est à chaque fois que vous faites de la donnée, vous devez vous demander quel est le use case de votre donnée et est-ce que...

39:03 Que vous êtes sur une donnée où vous devez privilégier la consistance, la continuité, la réplication ou la rapidité de réponse. Et je pense que c'est la façon de définir entre synchrone et asynchrone comment vous devez gérer le sujet, sachant que le synchrone, de toute façon, vous coûtera toujours plus cher parce que vous faites beaucoup plus de volume de données. Il est à noter que vous pouvez utiliser quand même, je fais un aparté, mais vous pouvez utiliser aussi ces stratégies-là. En local, je donne un exemple. Imaginons que votre business repose sur une base de données, par exemple PostgresQL. Vous avez votre base de données main qui prend la totalité des requêtes. C'est le leader, il prend toutes les requêtes d'écriture, etc. Puis vous avez beaucoup de charges, donc en fait vous lui avez fait deux followers synchrones qui freinent toutes les requêtes de lecture. Donc vous avez mis des proxys, par exemple des PG Boonser devant, qui... vont envoyer toutes les requêtes d'écriture sur le leader, le follower va se prendre les requêtes de lecture, et puis là débarquent les gens chez vous de Big Data et qui veulent faire un peu de BI sur vos données.

40:12 En fait, ces gens-là, ils vont faire de la BI sur vos données, mais en fait, ils vont passer leur temps à écrire des requêtes SQL extrêmement lourdes, extrêmement coûteuses, voire plantogènes. Et en fait, si vous les laissez requêter le cluster principal, en fait, comme votre leader attend l'acquiescement des followers sur les requêtes d'écriture, si jamais vous avez une requête très longue qui arrive sur un follower et le bloque, en fait, vous bloquez tout votre système et ce n'est pas une bonne stratégie du tout. Ce que vous faites dans ces cas-là, c'est que vous créez un autre follower, vous créez un follower asynchrone qui, lui, ne fournit pas d'acquiescement au leader, il le sait, le leader. Et en fait, lui, il va juste lire tout le flux de transaction du leader, parfois ne pas être complètement synchronisé avec le leader, mais très sincèrement, que les gens de la BI ne soient pas synchronisés à la requête près au leader, vous vous en foutez. Et quand les gens de la BI sont en train de foutre par terre votre follower de BI, en fait, vous n'avez pas d'impact sur la prod. Et vous voyez que cette stratégie, qui n'est pas seulement de la backup, qui est aussi de la réplication de données, vous pouvez appliquer les mêmes patterns de réflexion sur votre utilisation au quotidien.

41:18 Ce qui fait qu'un cas où vous aviez un problème de performance de base de données, vous n'avez plus de problème de performance de base de données, vous avez juste un problème de bonne configuration d'un schéma leader-follower. Merci, Quentin. Dis-moi, tout à l'heure, vous parliez avec Yoon sur la partie cloud provider et tu as indiqué qu'il était intéressant, en tout cas, de pouvoir faire des backups dans différentes régions d'un même pays. Moi, j'ai une question. Alors, du coup, plusieurs backups, différentes régions. Est-ce que j'ai la possibilité d'utiliser des cloud providers différents? Alors, je suis chez OVH, je vais faire ma sauvegarde chez AWS et je vais refaire une autre sauvegarde chez Google. Ça te paraît cohérent, pas cohérent? Est-ce que pour toi, je vais aller directement faire des répliques de données uniquement chez OVH parce que je suis déjà chez OVH, donc je vais faire mes répliques de données là-dedans ou j'ai la possibilité d'en utiliser d'autres des providers? Le problème de la backup en multi-cloud, c'est qu'en fait, en général, ils te font payer un peu plus cher ta bande passante.

42:30 Donc, ce sera toujours un sujet un peu plus coûteux. En plus, tu as de l'apprentissage, tu as un contrat spécifique pour ça, qui est un contrat que tu vas sous-optimiser parce qu'évidemment, tu as très peu de volume sur tes backups, donc tu ne peux pas faire effet levier. Par contre, en interne d'un fournisseur, tu prends toujours le risque qu'il y ait une brique interne que tu ne connais pas et dont parfois il n'en a pas conscience, le fournisseur, qui en fait faille une défaillance. Et là, tu te mets dans une galère parce que ton fournisseur, mono-fournisseur, a déconné. Donc moi, j'aurais tendance à avoir une réponse qui est de dire, déjà faire du multi-région chez le même fournisseur est une bonne chose, mais en vrai, faire du multiple fournisseur est plus sécuritaire pour beaucoup de bonnes raisons. Notamment le fait que tu te prémunis d'erreurs internes non volontaires de ce fournisseur-là. Et je pense qu'au global, c'est une bonne chose. Merci, Quentin, pour cet éclaircissement.

43:32 Alors, pour toi, cloud privé ou cloud public? Le problème, c'est qu'est-ce qu'on appelle le cloud privé? Si le cloud privé, c'est installer un V-Sphere, très sincèrement, aujourd'hui, vous avez une meilleure qualité de VM en cloud public. Si le cloud privé, c'est une optimisation de coût parce que vous avez des énormes infrastructures et qu'en fait, acheter du hardware ou liser du hardware et le mettre en DC, c'est plus rentable avec du software au-dessus et vous êtes plus propriétaire de ce qui s'y passe. En fait, parfois, c'est financièrement plus intéressant. Et parfois, vous n'avez pas le choix en termes de sécurité des données et ou en termes de performance ou de hardware spécifique que vous voulez utiliser. Donc, ce n'est pas nécessairement une mauvaise idée de faire du cloud privé. Le cloud public, ça a un intérêt. Il y a plus de choses auto-managées. La question, elle est se poser la question des engagements de votre cloud public et ce qu'il offre comme garantie, et notamment parfois la dissonance entre certains fournisseurs.

44:35 Si vous prenez par exemple AWS, leur marketing vous dit que ça a été designé pour être disponible à 99,99999999%, on ne perdra jamais vos données, etc. Si vous ouvrez leurs conditions générales, l'engagement de SCL, c'est que chili. Et ce qu'on vous dit sur S3, quel truc dans lequel vous faites tous vos backups, c'est la donnée que vous mettez dans S3, on ne peut pas vous la garantir, vous êtes censé la backuper. Vous voyez ce que je veux dire ? Et pourtant, ce n'est pas du tout ce qui est écrit sur le marketing d'S3. Et à chaque fois, vous avez une petite étoile. Ça a été designé pour tenir 99 vers une F8. Par contre, on ne s'y engage pas. C'est quand même le point qui est important. Donc après, est-ce qu'il ne vaut mieux pas aller chez un plus petit acteur qui, lui, va prendre des engagements contractuels? Et ça, je sais qu'il y en a qui le font. Nous, on en fait partie. Mais quand on dit cloud public ou cloud privé, oui. Après, ça ne veut pas dire que l'offre publique par défaut, c'est celle qu'il vous faut. Parfois, il faut demander aux fournisseurs de s'engager un peu plus loin.

45:37 Moi, j'ai toujours tendance à considérer que le cloud public sera plus rentable et plus scalable et plus simple pour la plupart des cas d'usage. Après, d'abord, quand vous êtes en cloud public, vous partagez des choses, vous partagez des bouts de network, vous partagez des bouts de machine. Et on l'a vu, un CPU, c'est corruptible. Donc, encore une fois, c'est quelle est la confidentialité de la donnée que vous avez? Est-ce que c'est une donnée qui va, pour finir, sur un use case hyper edgy, hyper bizarre, si F8, est-ce que c'est si dramatique que ça? Est-ce que vous aviez… Parce que peut-être oui, peut-être si on y réfléchit, pas tant que ça. Et donc, dans ces cas-là, si vous devez absolument garantir zéro fuite, le cloud privé, c'est nécessaire parce que c'est compliqué de garantir des choses software ou même hardware parfois. Et de l'autre côté, il y a le côté coût et comment vous organisez vos coûts. Je ne sais pas si j'étais clair. Très clair, merci Quentin. Merci d'avoir écouté cet extrait de Quentin Adam et de Youn.

46:42 N'hésitez pas à nous rejoindre sur le club Tech.Rocks, sur Clubhouse, ainsi que sur nos rooms tous les mardis de 12h30 à 13h30. Belle journée!