Guide de déduplication NetBackup™
- Introduction à NetBackup Media Server Deduplication Option
- Planification de votre déploiement
- À propos des conditions requises en matière de stockage et de connectivité de MSDP
- À propos de la déduplication de serveur de médias NetBackup
- À propos de la déduplication directe du client NetBackup
- A propos de la déduplication client de filiale MSDP
- A propos des gestionnaires de flux de MSDP
- Pratiques d'excellence de déploiement MSDP
- Provisionnement du stockage
- Configuration de la fonction de déduplication
- A propos de l'agent de déduplication à plusieurs threads MSDP
- A propos des empreintes MSDP
- Activer la prise en charge d'un MSDP de 400 To
- Configuration d'un serveur de stockage pour un pool de déduplication de serveur de médias
- À propos des pools de disques pour la déduplication NetBackup
- Configuration d'une unité de stockage d'un pool de déduplication de serveur de médias
- Configuration des attributs client pour la déduplication côté client du MSDP
- À propos du chiffrement MSDP
- À propos du chiffrement MSDP à l'aide du service NetBackup Key Management Server
- À propos d'un chemin d'accès de réseau distinct pour la duplication et la réplication MSDP
- À propos de la duplication optimisée MSDP au sein du même domaine
- Configuration de la réplication MSDP sur un autre domaine NetBackup
- À propos d'Auto Image Replication NetBackup
- Configuration d'une cible pour la réplication de MSDP vers un domaine distant
- À propos des politiques de cycle de vie du stockage
- Propriétés Réseau résilient
- À propos de la déduplication de longueur variable sur les clients NetBackup
- A propos du fichier de configuration pd.conf de MSDP
- A propos de l'enregistrement de la configuration de serveur de stockage MSDP
- Au sujet de la protection du catalogue MSDP
- À propos de la prise en charge du stockage WORM NetBackup pour les données immuables et ineffaçables
- Exécution des services MSDP avec l'utilisateur non-racine
- Exécution des commandes MSDP avec l'utilisateur non-racine
- Groupe de volumes MSDP (MVG)
- À propos du groupe de volumes MSDP
- Configuration du groupe de volumes MSDP
- Prise en charge du cloud MSDP
- A propos de la prise en charge du cloud MSDP
- Récupération d'espace cloud
- A propos de la reprise après incident pour la LSU cloud
- À propos du partage d'images à l'aide du cloud MSDP
- Conversion de l'image de la machine virtuelle en VHD dans Azure
- À propos de la prise en charge du stockage immuable (WORM) en cloud MSDP
- À propos de la prise en charge des objets immuables pour AWS S3
- À propos de la prise en charge du stockage immuable au niveau objet pour Google Cloud Storage
- À propos de la prise en charge d'AWS IAM Role Anywhere
- À propos de la prise en charge du principal de service Azure
- À propos de la prise en charge d'AWS Snowball Edge par NetBackup
- Configuration de NetBackup pour AWS Snowball Edge
- Reconfigurer NetBackup pour fonctionner avec S3
- À propos de la sauvegarde directe dans le cloud
- Interface S3 pour MSDP
- Configuration de l'interface S3 pour MSDP sur un serveur BYO MSDP
- Gestion des identités et des accès (IAM) pour l'interface S3 pour MSDP
- API S3 pour l'interface S3 pour MSDP
- API S3 sur les compartiments
- API S3 sur les objets
- API S3 sur les compartiments
- Reprise après incident dans l'interface S3 pour MSDP
- Surveillance de l'activité de déduplication
- Affichage des détails du travail MSDP
- Gestion de la fonction de déduplication
- Gestion des serveurs MSDP
- Gestion des informations d'authentification du moteur de déduplication NetBackup
- Gestion des pools de déduplication de serveur de médias
- Modification des propriétés d'un pool de déduplication de serveur de médias
- A propos de la vérification d'intégrité des données de MSDP
- A propos du changement de base du stockage MSDP
- Gestion des serveurs MSDP
- Récupération MSDP
- Remplacement des hôtes MSDP
- Désinstallation MSDP
- Architecture de déduplication
- Configuration et gestion de partages universels
- Présentation des partages universels
- Conditions préalables à la configuration de partages universels
- Conditions préalables et configuration matérielle requise pour configurer des partages universels sur un serveur BYO
- Configuration de l'authentification utilisateur pour un partage universel
- Gestion des partages universels
- Créer un partage universel
- Créer un partage universel
- Restauration de données à l'aide de partages universels
- Fonctions avancées des partages universels
- Orientation des données de partage universel vers un magasin d'objets
- Accélérateur de partage universel pour la déduplication de données
- Configuration d'un accélérateur de partage universel
- À propos du quota de l'accélérateur de partage universel
- Chargement des données de sauvegarde sur un partage universel avec le mode de réception
- Évolutivité des partages universels
- Gestion des services de partage universel
- Résolution des problèmes liés aux partages universels
- Configuration d'un environnement de récupération isolé (IRE)
- Configuration d'un environnement de récupération isolé (IRE) à l'aide de l'interface utilisateur Web
- Configuration d'un environnement de récupération isolé (IRE) à l'aide de la ligne de commande
- Utilisation de NetBackup Deduplication Shell
- Gestion des utilisateurs à partir du shell de déduplication
- À propos de la sauvegarde externe de catalogue MSDP
- Gestion des certificats à partir du shell de déduplication
- Gestion des services NetBackup à partir du shell de déduplication
- Surveillance et dépannage des services NetBackup à partir du shell de déduplication
- Gestion du service S3 à partir du shell de déduplication
- Dépannage
- À propos de la consignation unifiée
- À propos de la consignation héritée
- Résolution des problèmes de configuration MSDP
- Résolution des problèmes d'exploitation de MSDP
- Résolution des problèmes liés à plusieurs domaines
- Annexe A. Migration vers le stockage MSDP
- Annexe B. Migration de Cloud Catalyst vers les niveaux cloud directs MSDP
- À propos de la migration directe de Cloud Catalyst vers les niveaux de cloud directs MSDP
- Annexe C. Robot de chiffrement
Éléments à prendre en compte avant d'utiliser le partage d'images pour convertir une image de machine virtuelle en VHD dans Azure
Le partage d'images avec le fournisseur Azure prend en charge la conversion d'une machine virtuelle VMware en VHD Azure, qui est chargé sur l'objet blob du stockage Azure. Vous pouvez utiliser le portail Web Azure pour créer une machine virtuelle basée sur un VHD. Le partage d'image n'ajoute pas de limitations supplémentaires pour la conversion de machine virtuelle, mais les machines virtuelles sources dans Azure doivent respecter les conditions préalables suivantes :
Type de système d'exploitation de la machine virtuelle source
Les systèmes d'exploitation invités suivants sont pris en charge pour la machine virtuelle source :
Éditions de Windows 10
Éditions de Windows 2012 R2
Éditions de Windows 2016
Éditions de Windows 2019
Éditions de Windows 2022
RHEL 7.6, 7.7, 7.9, 8.6
Ubuntu 18.04
SUSE 12SP4, 15SP4
Pour les autres systèmes d'exploitation, voir Plates-formes prises en charge.
Pour les distributions non approuvées, vérifiez que la machine virtuelle source répond aux exigences des distributions non approuvées avant de convertir une machine virtuelle. Cette vérification est importante, car les machines virtuelles Linux basées sur une distribution approuvée de Microsoft Azure respectent les conditions préalables leur permettant de s'exécuter sur Azure, ce qui n'est peut-être pas le cas de machines virtuelles qui proviennent d'autres hyperviseurs. Pour plus d'informations, voir Informations concernant les distributions non approuvées.
Pilotes Hyper-V dans la machine virtuelle source
Sous Linux, les pilotes Hyper-V suivants sont requis sur la machine virtuelle source :
hv_netvsc.ko
hv_storvsc.ko
hv_vmbus.ko
Vous devrez peut-être reconstruire l'image initrd pour que les modules de noyau requis soient disponibles sur le disque virtuel d'origine. Le mécanisme de reconstruction de l'image initrd ou initramfs peut varier selon la distribution. De nombreuses distributions disposent déjà de ces pilotes intégrés. Pour Red Hat ou CentOS, les derniers pilotes Hyper-V (LIS) peuvent être requis si les pilotes intégrés ne fonctionnent pas correctement. Pour plus d'informations, voir Conditions requises pour le noyau Linux.
Par exemple, avant d'effectuer une sauvegarde pour une machine virtuelle source Linux qui exécute CentOS ou Red Hat, vérifiez que les pilotes Hyper-V requis sont installés sur la machine virtuelle source. Ces pilotes doivent être présents sur la sauvegarde de la machine virtuelle source pour démarrer la machine virtuelle après la conversion.
Prenez un snapshot de la machine virtuelle source.
Exécutez la commande suivante pour modifier l'image de démarrage :
sudo dracut -f -v -N
Exécutez la commande suivante pour vérifier que les pilotes Hyper-V sont présents dans l'image de démarrage :
lsinitrd | grep hv
Vérifiez qu'aucun fichier dracut conf (par exemple,
/usr/lib/dracut/dracut.conf.d/01-dist.conf
) ne contient la ligne suivante :hostonly="yes"
Exécutez une nouvelle sauvegarde à utiliser pour la conversion.
Disque
Le système d'exploitation des machines virtuelles sources est installé sur le premier disque des machines virtuelles sources. Ne configurez pas de partition de swap sur le disque du système d'exploitation. Voir la section Informations concernant les distributions non approuvées.
Plusieurs disques de données associés à une nouvelle VM créée par le VHD converti se trouveront à l'état hors ligne pour Windows et à l'état démonté pour Linux. Vous devrez les mettre en ligne et les monter manuellement après la conversion.
Après la création d'une machine virtuelle à l'aide d'un VHD converti, il se peut qu'un disque de stockage temporaire supplémentaire dont la taille est déterminée par la taille de la machine virtuelle soit ajouté par Azure dans les systèmes Linux et Windows. Pour plus d'informations, voir Disque temporaire de machine virtuelle Azure.
Réseau
Si la machine virtuelle source est dotée de plusieurs interfaces réseau, une seule interface restera disponible dans la nouvelle machine virtuelle créée par le VHD converti.
Linux : le nom de l'interface réseau principale sur les machines virtuelles sources doit être eth0 pour les distributions Linux approuvées. Sinon, le réseau ne peut pas se connecter à la nouvelle machine virtuelle créée par le VHD converti et certaines étapes doivent être effectuées manuellement sur les VHD convertis. Pour plus d'informations, voir Échec de la connexion à la machine virtuelle Linux Azure au moyen du réseau.
Windows : activez le protocole RDP (Remote Desktop Protocol) sur la machine virtuelle source. Dans certains systèmes Windows, le pare-feu doit être désactivé sur les machines virtuelles sources. Dans le cas contraire, la connexion à distance échoue.
Compte Azure
Lorsque vous convertissez le VMDK en VHD, le compte Azure dans le partage d'images utilisant le cloud MSDP doit être un compte de stockage Usage général Azure. Voir Présentation du compte de stockage.
Remarque :
Pour la conversion en machine virtuelle, si le volume de partage d'images est Veritas Alta Recovery Vault, seules les informations d'authentification d'accès sont prises en charge. Les informations d'authentification Azure Service Principal ou AWS IAM Anywhere ne sont pas prises en charge.