Yandex Cloud a récupéré 97,16 % des données après les attaques contre ses data centers, et les sauvegardes sont désormais activées par défaut

Il y a des choses que tout le monde sait et que tout le monde remet pourtant à plus tard. Les sauvegardes sont la première d'entre elles. La nouvelle histoire de Yandex Cloud illustre bien le prix de ce « plus tard » : après les attaques contre ses data centers, l'entreprise a expliqué quelle part des données de ses clients elle avait pu sauver, et quelle part elle n'avait pas pu sauver.

Ce qui s'est passé et les chiffres

Selon des informations publiées en citant Interfax, Yandex Cloud a rétabli l'accès à 97,16 % des données de ses clients. Cela s'est produit malgré des dommages critiques au matériel : il ne s'agit donc pas d'une brève panne, mais d'un préjudice physique porté à l'infrastructure.

Les 2,84 % restants n'ont pas pu être récupérés. Il y a deux raisons, qui ont joué ensemble : le matériel sur lequel se trouvaient les données est gravement endommagé, et les propriétaires de ces données n'avaient pas de sauvegardes propres sur la plateforme.

Si le client avait activé la sauvegarde, 100 % des données ont été préservées. C'est le chiffre central de toute cette histoire. Il montre que le matériel tombe en panne chez tout le monde, et que ce sont les réglages faits à l'avance par le client qui sauvent les données.

Pour le contexte : récemment, AWS, après des frappes contre son infrastructure à Bahreïn et aux Émirats arabes unis, a reconnu qu'une partie des données et des ressources sur les sites touchés ne pourrait pas être restaurée. Les risques physiques sont donc bien réels pour les grands clouds, ce n'est pas de l'exotisme.

Ce qui change dans le produit

Yandex fait un pas simple et judicieux : lors de la création de nouvelles machines virtuelles, les sauvegardes seront désormais activées par défaut. Auparavant, il fallait les activer manuellement, et beaucoup ne le faisaient pas.

Il reste possible de les refuser, les conditions du service n'ont pas changé. C'est un procédé classique de conception de produit : l'option sûre devient l'option par défaut, tandis que la décision consciente de prendre un risque reste à l'utilisateur. La plupart des gens ne modifient pas les paramètres par défaut, c'est pourquoi la part de machines non protégées dans les nouveaux projets devrait nettement baisser.

Parallèlement, les ingénieurs continuent de répartir les ressources de calcul sur de nouveaux sites indépendants dans différentes régions de Russie. La publication ne donne pas de détails sur le calendrier ni sur le schéma, il est donc trop tôt pour évaluer dans quelle mesure cela changera la tolérance aux pannes.

Que faire pour un développeur ou un fondateur

La leçon est terre à terre, sans grandes conclusions.

• Vérifiez si les sauvegardes sont activées. En particulier sur les machines virtuelles créées avant le changement. Le nouveau réglage par défaut ne s'y applique pas, et la publication ne dit rien des anciennes machines.
• Ne confondez pas la tolérance aux pannes du cloud avec une copie de sauvegarde. Le cloud peut promettre de la disponibilité, mais la destruction physique d'un site montre la différence : sans copie séparée, les données restent sur le même matériel.
• Réfléchissez à l'endroit où se trouve la copie. La publication ne précise pas où sont stockées exactement les sauvegardes des clients, mais la logique est simple : en cas d'incident grave, une copie située près de l'original risque d'être touchée avec lui. Il vaut la peine de lire la documentation du fournisseur et de vérifier si la copie est stockée dans un autre site.
• Testez la restauration. Une sauvegarde à partir de laquelle on n'a jamais essayé de relever un système reste une hypothèse.
• Intégrez cela dans votre produit. Si vous construisez un service au-dessus d'un cloud, le SLA et l'architecture doivent comporter des objectifs explicites : combien de données vous êtes prêt à perdre et à quelle vitesse vous devez être de retour.

Limites

Tous les chiffres proviennent de l'entreprise elle-même et sont relayés dans la publication. Il n'y a pas d'audit indépendant, et l'on ignore quelle part des clients et quels types de données figurent dans les 2,84 %. On ne dispose pas non plus de détails sur les attaques ni sur l'ampleur des dégâts. Il ne faut donc pas en conclure qu'un fournisseur est plus fiable qu'un autre. La comparaison avec AWS dans le post est plus émotionnelle que rigoureuse : les incidents sont différents, et il n'y a pas de données permettant une comparaison directe.

Néanmoins, la conclusion principale n'en est pas affaiblie. Même en cas de lourds dommages physiques, 97,16 % des données ont été restituées, et parmi ceux qui faisaient des sauvegardes, il n'y a eu aucune perte. Une copie de sauvegarde coûte peu comparée à la perte de données, et désormais il n'est même plus nécessaire de l'activer manuellement si vous créez de nouvelles machines.