Guide de l'administrateur NetBackup™ for MongoDB

NetBackup procède dans l'ordre suivant lors de la sélection d'un nœud dans un cluster MongoDB pour effectuer une sauvegarde :

Si vous souhaitez que NetBackup sélectionne un nœud de sauvegarde spécifique dans le cluster MongoDB, définissez-le en tant que nœud masqué.

Avant d'exécuter un travail de sauvegarde, assurez-vous que vous obtenez une réponse ping positive de tous les nœuds MongoDB de l'hôte de sauvegarde. Vérifiez et mettez à jour les paramètres de pare-feu afin que les hôtes de sauvegarde puissent communiquer avec le cluster MongoDB.

Assurez-vous que le cluster MongoDB que vous souhaitez protéger vous permet de prendre des snapshots LVM.

Le changement de nom du groupe de volumes ou des volumes physiques et logiques du LVM pour les chemins d'accès à la base de données MongoDB entraîne l'échec de la sauvegarde. Si vous renommez le groupe de volumes ou les volumes physiques et logiques du LVM, assurez-vous que la base de données MongoDB est montée sur le nouveau chemin d'accès avant de procéder à une sauvegarde.

La sauvegarde arrête l'équilibreur sur le processus mongos et bloque toutes les autres opérations. Ainsi, lorsque vous exécutez un processus de sauvegarde, assurez-vous qu'aucune autre opération utilisant le processus mongos n'est en cours, par exemple, l'importation de la base de données.

Exécutez toujours une sauvegarde complète lorsque vous modifiez le chemin d'accès à la base de données. Vous pouvez également modifier le fichier de configuration du processus mongod ou mongos ou modifier la topologie MongoDB.

Si une même politique de sauvegarde NetBackup comporte plusieurs clients MongoDB, augmentez la valeur du paramètre Délai de lecture client pour le serveur principal, le serveur de médias et le client afin de vous assurer que toutes les sauvegardes vont aboutir.

Pour plus d'informations, consultez le Guide de l'administrateur NetBackup™, volume I, et la section relative aux propriétés de délai d'expiration.

Les travaux de sauvegarde incrémentielle utilisent des images de sauvegarde cohérentes comme référence pour déterminer les modifications incrémentielles. Si la sauvegarde précédente a échoué ou n'a abouti que partiellement (échec pour l'un des nœuds), elle est totalement ignorée et une image de sauvegarde antérieure est prise en compte. Dans ce cas, l'opération de sauvegarde peut être plus longue et la taille de l'image créée peut être plus importante.

Le fichier oplog est doté d'un cache limité ou roulant et la taille du fichier est configurable. NetBackup utilise oplog pour capturer les données incrémentielles. La substitution d'oplog peut entraîner l'échec des sauvegardes incrémentielles. Pour éviter ce problème, assurez-vous que la taille du fichier oplog est suffisante pour contenir les données incrémentielles générées entre les sauvegardes incrémentielles.

Si le cluster MongoDB est en cours d'exécution sous le compte mongod, un compte sudoer non racine est requis et ceux-ci doivent être configurés en tant qu'utilisateur de l'hôte dans tpconfig.

Si le cluster MongoDB est en cours d'exécution sous un compte racine ou non racine, vérifiez que les informations d'authentification de l'utilisateur de l'hôte configurées à l'aide de la commande tpconfig correspondent à celles du compte utilisateur de l'hôte utilisé pour configurer le cluster MongoDB (compte utilisateur de l'hôte du daemon MongoDB, racine ou non racine).

Si vous utilisez la fonction de conservation oplog sur un jeu de répliques, assurez-vous que la durée programmée entre les sauvegardes incrémentielles est inférieure à la période de conservation oplog minimale. Cela garantira la capture de la sauvegarde incrémentielle appropriée.

NetBackup prend en charge la sauvegarde complète uniquement pour les MongoDB versions 4.4 et ultérieures prises en charge sur un cluster partitionné.