Guide de l'administrateur NetBackup™ for MongoDB

Prenez connaissance des conditions préalables et limitations suivantes avant de lancer la restauration ou la récupération :

• Assurez-vous que les éléments suivants sont identiques pour les clusters MongoDB source et cible :

  • Version de MongoDB

  • Type d'authentification

• Si le cluster MongoDB cible s'exécute sous le compte mongod, vous devez disposer d'un compte sudoer non racine. Configurez également ce compte comme utilisateur hôte dans tpconfig avant de lancer la restauration. NetBackup récupère et exécute l'instance sous le compte défini comme utilisateur du cluster cible.

• (Avant de restaurer les données MongoDB sur un autre cluster) Veillez à ajouter les informations d'authentification de l'autre cluster MongoDB dans le fichier d'informations d'authentification du cluster source.

  Se reporter à Ajout des informations d'authentification MongoDB dans NetBackup.

• Assurez-vous que les fichiers PEM ou les certificats de sécurité sont disponibles sur le cluster de destination avant de lancer l'opération de récupération.

• Le type d'authentification du cluster cible lors du processus de récupération doit être identique à celui utilisé lors de la sauvegarde.

• Assurez-vous que l'espace de stockage disponible sur le cluster MongoDB cible est suffisant pour restaurer les données.

• Sélectionnez un seul groupe d'images de sauvegarde complète et les images incrémentielles appropriées de ce groupe. Si vous sélectionnez plusieurs groupes d'images de sauvegarde complète, les données restaurées peuvent être endommagées et faire échouer la récupération.

• Le plug-in NetBackup for MongoDB ne prend pas en charge la restauration de système de fichiers multiplateforme. Par exemple, la restauration de XFS vers ext4 n'est pas prise en charge et inversement.

• Assurez-vous que la valeur de HostUser définie dans la commande tpconfig correspond au compte utilisateur hôte utilisé pour configurer le cluster MongoDB (compte utilisateur hôte du daemon MongoDB).

• Sélectionnez un hôte de sauvegarde comme client de destination avant de soumettre le travail de restauration.

• La récupération spécifique est valide uniquement pour la récupération à partir de sauvegardes incrémentielles.

• L'annulation d'un travail parent dans un travail de restauration composé n'annule pas les travaux de restauration enfants. Vous devez également annuler manuellement les travaux de restauration enfants.

• Après avoir exécuté un travail de restauration ou de récupération à partir de l'interface utilisateur Web, recherchez l'enregistrement et l'état du travail dans la section Progression de la tâche du nœud Récupération. Vous devrez peut-être patienter un certain temps pour que le travail apparaisse dans la liste et que le travail composé déclenche la vérification de prérécupération parente. Cliquez sur Actualiser pour mettre à jour la liste de tâches.

• Lors d'une opération Restaurer uniquement pour un cluster partitionné, suivez les étapes standard pour ce type d'opération :

  Arrêtez tous les processus MongoDB (mongos ou mongod) avant de lancer la restauration.

  L'utilisateur de l'hôte tpconfig doit disposer des droits d'accès au dossier cible dans la restauration initiale et l'autre restauration.

• Les chemins d'accès aux fichiers journaux MongoDB sont inchangés par rapport à la configuration initiale. Dans le cas d'une restauration alternative :

  • Assurez-vous que le même chemin d'accès est disponible lors de la restauration.

  • Modifiez le chemin d'accès au fichier journal dans le fichier de configuration du processus mongod ou mongos après une récupération réussie.

• Le chemin d'accès aux fichiers .pid doit être disponible dans le cluster de destination MongoDB pour que l'opération de récupération réussisse.

• Soyez particulièrement vigilant lors de la sauvegarde de plusieurs clusters MongoDB s'exécutant sur le même serveur (sauvegardes utilisant la même politique de sauvegarde ou des politiques de sauvegarde différentes). Veillez à bien sélectionner le serveur d'application à restaurer.

  Par exemple, si plusieurs clusters présentent la configuration suivante :

  Replica1
  Primary: 		host1:26050
  Secondary: host1:26060
  
  Replica2
  Primary: 		host1:26055
  Secondary: host1:26066

  Si vous souhaitez récupérer Replica1, veillez à spécifier le serveur d'application approprié et le port correspondant (host1-26050) comme Client source.

• Avant de lancer une opération de récupération, assurez-vous qu'aucun processus mdbserver obsolète (client léger) n'est en cours d'exécution sur votre instance MongoDB à l'emplacement suivant :

  /<mdbserver_location>/<Host>-<MongodPort>-<mdbserver_port in range>/mdbserver

  Si l'un de ces processus obsolètes est en cours d'exécution, l'opération de récupération ne peut pas arrêter l'instance MongoDB et le travail de récupération cesse de répondre.

• La restauration et la récupération du cluster MongoDB requièrent le mode de sécurité utilisé lors de la sauvegarde. Assurez-vous que le cluster d'origine et le cluster cible présentent le même mode de sécurité.

  Par exemple, si SSL est utilisé lors de la sauvegarde, la récupération est effectuée à l'aide de SSL et la configuration cible est modifiée en SSL. De même, si TLS est utilisé lors de la sauvegarde, la récupération est effectuée à l'aide de TLS et la configuration cible est modifiée en TLS.

• La restauration et la récupération du cluster MongoDB requièrent la version de Feature Compatibility (FCV) utilisée lors de la sauvegarde. Assurez-vous que la FCV est identique pour le cluster d'origine et le cluster cible.

  Par exemple, si FCV 4.2 est utilisé lors de la sauvegarde, la restauration utilise FCV 4.2 et le cluster cible dispose de FCV 4.2 à l'issue du processus de récupération. De même, si FCV 4.0 est utilisé lors de la sauvegarde, la restauration utilise FCV 4.0 et le cluster cible dispose de FCV 4.0 à l'issue du processus de récupération.