@@ -24,7 +24,7 @@ Le fichier dans [`config/backup_config.json`](./config/backup_config.json) recen
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ée 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.
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.
### Structure
...
...
@@ -101,3 +101,27 @@ 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"](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).