Guide de l'administrateur cloud sur l'interface utilisateur Web NetBackup™
- Gestion et protection des biens dans le cloud
- Configuration de Snapshot Managers dans NetBackup
- Ajout d'un fournisseur cloud pour Snapshot Manager
- Gestion des groupes cloud intelligents
- Protection des biens ou des groupes cloud intelligents
- À 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 objets PaaS
- Conditions préalables pour la protection des biens PaaS
- Installation des utilitaires client natifs
- 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
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 que vous utilisez pour la sauvegarde et la restauration, activez l'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 l'option 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 le 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é aux journaux 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.
Explication : ce problème se produit lors de la sauvegarde si le nom de client utilisé est long, car le chemin d'accès au fichier de l'image de catalogue contient plus de 256 caractères. La sauvegarde échoue et le message d'erreur ci-dessus s'affiche dans le moniteur d'activité.
Le message d'erreur suivant est également ajouté aux journaux 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 : renommez la base de données de sorte que le chemin d'accès au fichier ne contienne pas plus 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 la cause possible du problème.
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 essayez de sauvegarder une base de données qui a plusieurs tables avec différents rôles. Si les tables ont au moins un propriétaire différent du propriétaire de la base de données et qu'il n'est pas membre du rôle de propriétaire de la base de données, la sauvegarde peut échouer.
Action recommandée : vous devez disposer d'un rôle qui a accès à toutes les tables de la base de données que vous voulez sauvegarder ou restaurer.
Par exemple, imaginons que vous vouliez 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 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.