Guide de l'administrateur cloud sur l'interface utilisateur Web NetBackup™
- Gestion et protection des biens dans le cloud
- Configurer Snapshot Manager dans NetBackup
- Gestion de groupes intelligents pour les objets cloud
- Protection de biens cloud ou de groupes intelligents pour les biens cloud
- À propos de la protection des ressources Microsoft Azure au moyen de groupes de ressources
- À propos de l'accélérateur NetBackup pour les charges de travail cloud
- Protection des biens PaaS
- Installation des utilitaires client natifs
- Configuration du stockage pour différents déploiements
- Ajout d'informations d'authentification à une base de données
- Récupération des biens cloud
- Exécution d'une restauration granulaire
- Résolution des problèmes liés à la protection et à la récupération des biens dans le cloud
- Résolution des problèmes de protection et de récupération de charge de travail PaaS
Résolution des problèmes de protection et de récupération de charge de travail PaaS
Le message suivant s'affiche dans le moniteur d'activité :
AuthorizationFailed -Message: The client '<clientId> '<objetId>' does not have authorization to perform action 'Microsoft.Sql/servers/databases/read' over scope '<resoourceId>' or the scope is invalid. Si l'accès a été récemment accordé, actualisez vos informations d'authentification.
Explication : cette erreur se produit lorsque le gestionnaire de snapshots et NetBackup sont déployés dans AKS et :
Le pool de nœuds de pod de serveur de médias est un pool de nœuds différent du pool de nœuds du gestionnaire de snapshots.
L'identité gérée est activée dans le groupe de machines virtuelles identiques du gestionnaire de snapshots.
Solution de contournement : effectuez l'une des opérations suivantes :
Dans le serveur de médias utilisé pour la sauvegarde et la restauration, activez l'option Identité gérée dans le groupe identique. Assignez également l'autorisation requise au rôle associé à cette identité gérée.
Créez une unité de stockage sur le serveur MSDP et utilisez uniquement les serveurs de médias pour lesquels la fonction Identité gérée est activée lors de la configuration du groupe identique.
Explication: ce problème se produit si l'attribut de verrouillage en lecture seule ou de suppression du verrouillage est appliqué à la base de données ou au groupe de ressources.
Solution de contournement : avant d'effectuer une sauvegarde ou une restauration, supprimez tous les attributs de verrouillage en lecture seule et de suppression du verrouillage existants de la base de données ou du groupe de ressources.
Explication : cette erreur s'affiche lorsque vous annulez manuellement un travail de sauvegarde ou de restauration à partir du moniteur d'activité et qu'une base de données est créée sur le portail pendant l'opération de restauration partielle.
Solution de contournement : nettoyez manuellement la base de données sur le portail du fournisseur et l'emplacement intermédiaire temporaire à l'emplacement de montage du partage universel sous un répertoire spécifique créé avec le nom de la base de données.
Explication : si le service de conteneur Snapshot Manager redémarre brusquement, les travaux de restauration protégés par le fournisseur peuvent rester actifs, et l'état mis à jour ne s'affichera pas sur la page de détails du moniteur d'activité.
Solution de contournement : redémarrez les conteneurs du workflow à l'aide de la commande suivante dans le Snapshot Manager :
docker restart flexsnap-workflow-system-0-min flexsnap-workflow-general-0-min
Après le redémarrage des conteneurs, les travaux de restauration sont mis à jour en fonction du dernier état connu du moniteur d'activité.
Explication : cette erreur s'affiche si le nom de client utilisé pour la sauvegarde contient plus de 255 caractères.
Le message d'erreur suivant est également ajouté au journal bpdbm
:
db_error_add_to_file: Length of client is too long. Got 278, but limit is 255. read_next_image: db_IMAGEreceive() failed: text exceeded allowed length (225)
Remarque :
Ce problème survient lorsque le serveur principal exécute RHEL.
Solution de contournement : renommez la base de données de sorte que le nom du client ne contienne pas plus de 255 caractères.
Ou,
Explication : ce problème se produit lors de la sauvegarde si la longueur du préfixe de la politique défini lors de la création du plan de protection dépasse la limite autorisée. Dans ce cas, le chemin d'accès au fichier de l'image de catalogue contient plus de 256 caractères, la sauvegarde échoue donc et le message d'erreur ci-dessus s'affiche dans le moniteur d'activité.
Le message d'erreur suivant est également ajouté au journal bpdbm
:
<16> db_error_add_to_file: cannot stat(\\?\C:\Program Files\Veritas \NetBackup\db\images \azure-midb-1afb87487dc04ddc8fafe453dccb7ca3+ nbux-qa-bidi-rg+eastus+az-sql-mi-bidinet01+ testdb_bidinet02\1656000000\tmp\catstore\ BACKUPNOW+141a73e7-cdc4-4371-823a-f170447dba2d_ 1656349831_FULL.f_imgUserGroupNames0): No such file or directory (2) <16> ImageReadFilesFile::get_file_size: cannot stat(\\?\C:\Program Files\Veritas\NetBackup\db \images\azure-midb-1afb87487dc04ddc8fafe453d ccb7ca3+nbux-qa-bidi-rg+eastus+az-sql-mi-bidinet01+testdb_ bidinet02\1656000000\tmp\catstore\BACKUPNOW+141a73e7-cdc4-4371 -823a-f170447dba2d_1656349831_FULL.f_imgUserGroupNames0): No such file or directory (2) <16> ImageReadFilesFile::executeQuery: Cannot copy \\?\C:\Program Files\Veritas\NetBackup\db\images\azure-midb-1afb87487dc04ddc8fafe453dccb7 ca3+nbux-qa-bidi-rg+eastus+az-sql-mi-bidinet01+testdb_bidinet02\1 656000000\tmp\catstore\BACKUPNOW+141a73e7-cdc4-4371-823a-f170447d ba2d_1656349831_FULL.f_imgUserGroupNames0
Remarque :
Ce problème survient lorsque le serveur principal exécute Windows.
Solution de contournement : dans le plan de protection, utilisez un nom de préfixe de politique comprenant moins de 10 caractères, de sorte que le chemin d'accès complet du catalogue comprenne moins de 256 caractères.
Explication : NetBackup n'est pas en mesure d'exécuter correctement l'opération demandée.
Action recommandée : consultez les détails du moniteur d'activité pour identifier les causes possibles de la défaillance.
Explication : le message d'erreur s'affiche dans les journaux dbagentsutil
comme pg_dump: error: query failed: ERROR: permission denied for table test;pg_dump: error: query was: LOCK TABLE public.test IN ACCESS SHARE MODE;Invoked operation: PRE_BACKUP failed
Cela se produit lorsque vous tentez de sauvegarder une base de données comprenant plusieurs tables avec différents rôles. La sauvegarde peut échouer si au moins un propriétaire des tables est différent du propriétaire de la base de données et que cette personne n'est pas membre du rôle de propriétaire de la base de données.
Action recommandée : vous devez disposer d'un rôle ayant accès à toutes les tables de la base de données à sauvegarder ou à restaurer.
Par exemple, si vous souhaitez sauvegarder la base de données Scolaire
qui contient deux tables :
enfants
, dont le propriétaire estpostgres
professeur
, dont le propriétaire estadminscolaire
Créez un rôle. Par exemple, NBUbackupadmin
.
Exécutez la commande suivante pour créer le rôle :
postgres=> CREATE USER NBUbackupadmin WITH PASSWORD '***********';
CREATE ROLE
Pour faire de ce nouveau rôle un membre des rôles postgres
et adminscolaire
, exécutez la commande suivante :
postgres=> GRANT postgres TO NBUbackupadmin;
GRANT ROLE
postgres=> GRANT schooladmin TO NBUbackupadmin;
GRANT ROLE
Remarque :
Vous devez disposer d'un rôle qui est soit propriétaire, soit un membre du rôle de propriétaire de la table, pour toutes les tables de la base de données.
Explication : les sauvegardes échouent en raison de la perte de connexion au serveur de médias.
Action recommandée : vous pouvez redémarrer le travail de sauvegarde si des points de contrôle sont activés dans la politique. Une fois le problème réseau résolu, sélectionnez le travail de sauvegarde inachevé dans l'interface utilisateur Web et cliquez sur . Le travail reprend à partir du point où il a été arrêté. Si le point de contrôle n'est pas activé dans la politique, le travail s'affiche comme ayant échoué dans l'interface utilisateur Web.
Explication : les détails du travail contiennent des informations supplémentaires : authentification ManagedIdentityCredential non disponible. L'identité demandée n'est pas assignée à cette ressource. Aucune identité gérée n'est associée au serveur de médias alloué.
Action recommandée : si vous utilisez l'identité gérée par le système ou par l'utilisateur pour les services PaaS Azure SQL et Managed Instance, appliquez le même ensemble d'autorisations/de règles au(x) serveur(s) de médias et au Snapshot Manager. Si vous utilisez une identité gérée par l'utilisateur, associez la même identité gérée par l'utilisateur aux serveurs de médias et à Snapshot Manager.
La sauvegarde incrémentielle différentielle est prise en charge uniquement pour Azure SQL Server et Azure SQL Managed Instance. Cette erreur se produit lorsque vous sélectionnez un type de sauvegarde non pris en charge.
Cette erreur se produit lorsque vous n'êtes pas autorisé à activer ou désactiver la capture des données modifiées.
Solution de contournement : accordez à NetBackup les autorisations nécessaires pour activer ou désactiver la capture des données modifiées dans votre environnement Azure.
Remarque :
N'activez pas la capture des données modifiées manuellement. Accordez à NetBackup les autorisations nécessaires pour activer ou désactiver la capture des données modifiées.
Explication : cette erreur se produit lors de la restauration si l'image de sauvegarde a été générée sur un média 10.2 et que la restauration est effectuée vers un serveur de médias plus ancien (version antérieure à la 10.2).
Solution de contournement : mettez à niveau le média de restauration vers la version 10.2 et supprimez l'ancien média du stockage.
Explication : actuellement, la réponse de l'API AWS ne s'affiche pas si la mise à l'échelle automatique est activée pour une table. Ainsi, pendant la sauvegarde, ces métadonnées ne sont pas capturées dans NetBackup et, par conséquent, la mise à l'échelle automatique n'est pas activée pour la table restaurée.
Solution de contournement : activez manuellement la propriété de mise à l'échelle automatique de la table DynamoDB restaurée dans le portail AWS.
Explication : Azure SQL MI met à jour les détails de la base de données compatible avec la capture des données modifiées dans la table cdc_jobs
du schéma msdb
. Lorsque la base de données est abandonnée, son entrée cdc_jobs
doit être supprimée. Parfois, cette entrée n'est pas supprimée de la table de cdc_jobs
. De ce fait, lorsqu'une nouvelle base de données est créée avec le même db_id
qui existe déjà dans la table de cdc_jobs
, le problème se produit.
Solution de contournement : lorsque vous abandonnez une base de données, vérifiez l'entrée correspondante dans la table cdc_jobs
du schéma msdb
. Si l'entrée y est présente, supprimez-la manuellement.
Explication : une défaillance des API RDS boto3 entraîne l'affichage de cette erreur. NetBackup affiche cette erreur pour l'opération DescribeDBInstances.
Solution de contournement : synchronisez la date et l'heure du serveur de médias avec la date et l'heure réelles du réseau.
Vérifiez également que vous utilisez les bonnes informations d'authentification du fournisseur.
Explication : l'opération d'importation sur le domaine cible peut échouer avec le code d'état 191 : Aucun traitement d'image n'a abouti
. Le message suivant s'affiche dans le moniteur d'activité : Echec de la création de la charge utile JSON
.
Cause : l'image que vous répliquez vers le domaine cible est créée à partir d'un serveur de médias NetBackup 10.4 ou version antérieure qui ne contient pas les métadonnées requises dans le catalogue NetBackup.
Solution de contournement : effectuez l'une des opérations suivantes :
Utilisez une version de serveur de médias ultérieure à la 10.4 pour utiliser la fonction AIR pour les charges de travail PaaS.
Installez EEB sur un serveur de médias 10.4 afin de l'utiliser comme serveur de médias de version antérieure pour la fonction AIR pour les charges de travail PaaS. Pour en savoir plus, contactez le support Veritas.