technique:old:adminsys:backup:db:check

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
technique:old:adminsys:backup:db:check [2022/09/24 10:42] – supprimée - modification externe (Unknown date) 127.0.0.1technique:old:adminsys:backup:db:check [2022/09/24 10:42] (Version actuelle) – ↷ Page déplacée de technique:adminsys:backup:db:check à technique:old:adminsys:backup:db:check rdelaage
Ligne 1: Ligne 1:
 +{{indexmenu_n>40}}
 +# Vérification du fonctionnement
 +
 +Afin de s'assurer du bon fonctionnement du conteneur de sauvegarde, plusieurs vérifications peuvent être faites.
 +
 +Regarder le nom des sauvegardes dans le dossier de sauvegarde de la machine hôte (`/DATA/BACKUP/<service>`) avec la commande `ls -lrh`. Ci-dessous, nous pouvons voir que les sauvegardes se font toutes les 6 heures :<code>
 +
 +-rw-r--r-- 1 root root 172M janv.  5 12:00 2018.01.05.120001.sql
 +-rw-r--r-- 1 root root 172M janv.  5 06:00 2018.01.05.060001.sql
 +-rw-r--r-- 1 root root 172M janv.  5 00:00 2018.01.05.000001.sql
 +-rw-r--r-- 1 root root 172M janv.  4 18:00 2018.01.04.180001.sql
 +-rw-r--r-- 1 root root 172M janv.  4 12:00 2018.01.04.120001.sql
 +-rw-r--r-- 1 root root 172M janv.  4 06:00 2018.01.04.060001.sql
 +-rw-r--r-- 1 root root 172M janv.  4 00:00 2018.01.04.000001.sql
 +-rw-r--r-- 1 root root 172M janv.  3 18:00 2018.01.03.180001.sql
 +-rw-r--r-- 1 root root 172M janv.  3 12:00 2018.01.03.120001.sql
 +-rw-r--r-- 1 root root 172M janv.  3 06:00 2018.01.03.060001.sql
 +-rw-r--r-- 1 root root 172M janv.  3 00:00 2018.01.03.000001.sql
 +-rw-r--r-- 1 root root 172M janv.  2 18:00 2018.01.02.180001.sql
 +-rw-r--r-- 1 root root 171M janv.  2 12:00 2018.01.02.120001.sql
 +-rw-r--r-- 1 root root 171M janv.  2 06:00 2018.01.02.060001.sql
 +-rw-r--r-- 1 root root 171M janv.  2 00:00 2018.01.02.000001.sql
 +-rw-r--r-- 1 root root 171M janv.  1 18:00 2018.01.01.180001.sql
 +-rw-r--r-- 1 root root 171M janv.  1 12:00 2018.01.01.120001.sql
 +-rw-r--r-- 1 root root 171M janv.  1 06:00 2018.01.01.060001.sql
 +</code>
 +
 +<bootnote>L'augmentation de la taille des sauvegardes au cours du temps peut-être aussi un bon indicateur.</bootnote>
 +
 +Au redémarrage du conteneur, les services pour lesquels l'option d'initialisation des backups est à 1 produisent une sauvegarde, ce qui indique que les paramètres fournis permettent l'accès à la base de données. Pour compléter cette information, la commande `docker logs db-backup` permettra de vérifier le bon déroulement des sauvegardes :<code>
 +pica-backup             | => mattermost: Backup started: 2018.01.05.110001.sql
 +pica-backup             | mattermost:  Backup succeeded
 +pica-backup             | => mattermost: Backup started: 2018.01.05.120001.sql
 +pica-backup             | mattermost:  Backup succeeded
 +pica-backup             | => etherpad: Backup started: 2018.01.05.120001.sql
 +pica-backup             | etherpad: Backup succeeded
 +pica-backup             | => mattermost: Backup started: 2018.01.05.130001.sql
 +pica-backup             | mattermost:  Backup succeeded
 +pica-backup             | => mattermost: Backup started: 2018.01.05.140001.sql
 +pica-backup             | mattermost:  Backup succeeded
 +</code>
 +
 +<bootnote warning>Le même fichier de configuration est utilisé sur toutes les machines, pour des raisons de simplification. Ainsi, sur les machines où ne tourne **pas** Mattermost, le script produira cette erreur une seule fois :
 +
 +```
 +ping: mattermost-db: Name or service not known
 +
 +=========== mattermost-db not available, skipping backup... ===========
 +```
 +
 +Par la suite, le script de backup ne sera pas ajouté au cron.
 +</bootnote>
 +