Guide d'installation et de mise à niveau de NetBackup™ Snapshot Manager for Cloud

Échec de la connexion de l'agent NetBackup Snapshot Manager au serveur NetBackup Snapshot Manager si l'hôte d'agent est redémarré brusquement

Ce problème peut se produire si l'hôte sur lequel l'agent NetBackup Snapshot Manager est installé est arrêté brusquement. Même après le redémarrage de l'hôte, l'agent ne parvient pas à établir de connexion avec le serveur NetBackup Snapshot Manager et passe dans un état hors ligne.

Le fichier journal de l'agent contient l'erreur suivante :

Flexsnap-agent-onhost[4972] mainthread flexsnap.connectors.rabbitmq: error - channel 1 closed unexpectedly: (405) resource_locked - cannot obtain exclusive access to locked queue ' flexsnap-agent.a1f2ac945cd844e393c9876f347bd817' in vhost '/'

Ce problème se produit car la connexion RabbitMQ entre l'agent et le serveur NetBackup Snapshot Manager ne se ferme pas, même en cas d'arrêt brusque de l'hôte d'agent. Le serveur NetBackup Snapshot Manager ne peut pas détecter l'indisponibilité de l'agent tant que l'hôte d'agent n'a pas été interrogé. La connexion RabbitMQ reste ouverte jusqu'au prochain cycle d'interrogation. Si l'hôte d'agent redémarre avant le déclenchement de l'interrogation suivante, l'agent tente d'établir une nouvelle connexion avec le serveur NetBackup Snapshot Manager. Cependant, étant donné que la connexion RabbitMQ précédente existe déjà, la nouvelle tentative de connexion échoue avec une erreur de ressource verrouillée.

En raison de cet échec de connexion, l'agent est mis hors ligne et entraîne l'échec de toutes les opérations de restauration et de snapshot effectuées sur l'hôte.

Solution de contournement :

Redémarrez le service Veritas NetBackup Snapshot Manager Agent sur l'hôte d'agent.

L'enregistrement de l'agent NetBackup Snapshot Manager sur des hôtes Windows peut expirer ou échouer

Pour protéger des applications sous Windows, vous devez installer et enregistrer l'agent NetBackup Snapshot Manager sur l'hôte Windows. L'enregistrement de l'agent peut parfois dépasser le délai habituel et expirer ou échouer.

Solution de contournement :

Pour résoudre ce problème, procédez comme suit :

Pour en savoir plus, reportez-vous aux sections suivantes :

Se reporter à Enregistrement de l'agent basé sur Windows.

Se reporter à Redémarrage de NetBackup Snapshot Manager.

Reprise après incident lors de la perte du package de reprise après incident ou de la phrase de passe

Ce problème peut se produire en cas de perte du package DR ou de la phrase de passe.

Dans le cas d'une sauvegarde de catalogue, 2 packages de sauvegarde sont créés :

Le package DR contient les certificats UUID NetBackup et la base de données de catalogue comprend l'UUID. Lorsque vous procédez à une reprise après incident à l'aide du package DR, puis à la récupération de catalogue, le certificat UUID et l'UUID sont restaurés. Cela permet à NetBackup de communiquer avec NetBackup Snapshot Manager, car l'UUID reste inchangé.

Cependant, l'opération de reprise après incident ne peut pas être réalisée en cas de perte du package DR ou de la phrase de passe. Vous ne pouvez récupérer le catalogue sans le package DR qu'après la réinstallation de NetBackup. Dans ce cas, un nouvel UUID est créé pour NetBackup et NetBackup Snapshot Manager ne le reconnaît pas. Le mappage un à un de NetBackup et NetBackup Snapshot Manager est perdu.

Solution de contournement :

Pour résoudre ce problème, vous devez mettre à jour le nouvel UUID NBU et le numéro de version une fois le serveur principal NetBackup créé.

Après avoir obtenu l'UUID NBU et le numéro de version, exécutez la commande suivante sur l'hôte NetBackup Snapshot Manager pour mettre à jour le mappage :

/cloudpoint/scripts/cp_update_nbuuid.sh -i <NBU UUID> -v <Version Number>

Le travail de snapshot aboutit, mais le travail de sauvegarde échoue avec l'erreur « Le certificat NetBackup Snapshot Manager n'est pas valide ou n'existe pas. (9866) » lorsque le paramètre ECA_CRL_CHECK est désactivé sur le serveur principal.

Si le paramètre ECA_CRL_CHECK est configuré sur le serveur principal et désactivé, la même valeur doit être définie dans le fichier bp.conf de l'installation de NetBackup Snapshot Manager.

Prenons l'exemple d'une sauvegarde à partir d'un snapshot où le certificat externe utilisé pour la configuration de NetBackup est révoqué. Dans ce cas, si ECA_CRL_CHECK est défini sur DISABLE sur le serveur principal, définissez la même valeur dans le fichier bp.conf de l'installation de NetBackup Snapshot Manager. Si vous ne suivez pas cette procédure, l'opération de snapshot aboutira, mais l'opération de sauvegarde échouera avec l'erreur de certificat.

Se reporter à Configuration de la sécurité pour Azure Stack .

Les opérations cloud NetBackup Snapshot Manager échouent sur un système RHEL si un pare-feu est désactivé

Les opérations NetBackup Snapshot Manager échouent pour tous les plug-ins cloud pris en charge sur un système RHEL si un pare-feu est désactivé sur ce système alors que les services NetBackup Snapshot Manager sont en cours d'exécution. Ce problème de configuration réseau empêche NetBackup Snapshot Manager d'accéder aux terminaux clients d'API REST du fournisseur cloud.

Solution de contournement :

Le travail de sauvegarde à partir d'un snapshot et le travail d'indexation échouent avec les erreurs

Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) SSL
Connection failed with string, broker:<hostname>
Jun 10, 2021 2:17:48 PM - Error mqclient (pid=1054) Failed SSL
handshake, broker:<hostname>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Invalid
operation for asset: <asset_id>
Jun 10, 2021 2:19:16 PM - Error nbcs (pid=29079) Acknowledgement
not received for datamover <datamover_id>

et/ou

Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - Cannot retrieve the exported snapshot details
for the disk with UUID:<disk_asset_id>
Jun 10, 2021 3:06:13 PM - Info bptm (pid=32582) waited for full
buffer 1 times, delayed 220 times
Jun 10, 2021 3:06:13 PM - Critical bpbrm (pid=32373) from client
<asset_id>: FTL - cleanup() failed, status 6

Ce problème peut se produire lorsque l'accès entrant à NetBackup Snapshot Manager sur les ports 5671 et 443 est bloqué au niveau du pare-feu du système d'exploitation (firewalld). La communication entre le conteneur du datamover (utilisé pour les travaux de sauvegarde à partir d'un snapshot et les travaux d'indexation) et NetBackup Snapshot Manager est donc bloquée. Le conteneur du système de déplacement de données ne peut donc pas démarrer la sauvegarde ou l'indexation.

Solution de contournement :

Configurez les règles du pare-feu du système d'exploitation de façon à autoriser la connexion entrante sur les ports 5671 et 443.

La connexion sans agent échoue pour une machine virtuelle avec un message d'erreur.

La connexion sans agent échoue pour une machine virtuelle avec le message d'erreur suivant lorsque l'authentification par clé SSH d'une machine virtuelle est remplacée par une authentification par mot de passe via le portail :

User does not have the required privileges to establish an 
agentless connection

Ce problème se produit lorsque les autorisations ne sont pas correctement définies pour l'utilisateur dans le fichier sudoers, comme indiqué dans le message d'erreur ci-dessus.

Solution de contournement :

Résolvez le problème de fichier sudoers pour l'utilisateur en fournissant les autorisations requises pour exécuter les opérations sudo sans mot de passe.

La fonction NetBackup Snapshot Manager échoue lorsque NetBackup Snapshot Manager est déployé dans un sous-réseau privé (sans Internet)

Ce problème se produit lorsque NetBackup Snapshot Manager est déployé dans un réseau privé dans lequel le pare-feu est activé ou l'adresse IP publique est désactivée. L'équipe en charge de la sécurité des informations du client n'accorde pas à la machine virtuelle un accès complet à Internet.

Solution de contournement :

Activez les ports à partir de la ligne de commande du pare-feu à l'aide des commandes suivantes :

firewall-cmd --add-port=22/tcp

firewall-cmd --add-port=5671/tcp

firewall-cmd --add-port=443/tcp

La restauration d'un bien à partir d'une copie de sauvegarde échoue

Dans certains cas, une réinitialisation intermittente de la connexion se produit dans le conteneur Docker. La charge utile TCP envoyée par le serveur est alors supérieure à ce qu'indique la fenêtre du client. Le conteneur Docker supprime parfois le paquet SYN+ACK du nouveau protocole de connexion TCP. Pour autoriser ces paquets, utilisez l'option nf_conntrack_tcp_be_liberal.

Si nf_conntrack_tcp_be_liberal = 1, les paquets suivants sont autorisés :

Si nf_conntrack_tcp_be_liberal = 0, ils sont également considérés comme non valides et rejetés.

Solution de contournement :

Pour résoudre le problème de la restauration à partir de la copie de sauvegarde, définissez l'option nf_conntrack_tcp_be_liberal = 1 sur le nœud sur lequel s'exécute le conteneur du datamover.

Utilisez la commande suivante pour définir la valeur de nf_conntrack_tcp_be_liberal :

sysctl -w net.netfilter.nf_conntrack_tcp_be_liberal=1

Certains pods de l'extension Kubernetes sont passés à l'état Terminé.

Solution de contournement :

Désactivez l'extension Kubernetes.

Supprimez le pod d'écoute à l'aide de la commande suivante :

#kubectl delete pod flexnsap-listener-xxxxx -n <namespace>

Activez l'extension Kubernetes.

L'utilisateur ne peut pas personnaliser un plan de protection cloud

Solution de contournement :

Créez un plan de protection avec la configuration souhaitée et attribuez-le au bien.

Le délai d'expiration par défaut de 6 heures ne permet pas la restauration d'une base de données de plus de 300 Go

Solution de contournement :

La valeur du paramètre de délai d'expiration configurable peut être définie de façon à permettre la restauration d'une base de données plus volumineuse. La valeur du délai peut être spécifiée dans le fichier /etc/flexsnap.conf du conteneur flexsnap-coordinator. Il n'est pas nécessaire de redémarrer le conteneur de coordination. La valeur du délai d'expiration sera récupérée lors du prochain travail de restauration de la base de données.

L'utilisateur doit spécifier le délai d'expiration en secondes comme suit :

docker exec -it flexsnap-coordinator bash root@flexsnap-coordinator:/# cat /etc/flexsnap.conf [global] target = flexsnap-rabbitmq grt_timeout = 39600

La connexion sans agent et la restauration granulaire sur l'hôte restauré échouent lorsque 50 étiquettes sont associées à la machine virtuelle restaurée à partir d'une sauvegarde

Solution de contournement :

(Pour AWS) Si une machine virtuelle Windows restaurée à partir d'une sauvegarde comporte 50 étiquettes, et si aucune étiquette de plate-forme n'existe, vous pouvez supprimer n'importe quelle étiquette non requise et ajouter l'étiquette Platform: windows.

Pour certaines versions de GKE, des échecs de pod se produisent au niveau de l'espace de noms

Les pods ci-dessous échouent dans l'espace de noms et affichent l'état d'échec NodeAffinity :

$ kubectl get pods -n <cp_extension_namespace>

NAME                                        READY     STATUS       RESTARTS     AGE
flexsnap-datamover-
2fc2967943ba4ded8ef653318107f49c-664tm        0/1     Terminating    0          4d14h
flexsnap-fluentd-collector-c88f8449c-5jkqh    0/1     NodeAffinity   0          3d15h
flexsnap-fluentd-collector-c88f8449c-ph8mx    0/1     NodeAffinity   0          39h
flexsnap-fluentd-collector-c88f8449c-rqw7w    1/1     Running        0          10h
flexsnap-fluentd-collector-c88f8449c-sswzr    0/1     NodeAffinity   0          5d18h
flexsnap-fluentd-ftlnv                        1/1     Running        3 (10h ago)10h
flexsnap-listener-84c66dd4b8-6l4zj            1/1     Running        0          10h
flexsnap-listener-84c66dd4b8-ls4nb            0/1     NodeAffinity   0          17h
flexsnap-listener-84c66dd4b8-x84q8            0/1     NodeAffinity   0          3d15h
flexsnap-listener-84c66dd4b8-z7d5m            0/1     NodeAffinity   0          5d18h
flexsnap-operator-6b7dd6c56c-cf4pc            1/1     Running        0          10h
flexsnap-operator-6b7dd6c56c-qjsbs            0/1     NodeAffinity   0          5d18h
flexsnap-operator-6b7dd6c56c-xcsgj            0/1     NodeAffinity   0          3d15h
flexsnap-operator-6b7dd6c56c-z86tc            0/1     NodeAffinity   0          39h

Cependant, ces échecs n'affectent pas le fonctionnement de l'extension Kubernetes NetBackup Snapshot Manager.

Solution de contournement :

Nettoyez manuellement les pods en échec à l'aide de la commande suivante :

kubectl get pods -n <cp_extension_namespace> | grep NodeAffinity | awk '{print $1}' | xargs kubectl delete pod -n <cp_extension_namespace>

Les informations du plug-in sont dupliquées si des tentatives précédentes d'enregistrement de NetBackup Snapshot Manager ont échoué

Ce problème se produit uniquement lorsque NetBackup Snapshot Manager a été déployé à l'aide du mécanisme de déploiement du marketplace. Lorsque les informations de plug-in sont ajoutées avant l'enregistrement, des informations de plug-in sont créées en double dans le fichier CloudPoint_plugin.conf.

Solution de contournement :

Supprimez manuellement les informations de plug-in en double dans le fichier CloudPoint_plugin.conf.

Dans l'exemple suivant, l'entrée en double pour la configuration du plug-in GCP est visible (en gras) dans le fichier CloudPoint_plugin.conf :

{
    "CPServer1": [
      {
        "Plugin_ID": "test",
        "Plugin_Type": "aws",
        "Config_ID": "aws.8dda1bf5-5ead-4d05-912a-71bdc13f55c4",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  },
  {
    "CPServer2": [
      {
        "Plugin_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Type": "gcp",
        "Config_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
      {
        "Plugin_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Type": "gcp",
        "Config_ID": "gcp.2080179d-c149-498a-bf1f-4c9d9a76d4dd",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  }

Les informations du plug-in sont dupliquées si le NetBackup Snapshot Manager cloné est ajouté à NetBackup

Cela se produit uniquement lorsque le NetBackup Snapshot Manager cloné est ajouté à NetBackup lors de la migration de NetBackup Snapshot Manager vers une machine virtuelle RHEL 8.6. Le clonage de NetBackup Snapshot Manager utilise le volume NetBackup Snapshot Manager existant pour créer un nouveau NetBackup Snapshot Manager, ce qui entraîne la création d'un doublon d'entrée dans le fichier CloudPoint_plugin.conf.

Solution de contournement :

Modifiez et supprimez manuellement les informations de plug-in en double dans le fichier CloudPoint_plugin.conf.

Dans l'exemple suivant, l'entrée en double pour la configuration du plug-in Azure est visible (en gras) dans le fichier CloudPoint_plugin.conf :

{
    "CPServer1": [
      {
        "Plugin_ID": "config10",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  },
  {
    "CPServer2": [
      {
        "Plugin_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
       {
    "cpserver101.yogesh.joshi2-dns-zone": [
      {
        "Plugin_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Type": "azure",
        "Config_ID": "azure.327ec7fc-7a2d-4e94-90a4-02769a2ba521",
        "Plugin_Category": "Cloud",
        "Disabled": false
      },
      {
        "Plugin_ID": "AZURE_PLUGIN",
        "Plugin_Type": "azure",
        "Config_ID": "azure.4400a00a-8d2b-4985-854a-74f48cd4567e",
        "Plugin_Category": "Cloud",
        "Disabled": false
      }
    ]
  }
 ]
}

La sauvegarde à partir d'un snapshot avec la version 10.0 de Snapshot Manager déployée dans Azure échoue en raison d'une erreur de certificat SSL

La sauvegarde à partir d'un snapshot avec la version 10.3 de Snapshot Manager ou une version ultérieure déployée dans Azure échoue en raison d'une erreur de certificat SSL liée à la CRL (cURL).

Solution de contournement :

Ajoutez ECA_CRL_CHECK = 0 dans le fichier bp.conf de Snapshot Manager et assurez-vous que les terminaux clients Azure sont accessibles à partir du serveur de médias.