Recherche dans <book_title>…

Guide de l'administrateur cloud sur l'interface utilisateur Web NetBackup™

Last Published: 2024-11-11

Product(s): NetBackup & Alta Data Protection (10.5)

Limitations et remarques

Lors de la protection de charges de travail PaaS, tenez compte des points suivants :

Pour toutes les bases de données

Le déploiement de NetBackup Snapshot Manager dans RHEL 7.x n'est pas pris en charge pour la protection de biens PaaS.
Les déploiements de NetBackup sous Flex Appliance et Flex Scale ne sont pas compatibles avec les charges de travail PaaS.
La sauvegarde et la restauration ne sont pas prises en charge pour les bases de données dont la connexion à NetBackup nécessite des certificats client.
Seules les instances de charge de travail AWS RDS acceptent les ports personnalisés. Toutes les autres charges de travail acceptent uniquement les ports par défaut.
Les noms de base de données contenant les caractères « # » et « / » ne sont pas pris en charge pour les opérations de sauvegarde et de restauration. En outre, le nom de base de données doit respecter les conventions de nommage suggérées par les fournisseurs cloud.
Le point-virgule (« ; ») n'est pas pris en charge dans les mots de passe de serveur ou de base de données.
La sauvegarde et la restauration d'une base de données contenant des caractères ASCII non codés sur 7 bits ne sont pas prises en charge pour un serveur principal fonctionnant sous Windows ou disposant d'un serveur de médias doté d'une version antérieure à la 10.1.1.
Vous pouvez dupliquer l'image de sauvegarde PaaS sur un serveur de stockage pris en charge. Mais avant de lancer une restauration, vous devez dupliquer l'image sur un serveur MSDP pour lequel le partage universel est activé. Se reporter à Récupération d'images dupliquées à partir d'AdvancedDisk.
NetBackup 10.3 vous permet de sauvegarder et de restaurer des bases de données PaaS Azure prises en charge avec l'authentification de base de données basée sur l'identité gérée. Cette opération n'est pas prise en charge pour le serveur Azure Database for MariaDB. Cette fonction nécessite au moins un serveur de médias doté de la version 10.2 ou d'une version ultérieure.
Pour que l'authentification de bases de données Azure fonctionne sur tous les serveurs de médias, il est recommandé d'utiliser l'identité gérée attribuée par l'utilisateur. Un utilisateur de base de données doté d'une identité gérée attribuée par le système, associée au serveur de médias ou au groupe de machines virtuelles identiques (AKS/EKS), ne peut se servir d'aucun autre serveur de médias ou média appartenant à un autre groupe de machines virtuelles identiques (AKS/EKS).
L'identité gérée par Azure n'est pas prise en charge pour les abonnements rattachés à des locataires différents ou au même locataire.
Pour les biens PaaS, les journaux de récupération ne sont pas disponibles sous Récupération > ID du travail > Journaux. Vous pouvez y accéder à partir du moniteur d'activité ou de l'onglet Activité de restauration, dans les détails des biens.
La restauration des biens PaaS requiert l'autorisation d'affichage pour le serveur de stockage. Si la version du serveur de stockage est antérieure à la 10.2, des autorisations d'affichage et de création pour les partages universels sont également requises.
Si l'utilisateur connecté ne dispose pas d'autorisations d'affichage pour le serveur de stockage, NetBackup tente de récupérer les partages universels existants pendant une restauration. S'il n'existe aucun partage universel, NetBackup en crée un nommé dbpaasrestore pendant la restauration. NetBackup démarre ensuite le travail de récupération.

Pour PostgreSQL

La restauration des privilèges de sécurité n'est pas prise en charge.
Pendant la restauration, vous pouvez utiliser les options - no-owner et - no-privileges. Après la restauration, les métadonnées capturées lors de la sauvegarde sont affichées sous le propriétaire/la liste de contrôle d'accès dans l'activité de restauration du journal de progression sur l'interface utilisateur Web.
La restauration n'échoue pas si le propriétaire ou le rôle n'existe pas à l'emplacement de destination.
Après la restauration, le rôle de la base de données est associé selon les informations d'authentification spécifiées dans NetBackup par rapport à l'instance de destination.
Les utilisateurs doivent modifier la propriété des bases de données après la restauration.
La restauration de base de données Azure Postgres d'un serveur unique vers un serveur flexible, ou inversement, n'est pas prise en charge en raison des limitations du fournisseur cloud.
Le workflow de restauration ne prend pas en charge les caractères suivants dans les noms de base de données : `, @, \, [, ], !, #, %, ^, ., ,, &, *, (, ), <, >, ?, /, |, }, {, ~, :, ', ", ;, +, = et -.
Le nom d'utilisateur en majuscules n'est pas pris en charge pour les nouveaux utilisateurs ajoutés après la création du serveur PostgreSQL.
(RDS et Azure PostgreSQL uniquement) L'authentification SCRAM configurée sur une instance de base de données n'est pas prise en charge.

Pour AWS RDS PostgreSQL et AWS Aurora PostgreSQL

La sauvegarde et la restauration nécessitent un serveur de médias doté de NetBackup 10.4 ou d'une version ultérieure, ainsi qu'une LSU locale.
Si une image de sauvegarde contient une vue matérialisée, vous devez actualiser manuellement la vue matérialisée après la restauration. Pour en savoir plus sur l'actualisation des vues matérialisées, consultez l'article suivant :
https://www.veritas.com/support/en_US/article.100062910
Si les informations d'authentification utilisées pour la restauration sont celles d'un utilisateur IAM, l'objet de base de données est restauré avec la même propriété que dans la base de données source.
La propriété et les privilèges associés à un objet ne sont pas restaurés. L'utilisateur que vous utilisez pour la restauration devient propriétaire de tous les objets de base de données restaurés dans les scénarios suivants :
- Si les informations d'authentification de l'utilisateur restaurées sont le nom d'utilisateur et le mot de passe.
- Si l'image de sauvegarde est créée par une version de NetBackup antérieure à la 10.4.

Pour AWS DynamoDB

La restauration sur un autre client n'est pas prise en charge pour les régions et les comptes.
La restauration d'images importées à partir d'un autre serveur principal est uniquement prise en charge avec l'API REST NetBackup.
L'importation à partir de S3 pendant la restauration est prise en charge avec la version 10.3.1 du serveur de médias ou une version ultérieure. Cette fonction permet d'accélérer la restauration sans faire appel à la capacité d'écriture des tables.
L'importation à partir de S3 ne prend pas en charge la restauration de l'index secondaire local. Cette fonction est activée par défaut.
Pour restaurer l'index secondaire local, sélectionnez l'option Inclure les index secondaires locaux. La restauration peut être plus longue, car cette méthode fait appel à la capacité d'écriture des tables.

Pour AWS RDS SQL

Concernant la validation des informations d'authentification, IAM n'est pas pris en charge pour AWS RDS SQL. Vous pouvez utiliser la méthode avec nom d'utilisateur et mot de passe.
Seul le type de gestion des données Amazon RDS est pris en charge. Le type de gestion des données RDS Custom n'est pas pris en charge pour les éditions d'instance AWS RDS SQL.
Impossible de restaurer les bases de données qui contiennent un groupe de fichiers FILESTREAM.
Impossible de restaurer les bases de données portant le même nom qu'une base de données existante. Les noms de base de données doivent être uniques.
Vous pouvez exécuter jusqu'à deux tâches de sauvegarde ou de restauration simultanément pour une instance RDS SQL spécifique.
RDS SQL prend en charge les restaurations natives de bases de données jusqu'à 16 To. Vous ne pouvez restaurer que 10 gigaoctets de bases de données sur SQL Server Express Edition.
Les sauvegardes natives ne sont pas prises en charge pendant la fenêtre de maintenance ou pendant la création d'un snapshot de la base de données par Amazon RDS SQL. Si une tâche de sauvegarde native chevauche la fenêtre de sauvegarde quotidienne du RDS, la tâche est annulée.
Le certificat TDE de l'instance RDS SQL source doit être présent sur l'instance RDS SQL cible pour effectuer une restauration à un autre emplacement d'une base de données compatible TDE.
Vous pouvez créer des sauvegardes natives de bases de données compatibles TDE, mais vous ne pouvez pas restaurer ces sauvegardes sur des bases de données sur site.

Pour MySQL

L'opération de restauration requiert des privilèges de superutilisateur si le fichier de vidage contient l'instruction CREATE DEFINER pour les sauvegardes effectuées sur une version antérieure à la 10.2.
Les sauvegardes effectuées sur la version 10.3 ou une version ultérieure ne peuvent pas être restaurées à l'aide d'une version antérieure à la 10.2.
La sauvegarde et la restauration ne sont pas prises en charge si seule la connexion SSL s'applique au niveau du serveur pour la charge de travail GCP MySQL.
Vous pouvez restaurer une base de données MySQL vers une autre instance dotée d'une version de MySQL différente de celle de l'instance de sauvegarde, selon la compatibilité de version de MySQL.

Pour des sauvegardes incrémentielles à l'aide du serveur Azure MySQL

Vous pouvez protéger les biens d'un serveur Azure MySQL à l'aide d'un plan de protection et d'une politique. Vous pouvez utiliser des planifications complètes et incrémentielles différentielles au niveau de l'instance. Les bases de données spécifiques peuvent uniquement être protégées à l'aide de la planification complète.
Vous pouvez récupérer des bases de données spécifiques à partir des sauvegardes d'un serveur effectuées sur un autre serveur cible. La restauration échoue si une base de données portant le même nom existe sur le serveur cible.
Actuellement, NetBackup ne restaure pas les utilisateurs et leurs autorisations sur le serveur cible. Tous les objets de base de données sont récupérés avec les mêmes utilisateurs que dans la base de données source au moment de la sauvegarde. Vous pouvez créer des utilisateurs et accorder les autorisations nécessaires après la restauration.
Les enregistrements dans les tables créées avec le type de moteur de stockage MEMORY ne sont pas sauvegardés dans le cadre d'une planification incrémentielle. Ces enregistrements sont conservés dans la mémoire et les modifications apportées à ces tables ne figurent pas dans les journaux binaires.
NetBackup effectue une sauvegarde complète dans le cadre d'une planification incrémentielle dans les scénarios suivants :
- Un ou plusieurs journaux binaires sur le serveur sont purgés entre deux sauvegardes incrémentielles. Assurez-vous que le paramètre binlog_expire_logs_seconds est défini sur la valeur appropriée en fonction de la fréquence de la planification incrémentielle.
- Si vous modifiez le schéma d'une ou plusieurs bases de données sur un serveur et que vous effectuez une action de langage de définition de données (DDL) sur l'une de ces bases de données.
- Une ou plusieurs bases de données sont ajoutées au serveur ou supprimées de celui-ci.
- Si le serveur est configuré en mode haute disponibilité et qu'un basculement se produit sur le serveur.
- Si le nombre maximal de points de récupération incrémentiels (100) du bien est atteint dans le cadre de la politique ou du plan de protection abonné.

Pour GCP SQL Server

La sauvegarde et la restauration de bases de données en lecture seule ne sont pas prises en charge.
Les informations d'authentification du fournisseur sont validées pour la sauvegarde complète et la restauration, non comme informations d'authentification de base de données.
La sauvegarde et la restauration de bases de données en mode utilisateur unique ne sont pas prises en charge.
Lorsqu'une opération est en cours, les travaux suivants sont placés dans la file d'attente. Si l'exécution du travail en cours prend du temps, les travaux présents dans la file d'attente peuvent expirer et échouer.

Pour des sauvegardes incrémentielles à l'aide de GCP SQL Server

Suite à une modification apportée à la DML, les sauvegardes incrémentielles peuvent échouer lorsqu'une table est renommée après l'activation de la capture des données modifiées dans la table. Pour contourner ce problème, vous devez modifier manuellement tous les objets qui référencent la table renommée. Par exemple, si vous renommez une table qui est référencée dans un déclencheur, vous devez modifier ce déclencheur pour qu'il contienne le nouveau nom de la table. Pour répertorier les dépendances dans la table avant de la renommer, consultez la documentation Azure.
La sauvegarde et la restauration de bases de données contenant des données binaires ou d'images ne sont pas prises en charge. Les insertions en bloc sur Cloud SQL Server requièrent une autorisation sysadmin non fournie par GCP.
Lors de la duplication de sauvegardes incrémentielles sur différents serveurs de stockage, NetBackup génère différents numéros de copie pour le même point de récupération. Si vous tentez de restaurer une copie incrémentielle ne contenant aucune sauvegarde complète ou incrémentielle, l'opération risque d'échouer.
Si vous disposez de plusieurs serveurs de médias, les sauvegardes incrémentielles peuvent s'exécuter uniquement avec la version 10.3 ou une version ultérieure.
Les bases de données système et le schéma de la capture des données modifiées sont sauvegardés et restaurés sur la base de données cible.
Vous devez définir pour la capture des données modifiées une période de conservation supérieure à la période de planification de la fréquence des sauvegardes incrémentielles.
Les sauvegardes incrémentielles des bases de données comportant plusieurs tables peuvent être plus longues, car l'activation de la capture des données modifiées pour plusieurs tables prend plus de temps.
Les sauvegardes incrémentielles ne sont pas prises en charge pour les éditions Web et Express des bases de données.
Toute tentative d'activation de la capture des données modifiées échoue si la base de données contient déjà un schéma personnalisé ou une capture des données modifiées nommée par l'utilisateur.
Pour assurer la cohérence au niveau application, NetBackup utilise la sauvegarde complète précédente et toutes les sauvegardes incrémentielles suivantes.Si une image de sauvegarde quelconque est expirée, cela peut entraîner une incohérence au niveau application en raison de la perte de données.
La capture des données modifiées requiert les éditions Standard ou Enterprise de SQL Server. Si une base de données est connectée ou restaurée avec l'option KEEP_CDC vers une édition différente de Standard ou Enterprise, la sauvegarde échoue. Le message d'erreur 932 s'affiche alors.

Pour Azure SQL et SQL Managed Instance

Une machine virtuelle Azure utilisée comme serveur de médias doit appartenir au même réseau virtuel (Vnet) que celui de l'instance gérée par Azure. Autrement, si le serveur de médias et l'instance gérée par SQL sont dans un Vnet différent, les deux Vnets doivent être configurés comme pairs pour accéder à l'instance de base de données.
Échec de la sauvegarde lorsqu'un Readlock est placé sur la base de données ou le groupe de ressources.
NetBackup crée une base de données temporaire dans l'instance SQL protégée à l'aide d'un point de récupération SQL Azure à un moment précis afin de disposer d'une base de données intermédiaire en lecture seule et cohérente à des fins de sauvegarde. La prise en charge de la base de données temporaire par NetBackup nécessite de l'espace supplémentaire sur l'instance. La base de données temporaire est de la même taille que la base de données protégée.
La sauvegarde aboutit partiellement lorsqu'un verrou de suppression est appliqué à la base de données ou au groupe de ressources.
NetBackup effectue le nettoyage des bases de données temporaires une fois les sauvegardes terminées. Si un verrouillage de suppression est associé à la base de données ou au groupe de ressources résidant sur le serveur, NetBackup ne peut pas supprimer la base de données temporaire, ce qui entraîne la réussite partielle de la sauvegarde. Ces bases de données temporaires obsolètes occupent de l'espace sur l'instance gérée par Azure et peuvent entraîner des échecs de sauvegarde si l'espace sur l'instance est insuffisant. Dans un tel scénario, assurez-vous qu'aucun travail de sauvegarde NetBackup n'est en cours d'exécution pour cette instance avant de nettoyer manuellement la base de données temporaire.
Avant de lancer la restauration d'une base de données sur un serveur Azure SQL ou sur Azure Managed Instance, vous devez attribuer le privilège d'administrateur AAD sur le serveur cible. Avant la restauration, accordez les droits à l'un des éléments suivants :
- L'identité gérée par le système ou par l'utilisateur des serveurs de médias.
- Le groupe de machines virtuelles identiques dans lequel le média NetBackup est déployé (dans le cas d'un déploiement AKS ou EKS).

Pour une sauvegarde incrémentielle Azure SQL Server et SQL Managed Instance

Vous pouvez activer la capture des données modifiées uniquement sur les niveaux de bases de données S3 et supérieurs. Cette fonctionnalité n'est pas prise en charge pour les bases de données Azure SQL Server et SQL Managed Instance de type sous-cœur (bases de données de base, S0, S1 et S2).
Des problèmes de sauvegarde ou de restauration peuvent se produire pour les bases de données dont la table contient des colonnes chiffrées. Pour contourner le problème, Microsoft suggère d'utiliser les commandes Publish/Extract.
La restauration peut échouer pour les bases de données dont la table contient des données d'objet blob.
Pour dupliquer des sauvegardes incrémentielles sur différents serveurs de stockage, NetBackup génère différents numéros de copie pour le même point de récupération. Si vous tentez de restaurer une copie incrémentielle ne contenant aucune référence antérieure à une sauvegarde complète ou incrémentielle, l'opération échoue.
Remarque :
Les sauvegardes incrémentielles d'Azure SQL Server peuvent s'exécuter uniquement sur un serveur de médias doté de NetBackup 10.2 ou d'une version ultérieure. Les sauvegardes incrémentielles d'Azure SQL Managed Instance peuvent s'exécuter uniquement sur un serveur de médias doté de NetBackup 10.3 ou d'une version ultérieure.
L'ID d'utilisateur utilisé pour le service cloud doit être autorisé à activer et à désactiver la capture des données modifiées. Sans cette autorisation, vous risquez de rencontrer ces types d'erreurs :
```
3842: "Failed to enable CDC" 
and
3844: "Failed to disable CDC"
```
Toute tentative d'activation de la capture des données modifiées échoue si la base de données contient un schéma personnalisé ou un utilisateur nommé cdc. L'utilisation du terme cdc est réservée au système.
Dans une base de données dotée d'un schéma de capture des données modifiées créé avant la première sauvegarde complète, ce schéma n'est pas sauvegardé ni restauré.
Si vous effectuez une restauration vers une édition autre que l'édition Standard ou Enterprise, l'opération est bloquée, car la capture des données modifiées requiert l'une de ces éditions de SQL Server. Le message d'erreur 932 s'affiche.
Évitez de sauvegarder des bases de données contenant des tables de données d'objet BLOB. Si une table contient des données d'objet BLOB, la sauvegarde peut aboutir, mais la restauration échoue.
Le paramètre de chiffrement d'une base de données Azure SQL Server ou Azure SQL Managed Instance ne peut pas être préservé (Is_encryption=0) pendant une restauration.

Pour Azure Cosmos DB for MongoDB

La découverte, la protection et la restauration ne sont pas prises en charge si le compte est configuré à l'aide du cluster vCore.
La sauvegarde et la restauration ne sont pas prises en charge si le compte est configuré avec une clé personnalisée.
NetBackup ne prend pas en charge la version 3.2 d'Azure Cosmos DB for MongoDB.
L'option Ecraser la base de données existante n'est pas prise en charge.
Règles d'attribution de nom des bases de données :
- La longueur des noms de base de données doit être comprise entre 3 et 63 caractères.
- Les noms de base de données prennent en charge tous les caractères, excepté les suivants : #, /, ?,&, <, >, =, }, $, {, ], [, ", ', ., \ .

Pour Azure Cosmos DB for NoSQL

La sauvegarde et la restauration ne sont pas prises en charge si le compte est configuré avec une clé personnalisée.
La protection de Azure Cosmos DB for MongoDB version 3.2 n'est pas prise en charge.
L'option Ecraser la base de données existante n'est pas prise en charge.
Règles d'attribution de nom des bases de données :
- La longueur des noms de base de données doit être comprise entre 3 et 63 caractères.
- Les noms de base de données prennent en charge tous les caractères, excepté les suivants : #, /, ?,&, <, >, =, }, $, {, ], [, ", ', ., \ .

Pour Amazon RDS for Oracle

La sauvegarde et la restauration prennent en charge les protections complètes, incrémentielles différentielles et de journaux redo d'archive.
Oracle 21c et 19c CDB sont pris en charge. La version 19c non-CDB est également prise en charge.
Les bases de données CDB avec des bases de données de conteneurs multi et mono-locataires et les bases de données non CDB sont prises en charge.
Les éditions Enterprise et Standard sont prises en charge.
La sauvegarde et la restauration sont prises en charge pour S3 avec le chemin d'accès intermédiaire.
La sauvegarde et la restauration ne sont pas prises en charge pour les instances ou les répliques de lecture RDS Oracle pour lesquelles la fonction TDE est activée.
Concernant la validation des informations d'authentification, IAM n'est pas pris en charge pour AWS RDS Oracle. Vous pouvez utiliser la méthode avec nom d'utilisateur et mot de passe.
Le groupe d'options associé à RDS Oracle doit présenter la même version et le même nom de moteur de base de données.
La restauration est prise en charge vers l'emplacement intermédiaire S3 uniquement, y compris la récupération manuelle à partir de l'onglet Base de données à accès instantané.
Seul le type de gestion des données Amazon RDS est pris en charge. Le type de gestion des données RDS Custom n'est pas pris en charge.
Si l'intégration de S3 n'est pas configurée ou si la configuration de S3 échoue, une sauvegarde revient à l'EFS dans la version 19c uniquement, à condition que l'EFS soit configuré.
Veillez à supprimer l'entrée d'ID d'EFS du groupe d'options avant de supprimer cet EFS.
Avant d'exécuter la sauvegarde des journaux d'archive, définissez la période de conservation dans le plan de protection. Consultez l'article suivant de la base de connaissances : https://www.veritas.com/support/en_US/article.100059038
N'effectuez pas de sauvegardes externes à l'aide des API RDS rman sur l'instance pour préserver la cohérence des données.
Le script de récupération prend en charge EC2 ou les machines virtuelles sur site.
NetBackup applique des sauvegardes complètes dans les trois cas suivants :
- En cas d'annulation ou d'échec d'une sauvegarde. NetBackup suit ces événements grâce à un indicateur dans le fichier d'état DBPaaS précédent.
- Si la première sauvegarde planifiée est une sauvegarde incrémentielle ou de journaux d'archive.
- Si vous dépassez la valeur de seuil de sauvegardes incrémentielles ou d'archive. La valeur de seuil se rapporte au nombre de points de récupération des sauvegardes incrémentielles et de journaux d'archive.

Pour les bases de données Amazon Redshift

Les restaurations de bases de données Redshift vers d'autres régions ou d'autres comptes ne sont pas prises en charge.
Le mode FIPS n'est actuellement pas pris en charge pour les bases de données Redshift.
Seules les bases de données utilisateur sont protégées. Les bases de données système ne sont pas affichées ou protégées.
La restauration d'images importées à partir d'un autre serveur principal est prise en charge uniquement à l'aide de l'API REST NetBackup.
Seuls les clusters Redshift sont pris en charge. Redshift sans serveur n'est pas pris en charge.
Avant de démarrer une sauvegarde de la base de données, le cluster Redshift doit être à l'état disponible.
Les tables dont les noms sont sensibles à la casse et contiennent des guillemets doubles ne sont pas restaurées.
Lors de la restauration, le nombre total de fichiers sauvegardés peut afficher un fichier en moins par rapport au nombre réel.
Il est déconseillé de sauvegarder des bases de données dont les tables sont vides.
NetBackup assure une protection en mode cohérence d'incident des données Redshift. Tenez compte du type d'activité et des conditions d'application avant d'effectuer des sauvegardes pour déterminer si ces opérations nécessitent la vérification ou la suspension d'une application.

Pour les clusters Amazon Redshift

NetBackup 10.5 est la version minimum requise pour les serveurs principaux, de médias et de gestion de snapshots.
Le mode FIPS n'est actuellement pas pris en charge pour les clusters Redshift.
Les clusters Redshift créés avec des informations d'authentification AWS Secrets Manager ne sont pas pris en charge.
Les restaurations de clusters Redshift vers d'autres régions ou d'autres comptes ne sont pas prises en charge.
Avant de déclencher un snapshot de cluster, le cluster Redshift doit être à l'état disponible.
Un travail de restauration de cluster peut rapidement afficher un état de réussite dans le moniteur d'activité, même s'il est encore en cours. Surveillez le travail de restauration de cluster dans votre console AWS pour connaître l'état réel du travail.
Chaque cluster Redshift peut compter 20 snapshots manuels maximum.
Pendant la restauration, la propriété PubliclyAccessible du cluster restauré est définie sur False. Vous pourrez la modifier manuellement si nécessaire après la restauration.
Ne déclenchez pas l'expiration d'images NetBackup pour des images de snapshot de cluster Redshift en cours de restauration. Si des travaux automatisés d'expiration d'images sont exécutés en même temps qu'une restauration, le nettoyage du snapshot sur le portail AWS échouera.
Le moniteur d'activité NetBackup n'affiche pas les valeurs des paramètres de snapshot suivants : Octets transférés, Fichiers écrits, Fichier actuel, Estimation des fichiers restants et Fichiers estimés.

Pour GCP BigQuery

Les utilisateurs de projet GCP et leurs autorisations ne sont pas restaurés. Le propriétaire du jeu de données restauré est le principal de service GCP configuré dans NetBackup lors de l'ajout du fournisseur cloud.
La limite maximale d'exportation de données est de 50 To par jour et par projet.
Les étiquettes associées aux jeux de données et aux tables ne sont pas restaurées.
Les jeux de données créés pour plusieurs régions (États-Unis, UE) ne sont pas pris en charge.
L'exportation de type de données RANGE n'est pas prise en charge par l'API d'exportation GCP.
Les jeux de données liés ne sont ni découverts, ni sauvegardés, ni restaurés.
Les enregistrements avec le type de données DATETIME dans les tables ne sont pas pris en charge pour la sauvegarde.
NetBackup ne sauvegarde pas les tables sans colonne ou sans schéma.
Les sauvegardes des tables avec contrôle d'accès au niveau des colonnes ou avec sécurité au niveau des lignes ne sont pas prises en charge.