README.md 5.07 KB
Newer Older
1
# Backup des bases de données des services
2

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

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

7
Il est flexible et se configure via un fichier JSON.
8
9
10

## Configuration

11
Le fichier dans [`config/backup_config.json`](./config/backup_config.json) recensent les informations sur les différentes bases de données qui doivent être backupées.
12

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

16
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.
17

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

20
### Structure
21

22
 - Nom du service : Contient une structure de données contenant les informations relatives au service telles qu'indiquées ci-dessous
23
24
25
26
27
28
29
30
 - `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
31

Quentin Duchemin's avatar
Quentin Duchemin committed
32
33
### Gestion des secrets

34
Afin de pouvoir versionner le fichier de configuration sans exposer les identifiants aux bases de données, on utilise le système suivant :
Quentin Duchemin's avatar
Quentin Duchemin committed
35
36
37
38
39
* 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.

40
### Exemple
41

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

44
```json
45
{
46
  "mattermost":
47
    {
48
49
50
51
52
53
54
      "Host": "mattermost-db",
      "Port": "5432",
      "User": "MATTERMOST_DB_USER",
      "Password": "MATTERMOST_DB_PASSWORD",
      "Database": "mattermost",
      "Type": "postgres",
      "Folder": "mattermost",
55
      "Cron" : "0 * * * *",
56
      "Init-Backup" : "1",
57
58
59
60
61
    },
  "etherpad":
    {
      "Host": "etherpad-db",
      "Port": "3306",
Quentin Duchemin's avatar
Quentin Duchemin committed
62
63
      "User": "ETHERPAD_DB_USER",
      "Password": "ETHERPAD_DB_PASSWORD",
64
65
66
      "Database": "--all-databases",
      "Type": "mysql",
      "Folder": "etherpad",
67
      "Cron" : "0 */6 * * *",
68
      "Options" : "--single-transaction",
69
70
71
72
73
74
75
76
77
78
79
      "Init-Backup" : "1",
    },
    "wekan":
    {
      "Host": "wekan-db",
      "Port": "27017",
      "Database": "wekan",
      "Type": "mongo",
      "Folder": "wekan",
      "Cron" : "0 */12 * * *",
      "Init-Backup" : "1",
80
81
    }
}
82

83
```
84
85
86

## Lancement

87
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]((#gestion-des-secrets))).
88

89
On lance ensuite le Docker Compose :
90
91
92
93

```
$ docker-compose up -d
```
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116

## 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"](https://www.postgresql.org/docs/current/app-pgdump.html) 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).
117
* Avoir un dump dans un format plus souple, qui permet de sélectionner manuellement et réorganiser les items archivés pendant la restauration