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
- Gestion des politiques relatives aux biens cloud
- Limites et remarques
- Ajout d'une SLP et d'une politique cloud
- Configuration des attributs pour le type de politique cloud IaaS
- Configuration des attributs pour le type de politique cloud PaaS
- Création d'attributs de planification pour un type de politique PaaS
- Configuration des biens cloud pour IaaS
- Configuration des biens cloud pour PaaS
- Options de sauvegarde pour IaaS
- Opérations sur la politique cloud
- Configurations des SLP PaaS et IaaS
- 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 des biens PaaS
- Conditions préalables pour la protection des biens PaaS
- Installation des utilitaires client natifs
- Configuration du serveur de stockage pour l'accès instantané
- Conditions préalables à la protection des biens de base de données Amazon RDS SQL Server
- Configuration du stockage pour différents déploiements
- À 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
- Limitations et remarques
- 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
- Ajout de la protection des biens PaaS
- Réalisation d'une sauvegarde immédiate
- Protection de machines virtuelles AWS ou Azure pour la récupération sur VMware
- Nettoyage des biens cloud
- Filtrage des biens cloud
- 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
- Restauration vers un autre fournisseur 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
- Étapes supplémentaires requises après la restauration d'une instance de base de données AWS RDS
- 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 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