Le 31 janvier dernier aux environs de 18 h GMT, un administrateur chez GitLab a accidentellement supprimé plus de 300 Go de données de production. À la suite de cette erreur humaine, le site fut indisponible depuis cet incident jusqu’au lendemain aux environs de 18 h GMT.
Généralement, les entreprises qui stockent des données sensibles assurent leur résilience en faisant des sauvegardes régulières de leurs données et cela dans différents endroits. Par ailleurs, elles s’efforcent de suivre des codes de bonnes pratiques en testant de manière régulière l’intégrité de leurs sauvegardes afin de ne pas avoir de mauvaises surprises en cas de soucis. Toutefois, l’incident qui a frappé la plateforme GitLab a démontré que l’entreprise ne s’était pas préparée à tout cela. Toutes les tentatives de restauration de la base de données supprimée à partir des sauvegardes ont échoué.
Fort heureusement, les données supprimées ne concernaient que celles des utilisateurs, des commentaires, des snippets, des bogues, des demandes d’intégration de changements, etc. Les dépôts Git et Wiki des développeurs ainsi que les installations hébergées par l’entreprise n’ont pas été affectés par cet accident. Par ailleurs, GitLab souligne que seul 1 % des utilisateurs (707 en tout) sont concernés par ces données supprimées.
En fin de compte, GitLab a pu récupérer un instantané des données disponibles sur un serveur de tests afin de restaurer les données supprimées et est de retour sur la toile. Toutefois, GitLab explique que ces données restaurées proviennent d’une sauvegarde vieille de 6 heures. Ce qui signifie que toutes les données de projets, de problèmes, de demandes de fusion d’utilisateurs, de commentaires, de snippets comprises entre 17 h 20 et 23 h 25 GMT du 31 janvier sont perdues.
Consciente que la perte de données de production sans possibilité de les restaurer en totalité est inacceptable, GitLab entend publier dans les jours à venir les causes de l’occurrence d’un tel accident et la liste des mesures qu’elle a implémentées pour éviter que pareilles erreurs ne surviennent à nouveau.
Source : GitLab
Et vous ?
Quelles leçons tirez-vous de l’accident qui a frappé GitLab ;?
Quels conseils pouvez-vous donner afin de permettre aux autres entreprises de mieux gérer de tels incidents ;?
Voir aussi
Un administrateur système de GitLab supprime accidentellement 310 Go de données de production et rend le site indisponible depuis plusieurs heures
GitHub : des utilisateurs de la plateforme se disent « frustrés » et « complètement ignorés » sur une pétition signée par des centaines d'entre eux
Forum Actualités, Wiki Developpez.com, Débats Best of, FAQ Developpez.com
GitLab parvient à restaurer certaines données supprimées accidentellement et se remet en ligne
Mais 6 heures de données n'ont pas pu être récupérées
GitLab parvient à restaurer certaines données supprimées accidentellement et se remet en ligne
Mais 6 heures de données n'ont pas pu être récupérées
Le , par Olivier Famien
Une erreur dans cette actualité ? Signalez-nous-la !