L’incident Gitlab et la bonne pratique d’utiliser un vérificateur de sauvegarde

La lecture du rapport de l’incident de base de données Gitlab me semble un cas d’école intéressant pour rappeler à la communauté l’importance de la vérification régulière des sauvegardes.

gitlab

Rappelons tout d’abord les faits : le 31 janvier 2017 la société Gitlab subit une perte des données de ses utilisateurs due (entre autre) à une erreur humaine du fameux team-member-1 (qui travaille toujours chez Gitlab, information confirmée car de nombreuses personnes s’étaient inquiétées de son avenir professionnelle), erreur à associer à l’incapacité de restaurer une sauvegarde récente.

Kudos à Gitlab pour – comme d’habitude avec cette entreprise – une communication exemplaire et transparente pendant et après l’incident. Tous les détails dans le post-mortem de l’incident.

En tant qu’auteur de l’outil de vérification automatisée de sauvegarde Backup Checker, j’ai lu les différentes communications autour de cet incident avec le plus grand intérêt. Loin de moi l’idée de me réjouir d’un perte de données. C’est surtout que Gitlab était à cette occasion fort rare (je n’en connais pas d’autre en fait) la première entreprise de taille et de renommée importante à reconnaître publiquement une perte de données de ses utilisateurs liée à un défaut de sauvegarde.

Les sauvegardes, tout le monde s’en fout avant l’incident, tout le monde en veut après

Après quelques années de mise en place d’architecture systèmes chez des clients différents (startups, PME, institutions, banques, grands comptes privés, …), j’ai pu arriver à la conclusion suivante : les sauvegardes ne sont une chose sérieuse que pour les hébergeurs et les équipes chargées de sauvegardes de (très) grands groupes. Pour les autres, c’est du temps de perdu. Au pire ils n’en font pas – je l’ai constaté à peu près dans toutes les types d’entreprises citées précédemment – et au mieux, ils les ont un jour mis en place et depuis…

Pourtant en réunion, à peu près tout le monde est d’accord pour dire que les sauvegardes sont primordiales. Mais lorsque vient le moment de les mettre en place, pas ou peu de moyens sont mobilisés pour arriver à une chaîne complète de :

  1. réalisation automatique de la sauvegarde
  2. supervision de la bonne exécution de la sauvegarde
  3. test de la sauvegarde

Je vois ici les administrateurs système chevronnés rigoler. En effet, nous sommes tous sous l’eau, à travailler en parallèle sur de trop nombreux projets. Il est donc illusoire de croire que l’on va pouvoir bloquer plusieurs heures régulièrement pour un sujet aussi peu sexy (en terme de revenu pour l’entreprise) que la vérification des sauvegardes.

Et même si du temps était dégagé pour cette tâche, il est important de comprendre pourquoi cette vérification n’est jamais faite : c’est qu’elle est humainement chiante à mourir ! Aucun intérêt intellectuel, aucun côté plaisant pour l’administrateur qui doit la réaliser. Pour ces raisons 99,99999% du temps, aucune vérification n’est faite.

Vérifier automatiquement vos sauvegardes avec Backup Checker

C’est dans le but de résoudre ce problème et de faciliter la vie des administrateurs système que j’ai écrit Backup Checker, un outil de vérification automatisée de sauvegarde.

Cet outil gère de nombreux formats d’archives (tar.{gz,bz2,xz}, zip, archives de fichiers) et propose d’utiliser de nombreux types de contrôles sur l’archive elle-même (taille de l’archive, droits, somme de hachage, …) ou son contenu (taille, droits, propriétaire, somme de hachage, …). Un coup d’oeil à la documentation officielle du projet vous permettra de trouver le type de contrôle qui correspond à votre besoin.

Un exemple complet d’une configuration possible de Backup Checker

Écrire la configuration d’un outil de sauvegarde consiste à décrire quel devrait être l’état de la sauvegarde au moment du contrôle. Cet état s’incarne dans un fichier de configuration lu par votre outil de vérification de sauvegarde.

Maintenant, 2 minutes de votre temps pour un exemple concret. Nous allons vérifier une archive contenant le dump d’une base de données SQL.

Nous commençons par générer automatiquement la liste complète des caractéristiques de notre archive avec la commande suivante :

$ backupchecker -G database-dump.tar.gz
$ cat database-dump.list
[archive]
mtime| 1486480274.2923253

[files]
database.sql| =7854803 uid|1000 gid|1000 owner|chaica group|chaica mode|644 type|f mtime|1486480253.0

Nous supprimons maintenant les paramètres trop précis (par exemple la taille précise, car demain votre dump sera sûrement plus gros) pour réaliser un template de contrôle réutilisable. Nous arrivons au résultat suivant :

[files]
database.sql| >6m uid|1000 gid|1000 mode|644 type|f

Le contenu de ce fichier signifie que notre outil de contrôle de sauvegarde s’attend à trouver dans notre archive un fichier nommé database.sql dont la taille est supérieure à 6 méga-octets, dont l’uid est de 1000, le gid de 1000, les permissions en 644.

C’est simple non ? Maintenant, pour le fun, répliquons l’incident de Gitlab et générons une archive contenant un dump vide qui rendra donc votre sauvegarde strictement inutile.

$ touch /tmp/database.sql && \
tar zcvf /tmp/database-dump.tar.gz /tmp/database.sql && \
cp /tmp/database-dump.tar.gz .

Maintenant relancons Backup Checker en mode contrôle avec le template de contrôle précédemment créé.

$ backupchecker -C database-dump.conf
$ cat a.out 
WARNING:root:1 file smaller than expected while checking /tmp/article-backup-checker/database-dump.tar.gz: 
WARNING:root:database.sql size is 0. Should have been bigger than 6291456.

Boum, le résultat ne se fait pas attendre et Backup Checker indique immédiatement que le fichier database.sql contenu dans votre archive est vide, alors que sa taille devrait être supérieure à 6 méga-octets.

Pour aller plus loin

Nous avons donc vu que le contrôle des sauvegardes ne devrait pas représenter un problème car une solution de contrôles automatisés existe et est simple à mettre en place, à travers un fichier de configuration simple à comprendre et à manipuler.

À travers un exemple très simple mais ô combien utile dans cet article, nous avons abordé la puissance de Backup Checker et les très nombreux contrôles à votre disposition. La documentation officielle vous fournira tous les détails sur comment les mettre en place.

Les pertes de données sont des événements terribles dans la vie des entreprises quand elles impactent des données des clients. Essayons d’apprendre de nos erreurs, erreurs qui peuvent arriver à chacun de nous, et de construire des systèmes de sauvegarde plus robustes et donc plus fiables.

Plus d’informations au sujet de Backup Checker

Soutenir le projet Backup Checker

Si vous souhaitez soutenir la vérification des sauvegardes et le projet Backup Checker, vous pouvez effectuer un don récurrent pour l’auteur de Backup Checker Carl Chenet auprès de Liberapay. Tous les dons même les plus minimes seront un facteur de motivation important 🙂

3 thoughts on “L’incident Gitlab et la bonne pratique d’utiliser un vérificateur de sauvegarde

  1. Bonjour,
    corrigez-moi si je me trompe mais checker une sauvegarde
    peut aussi etre réalisé en faisant un hash check non ?

    Ex: je genère ma sauvegarde et note le hash (au choix)
    je vérifie tous les x temps que mon hash correspond et donc l’intégrité de ma sauvegarde.

    PK

    • Oui tu peux avoir un premier niveau de vérification d’intégrité de ce type. Mais bonne chance pour trouver ce qui a changé si le hash n’est pas le même, en particulier dans une archive complexe avec de nombreux fichiers.

      Backup Checker part de l’idée qu’une sauvegarde conforme l’est si elle remplit une liste de critère prédéfinis, comme dans l’exemple ci-dessus avec la taille du dump.

      Mais tu peux bien sûr décrire de très nombreux types de contrôles et générer l’intégralité des contrôles automatiquement.

      Ce qui fait que dans ton type d’utilisation, Backup Checker sera immédiatement capable de te dire ce qui a changé et ce qui n’est pas conforme dans ta sauvegarde, contrairement à avoir simplement un hash non-attendu.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *