Guide de l'administrateur cloud sur l'interface utilisateur Web NetBackup™
- Gestion et protection des biens dans le cloud
- À propos de la protection des biens cloud
- Restrictions et remarques
- Prise en charge des services cloud AWS et Azure Government
- 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 des politiques de cycle de vie du stockage
- Gestion des politiques relatives aux biens cloud
- Limites et remarques
- Planification de politiques
- Création de politiques relatives aux biens cloud
- Configuration des attributs pour les biens PaaS
- Configuration des attributs pour les biens IaaS
- Création de planifications
- À propos de la fréquence de sauvegarde
- À propos de l'assignation de périodes de conservation
- Configuration de la fenêtre de démarrage
- Configuration des dates d'inclusion
- Configuration des dates d'exclusion
- Configuration des biens cloud pour PaaS
- Configuration des biens cloud pour IaaS
- Configuration des options de sauvegarde pour IaaS
- Gestion des politiques cloud
- Analyse antimalware
- Protection des ressources Microsoft Azure à l'aide de groupes de ressources
- Accélérateur NetBackup pour les charges de travail cloud
- Configuration de planifications de sauvegarde pour les charges de travail cloud à l'aide d'un plan de protection
- Options de sauvegarde des charges de travail cloud
- Réplication de snapshot AWS
- Protection d'applications sur le cloud avec des snapshots cohérents au niveau application
- Protection de machines virtuelles AWS ou Azure pour la récupération sur VMware
- Nettoyage des biens cloud
- Filtrage des biens cloud
- Protection des biens PaaS
- Protection des biens PaaS
- Étapes pour protéger les biens PaaS
- Conditions préalables pour la protection des biens PaaS
- Activation de la consignation binaire pour les bases de données MySQL et MariaDB
- Activation de la sauvegarde et de la restauration dans Kubernetes
- Conditions préalables à la protection des biens de base de données Amazon RDS SQL Server
- Protection des instances RDS Custom
- Protection des bases de données Azure Managed Instance
- Conditions préalables à la découverte au niveau de la base de données
- Limites et remarques
- Pour toutes les bases de données
- Pour PostgreSQL
- Pour les sauvegardes incrémentielles Azure PostgreSQL
- Pour Amazon RDS PostgreSQL et Amazon Aurora PostgreSQL
- Pour Amazon DynamoDB
- Pour Amazon DocumentDB
- Pour Amazon Neptune
- Pour Amazon RDS SQL
- Pour Azure, Amazon RDS et Aurora MySQL
- Pour les sauvegardes incrémentielles cumulatives à l'aide d'Amazon RDS SQL
- Pour des sauvegardes incrémentielles à l'aide d'Amazon DynamoDB
- Pour des sauvegardes incrémentielles à l'aide du serveur Azure MySQL
- Pour des sauvegardes incrémentielles à l'aide de GCP SQL Server
- Pour les sauvegardes incrémentielles effectuées à l'aide de GCP PostgreSQL
- Pour les sauvegardes incrémentielles avec Amazon RDS PostgreSQL et Amazon Aurora PostgreSQL
- Pour Azure SQL et SQL Managed Instance
- Pour une sauvegarde incrémentielle Azure SQL Server et SQL Managed Instance
- Pour Azure Cosmos DB for MongoDB
- Pour Azure Cosmos DB for NoSQL
- Pour Amazon RDS for Oracle
- Pour les bases de données Amazon Redshift
- Pour les clusters Amazon Redshift
- Pour GCP SQL Server
- Pour GCP BigQuery
- Installation des utilitaires client natifs
- Configuration du stockage pour différents déploiements
- Configuration du serveur de stockage pour l'accès instantané
- À propos des sauvegardes incrémentielles pour les charges de travail PaaS
- Configuration de sauvegardes incrémentielles pour le serveur Azure MySQL
- À propos de la sauvegarde des journaux redo d'archive pour les charges de travail PaaS
- À propos d'Auto Image Replication pour les charges de travail PaaS
- Découverte des biens PaaS
- Affichage des biens PaaS
- Gestion des informations d'authentification PaaS
- Affichage du nom des informations d'authentification appliquées à une base de données
- Ajout d'informations d'authentification à une base de données
- Création d'un nom d'utilisateur de base de données IAM
- Création d'un nom d'utilisateur d'identité gérée par le système ou par l'utilisateur
- Configuration des autorisations pour l'utilisateur de base de données
- Ajout de la protection des biens PaaS
- Récupération des biens cloud
- Récupération des biens cloud
- À propos de la vérification de prérécupération pour les machines virtuelles
- Paramètres pris en charge pour la restauration de biens cloud
- Récupération de machines virtuelles
- Récupération d'applications et de volumes à leur emplacement d'origine
- Récupération des applications et des volumes à un autre emplacement
- Scénarios de récupération pour les machines virtuelles GCP avec des volumes en lecture seule
- (GCP uniquement) Restauration de machines virtuelles et de volumes à l'aide de la prise en charge de la suppression automatique de disque
- Restauration des biens cloud
- Restaurer vers un autre fournisseur cloud
- Récupération de machines virtuelles AWS ou Azure sur VMware
- Récupération des biens PaaS
- Récupération des biens cloud
- Exécution d'une restauration granulaire
- À propos de la restauration granulaire
- Liste des environnements pris en charge
- Listes des systèmes de fichiers pris en charge
- Avant de commencer
- Limitations et remarques
- Restauration de fichiers et de dossiers à partir de machines virtuelles cloud
- Restauration de volumes sur des machines virtuelles cloud
- Actions à effectuer après la restauration de volumes LVM
- Dépannage
- 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 de la charge de travail cloud
- Code d'erreur 9855 : Une erreur s'est produite lors de l'exportation du snapshot pour le bien <asset_name>
- Les machines virtuelles et les autres biens OCI contenant des disques chiffrés par clé CMK sont marqués comme supprimés dans l'interface utilisateur NetBackup.
- Les travaux de sauvegarde à partir d'un snapshot prennent plus de temps que prévu
- Le travail de sauvegarde à partir d'un snapshot échoue en raison de problèmes de connectivité lorsque Snapshot Manager est déployé sur un hôte Ubuntu
- Clarification d'erreurs s'affichant dans l'interface utilisateur NetBackup
- Code d'état 150 : arrêt demandé par l'administrateur
- Résolution des problèmes de protection et de récupération de charge de travail PaaS
Préparer les machines virtuelles pour la sauvegarde
Cette section décrit les considérations et les conditions requises pour sauvegarder les machines virtuelles pour la restauration sur une plate-forme cloud différente. Le processus est différent selon les systèmes d'exploitation et selon le service cloud sur lequel vous voulez effectuer la restauration.
Cible : AWS
- Installez les pilotes Xen et Nitro requis :
Si les pilotes ne sont pas installés, exécutez les commandes suivantes pour le faire :
lsinitrd | grep -i -e nvme -e ena -e xen
modinfo nvme
Pour en savoir plus, consultez la page Installation ou mise à niveau du pilote NVMe.
modinfo ena
Pour en savoir plus, consultez la page Activer une mise en réseau améliorée avec ENA sur vos instances EC2.
Mettez à jour/créez le fichier
/etc/dracut.confavec la ligne suivante :add_drivers+="xen-blkfront xen-netfront nvme-core nvme"
Exécutez la commande suivante :
dracut -f -v
Exécutez la commande suivante pour vérifier que les pilotes ont été installés correctement :
lsinitrd | grep -i -e nvme -e ena -e xen
- Pour éviter tout échec de montage, il est recommandé de remplacer les noms de périphérique par UUID dans le fichier
/etc/fstab.Sauvegardez le fichier
fstabd'origine et commentez les entrées azure spécifiques ainsi que toute autre entrée non critique pouvant entraîner un échec de démarrage après la restauration. Vous pouvez également ajouternofaildans le fichierfstabpour ces entrées. - Créez un mot de passe d'utilisateur racine.
- Si la machine virtuelle est configurée avec une connexion basée sur une clé, configurez ou obtenez les informations d'authentification de l'utilisateur racine.
Pour utiliser une connexion basée sur une clé, procédez comme suit :
Sauvegardez le fichier
/root/.ssh/authorized_keysd'origine.Le fichier
/root/.ssh/authorized_keyscontient la même clé publique que azureuser, mais ne peut pas se connecter à l'aide de l'utilisateur racine et de la clé, car la commande suivante est présente dansauthorized_keyspour l'utilisateur racine et la clé associée :`echo 'Please login as the user \"azureuser\" rather than the user \"root\".';echo;sleep 10;exit 142`
Remarque :
applicable aux clés créées par Azure et fournies par l'utilisateur.
Vous devez supprimer la commande pour que la connexion racine puisse fonctionner après la restauration.
Après modification, l'entrée s'affiche comme suit :
cat /root/.ssh/authorized_keys no-port-forwarding,no-agent-forwarding,no-X11-forwarding, ssh-rsa AAAAB3Nza..<truncated>..HruCzDsb3j
Cible : Azure
- Les pilotes Hv et NVMe sont préinstallés sur les instances AWS. Aucune opération supplémentaire n'est donc requise. Confirmez si les pilotes existent dans votre instance, exécutez la commande :
lsinitrd | grep -i -e hv -e nvme
- Remplacez les noms de périphérique par UUID dans le fichier
/etc/fstab.
Cible : AWS
Par défaut, AWS utilise le noyau SUSE. Vous devez donc procéder comme suit pour installer le noyau SUSE et le sélectionner au démarrage à partir du menu GRUB sur la machine virtuelle restaurée :
- Consultez la documentation suivante pour en savoir plus sur les entrées du fichier
zypp.conf, car elles peuvent affecter le nombre de noyaux conservés et leur comportement :Installation de plusieurs versions de noyau
Passez aux étapes suivantes pour vous assurer que l'ordinateur SUSE peut fonctionner avec plusieurs noyaux.
- Exécutez la commande suivante pour répertorier les noyaux disponibles :
zypper se -s 'kernel*'
- À partir de la liste de noyaux affichée dans l'étape ci-dessus, installez une version de noyau par défaut appropriée :
zypper in kernel-default-<VERSION>
Par exemple, zypper in kernel-default-5.3.18-53.3
- Répertoriez les noyaux et modules de noyau installés à l'aide de la commande suivante :
zypper se -si 'kernel*'
- Il est recommandé de définir un mot de passe d'utilisateur racine.
- Si les pilotes requis ne sont pas installés, exécutez les commandes suivantes pour le faire :
lsinitrd --kver <YOUR NEW KERNEL VERSION> | grep xen
Mettez à jour/créez le fichier
/etc/dracut.confavec la ligne suivante :add_drivers+="xen-blkfront xen-netfront nvme-core nvme"
Exécutez la commande suivante :
dracut -f -v
dracut -f -v --kver <YOUR NEW KERNEL VERSION>
lsinitrd --kver <YOUR NEW KERNEL VERSION> | grep xen
<YOUR NEW KERNEL VERSION> est la nouvelle version de noyau installée à l'étape 3 ci-dessus.
- Sauvegardez le fichier
/etc/default/grub. Modifiez le fichiergrubd'origine, ajoutez des entrées GRUB_TIMEOUT et GRUB_TIMEOUT_STYLE et commentez les paramètres suivants :GRUB_HIDDEN_TIMEOUT
GRUB_HIDDEN_TIMEOUT_QUIET
Par défaut, l'entrée GRUB_DEFAULT est définie sur 0 dans le fichier
/etc/default/grub. Modifiez la valeur par défaut de sorte qu'elle charge le noyau Azure au redémarrage et non le noyau récemment installé.Par exemple,
GRUB_DEFAULT='1>KERNEL_INDEX'où KERNEL_INDEX peut être trouvé avec la commande grub2-mkconfig ou en analysant le fichier /boot/grub2/grub.cfg.La mise à jour de GRUB_DEFAULT permet de s'assurer que la machine virtuelle source continue d'utiliser le noyau Azure, en cas de redémarrage lorsque le nouveau noyau est installé.
Le fichier de configuration GRUB comporte des entrées semblables à l'exemple suivant :
#GRUB_HIDDEN_TIMEOUT= #GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_DEFAULT'1><YOUR KERNEL INDEX NUMBER>' GRUB_TIMEOUT=20 GRUB_TIMEOUT_STYLE=menu
Mettez à jour le fichier de configuration GRUB à l'aide de la commande suivante :
grub2-mkconfig -o /boot/grub2/grub.cfg
Après la restauration, pour accéder au menu GRUB lors du redémarrage, appuyez deux fois sur le bouton ECHAP pendant le compte à rebours sur la console série EC2.
Pour en savoir plus sur les entrées GRUB, consultez la section Simple configuration handling.
Cible : Azure
- Pour vérifier que les pilotes sont préinstallés, exécutez la commande suivante :
lsinitrd | grep -i -e hv -e nvme
- Il est recommandé de remplacer les noms de périphérique par UUID dans le fichier
/etc/fstab.
Cible : AWS
- Exécutez la commande suivante pour installer le package de noyau linux-aws :
sudo apt-get update && sudo apt-get upgrade -y linux-aws
- Modifiez le style de compte à rebours grub et augmentez le délai d'expiration dans le fichier
/etc/default/grub. L'utilisateur peut ainsi entrer en mode de récupération en cas de problème lors du redémarrage :GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=20
- Pour éviter de charger le nouveau noyau au redémarrage, assurez-vous que l'entrée de noyau par défaut (GRUB_DEFAULT) du fichier de configuration grub pointe vers le noyau Azure spécifique et non vers le noyau récemment installé.
- Exécutez la commande suivante pour mettre à jour le fichier
grub:update-grub
Cible : Azure
- Pour vérifier que les pilotes sont préinstallés, exécutez la commande suivante :
lsinitrd | grep -i -e hv -e nvme
- Il est recommandé de remplacer les noms de périphérique par UUID dans le fichier
/etc/fstab.
Cible : AWS
- Vérifiez le mode de démarrage (hérité ou UEFI).
- Exécutez la commande suivante :
(Ctrl + R) -> MSInfo32.exe → BIOS Mode
- Installez les pilotes suivants :
Pilote PV : AWSPVDriver.zip
Installation d'EC2 : EC2Install.zip
NVME : AWSNVMe.zip
ENA : AwsEnaNetworkDriver.zip