Concept
Shinken Entreprise V02.06.00 introduit un nouveau Module : synchronizer-module-database-backup permettant d'effectuer une sauvegarde automatique à intervalles réguliers de la base de données du Synchronizer ( voir la page Module synchronizer-module-database-backup ).
Cela permettra, en cas de mauvaise manipulation, de restaurer facilement une ancienne version grâce à la commande shinken-synchronizer-database-restore.
Cette commande ne permet de restaurer que la base de données MongoDB du Synchronizer ! Les fichiers de configuration, les logs, les SLA, les métriques et les données utilisateur ne sont pas sauvegardés par le module et ne sont donc par inclus dans la restauration de cette commande.
Pour une restauration complète, voir la page Shinken-backup et Shinken-restore, les commandes de sauvegarde et de restauration.
Utilisation de la commande
La commande shinken-synchronizer-database-restore permet de restaurer n'importe quelle version sauvegardée.
- Si plusieurs sauvegardes sont disponibles, elle propose la liste des sauvegardes disponibles avec un horodatage, triée de la plus ancienne à la plus récente.
Il est possible de choisir la sauvegarde à restaurer en saisissant son numéro.
- Afin que la restauration puisse être effectuée sans risque de corruption de données, la commande shinken-synchronizer-database-restore demande un accord pour arrêter Shinken durant la procédure de restauration.
- Une fois celle-ci effectuée, la commande demande un accord pour redémarrer Shinken.
- Lorsque de la restauration de la base de données du Synchronizer, il est possible de restaurer une base qui n'est pas compatible avec la version actuellement installée de Shinken ( c'est le cas si l'archive est antérieure à la mise à jour de Shinken ) .
- Pour cette raison, la commande lance des actions automatiques afin d'assurer la compatibilité entre la base de données restaurée et la version actuellement installée de Shinken.
Options de de paramètrage des sauvegardes à charger
| Option | Valeur par défaut | Description |
|---|---|---|
-c
| /etc/shinken/synchronizer.cfg | Chemin du fichier de configuration du Synchronizer. |
-d
| Le dossier spécifié dans le fichier de configuration du module "synchronizer-module-database-backup" ( voir la page Module synchronizer-module-database-backup ) | Chemin du dossier où se trouvent les archives de la base MongoDB du Synchronizer. |
-f
| --- | Nom d'un backup à charger ( sans l'extension ). |
Options de connexion à la base MongoDB
Cette commande récupère les paramètres de connexion à la base MongoDB depuis la configuration.
Il est nécessaire d'utiliser les options de la ligne de commande que si les fichiers de configuration ne correspond pas à la base MongoDB sur la quel la commande doit être exécutée ( migration de base, test sur une préprod ... ).
La commande dispose d'options de connexion à la base MongoDB qui peuvent être utilisés dans les cas suivants : La combinaison des options de connexion à MongoDB peut rapidement devenir complexe ; voici des paramètres adaptés aux cas les plus courants. localhost Nom ou IP du serveur MongoDB. 27017 Port de la base MongoDB. shinken ( ou synchronizer si la commande concerne la base du Synchronizer ) Nom de la base de données à utiliser dans MongoDB. À n'utiliser que si la configuration du module ou du démon a changé la base utilisée par défaut. --- Active la connexion SSH au serveur MongoDB. /var/lib/shinken/.ssh/id_rsa Clé privée SSH pour la connexion au serveur MongoDB. À utiliser en complément de l'option --mongo-use-ssh. shinken Utilisateur à utiliser pour la connexion SSH. À utiliser en complément de l'option --mongo-use-ssh. --- Utilisateur pour l'authentification avec mot de passe. --- Mot de passe de l'utilisateur pour l'authentification avec mot de passe. À utiliser en complément de l'option --mongo-username. Si l'option --mongo-password est utilisée, le mot de passe risque d'être visible dans l'historique des commandes ( via la commande history ). Pour éviter d'exposer le mot de passe, il est possible d'utiliser cette commande uniquement avec l'option --mongo-username. Un prompt interactif apparaîtra alors pour demander le mot de passe. Pour automatiser les commandes dans un script, il est possible de rediriger le contenu d'un fichier contenant le mot de passe ( par exemple : --mongo-password $(cat my_file_with_password) ). --- Active SSL/TLS pour les communications avec la base MongoDB. --- Chemin vers le fichier de l’autorité de certification ( CA ) utilisé pour vérifier le certificat SSL de MongoDB. À utiliser en complément de l'option --mongo-ssl. --- Chemin vers le fichier contenant le certificat SSL du client. À utiliser en complément de l'option --mongo-ssl. --- Mot de passe du certificat SSL du client. À utiliser en complément de l'option --mongo-ssl. --- Chemin vers le fichier CRL ( liste de révocation ) des certificats SSL à rejeter. À utiliser en complément de l'option --mongo-ssl. --- Accepter le certificat SSL de MongoDB même si le nom d’hôte du certificat ne correspond pas à celui du serveur. À utiliser en complément de l'option --mongo-ssl. --- Accepter le certificat SSL de MongoDB même s’il est invalide, par exemple expiré. À utiliser en complément de l'option --mongo-ssl.Options génériques
[root@serveur01 ~] shinken-commande --mongo-host 127.0.0.1 --mongo-port 27017 --mongo-database shinken
Option Valeur par défaut Description Options de connexion SSH
[root@serveur01 ~] shinken-command --mongo-host serveur02 --mongo-port 27017 --mongo-use-ssh --mongo-ssh-key /var/lib/shinken/.ssh/id_rsa --mongo-ssh-user shinken
Option Valeur par défaut Description Options d'authentification
[root@serveur01 ~] shinken-command --mongo-host 127.0.0.1 --mongo-port 27017 --mongo-username shinken --mongo-password shinken
Option Valeur par défaut Description Options SSL/TLS
[root@serveur01 ~] shinken-command --mongo-host serveur02 --mongo-port 27017 --mongo-ssl-ca-file /etc/shinken/certs/mongo/ca.pem --mongo-ssl-pem-key-file /etc/shinken/certs/mongo/client.pem
Option Valeur par défaut Description
Exemple
Si le script est lancé avec l'option -f et que le backup indiqué n'existe pas, le script l'indiquera et proposera les backups disponibles, comme dans l'exemple ci-dessous :
$ shinken-synchronizer-database-restore -f this-backup-does-not-exists
Impossible to load the required backup
Theses backup were found :
[ 0] 2024-09-24_14-58_synchronizer_localhost.tgz
[ 1] 2024-09-24_15-49_synchronizer_localhost.tgz
[ 2] 2024-09-24_15-54_synchronizer_localhost.tgz
Which backup do you want to restore ? [0-2] :