Backup des bases de données des services

Cet outil orchestre le backup des différents services de Picasoft.

Il est capable de gérer les bases de données postgres, mysql ou mongo pour le moment.

Il est flexible et se configure via un fichier JSON.

Configuration

Le fichier dans config/backup_config.json recensent les informations sur les différentes bases de données qui doivent être backupées.

Ce fichier est utilisé en production. Il ne doit pas être modifié sur les machines sans être synchronisé avec le dépôt Git.

Ce service est destiné à être lancé sur l'ensemble des machines : de cette manière peu importe que Mattermost tourne sous pica01 ou pica02, elle aura des backups. Si une base de données n'est pas accessible, elle est simplement ignorée, ce qui permet d'utiliser le même fichier de configuration pour l'ensemble des machines.

Attention : si la base de donnée tourne dans un réseau Docker isolé, comme pica-etherpad, il faudra ajouter db-backup à ce réseau dans le docker-compose.yml.

Structure

• Nom du service : Contient une structure de données contenant les informations relatives au service telles qu'indiquées ci-dessous
• Host : Indique l'hôte de la base de données
• Port : Indique le port pour se connecter au service
• Database : Indique le nom de la base de données
• User : Nom d'utilisateur ou nom d'une variable d'environnement (optionnel)
• Password : Mot de passe ou nom d'une variable d'environnement (optionnel)
• Folder : Indique le nom du dossier de backup utilisé par le script de backup et de rotation
• Cron : Indique la fréquence de temps à laquelle les backups sont effectués par le script de rotation au format cron
• Init-Backup : Indique si un backup doit être effectué au démarrage du service, en plus de la programmation du cron

Gestion des secrets

Afin de pouvoir versionner le fichier de configuration sans exposer les identifiants aux bases de données, on utilise le système suivant :

• Dans le JSON, on utilise un nom de variable d'environnement à la place de l'identifant, sans le $, e.g. ETHERPAD_DB_USER.
• Dans le fichier db.secrets, on renseigne la valeur de cette variable d'environnement.

La substitution est effectué automatiquement par l'outil.

Exemple

Cet exemple montre trois possibilités : le backup d'une base MySQL, Postgresql et MongoDB.

{
  "mattermost":
    {
      "Host": "mattermost-db",
      "Port": "5432",
      "User": "MATTERMOST_DB_USER",
      "Password": "MATTERMOST_DB_PASSWORD",
      "Database": "mattermost",
      "Type": "postgres",
      "Folder": "mattermost",
      "Cron" : "0 * * * *",
      "Init-Backup" : "1",
    },
  "etherpad":
    {
      "Host": "etherpad-db",
      "Port": "3306",
      "User": "ETHERPAD_DB_USER",
      "Password": "ETHERPAD_DB_PASSWORD",
      "Database": "--all-databases",
      "Type": "mysql",
      "Folder": "etherpad",
      "Cron" : "0 */6 * * *",
      "Options" : "--single-transaction",
      "Init-Backup" : "1",
    },
    "wekan":
    {
      "Host": "wekan-db",
      "Port": "27017",
      "Database": "wekan",
      "Type": "mongo",
      "Folder": "wekan",
      "Cron" : "0 */12 * * *",
      "Init-Backup" : "1",
    }
}

Lancement

On se synchronise simplement avec le dépôt et on copie secrets/db.secrets.example dans secrets/db.secrets et on renseigne les secrets (voir Gestion des secrets).

On lance ensuite le Docker Compose :

$ docker-compose up -d

Notes diverses

Backup des BDD PostgreSQL

Initialement, postgres-run.sh réalisait un dump de la base de données en plain text avec pg_dump -w -c qui était ensuite compressé par tar. Ceci a été changé par eb54ac21 et 6828cfa5 pour utiliser le format "custom" de pg_dump.

Le temps pour réaliser un backup et sa taille restent quasiment les mêmes:

-rw-r--r-- 1 root root 133694555 avril  2 04:00 2020.04.02.020001.tar.gz
-rw-r--r-- 1 root root 133700591 avril  2 05:00 2020.04.02.030001.tar.gz
-rw-r--r-- 1 root root 133704227 avril  2 06:00 2020.04.02.040001.tar.gz
-rw-r--r-- 1 root root 133002366 avril  2 06:28 2020.04.02.042736.dump
-rw-r--r-- 1 root root 133005154 avril  2 07:00 2020.04.02.050001.dump
-rw-r--r-- 1 root root 133019511 avril  2 08:00 2020.04.02.060001.dump

(Les heures dans les noms des fichiers à droite sont incorrectes, il faut ajouter 2h pour avoir l'heure correcte, les backups sont quasi instantanés)

Cependant, utiliser le format "custom" permet de:

• Ne pas avoir des fichiers temporaires (les fichiers *.sql avant compression) qui prennent beaucoup de place pendant quelques instants. On a ainsi un élément de risque en moins (ces fichiers auraient pu être à l'origine d'un disque plein et donc casser tous les services d'une VM).
• Avoir un dump dans un format plus souple, qui permet de sélectionner manuellement et réorganiser les items archivés pendant la restauration