Le jour où mes sauvegardes ont failli saturer un serveur de production

Un serveur "down" comme on dit dans le jargon, c'est-à-dire un serveur qui ne fonctionne plus, n'est pas quelque chose qui est évident à voir au premier abord pour un développeur. Lorsqu'on travaille sur des applications, on est souvent sur une version de test de l'application et on ne va que rarement sur la version en ligne pour vérifier si elle est toujours accessible.

Laisser un serveur dans cet état est cependant bien évidemment inacceptable. Et il existe évidemment des outils qui permettent de détecter les problèmes auxquels on risque de faire face ou qui sont déjà en cours. Gérer un serveur demande donc de surveiller plusieurs données pour assurer que tout fonctionne correctement et de recevoir des alertes quand nécessaire.

L'espace occupé et l'espace disponible

L'espace disponible sur un serveur est l'un des éléments les plus importants. Si l'espace manque à un moment, le comportement de toutes les applications déployées sur ce serveur devient imprévisible.

Heureusement, il s'agit d'une donnée relativement stable pour la majorité des applications. À l'inverse d'un ordinateur, on a rarement besoin de télécharger de nouveaux fichiers lorsque l'on gère des sites Internet. Mais, à l'inverse d'autres données, il s'agit d'une donnée qui a tendance à ne pas s'équilibrer avec le temps sans une action manuelle.

En effet, plusieurs types de données viennent régulièrement se cumuler et peuvent s'accumuler jusqu'à prendre tout l'espace accessible d'un serveur si l'on n'y fait pas attention :

Les données de bases de données

Ces données évoluent souvent doucement. Une ligne dans une base de données ne représente que rarement plus de quelques ko. Même si l'on avait 1000 nouvelles entrées par jour, cela représenterait quelques Mo à peine (1000 x 1 ko = 1 Mo), ce qui est relativement négligeable sachant que les serveurs, comme les ordinateurs, ont souvent des espaces de plusieurs centaines de Go par défaut.

Pour remplir un serveur de 100 Go, en ayant 1000 nouveaux clients par jour et avec un espace nécessaire de 1 ko par client (ce qui serait énorme), il faudrait encore 273 ans pour arriver à saturer le serveur.

Les fichiers

Toutes les applications et tous les sites Internet utilisent des fichiers : des images, des vidéos, etc. Et une grande majorité d'entre eux sont conçus pour permettre d'ajouter des fichiers au fur et à mesure (une nouvelle image à ajouter pour ajouter une page sur un site Internet par exemple).

Le remplissage d'un serveur pourrait être relativement rapide si l'on chargeait de la sorte de grandes quantités d'images et de fichiers. Une image pèse souvent quelques centaines de ko et une vidéo peut peser beaucoup plus lourd, plusieurs dizaines de Mo.

Heureusement, il y a ici aussi souvent de la marge. Sachant qu'une minute de vidéo en qualité HD (1920x1080) pèse environ 15 Mo, il faudrait plus de 100 heures de vidéos en qualité HD pour remplir un serveur de 100 Go.

Les logs

Les développeurs incluent souvent des logs dans les applications, c'est-à-dire des informations qui permettent de retrouver ce qu'il s'est passé, et ces informations doivent évidemment être conservées pour pouvoir analyser ce qu'il s'est passé lorsqu'une erreur arrive.

Un log est cependant une donnée très légère. La majorité pèsent à peine quelques centaines d'octets (+/- 0,1 ko), il en faudrait donc des milliards pour remplir un serveur de 100 Go.

Il est beaucoup plus difficile d'évaluer la vitesse à laquelle un serveur pourrait se remplir avec des logs. Certains logs sont prévisibles (par exemple, si l'on vérifie une fois par seconde que le serveur est en ligne, on aura 86400 logs par jour pour cette information), d'autres dépendent du nombre d'utilisateurs qui vont sur les applications, de ce qu'ils y font et de la quantité de logs que le développeur a intégrée dans l'application.

Les sauvegardes

Garder une copie des données sur le même serveur est une pratique assez courante qui permet de travailler en sécurité sur un serveur lorsqu'un développeur doit effectuer une mise à jour ou une modification des applications.

Elle permet de faire demi-tour le plus rapidement possible si quelque chose s'est mal passé au cours de la manipulation. Il suffira en effet au développeur de copier les données de la sauvegarde dans l'application pour récupérer son état précédent en quelques minutes (et garantir zéro perte de données).

Le risque

Indépendamment, la plupart de ces données ne représentent pas un risque, mais cumulées, et sachant qu'elles ne font qu'augmenter avec le temps, il arrive toujours un moment où elles peuvent prendre trop d'espace.

En cas de saturation, les conséquences peuvent être très importantes. On risque de bloquer les systèmes de récupération des serveurs et de se retrouver avec des applications complètement inaccessibles, et même de perdre des données clients.

Même s'il s'agit d'une donnée assez stable, la surveillance de cette donnée est donc importante puisqu'elle peut faire dysfonctionner les applications et les sécurités mêmes de ces applications.

Analyse d'une courbe

Quand on suit la donnée, on voit bien qu'il s'agit d'une information relativement stable.

Ce qui est intéressant ici, ce sont les petits pics vers le bas. Ce sont les sauvegardes effectuées sur le serveur. À intervalle régulier, une sauvegarde complète est effectuée de toutes les données. On commence par créer une copie compressée des données (un zip) avant de les sauvegarder ; le zip est un nouveau fichier créé qui réduit l'espace disponible dans le disque. Lorsqu'il est envoyé vers le système externe d'enregistrement des sauvegardes, l'espace est libéré.

Ces pics représentent le réel danger pour un serveur. C'est au moment de la création de ces fichiers, qui peuvent peser plusieurs dizaines de Go puisqu'il s'agit souvent d'une copie de bases de données complètes ou de dossiers complets, que l'on risque d'atteindre la limite d'espace disponible sur un serveur.

Ce que l'on voit au début, ce sont les conséquences d'un système de sauvegarde non optimisé pour économiser la consommation de l'espace de stockage. L'espace disponible sur le disque a frôlé le zéro. Bien que j'avais une sécurité pour ne pas effectuer la sauvegarde si l'espace est insuffisant, une tâche automatisée qui aurait besoin d'un peu d'espace disponible aurait pu achever le serveur.

Jusqu'à cette date, je n'avais en effet pas eu besoin d'améliorer le système de sauvegarde car j'avais toujours eu suffisamment de marge pour effectuer une sauvegarde. Maintenant, je n'ai cependant plus suffisamment d'espace disponible sur le serveur pour procéder de la sorte, j'ai donc travaillé sur une solution optimisée pour gérer les sauvegardes en limitant le besoin d'espace disponible.

La solution

Les sauvegardes étaient auparavant effectuées d'un coup sur tout le serveur. Je créais une copie compressée de la totalité des données variables du serveur (toutes les bases de données, tous les fichiers clients, toutes les images etc), je copiais cette copie une deuxième fois, puis j'envoyais la sauvegarde vers un serveur externe d'un coup.

Le problème : j'approchais des 80 Go de données à sauvegarder, ce qui veut dire que je créais un fichier zip d'environ 80 Go et une copie de ce fichier. En plus, je conservais les 7 dernières copies des bases de données sur le serveur directement. J'avais donc besoin de 160 Go disponibles pour effectuer une sauvegarde et j'avais moins d'espace disponible par défaut puisque 20 Go sur le serveur servaient à stocker les bases de données.

Pour y pallier, j'ai modifié le système automatisé de gestion des sauvegardes. Dorénavant, chaque application est sauvegardée une par une. Je crée toujours la copie compressée des fichiers à envoyer au serveur externe et une copie de ce fichier, donc j'ai toujours besoin de 40 Go disponibles pour effectuer la sauvegarde de l'application la plus lourde cumulant 20 Go de données.

Lorsque le fichier est créé, il est maintenant directement envoyé sur le serveur externe puis supprimé sur le serveur local si tout s'est bien déroulé avant de passer au suivant.

Résultat : j'ai besoin de 4 fois moins d'espace disponible sur le serveur et en plus, la sauvegarde a plus de chances de se dérouler sans encombre. En cas de problème sur l'une des applications, je reçois un message d'erreur et la suite des applications est sauvegardée.

On pourrait penser que j'ai pris un risque en supprimant les copies locales des bases de données, mais ce risque est en réalité très limité. D'abord parce qu'elles ont été déplacées et qu'elles seront toujours accessibles rapidement si besoin. Ensuite parce que le système me permet toujours d'effectuer une copie temporaire avant de réaliser une opération sensible pour garantir qu'absolument aucune donnée ne sera perdue pour mes clients.

Conclusion

Comme vous pouvez le voir, le système fonctionne dorénavant correctement. Le serveur a maintenant environ 140 Go d'espace disponible par défaut et les sauvegardes ne consomment que 40 Go. J'ai donc récupéré largement assez d'espace disque pour m'assurer que je n'aurai plus de problème avec les sauvegardes. Et j'ai aussi maintenant la marge nécessaire pour absorber la croissance des données de mes clients.

Ce système que je vous présente est en réalité un outil que je gère et que je mets en place sur les serveurs de mes clients pour leur assurer une infogérance semi-automatisée et une sécurité renforcée sur leurs serveurs. Bien qu'il soit particulièrement optimisé pour gérer plusieurs applications au sein d'un seul serveur, il fonctionne tout aussi bien pour mes clients n'ayant que 2 ou 3 applications. Je peux ainsi me concentrer plus sereinement sur la partie la plus importante : le développement.