SonarQube Service Stratégie Backup

De EjnTricks
Révision de 21 décembre 2020 à 18:20 par Etienne (discussion | contributions)

(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)

Suite à l'installation de la version 4.4 en service, la stratégie de sauvegarde mise en place pour Sonar a été adaptée pour réaliser:

  • 1 sauvegarde quotidienne de la base de données.
  • Export des sauvegardes vers un serveur "externe" via FTP.
  • Conservation des trois dernières sauvegardes complètes, et des incrémentales.

La synchronisation des sauvegardes s'effectue à l'aide de l'outil de backup Duplicity. Le fait d'externaliser les sauvegardes apporte une garantie supplémentaire. En effet, si le serveur venait à être en panne, les sauvegardes de SonarQube resteront disponibles.

La base de données MySQL est sauvegardée à l'aide de l'outil AutoMySQLBackup.

La base de données PostgreSql est sauvegardée selon le principe mis en place pour PostgreSql.

Pour cela, un compte de sauvegarde est utilisé pour accéder à la base de données en lecture seule.


Hand-icon.png Votre avis

Nobody voted on this yet

 You need to enable JavaScript to vote


Viewer icon.png Objectif

L'installation faite sous Ubuntu met en place différents répertoires / fichiers:

  • Répertoire /var/opt/sonarqube: Contient les binaires et les extensions.
  • Fichier /etc/apache2/httpd.conf: Contient la déclaration de la publication sous Apache.

Sous Ubuntu, il existe le répertoire /var/backups, utilisé par aptitude, dpkg, OpenLDAP ... Cependant, il ne sera pas utilisé dans le cadre de cet article, pour ne pas engendrer d'éventuels effets de bord. Tous les scripts et données seront stockés dans un nouveau répertoire /var/opt/backups (pour l'ensemble des stratégies) et plus particulièrement dans le répertoire /var/opt/backups/sonar pour Sonar. Concernant les logs, elles seront toutes placées dans le répertoire /var/log/backups.

#sudo mkdir -p /var/opt/backups/sonar
#sudo chmod 750 /var/opt/backups/sonar
#sudo chown root:backup /var/opt/backups/sonar
#sudo mkdir /var/log/backups


Icon-database-process.png Sauvegardes

Logo Mysql.png Sauvegarde MySQL

PostgreSql.png Sauvegarde PostgreSQL

Command-icon.png Scripts export sauvegardes

Le script sonar_backup.sh est mis en place, avec des sécurités autorisant uniquement le compte root à le modifier, dans le répertoire /var/opt/backups/sonar avec le code suivant:

#!/bin/bash
dateLogFormat="+%Y-%m-%d %H:%M";
# Backup log
pathLog="/var/log/backups/sonar_backup.log";

echo "[$(date "$dateLogFormat")] Start backup" >> $pathLog;
echo "[$(date "$dateLogFormat")] Start upload with duplicity" >> $pathLog;

export PASSPHRASE=DUPLICITY PASSPHRASE
export FTP_PASSWORD=USER_PASSWORD

duplicity remove-all-but-n-full 3 --force ftp://FTP_LOGIN@HOST/backup/sonar >> $pathLog;
duplicity --include '/var/opt/sonarqube' --include '/var/opt/backups/sonar/db' 
--include '/etc/apache2/httpd.conf' --exclude '**' --full-if-older-than 7D / ftp://FTP_LOGIN@HOST/backup/sonar >> $pathLog;

unset PASSPHRASE
unset FTP_PASSWORD

echo "[$(date "$dateLogFormat")] End upload with duplicity" >> $pathLog;
echo "[$(date "$dateLogFormat")] End backup" >> $pathLog;

Attention à l'utilisation de l'instruction export, surtout pour la PASSPHRASE. En effet, si celle-ci contient des espaces, il est impératif de la placer entre le caractère ".

Il n'est pas nécessaire de positionne le droit d'exécution sur ce fichier.

#sudo chmod 660 /var/opt/backups/sonar/sonar_backup.sh
#sudo chown root:backup /var/opt/backups/sonar/sonar_backup.sh

Le fonctionnement de ce script est assez simple. Puis deux variables d'environnement sont mises en place:

  • PASSPHRASE: Phrase pour le cryptage des données par duplicity.
  • FTP_PASSWORD: Le mot de passe FTP utilisé pour se connecté via duplicity.

La première instruction, avec l'argument remove-all-but-n-full 3, va conserver les trois dernières sauvegardes complètes. Puis la seconde instruction, avec l'argument --full-if-older-than 7D effectue une sauvegarde incrémentale uniquement si la précédente complète est plus ancienne de sept jours.

Le résultat de l'export est ensuite envoyé sur un serveur FTP, configuré par la value HOST, en utilisant le login FTP_LOGIN et le mot de passe USER_PASSWORD placé dans la variable FTP_PASSWORD. Les sauvegardes sont stockées à l'emplacement backup/sonar à la racine du compte après connexion sur FTP.

Enfin, les exécutions sont tracées dans la log /var/log/backups/sonar_backup.log.

Les messages d'exécution de AutoMySQLBackup sont redirigés vers la log /var/log/backups/sonar_backup_db.log.

Scheduled-Tasks-icon.png Planification

Une fois que le script de sauvegarde est mis en place, il est possible de l'exécuter manuellement. Mais l'objectif est de l'exécuter automatiquement et régulièrement sans s'en préoccuper. Dans le cadre de cette implémentation, la planification est réalisée à l'aide de l'outil Crontab disponible sur les systèmes Linux. L'outil Anacron n'a pas été utilisé car les planifications souhaitées doivent se faire à des heures et des jours particuliers.

La mise en place s'effectue en modifiant le fichier /etc/crontab pour y ajouter une ligne.

Dans le cas de MySQL, le script /var/opt/backups/sonar/sonar_automysqlbackup.sh est planifié.

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
40 5    * * *   root    cd / && /var/opt/backups/sonar/sonar_automysqlbackup.sh
#

Dans le cas de PostgreSQL, le script /var/opt/backups/sonar/sonar_autopostgresqlbackup.sh est planifié.

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# m h dom mon dow user  command
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
40 5    * * *   root    cd / && /var/opt/backups/sonar/sonar_autopostgresqlbackup.sh
#

Les sauvegardes sont planifiées à 5h40 AM, tous les jours de la semaine, par l'exécution de la commande cd / && /var/opt/backups/sonar/sonar_automysqlbackup.sh.


Icon-log.png Gestions des logs

Des fichiers de log sont créés par le script mis en place. Comme pour l'ensemble des produits, une rotation de ces logs est mise en place, à l'aide de l'outil Logrotate. L'ensemble des logs se trouvent donc dans le répertoire /var/log/backups avec les noms sonar_backup_db.log et sonar_backup.log. La configuration permet une rotation hebdomadaire, en conservant 3 rotations. Les rotations sont compressées, en asynchrone, et créées avec un accès en modification au compte root.

Cette configuration est mise en place dans le fichier sonar_backup, sous le répertoire /etc/logrotate.d

/var/log/backups/sonar*.log {
        weekly
        missingok
        rotate 3
        compress
        delaycompress
        notifempty
        create 640 root root
}