L’incident de GitLab illustre la nécessité de tester les sauvegardes

La start-up GitLab, qui offre un entrepôt de code source, connait d’énormes difficultés depuis hier, et l’effacement accidentel d’un dossier contenant 300 gigaoctets de données.

Le code source hébergé ne serait pas affecté, mais la base de données principale est touchée, et de nombreux clients n’arrivent même pas à se connecter.

L’incident a été l’occasion pour la start-up de découvrir que parmi les cinq mesures de réplication et de sauvegarde en place, aucune ne fonctionne…

GitLab n’a trouvé qu’un seul instantané utilisable, terminé six heures avant l’incident: six heures de modifications et d’ajouts sont donc définitivement perdus. C’est cet instantané qu’elle est toujours en train de récupérer.

Cet échec cuisant illustre encore une fois l’importance des procédures de sauvegarde et de récupération, et la nécessité de tester régulièrement la récupération. Malheureusement, ces procédures font rarement l’objet de l’attention et du financement nécessaire, parce qu’elles sont fastidieuses, lentes, et nécessitent des moyens non négligeables pour être testées.

La leçon pour le client final de tels services dans le nuage est également qu’il ne peut pas se reposer sur un service pour assurer l’intégrité de ses données, et que des procédures de sauvegarde et de récupération locales sont avantageuses.

Pour GitLab, fondée en 2014 et ayant levé 20 millions de financement, la situation est d’autant plus déshonorante qu’elle s’était vantée d’être au delà du nuage informatique, et qu’elle avait préféré fabriquer et opérer ses propres serveurs. Un choix stratégique remis en cause aujourd’hui.