Contexte
Afin de prévenir d'une perte de données après un crash d'un ou de plusieurs de vos serveurs utilisés dans votre architecture Shinken, nous vous conseillons d'utiliser les commandes shinken-backup et shinken-restore.
Ces deux commandes vous permettront de sauvegarder ou de restaurer tout ou une partie d'un serveur de votre architecture Shinken.
Commande de sauvegarde
Utilisation
La commande de base pour la sauvegarde complète d'un serveur shinken est la suivante :
shinken-backup
Les différentes options possibles :
| Option | Option courte | Description | Démon sur lequel se trouve les données à sauvegarder |
|---|---|---|---|
| --help | -h | Affiche l'aide de la commande | Tous |
| --sla | -s | Sauvegarde les données SLA | Broker |
| --user | -u | Sauvegarde les données des utilisateurs de l'interface de visualisation (portails, listes, favoris, tableaux de bords..) | Broker |
| --configuration | -c | Sauvegarde les données de configuration | Synchronizer |
| --configuration-anonymous | -ca | Sauvegarde les données de configuration anonymisées | Synchronizer |
| --metrology | -m | Sauvegarde les données de métrologie | Broker |
| --log | -l | Sauvegarde les logs | Tous |
| --output-directory [dir] | -od [dir] | Permet de choisir où enregistrer la sauvegarde | |
| --output-name [name] | -on [name] | Permet de choisir le nom de la sauvegarde |
La commande shinken-backup ne peut pas être exécutée dans les dossiers /etc/shinken et /etc/shinken-user
Attention, pensez bien à utiliser cet outil générique sur le bon serveur. Par exemple, sauvegarder les SLA depuis un serveur Poller ne sera pas cohérent. Ou encore, pour sauvegarder la configuration de Shinken, placez vous sur le serveur hébergeant le duo Arbiter/Synchronizer.
Sauvegarde de données de configuration chiffrées
Lorsque la sauvegarde de données de configuration avec des données protégées est effectué, shinken-backup affiche un avertissement si la clé n'a pas été sauvegardée.
La sauvegarde est tout de même effectué mais vous devez effectuer une sauvegarde de la clé en utilisant la commande shinken-protected-fields-keyfile-export avant toute autre opération impliquant un changement de clé.
Le message suivant apparaîtra si vous n'avez pas effectué de sauvegarde de la clé avant la sauvegarde de la configuration :
The protected fields key from this backup looks like it has never been saved
Si la sauvegarde de la clé a été effectuée par la suite, vous pouvez ignorer ce message et restaurer la clé selon la procédure de restauration habituelle.
Sauvegarde d'une configuration anonymisée
Afin de transmettre une configuration au support, il est possible d'anonymiser la configuration lors de la sauvegarde. Le tableau suivant présente les propriétés qui seront remplacées avant d'être écrit dans les fichiers de configuration.
| Type de donnée | Valeur remplacée | Description |
|---|---|---|
| address | clean address | Permet de masquer les adresses des équipements |
| check_command | clean_command | Permet de masquer les commandes : Une fois restaurée, la configuration pourra démarrer sans effectuer de check |
| poller_tag | La valeur est supprimée pour permettre à la configuration de démarrer | |
| reactionner_tag | La valeur est supprimée pour permettre à la configuration de démarrer | |
| realm | La valeur est supprimée pour permettre à la configuration de démarrer | |
| password | clean | Les mots de passe sont effacés |
Toutes les données utilisateur, chiffrées ou non, présentes dans le système de champs protégé sont également remplacée par la valeur "clean". Pour connaître la liste des champs protégés, utilisez la commande shinken-protected-fields-data-manage.
Le nom de la sauvegarde généré sera succédé de "--anonymous" afin de le distinguer des sauvegardes par défaut.
exemple de nom de sauvegarde anonyme : 2018-12-20__09-52-58--anonymous
Les données ne sont ni effacées ni modifiées sur le serveur sur lequel le shinken-backup est effectué. Elles sont simplement remplacées avant d'être écrites dans les fichiers de sauvegardes.
La sauvegarde réalisée n'est pas chiffrée, car toutes les données présentant un risque ont été remplacées.
Exemples
Voici un exemple de sauvegarde complet d'un serveur hébergeant l'ensemble des démons :
root@vm-shinken: ~ $ shinken-backup Saving Sla Sla save size: 360M Saving User User save size: 72K Saving Configuration Configuration save size: 8.0M Saving Metrology Metrology save size: 3.9M Saving Logs Logs save size: 2.8M Done : your backup directory is /root/shinken-backups/2017-11-13__17-50-33
Exemple de la sauvegarde de la configuration sur un serveur hébergeant le démon Synchronizer :
root@vm-shinken: ~ $ shinken-backup --configuration Saving Configuration Configuration save size: 3.1M Done : your backup directory is /root/shinken-backups/2017-11-10__17-46-11
Commande de restauration
Utilisation
shinken-restore DIRECTORY-TO-RESTORE
Le dossier "DIRECTORY-TO-RESTORE" doit contenir les dossiers de sauvegardes comme :
- configuration/
- metrology/
- user/
- sla/
- context/
Les différences options possibles :
| Option | Option court | Description | Démon sur lequel se trouve les données à restaurer |
|---|---|---|---|
| --help | -h | Affiche l'aide de la commande | Tous |
| --sla | -s | Restaure les données SLA | Broker |
| --user | -u | Restaure les données des utilisateurs de l'interface de visualisation (portails, listes, favoris, tableaux de bords..) | Broker |
| --restore-only-user [USER] | Restaure les données de l'interface de visualisation (portails, listes, favoris, tableaux de bords..) pour l'utilisateur spécifié - à utiliser avec l'option -u
| Broker | |
| --configuration | -c | Restaure les données de configuration | Synchronizer |
| --with-key-backup [HASH] | Pour une sauvegarde contenant des données protégées, restaure également le hash de la clé de chiffrement spécifiée. Il s'agit du résultat de la commande shinken-protected-fields-keyfile-export. | Synchronizer | |
| --metrology | -m | Restaure les données de métrologie | Broker |
| --log | -l | Restaure les logs | Tous |
Cette option ne demande pas le redémarrage de Shinken Restauration d'une base de données de configuration dont les données sensibles sont chiffrées
Si une clé est déjà présente sur le serveur et qu'elle est identique à celle de la sauvegarde, shinken-restore restaurera cette sauvegarde en utilisant la clé.
Si la clé n'a pas été exportée, shinken-restore affichera un avertissement vous signalant qu'elle est automatiquement exportée dans un fichier temporaire, en vous enjoignant de le déplacer en lieu sûr.
Si les deux clés sont différentes vous devez spécifier l'option --with-key-backup suivi du l'export de la clé, qui vous permet de faire la restauration et de placer automatiquement la clef fournie.
En suivant, vous devrez redémarrer le Synchronizer.
- Le Synchronizer refusera de démarrer tant que la clé n'est pas restaurée.
Si vous avez égaré votre clé, nous vous conseillons de lire la page de la documentation "shinken-protected-fields-keyfile-rescue-from-backup". Cette commande vous permettre de restaurer votre clé via l'intermédiaire du support Shinken.
Exemples
Voici un exemple de restauration d'une sauvegarde complète de Shinken depuis le dossier ~/shinken-backups :
root@vm-shinken: ~/shinken-backups $ shinken-restore 2017-11-09__16-16-53 Stopping Shinken before restoring Restoring from 02.04.01.fr to 02.04.02.fr -Restoring Sla DONE -Restoring User DONE -Restoring Configuration DONE -Restoring Metrology DONE -Restoring Logs DONE Sanatizing your restored data fix_double_link : skip (unecessary) fix_double_sync_keys : skip (unecessary) fix_default_item_se_uuid : skip (unecessary) fix_remove_shinken_core : skip (unecessary) fix_remove_deprecated_check : skip (unecessary) fix_remove_undefined_aix_templates : skip (unecessary) fix_flapping_thresholds : skip (unecessary) fix_business_impact : skip (unecessary) Done. You can restart your shinken with /etc/init.d/shinken start
Après la restauration des données, des scripts de "Sanatize" sont lancés. Ces scripts permettent, si nécessaire, de réparer certaines incohérences dans vos données.
Une fois la restauration terminée, vous devez démarrer Shinken:
/etc/init.d/shinken start
Voici un autre exemple de restauration d'une sauvegarde de la configuration de Shinken, lancé depuis le serveur hébergeant l'Arbiter/Synchronizer :
root@vm-shinken: ~/shinken-backups $ shinken-restore --configuration 2017-11-08__10-58-54 Stopping Shinken before restoring Restoring from 02.04.01-release to 02.04.02-release -Restoring Configuration DONE Sanatizing your restored data fix_double_link : executed [OK] fix_double_sync_keys : skip (unecessary) fix_default_item_se_uuid : skip (unecessary) fix_remove_shinken_core : skip (unecessary) fix_remove_deprecated_check : skip (unecessary) fix_remove_undefined_aix_templates : skip (unecessary) fix_flapping_thresholds : skip (unecessary) fix_business_impact : skip (unecessary) Done. You can restart your shinken with /etc/init.d/shinken start
Voici un dernier exemple de restauration d'une sauvegarde des données de l'utilisateur "monutilisateur" de Shinken (portails, listes, favoris, tableaux de bords), lancé depuis le serveur hébergeant le Broker :
root@vm-shinken: ~/shinken-backups $ shinken-restore -u --restore-only-user monutilisateur 2017-12-13__11-44-49/ Restoring from 02.04.01-release to 02.04.03-release -Restoring User Restoring only the user monutilisateur Restore of the user monutilisateur data is OK