Versions Compared

Old Version 29

changes.mady.by.user Julien Pilleux

Saved on

compared with

New Version Current

changes.mady.by.user Soubrié Grégoire

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Make by tools (01.00.01) - action=same_as_next_version
Scroll Ignore
scroll-viewporttrue
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtrue
scroll-htmltruefalse
Panel
titleSommaire

Table of Contents
stylenone

Description

Concept

Shinken ne fournit pas de commandes natives La méthode pour sauvegarder ou restaurer une rétention. Cette page décrit le protocole à suivre pour effectuer ces opérations manuellement.

La procédure de sauvegarde et de restauration dépend du et restaurer manuellement la rétention dépend du type de module de rétention utilisé par vos Schedulers Scheduler :


Sauvegarde et restauration de la rétention avec le module

MongodbRetention ) ;
Info

Vous trouverez plus d'information sur ces modules sur les pages décrivant leur mise en place :

AnchorsavePickleRetentionsavePickleRetentionSauvegarde et restauration de la rétention avec le module PickleRetentionFile

Où trouver la rétention Pickle

PickleRetentionFile

Où trouver la rétention Pickle

Lorsque le module PickleRetentionFile est utilisé, la rétention est sauvegardée dans un fichier, situé par défaut dans le répertoire suivant : /var/lib/shinken/.

Ce chemin peut toutefois varier selon la configuration spécifique des modules PickleRetentionFile utilisés par les Scheduler ( voir la page Module PickleRetentionFile ( Rétention par fichier plat ) ).

Voici un exemple complet de nom de fichier de rétention Pickle : 

Lorsque le module PickleRetentionFile est utilisé, la sauvegarde de la rétention se fait dans un fichier situé au chemin suivant :
Code Block
languagetext
themeEmacs
/var/lib/shinken/

Le nom de ces fichiers respecte ce format :

Code Block
retention.dat_--_realm--REALM_NAMEall_--_scheduler--scheduler-SCHEDULUER_NAMEmaster_--_id--SCHEDULER_ID0.retention
NomExempleDescription
Code Block
REALM_NAME
AllNom du royaume sauvegardé dans la rétention.
Code Block
SCHEDULER_NAME
scheduler-masterNom du Scheduler qui a effectué la rétention.
Code Block
SCHEDULER_ID
0Id du Scheduler qui a effectué la rétention.

Comment sauvegarder la rétention Pickle

Pour sauvegarder les fichiers de rétention, il suffit de les copier vers l'emplacement choisi en veillant à préserver leur intégrité et leurs permissions :

Code Block
languagetext
themeEmacs
cp -a /var/lib/shinken/

Exemple de nom de fichier : 

En fonction de votre configuration ( en fonction du nombre de royaumes et de Schedulers que vous avez ) il peut y avoir plusieurs fichiers
Code Block
retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /root/retention
Info
_save/


  • -a : permet de préserver les droits et métadonnées du fichier

Comment restaurer la rétention Pickle

Restauration des fichiers de rétention

Pour restaurer un fichier de rétention Pickle, il faut le copier dans le dossier /var/lib/shinken/

Pensez à vérifier que vous avez sauvegardé tous les fichiers.

Comment sauvegarder la rétention Pickle

:

Code Block
languagetext
themeEmacs
cp -a /root/retention_save

Pour sauvegarder ces fichiers de rétention, il suffit de les copier à l'endroit souhaité avec la commande cp <source> <destination> :

Code Block
cp /var/lib/shinken/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /rootvar/retention_save/

Cette commande va copier le fichier de rétention retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention dans le dossier nommé /root/retention_save/

Info
  • Le dossier de destination /root/retention_save/ doit exister avant de lancer la commande.
  • Le dossier de destination /root/retention_save/ n'est qu'un exemple, choisissez où bon vous semble.

Comment restaurer la rétention Pickle

Restauration des fichiers de rétention

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/

Si les fichiers ont été copiés dans un dossier nommé /root/retention_save/, alors la commande pour restaurer la rétention devrait ressembler à ça :

Code Block
cp /root/retention_save/retention.dat_--_realm--all_--_scheduler--scheduler-master_--_id--0.retention /var/lib/shinken/
Warning

Attention, la commande cp écrase la destination !

Avant de restaurer les fichiers Pickle, assurez-vous qu'il n'y a pas de fichier du même nom dans /var/lib/shinken/, ou assurez-vous de les sauvegarder si besoin.

Redémarrage du Scheduler

Après avoir restauré les fichiers de rétention, il faut redémarrer le Scheduler pour que les changements fassent effet :

Code Block
service shinken-scheduler restart
AnchorsaveMongodbRetentionsaveMongodbRetentionSauvegarde et restauration de la rétention avec le module MongodbRetention

Où se trouve la rétention dans Mongo

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.

Note

Pensez à vérifier que vous n'avez pas changé le nom de la base par défaut ( shinken ), dans le cas contraire, il faudra changer le nom de la base dans la commande ( paramètre "-d" )

Comment sauvegarder la rétention MongodbRetention

Avant de lancer la sauvegarde

Avant de sauvegarder la rétention, il est conseillé ( si possible ) de redémarrer le Scheduler afin de forcer la rétention, et donc d'avoir des données plus fraiches : 

Code Block
service shinken-scheduler restart
AnchormongodumpCommandmongodumpCommandDétails de la commande mongodump

Pour enregistrer les données de ces collections, on utilise la commande mongodump :

Code Block
mongodump -d DATABASE_NAME -c COLLECTION_NAME -h HOST_NAME --poty=HTTP_PORT --ssl -o OUTPUT_NAME

Explication des paramètres :

ParamètreObligatoireExempleDescription
Code Block
-d DATABASE_NAME
OuishinkenNom de la base Mongo
Code Block
-c COLLECTION_NAME
Ouiretention_hosts_rawNom de la collection Mongo
Code Block
-h HOST_NAME
Non192.168.1.25Adresse IP ou nom de l'hôte où se trouve la base MongoDB utilisée par le Scheduler pour sauvegarder sa rétention. Non nécessaire si la commande est lancée sur le même serveur.
Code Block
--port=HTTP_PORT
Non27018

Port HTTP de la base MongoDB  ( et non du serveur ). Par défaut le port utilisé est 27017.

Ce port peut être trouvé par défaut dans le fichier /etc/mongod.conf ( ou /etc/mongos.conf si vous utilisez MongoDB en cluster ).

Si vous avez changé le port de MongoDB ( par défaut 27017 ) il faut le préciser via ce paramètre, même en local.

Code Block
--ssl
Non-Si votre base MongoDB utilise le SSL, il faut ajouter cette option qui ne prend pas d'arguments.
Code Block
-o OUTPUT_NAME
Nonretention_hosts_11_10_2021Nom 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.
Note

Si vous utilisez MongoDB en mode cluster, il faut s'assurer de communiquer avec le bon service : Cas du cluster

Info
  • Pour savoir quels paramètres utiliser, vous pouvez vous référer au fichier de configuration de votre Scheduler, par défaut ici : /etc/shinken/schedulers/scheduler-master.cfg
  • Il est possible d'utiliser plusieurs fois le même OUTPUT_NAME, les données seront alors toutes sauvegardées dans le même dossier et donc peuvent être toutes restaurées avec qu'une seule commande mongorestore.

Ces deux commandes vont créer deux dossiers à 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 fichiers .json et .bson qui contiennent les données des collections correspondantes.

Quelques exemples de mongodump

Sauvegarde de la rétention sur une MongoDB en local

Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021 depuis un MongoDB sur le même serveur où ces commandes sont lancées :

Code Block
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
Sauvegarde de la rétention sur une MongoDB sur un autre serveur

Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021 depuis un MongoDB sur un serveur hébergé sur un serveur nommé host_bordeaux et où MongoDB utilise le port 27018.

Code Block
mongodump -d shinken -c retention_hosts_raw -h host_bordeaux --port=27018 -o /root/retention_mongo/retention_hosts_11_10_2021
mongodump -d shinken -c retention_services_raw -h host_bordeaux --port=27018 -o /root/retention_mongo/retention_services_11_10_2021
Sauvegarde de la rétention sur une MongoDB sur un autre serveur qui utilise le SSL

Pour sauvegarder la rétention dans deux dossiers retention_hosts_11_10_2021 et retention_services_11_10_2021 depuis un MongoDB sur un serveur hébergé sur un serveur nommé host_bordeaux, où MongoDB utilise le port 27017 ( port par défaut ) et utilisant le SSL :

Code Block
mongodump -d shinken -c retention_hosts_raw -h host_bordeaux --ssl -o /root/retention_mongo/retention_hosts_11_10_2021
mongodump -d shinken -c retention_services_raw -h host_bordeaux --ssl -o /root/retention_mongo/retention_services_11_10_2021
lib/shinken/

Redémarrage du Scheduler

Après avoir restauré les fichiers de rétention, il faut redémarrer le Scheduler pour que les changements soient pris en compte :

Code Block
languagetext
themeEmacs
service shinken-scheduler restart

Anchor
saveMongodbRetention
saveMongodbRetention

Sauvegarde et restauration de la rétention avec le module MongodbRetention

Où trouver la rétention Mongo

Lorsque le module MongodbRetention est utilisé, la rétention est sauvegardée dans la base shinken de MongoDB ( voir la page Module MongodbRetention ( Rétention en base de données centralisée par royaume ) ), au sein des collections retention_hosts_raw et retention_services_raw. 

Info

Il est impératif de sauvegarder et de restaurer les deux collections pour garantir l’intégrité de la rétention.

Comment sauvegarder la rétention Mongo

Avant de lancer la sauvegarde

Avant de procéder à la sauvegarde de la rétention, il est conseillé de redémarrer le Scheduler afin de forcer la mise à jour de la rétention et d’obtenir ainsi des données plus fraîches : 

Code Block
languagetext
themeEmacs
service shinken-scheduler restart

Anchor
mongodumpCommand
mongodumpCommand

Sauvegarder la rétention

Pour enregistrer la rétention, il faut lancer les deux commandes suivantes :


Code Block
languagetext
themeEmacs
mongodump -d shinken -c retention_hosts_raw -o /root/retention_mongo/ ( + MONGO_DB_CONNECTION_OPTIONS )
Code Block
languagetext
themeEmacs
mongodump -d shinken -c retention_services_raw -o /root/retention_mongo/ ( +  MONGO_DB_CONNECTION_OPTIONS )


  • shinken : nom de la base définie dans la configuration du module (voir la page Module MongodbRetention ( Rétention en base de données centralisée par royaume ) ).
  • /root/retention_mongo/ : dossier où seront sauvegardées les rétentions. Le chemin peut être absolu ou relatif ( dans ce dernier cas, le dossier sera créé à l’emplacement où la commande est exécutée ).
  • retention_hosts_raw / retention_services_raw : noms des collections où se trouvent les données de retentions. Ne pas les modifier dans la commande.
  • MONGO_DB_CONNECTION_OPTIONS : options de connexion à MongoDB. Ces options sont nécessaires si l’authentification, le chiffrement ou des paramètres spécifiques sont activés sur la base ( voir le chapitre Options de connexion à la base MongoDB ).



Note

Dans le cas d'un cluster MongoDB, il faut s'assurer de communiquer avec un mongos.


La commande crée les fichiers suivants :  

  • retention_hosts_raw.bson
  • retention_hosts_raw.metadata.json
  • retention_services_raw.bson
  • retention_services_raw.metadata.json


Anchor
Options de connexion à la base MongoDB
Options de connexion à la base MongoDB

Include Page
MongoDB - options de connexion à la base des commandes MongoDB
MongoDB - options de connexion à la base des commandes MongoDB

Exemple de sauvegarde

Sauvegarde de la rétention sur un MongoDB en local

Pour sauvegarder la rétention depuis un MongoDB sur le même serveur où les commandes sont lancées :

Code Block
languagetext
themeEmacs
mongodump -d shinken -c retention_hosts_raw -o /root/retention_mongo/
mongodump -d shinken -c retention_services_raw -o /root/retention_mongo/
Info

Il faut faire la sauvegarde en local sur la machine.  Pour des raisons de sécurité, MongoDB écoute que sur l'interface locale ( localhost ).

Exemple de retour avec succès de la commande
Code Block
languagetext
themeEmacs
2025-06-04T03:58:27.264-0400    writing shinken.retention_services_raw to /root/retention_mongo/shinken/retention_services_raw.bson
2025-06-04T03:58:27.269-0400    writing shinken.retention_services_raw metadata to /root/retention_mongo/shinken/retention_services_raw.metadata.json
2025-06-04T03:58:27.272-0400    done dumping shinken.retention_services_raw (32 documents)


Si la dernière ligne du retour de la commande, il y a écrit "(0 documents)" :

  • La première sauvegarde de la rétention n'a pas encore eu lieu.
  • Les paramètres fournis sont incorrects. Vérifier le nom de la base, des collections. 

Comment restaurer la rétention MongodbRetention

Avant de sauvegarder la rétention

Avant d'effectuer la restauration de la rétention, il est conseillé d'éteindre le Scheduler :

Code Block
languagetext
themeEmacs
service shinken-scheduler stop

Anchor
mongorestoreCommand
mongorestoreCommand

Détails de la commande mongorestore

Pour restaurer la rétention, lancer la commande : 

Code Block
languagetext
themeEmacs
mongorestore --drop  /root/retention_mongo/ ( +  MONGO_DB_CONNECTION_OPTIONS )


  • --drop : Permet de supprimer les collections de rétention présentes dans la base afin d’éviter toute incohérence.
  • /root/retention_mongo/ :Dossier contenant la sauvegarde de la rétention, créé par la commande mongodump ( voir le chapitre mongodump ).
  • MONGO_DB_CONNECTION_OPTIONS : Options de connexion à MongoDB. Nécessaire si l'authentification ou le chiffrement de la base est activé, ou si la base n'utilise pas les paramètres par défauts.



Include Page
MongoDB - options de connexion à la base des commandes MongoDB
MongoDB - options de connexion à la base des commandes MongoDB

Note

Dans le cas d'un cluster MongoDB, il faut s'assurer de communiquer avec un mongos.

Exemple de restauration 

Restauration d'une rétention sur un MongoDB en local

Cette commande va restaurer dans un MongoDB local les données contenues dans le dossier /root/retention_mongo/ : 

Code Block
languagetext
themeEmacs
mongorestore --drop /root/retention_mongo/
Info

Il faut faire la restauration en local sur la machine.  Pour des raisons de sécurité, MongoDB écoute que sur l'interface locale ( localhost ).

Exemple de retour avec succès d'une commande de restauration
Code Block
languagetext
themeEmacs
2025-06-04T04:22:19.606-0400    building a list of dbs and collections to restore from retention_mongo/ dir
2025-06-04T04:22:19.611-0400    reading metadata file from retention_mongo/shinken/retention_services_raw.metadata.json
2025-06-04T04:22:19.611-0400    restoring shinken.retention_services_raw from file retention_mongo
Exemple de retour avec succès de la commande
Code Block
themeEmacs
2021-10-12T11:09:12.823+0200    writing shinken.retention_services_raw to /root/retention_hosts_11_10_2021/shinken/retention_services_raw.bson
20212025-1006-12T1104T04:0922:12.823+020019.661-0400    writing shinken.retention_services_raw metadata to /root/retention_hosts_11_10_2021reading metadata file from retention_mongo/shinken/retention_serviceshosts_raw.metadata.json
20212025-1006-12T1104T04:0922:12.825+020019.661-0400    therestoring collection shinken.retention_serviceshosts_raw appearsfrom to have been dropped after the dump started
2021-10-12T11:09:12.825+0200    done dumpingfile retention_mongo/shinken/retention_hosts_raw.bson
2025-06-04T04:22:19.666-0400    restoring indexes for collection shinken.retention_services_raw (45 documents)
Note

Si sur la dernière ligne du retour de la commande, il y a écrit "(0 documents)", alors il y a peut-être un problème quelque part, comme le nom de la collection qui n'est pas correcte.

Comment restaurer la rétention MongodbRetention

Avant de sauvegarder la rétention

Avant d'effectuer la restauration de la rétention, il est conseillé d'éteindre le Scheduler :

Code Block
service shinken-scheduler stop
AnchormongorestoreCommandmongorestoreCommandDétails de la commande mongorestore

La restauration des données issues de la commande mongodump se fait avec la commande mongorestore :

Code Block
mongorestore --drop --ssl -h HOST_NAME --port=HTTP_PORT RETENTION_FOLDER_PATH
ParamètreObligatoireExempleDescription
Code Block
--drop
Non mais conseillé-

Sans ce paramètre, MongoDB va tenter de garder les collections présentes actuellement dans la base, ce qui peut résulter en des mélanges de données non souhaitée. Pour retrouver la rétention au même état qu'au moment de sa sauvegarde, il faut utiliser ce paramètre.

Warning

Ce paramètre va effacer la rétention acutellement présente en base.

Code Block
--ssl
Non-Si votre base MongoDB utilise le SSL, il faut ajouter cette option qui ne prend pas d'arguments.
Code Block
-h HOST_NAME
Non192.168.1.25Adresse IP ou nom de l'hôte où se trouve la base MongoDB utilisée par le Scheduler pour sauvegarder sa rétention. Non nécessaire si la commande est lancée sur le même serveur.
Code Block
--port=HTTP_PORT
Non27018

Port HTTP de la base MongoDB  ( et non du serveur ). Par défaut le port utilisé est 27017.

Ce port peut être trouvé par défaut dans le fichier /etc/mongod.conf ( ou /etc/mongos.conf si vous utilisez MongoDB en cluster ).

Si vous avez changé le port de MongoDB ( par défaut 27017 ) il faut le préciser via ce paramètre, même en local.

Code Block
RETENTION_FOLDER_PATH
Oui/root/retention_hosts_11_10_2021/Chemin vers le dossier contenant la sauvegarde de la rétention qui a été créé avec la commande mongodump. Le dossier doit être sur le même serveur que celle où la commande est lancée.
Note

Si vous utilisez MongoDB en mode cluster, il faut s'assurer de communiquer avec le bon service : Cas du cluster

Quelques exemples de commandes de restauration

Restauration d'une rétention sur un MongoDB en local

Cette commande va restaurer dans un MongoDB local les données contenues dans le dossier /root/retention_hosts_11_10_2021/

Code Block
mongorestore --drop /root/retention_hosts_11_10_2021/
from metadata
2025-06-04T04:22:19.700-0400    finished restoring shinken.retention_services_raw (32 documents)
2025-06-04T04:22:19.701-0400    restoring indexes for collection shinken.retention_hosts_raw from metadata
2025-06-04T04:22:19.702-0400    finished restoring shinken.retention_hosts_raw (2 documents)


Si la dernière ligne du retour de la commande, il y a écrit "(0 documents)" :

  • La première sauvegarde de la rétention n'a pas encore eu lieu.
  • Les paramètres fournis sont incorrects.
    • Vérifier le nom de la base, des collections. 

  • Il y a eu une erreur lors de la sauvegarde précédente. 

Après la restauration de la rétention

Une fois la restauration terminée, il faut redémarrer le Scheduler :

Code Block
languagetext
themeEmacs
service shinken-scheduler start
Restauration d'une rétention sur un MongoDB sur un autre serveur

Cette commande va restaurer dans un MongoDB sur un serveur nommé host_bordeaux où MongoDB utilise le port 27018 les données contenues dans le dossier /root/retention_hosts_11_10_2021/

Code Block
mongorestore --drop -h host_bordeaux --port=27018 /root/retention_hosts_11_10_2021/
Restauration d'une rétention sur un MongoDB sur un autre serveur qui utilise le SSL

Cette commande va restaurer dans un MongoDB sur un serveur nommé host_bordeaux avec le port 27018 et utilisant le SSL, les données contenues dans le dossier /root/retention_hosts_11_10_2021/

Code Block
mongorestore --drop --ssl -h host_bordeaux --port=27018 /root/retention_hosts_11_10_2021/
Exemple de retour avec succès d'une commande de restauration
Code Block
themeEmacs
2021-10-12T11:11:01.024+0200    building a list of dbs and collections to restore from /root/retention_hosts_11_10_2021/ dir
2021-10-12T11:11:01.026+0200    reading metadata file from /root/retention_hosts_11_10_2021/shinken/retention_services_raw.metadata.json
2021-10-12T11:11:01.026+0200    restoring shinken.retention_services_raw from file /root/retention_hosts_11_10_2021/shinken/retention_services_raw.bson
2021-10-12T11:11:01.027+0200    finished restoring shinken.retention_services_raw (45 documents)
2021-10-12T11:11:01.027+0200    done
Note

Si sur l'avant-dernière ligne du retour de la commande, il y a écrit "(0 documents)", alors il y a peut-être un problème quelque part, comme la commande mongodump qui s'est mal passée ( nom de collection incorrect par exemple )

Après la restauration de la rétention

Une fois la restauration terminée, vous pouvez redémarrer le Scheduler :

Code Block
service shinken-scheduler start
AnchormongodbClustermongodbClusterCas particulier de l'utilisation d'un cluster MongoDB

Si vous utilisez MongoDB en mode cluster, les commandes restent les mêmes, à la nuance près qu'il faut préciser le port du bon service et il faut s'assurer d'avoir fait la sauvegarde de tous les replicaset.

  • Pour sauvegarder l'entièreté d'un replicaset, il faut s'assurer de lancer les commande sur le service mongos et non mongod.
  • Pour utiliser un service plutôt que l'autre, il suffit de trouver et utiliser son port à fournir aux commandes.
Info

Pour plus d'informations sur les clusters et les termes de MongoDB liés à ce sujet, référez-vous à cette page : Haute disponibilité de la base MongoDB (mise en place d'un cluster)

Vérifier la présence du service mongos

Pour vérifier si un mongos est sur un serveur et qu'il est opérationnel, il est possible de vérifier en demandant le status du service mongos :

Code Block
service mongos status

Si un processus mongos tourne sur le serveur sur lequel la commande a été lancée, alors le retour de la commande devrai ressembler à ça :

Code Block
themeEmacs
● mongos.service - SYSV: Mongo is a scalable, document-oriented database.
   Loaded: loaded (/etc/rc.d/init.d/mongos; bad; vendor preset: disabled)
   Active: active (running) since Tue 2021-10-19 11:04:58 CEST; 53min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2805 ExecStart=/etc/rc.d/init.d/mongos start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/mongos.service
           └─2820 /usr/bin/mongos -f /etc/mongos.conf
Info

Si la commande précédente échoue, il est possible que le processus mongos se trouve sur un autre serveur.

AnchorfindMongosPortfindMongosPortTrouver le port du service mongos

Le port se trouve dans le fichier de configuration de mongos ( par défaut dans /etc/mongos.conf ) :

Code Block
...

# network interfaces
net:
  port: 27018
  bindIp: 192.168.1.100

sharding:
    configDB: primary:27019, secondary1:27019, secondary2:27019


...

Le port souhaité est celui indiqué dans la section "net", dans notre exemple, ce sera le port du service mongos est 27018.

Exemples de restauration et de sauvegarde

Après avoir trouvé le port du bon service, disons 27018, il faut le renseigner aux commande de sauvegarde et de restauration :

Exemple de sauvegarde
Code Block
mongodump --port=27018 -d shinken -c retention_hosts_raw -o /root/retention_mongo/retention_hosts_11_10_2021
mongodump  --port=27018 -d shinken -c retention_services_raw -o /root/retention_mongo/retention_services_11_10_2021
Info

Pour plus de détails sur la commande mongodump, référez vous à la section Détails de la commande mongodump

Exemple de restauration
Code Block
mongorestore --port=27018 --drop /root/retention_mongo/retention_hosts_11_10_2021
mongorestore --port=27018 --drop /root/retention_mongo/retention_services_11_10_2021
Info

Pour plus de détails sur la commande mongorestore, référez-vous à la section Détails de la commande mongorestore

Faire la sauvegarde et restauration de tous les replicaset

Pour sauvegarder et restaurer l'entièreté d'un cluster MongoDB, il faut faire le tour de tous les replicaset.

Pour vérifier quel replicaset un service mongos gère, vous pouvez utiliser cette commande :

Code Block
mongo --quiet --port MONGOS_PORT --eval "printjson(rs.status().set)"
Note

Pensez à remplacer MONGOS_PORT par le port du service mongos, vous pouvez vous aider de la partie sur ce sujet : Trouver le port du service mongos

Cette commande devrait retourner le nom du replicaset gérée par ce service.

Exemple de retour :

Code Block
themeEmacs
$ mongo --quiet --port 27018 --eval "printjson(rs.status().set)"
"replicaset-name"
Info
Pour plus d'informations sur la récupération d'informations d'un replicaset, référez-vous à cette page : Etape 4: Déclaration du replicaset dans Mongo