Guide de l'administrateur Veritas NetBackup™ for MongoDB

Dans un cluster MongoDB partitionné qui contient plusieurs processus mongos, avant le démarrage d'une opération de restauration et de récupération, seul le processus mongos à l'emplacement de restauration de l'image du jeu de répliques du serveur de configuration (CSRS) doit être en cours d'exécution.

Arrêtez manuellement tout autre processus mongos dans le cluster avant de lancer une opération de restauration et de récupération.

Une fois la récupération terminée, reconfigurez les services mongos pour qu'ils pointent vers le cluster récupéré.

Si le processus mongos n'est pas arrêté sur tous les nœuds sauf un, les autres processus mongos peuvent entrer en conflit avec l'opération de restauration et de récupération et empêcher l'accès aux données restaurées par le biais d'une connexion à mongos.

Si les processus mongos ne sont pas arrêtés avant le démarrage de la restauration et de la récupération, vous devrez arrêter manuellement les processus mongos obsolètes après la récupération, puis redémarrer tous les processus mongod et mongos récupérés dans le cluster.

Vous devez démarrer les processus MongoDB avec un chemin absolu vers les fichiers de configuration et utiliser les chemins absolus des fichiers de certificat et du fichier d'autorité de certification. Vous devez également spécifier les chemins absolus du fichier d'autorité de certification, du fichier PEM et des fichiers de clé.

N/A

Si vous exécutez un travail de récupération nécessitant une authentification différente de celle utilisée pour les modifications de sauvegarde, il se peut que le processus de récupération échoue.

Assurez-vous d'utiliser pour la récupération le même type d'authentification que pour la sauvegarde.

Si vous renommez le groupe de volumes ou le volume logique après une sauvegarde, la sauvegarde suivante risque d'échouer.

N/A

Lors de la récupération, veillez à sélectionner une seule image de sauvegarde complète et les images incrémentielles suivantes appropriées. Si vous sélectionnez plusieurs images, les données restaurées peuvent être endommagées et faire échouer la récupération.

N/A

Une fois le cluster MongoDB récupéré, seules les informations de cluster du nœud restauré sont disponibles.

Une fois le processus de récupération terminé, ajoutez manuellement les nœuds secondaires au cluster.

Pour plus d'informations, consultez l'article suivant :Ajouter des membres au jeu de répliques

Pendant le processus de sauvegarde, si l'opération d'importation MongoDB est en cours d'exécution, elle peut cesser de répondre. Évitez de procéder à l'opération d'importation MongoDB pendant le processus de sauvegarde ou de restauration.

N/A

Pendant le processus de restauration, la fenêtre contextuelle « La restauration a été lancée » s'affiche, mais le travail de restauration ne démarre pas.

Ce problème se produit lorsque vous entrez le serveur d'application dans le client source et le client de destination dans l'interface utilisateur BAR.

Assurez-vous que le client source et le client de destination sont entrés correctement. Le client source doit correspondre au serveur d'application et le client de destination, à l'hôte de sauvegarde.

Si votre environnement présente une configuration DNAT, assurez-vous que l'hôte de sauvegarde ou l'hôte de restauration ainsi que tous les nœuds MongoDB se trouvent dans le même réseau privé.

N/A

Le plug-in NetBackup for MongoDB ne prend pas en charge les options de ligne de commande bprestore-w et -print_jobid.

N/A

Les restaurations MongoDB ne sont pas prises en charge à partir des hôtes de sauvegarde. Toutes les opérations de restauration pour MongoDB doivent être lancées à partir du serveur maître NetBackup.

N/A

Si votre envoi de travail de restauration n'affiche pas le travail de restauration, vérifiez si un plug-in MongoDB est installé sur votre nœud de destination.

N/A

Si vous restaurez la base de données MongoDB à un emplacement non LVM, et que vous tentez d'effectuer une sauvegarde à partir de cet emplacement non LVM, la sauvegarde échoue.

Restaurez les données à un emplacement LVM, puis tentez de sauvegarder les données restaurées.

Le plug-in NetBackup for MongoDB ne prend pas en charge les liens physiques ou virtuels dans les dossiers de chemin d'accès aux données. N'ajoutez aucun lien physique ou virtuel qui pointe vers des emplacements d'un volume logique ou non logique différent.

NetBackup ne peut pas garantir la cohérence des données au moment des sauvegardes si le dossier de chemin d'accès aux données contient des liens physiques ou virtuels. Pendant le processus de restauration, les liens physiques ou virtuels sont créés en tant que dossiers et non en tant que liens.

N/A

Lorsque vous annulez un travail de restauration enfant pendant le processus de restauration et de récupération MongoDB, le client léger (mdbserver) n'est pas supprimé immédiatement. Il sera supprimé après l'opération de restauration suivante.

N/A

La restauration MongoDB échoue et affiche l'erreur 2850.

Assurez-vous que l'hôte et le port de destination sont valides et disposent des informations d'authentification configurées à l'aide de la commande tpconfig et du fichier d'informations d'authentification. Pour plus d'informations, reportez-vous aux journaux tar.

Après la récupération, le redémarrage manuel du nœud de partition MongoDB échoue et l'erreur suivante est consignée dans les journaux MongoDB :

NoSuchKey: Missing expected field "configsvrConnectionString"

Sur la partition MongoDB concernée par le problème, démarrez MongoDB en mode maintenance et exécutez la méthode suivante sur la collection system.version dans la base de données d'administration :

use admin
db.system.version.deleteOne
( { _id: "minOpTimeRecovery" } )

Dans le cas d'une opération de restauration et de récupération contenant un ou plusieurs jeux de répliques, les membres du jeu de répliques sont restaurés sur le jeu de répliques à l'aide de la valeur par défaut "cfg.members[#].host" fournie par rs.config().

Si cette valeur par défaut a été précédemment modifiée, il sera peut-être nécessaire de la mettre à jour après la restauration et la récupération (remplacer le nom court par le nom de domaine complet, par exemple) pour qu'elle corresponde à la configuration initiale.

Solution de contournement :

Les travaux de sauvegarde échouent et les codes d'erreur suivants s'affichent :

Assurez-vous que les fenêtres de sauvegarde pour les sauvegardes incrémentielles sont différentes pour un même cluster MongoDB. Les fenêtres de sauvegarde d'un cluster MongoDB ne doivent pas se chevaucher pour les sauvegardes incrémentielles.

Assurez-vous que des autorisations sont définies pour l'emplacement mdbserver, l'emplacement oplog et l'emplacement de montage de snapshot. Pour plus d'informations, Se reporter à Utilisation d'un utilisateur non racine comme utilisateur hôte.

Dans un environnement de cluster MongoDB partitionné, une erreur 112 peut indiquer que le processus mongos n'est pas en cours d'exécution sur le client défini dans la politique de sauvegarde.

Une erreur 112 peut également indiquer que plusieurs hôtes de sauvegarde portant des noms d'hôte identiques sont ajoutés à la politique BigData. Utilisez un nom d'hôte unique pour chaque hôte de sauvegarde exécutant les opérations de sauvegarde.

Si vous tentez d'arrêter et de redémarrer les services mongod ou mongos (service mongod stop ou service mongod restart) après une opération de restauration et de récupération, les commandes échouent.

Cette erreur se produit lorsque les processus mongod ou mongos sont lancés en tant que service à l'aide des commandes service ou systemctl et non à l'aide d'une commande directe.

Solution de contournement :

Utilisez une autre méthode pour arrêter les services mongod ou mongos. Par exemple, mongod -f /etc/mongod.conf --shutdown ou kill <PID>. Une fois les services arrêtés, vous pourrez de nouveau utiliser les commandes service ou systemctl.

L'opération de sauvegarde échoue si une commande qui génère une sortie dans .bashrc est ajoutée.

La sauvegarde échoue avec l'erreur 6646 et affiche le message suivant :

Erreur : Impossible de communiquer avec le serveur.

Assurez-vous que .bashrc (echo ou toute autre commande générant des sorties) ne génère aucune sortie. La sortie ne doit pas renvoyer STDERR ou STDOUT si le shell n'est pas interactif.

Lorsque vous sélectionnez deux images de sauvegarde complète et que vous tentez de restaurer une image spécifique qui se trouve entre ces deux images de sauvegarde complète, la dernière image de sauvegarde complète est restaurée.

Solution de contournement :

Pendant l'opération de restauration et de récupération, ne sélectionnez qu'une image de sauvegarde complète.

Pour une récupération à un moment précis, assurez-vous d'exécuter des sauvegardes incrémentielles différentielles plus courtes.

Impossible d'afficher la progression du travail de restauration dans le moniteur d'activité.

Solution de contournement :

Pour les travaux de restauration composés qui utilisent un serveur non maître comme hôte de restauration, vous devez utiliser le bouton Mettre à jour la liste des tâches pour afficher la progression du travail de restauration dans le moniteur d'activité.

La sauvegarde échoue avec l'erreur suivante :

(6625) L'hôte de sauvegarde n'est pas autorisé à exécuter l'opération ou il ne peut pas établir une connexion au serveur d'applications.

Solution de contournement :

Sur le serveur sur lequel MongoDB est installé, assurez-vous que PasswordAuthentication n'est pas désactivé dans le fichier /etc/ssh/sshd_config.

Exécutez la commande sudo service sshd restart.

La sauvegarde échoue avec l'erreur suivante :

(6646) Impossible de communiquer avec le serveur.

Solution de contournement :

Assurez-vous que l'hôte de sauvegarde peut accéder au port défini dans le fichier mongodb.conf ou au port mdbserver_port par défaut (11000).

L'erreur suivante est consignée dans les journaux mdbserver :

error-sudo: sorry, you must have a tty to run sudo

Solution de contournement :

Le dossier des journaux nbaapireq_handler n'est pas créé sur un conteneur Flex, même après l'exécution de la commande mklogdir.

Solution de contournement :

Lorsqu'une appliance Flex est mise à niveau de la version 8.1.2 vers la version 8.2 et que le serveur de médias Flex est utilisé comme hôte de sauvegarde, vous devez créer le dossier nbaapireq_handler dans le répertoire /usr/openv/netbackup/logs/ pour consigner les journaux de restauration du plug-in MongoDB.

La restauration MongoDB échoue avec l'erreur 2850

Le chemin d'accès à la base de données cible n'existe pas et certaines autorisations sont insuffisantes pour l'utilisateur non racine.

Solution de contournement :

Assurez-vous que le chemin d'accès à la base de données cible existe et que l'utilisateur non racine dispose d'autorisations suffisantes.

La taille de snapshot décrite par le paramètre free_space_percentage_snapshot doit être définie selon la taille de cluster MongoDB et doit être suffisamment grande. Si ces critères ne sont pas remplis, la sauvegarde échoue et l'erreur suivante s'affiche :

invalid command parameter (20)

Validez la valeur free_space_percentage_snapshot avec le cluster MongoDB.

La sauvegarde échoue avec l'erreur suivante :

(13) échec de lecture du fichier pour le média

Assurez-vous que :

Le paramètre mdb_progress_loglevel n'est pas disponible dans l'outil de configuration MongoDB.

Pour modifier le paramètre mdb_progress_loglevel, mettez à jour le fichier mongodb.conf une fois que l'outil de configuration MongoDB l'a créé.

Pour plus d'informations, consultez le Guide de l'administrateur MongoDB.

Les snapshots ne sont pas supprimés et des instances mdbserver obsolètes sont affichées. Ce scénario peut entraîner des erreurs Cannot lstat lors des sauvegardes et des sauvegardes partiellement réussies.

Modifiez les paramètres de configuration pour les paramètres suivants dans le fichier mongodb.conf :

Définissez les valeurs de sorte que les snapshots et instances obsolètes de mdbserver soient effacés avant la planification de sauvegarde complète ou incrémentielle suivante.

Si la version de NetBackup installée sur l'hôte de sauvegarde est antérieure à la 8.3 alors que le serveur maître et le serveur de médias disposent de la dernière version, les codes d'erreur suivants peuvent s'affichent pour différents scénarios :

13302, 13303, 13304, 13305, 13306, 13307, 13308, 13309, 13310, 13311, 13312, 13313, 13314, 13315

Solution de contournement :

Si des codes d'erreur non valides s'affichent, consultez la liste suivante de codes d'erreur réels pour découvrir les scénarios réels et les actions recommandées :

Pour en savoir plus et découvrir les actions recommandées, consultez le Guide de référence des codes d'état NetBackup.

Le bouton Restaurer de l'interface utilisateur BAR de NetBackup peut être désactivé pour les images de sauvegarde MongoDB importées.

Solution de contournement :

Si vous importez les images sur le serveur maître NetBackup sur lequel elles ont été initialement sauvegardées, appliquez l'une des méthodes suivantes :

Si vous importez les images sur un serveur maître NetBackup autre que celui sur lequel elles ont été initialement sauvegardées, utilisez la commande bprestore pour exécuter l'opération de restauration.