En fonction du type du module de rétention utilisé par votre ( ou vos ) Schedulers, il y a deux méthodes pour sauvegarder et restaurer la rétention :
Lorsque le module PickleRetentionFile est utilisé, la sauvegarde de la rétention se fait dans un fichier situé à la destination suivante : /var/lib/shinken/
Les fichiers de rétention sont nommés en suivant ce format :
retention.dat_--_realm--REALM_NAME_--_scheduler--SCHEDULUER_NAME_--_id--SCHEDULER_ID.retention |
Avec :
| Nom | Exemple | Description |
|---|---|---|
| REALM_NAME | All | Nom du royaume |
| SCHEDULER_NAME | scheduler-master | Nom du Scheduler |
| SCHEDULER_ID | 0 | Id du Scheduler |
Exemple de fichier :
retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention |
Il peut y avoir plusieurs fichiers de rétention dans /var/lib/shinken/ si vous avez plusieurs royaumes et / ou plusieurs Schedulers. Pensez à vérifier que vous les avez tous sauvegardés. |
Pour sauvegarder ces fichiers de rétention, il suffit de les copier à l'endroit souhaité avec la commande cp <source> <destination> :
cp /var/lib/shinken/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /root/retention_save/ |
Cette commande va copier le fichier de rétention retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention dans le dossier /root/retention_save/
|
Pour restaurer un fichier de rétention Pickle, il suffit de le remettre à l'endroit depuis lequel ils ont été copiés : /var/lib/shinken/
cp /root/retention_save/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /var/lib/shinken/ |
Attention, la commande cp écrase la destination ! Avant de restaurer les fichiers Pickle, assurez-vous qu'ils n'y a pas de fichier du même nom dans /var/lib/shinken/, ou assurez-vous de les sauvegarder si besoin. |
Avec le module MongodbRetention, la rétention se trouve dans la base shinken ( par défaut ) dans les collections retention_hosts_raw et retention_services_raw.
Pensez à vérifier que vous n'avez pas changé le nom de la base par défaut ( shinken ) |
Pour enregistrer les données de ces collections, on utilise la commande mongodump :
mongodump -d DATABASE_NAME -c COLLECTION_NAME -o OUTPUT_FOLDER_NAME |
Avec :
| Nom | Exemple | Description |
|---|---|---|
| DATABASE_NAME | shinken | Nom de la base Mongo |
| COLLECTION_NAME | retention_hosts_raw | Nom de la collection Mongo |
| OUTPUT_FOLDER_NAME | retention_hosts_11_10_2021 | Nom du fichier de sortie de la commande. Ce paramètre est optionnel mais nous vous recommandons de donner un nom parlant au dossier créé par mongodump. Si ce paramètre n'est pas renseigné, alors le dossier sera nommé dump. |
Exemple de commandes :
mongodump -d shinken -c retention_hosts_raw -o /root/retention_mongo/retention_hosts_11_10_2021 mongodump -d shinken -c retention_services_raw -o /root/retention_mongo/retention_services_11_10_2021 |
Ces deux commandes vont créer deux dossier à l'emplacement /root/retention_mongo/ ( assurez vous que ce chemin existe ) nommés retention_hosts_11_10_2021 et retention_services_11_10_2021 contenant des fichier .json et .bson qui contiennent les données des collections correspondantes.
La sortie de la commande mongodump écrase le dossier du même nom s'il en existe, avant de lancer la commande, assurez-vous qu'il n'y ait pas de dossier appelé comme la valeur de votre paramètre "-o" ( ou dump si vous n'utilisez pas le paramètre "-o" ) |
La restauration des données issues de la commande mongodump se fait avec la commande mongorestore :
mongorestore --drop RETENTION_FOLDER_PATH |
Il faut préciser à cette commande le dossier créé par la commande mongodump.
Le paramètre --drop va effacer toute la collection cible avant de la restaurer. |
Exemple de commandes :
mongorestaure --drop /root/retention_mongo/retention_hosts_11_10_2021 mongorestaure --drop /root/retention_mongo/retention_services_11_10_2021 |