Guide de référence des codes d'état NetBackup™
- Codes d'état NetBackup
- Codes d'état NetBackup
- Codes d'état de KMS NetBackup
- Codes d'état NetBackup
- Codes d'état Media Manager
- Codes d'état Media Manager
- Codes d'état Media Manager
- Codes d'état de configuration de périphérique
- Codes d'état de configuration de périphérique
- Codes d'état de configuration de périphérique
- Codes d'état de gestion de périphérique
- Codes d'état de gestion des périphériques :
- Codes d'état de gestion des périphériques :
- Codes d'état robotique
- Codes d'état robotique
- Codes d'état robotique
- Codes d'erreur robotique
- Codes d'erreur robotique
- Codes d'erreur robotique
- Codes d'état des services de sécurité
- Codes d'état des services de sécurité
- Codes d'état des services de sécurité
- Codes d'état de notification d'alerte de NetBackup
Code d'état NetBackup : 8453
Explication: le travail de migration s'exécute avant le déploiement principal et après configChecker lorsque la classe de stockage est renommée dans le fichier environment.yaml
. Ce travail de migration n'a pas été créé dans le cluster.
Action recommandée: procédez comme suit, selon le cas :
Consultez les journaux de NetBackup Operator à l'aide de la commande suivante pour en savoir plus :
kubectl logs <netbackup-operator-pod-name> netbackup-operator -n<netbackup-operator-namespace>
Vérifiez que les autorisations RBAC sont correctes pour le travail. Consultez le Guide de l'administrateur du déploiement de NetBackup pour un cluster Azure Kubernetes (AKS).
Si le problème concerne la ressource personnalisée du serveur principal, procédez comme suit :
Supprimez la ressource personnalisée de l'environnement à l'aide de la commande kubectl delete -f <environment.yaml>.
Redéployez l'environnement à l'aide de la commande kubectl apply -f <environment.yaml>.
Si ce problème se produit pendant la migration des données, procédez comme suit :
Consultez les journaux du pod de migration à l'aide de la commande kubectl logs <catalog-or-log-migration-job-name> -n <netbackup-environment-namespace> pour plus d'informations :
Si le pod de l'opérateur NetBackup contient l'un des messages suivants :
Erreur lors de l'obtention de la demande PVC de changement de nom.
Erreur lors de la suppression de l'ancienne demande PVC.
Erreur lors de l'application d'un correctif sur l'ancienne demande PVC.
Erreur lors du renommage des journaux de la demande PVC.
Erreur lors du renommage du catalogue de la demande PVC.
Effectuez les étapes suivantes :
Copiez ou ignorez manuellement les fichiers, ou passez aux étapes suivantes.
Enregistrez le nom de volume et la classe de stockage de la demande de volume persistant comme suit :
kubectl describe pvc <azure-disk- or-files-pvc-name> -n <netbackup-environment-namespace>
Supprimez l'ancienne demande de volume persistant de disques ou fichiers Azure et attribuez à la nouvelle demande le nom de l'ancienne, comme suit :
kubectl delete pvc <azure-disk-or-files-pvc-name> -n <netbackup-environment-namespace> kubectl patch pv <saved_volume_name> --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'
Assurez-vous que le volume persistant est disponible à l'issue des étapes précédentes.
Créez une nouvelle demande de volume persistant de fichiers Azure avec l'ancien volume persistant comme suit :
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: <old_pvc_name> namespace: <old_pvc_namespace> spec: accessModes: - ReadWriteMany volumeName: <saved_volume_name> storageClassName: <saved_storage_class_name> resources: requests: storage: 100Gi #previous files size
Activez les sondes /opt/veritas/vxapp-manage/nb-health enable.
Définissez le nombre de répliques sur 1 ou réappliquez le fichier
environment.yaml
comme suit :kubectl scale --replicas=1 <STS name> -n <netbackup-environment-namespace> ou réappliquez le fichier
environment.yaml
.
Cliquez ici pour afficher les notes techniques et d'autres informations disponibles sur le site Web Support technique de Veritas au sujet de ce code d'état.