Utilisez Data Box pour migrer du stockage connecté au réseau (NAS) vers les partages de fichiers Azure

✔️ S’applique à : partages de fichiers SMB classiques créés avec le fournisseur de ressources Microsoft.Storage

✖️ Ne s’applique pas à : Tous les partages de fichiers NFS, y compris les partages de fichiers créés avec le fournisseur de ressources Microsoft.FileShares ou les partages de fichiers classiques créés avec le fournisseur de ressources Microsoft.Storage

Cet article sur la migration fait partie de plusieurs portant sur les mots-clés NAS et Azure Data Box. Vérifiez qu’il s’applique à votre scénario :

Si votre scénario est différent, consultez le tableau des guides de migration.

Cet article vous guide tout au long des étapes de planification, de déploiement et de mise en réseau nécessaires à la migration de votre appliance NAS vers des partages de fichiers Azure fonctionnels. Ce guide utilise Azure Data Box pour le transport massif de données (transport de données hors ligne).

Objectifs de la migration

L’objectif est de déplacer les partages de votre appliance NAS vers Azure et de les convertir en partages de fichiers Azure natifs. Vous pouvez utiliser des partages de fichiers Azure natifs sans avoir besoin d’un serveur Windows. Cette migration doit être effectuée de manière à garantir l’intégrité des données de production et la disponibilité pendant la migration. Garantir la disponibilité implique de garder les temps d’arrêt à un niveau minimal pour qu’ils respectent les fenêtres de maintenance habituelles ou ne les dépassent que légèrement.

Présentation de la migration

Le processus de migration se compose de plusieurs phases : Tout d’abord, déployez des comptes de stockage Azure et partagez des fichiers et configurez le réseau. Ensuite, migrez vos fichiers en utilisant Azure Data Box et RoboCopy pour suivre les changements. Enfin, basculez vos utilisateurs et vos applications vers les nouveaux partages de fichiers Azure. Les sections suivantes décrivent en détail les phases du processus de migration.

Phase 1 : Identifier le nombre de partages de fichiers Azure dont vous avez besoin

Déterminez combien de partages de fichiers Azure vous avez besoin. Vous pouvez avoir plus de dossiers dans vos volumes que ce que vous partagez actuellement localement en tant que partages SMB pour vos utilisateurs et applications. Selon le nombre de partages de fichiers que vous souhaitez migrer vers le cloud, choisissez soit une correspondance un pour un, soit un regroupement de partages.

Utiliser un mappage 1 à 1

Si vous avez un petit nombre de partages, utilisez un mappage un-à-un. La façon la plus simple de se représenter ce scénario est d’envisager un partage local qui correspond, dans une relation un à un, à un partage de fichiers Azure.

Utiliser le regroupement de partages

Si vous avez un grand nombre de partages de fichiers, envisagez de regrouper les partages. Par exemple, si votre service des ressources humaines (RH) a 15 partages, vous pouvez envisager de stocker toutes les données RH dans un seul partage de fichiers Azure. Ainsi, un seul partage de fichiers Azure dans le cloud est nécessaire pour ce groupe de partages locaux.

Phase 2 : Déployer des ressources de stockage Azure

Dans cette phase, provisionnez les comptes de stockage Azure et les partages de fichiers qu’ils contenent.

N’oubliez pas qu’un partage de fichiers Azure est déployé dans le cloud dans un compte de stockage Azure. Pour les partages de fichiers HDD (standard), cette disposition rend le compte de stockage une cible d'optimisation des performances pour des indicateurs tels que les IOPS et le débit. Si vous placez plusieurs partages de fichiers dans un seul compte de stockage, vous créez un pool partagé d’IOPS et de débit pour ces partages.

En règle générale, vous pouvez regrouper plusieurs partages de fichiers Azure dans le même compte de stockage s’ils sont destinés à l’archivage ou si vous pensez qu’ils feront l’objet d’une activité quotidienne réduite. Cependant, si vous avez des partages très actifs (des partages utilisés par de nombreux utilisateurs et applications), déployez des comptes de stockage avec un partage de fichiers chacun. Ces limitations ne s’appliquent pas aux comptes de stockage FileStorage (SSD), où les performances sont explicitement approvisionnées et garanties pour chaque partage.

Lorsque vous déployez un compte de stockage, vous devez également tenir compte de la redondance. Consultez Redondance d’Azure Files.

Si vous faites une liste de vos partages, associez chaque partage au compte de stockage où vous le créez.

Le nom des ressources est également important. Par exemple, si vous regroupez plusieurs partages pour le service RH dans un compte de stockage Azure, nommez le compte de stockage de manière appropriée. De même, lorsque vous nommez vos partages de fichiers Azure, utilisez des noms similaires à ceux utilisés pour leurs équivalents sur site.

Déployez maintenant le nombre approprié de comptes de stockage Azure avec le nombre approprié de partages de fichiers Azure, en suivant les instructions fournies dans Créer un partage de fichiers SMB. Dans la plupart des cas, assurez-vous que la région de chacun de vos comptes de stockage est la même.

Phase 3 : Déterminer le nombre d’appliances Azure Data Box dont vous avez besoin

Commencez cette étape seulement après avoir terminé la phase précédente. À ce stade, vous devriez avoir créé vos ressources de stockage Azure, y compris les comptes de stockage et les partages de fichiers. Lors de votre commande de Data Box, vous devez spécifier dans quels comptes de stockage la Data Box déplace les données.

Lors de cette phase, cartographiez les résultats du plan de migration de la phase précédente aux limites des options de Data Box disponibles. Ces considérations vous aident à élaborer un plan pour déterminer quelles options Data Box choisir et combien il vous en faut pour transférer vos partages NAS vers des partages de fichiers Azure.

Pour déterminer le nombre d’appareils dont vous avez besoin, tenez compte des limites importantes suivantes :

• N’importe quel Azure Data Box peut transférer des données dans jusqu’à 10 comptes de stockage.
• Chaque option Data Box a sa propre capacité utilisable. Consultez les options de Data Box.

Consultez votre plan de migration pour connaître le nombre de comptes de stockage que vous avez choisi de créer et les parts dans chacun. Examinez ensuite la taille de chaque partage sur votre NAS. Combiner ces informations vous permet de décider quel appareil doit envoyer des données à quels comptes de stockage. Vous pouvez faire déplacer deux appareils Data Box dans le même compte de stockage, mais ne divisez pas le contenu d’un seul partage de fichiers entre deux appareils Data Box.

Options de Data Box

Pour une migration standard, choisissez une ou une combinaison de ces deux options de Data Box :

• Data Box Cette option est la plus courante. C’est un appliance Data Box robuste qui fonctionne de manière similaire à un NAS. Il vous est livré avec une capacité utilisable de 80 TiB. Pour plus d’informations, consultez la documentationde Data Box.
• Data Box Heavy Cette option propose un appareil robuste sur roues qui fonctionne de manière similaire à un NAS, avec une capacité de 1 PiB. La capacité utilisable est d’environ 20 % inférieure en raison du chiffrement et de la surcharge du système de fichiers. Pour plus d’informations, consultez la documentationde Data Box Heavy.

Phase 4 : Configurer une instance Windows Server temporaire

En attendant l’arrivée de vos appliances Azure Data Box, vous pouvez déjà déployer un ou plusieurs serveurs Windows nécessaires pour exécuter des tâches RoboCopy. Pour les exigences de version du système d’exploitation, voir la note importante dans la section RoboCopy.

• Utilisez ces serveurs pour copier des fichiers sur la Data Box.
• Utilisez ces serveurs pour suivre les changements survenus sur l’appareil NAS pendant que la Data Box est en transport. Cette approche permet de réduire au minimum le temps d’arrêt côté source.

La rapidité à laquelle vos emplois RoboCopy fonctionnent dépend principalement de ces facteurs :

• les IOPS sur le stockage source et le stockage cible ;
• la bande passante réseau disponible entre eux
  Pour plus d’informations, consultez les considérations relatives aux E/S par seconde et à la bande passante
• la possibilité de traiter rapidement des fichiers et des dossiers dans un espace de noms
  Trouver plus de détails : vitesse de traitement
• Le nombre de modifications entre les exécutions RoboCopy
  Pour en savoir plus : évitez les tâches inutiles

Gardez à l’esprit les détails référencés lorsque vous décidez de la RAM et du nombre de threads que vous fournissez à votre ou vos Windows Server temporaires.

Phase 5 : Préparation à l’utilisation des partages de fichiers Azure

Pour gagner du temps, poursuivez cette phase en attendant l’arrivée de votre Data Box. Avec les informations de cette phase, vous pouvez décider comment vos serveurs et utilisateurs peuvent utiliser vos partages de fichiers Azure. Voici quelles sont les décisions les plus importantes à prendre :

• Mise en réseau : autorisez vos réseaux à acheminer le trafic SMB.
• Authentification : configurez les comptes de stockage Azure pour l’authentification Kerberos. Microsoft Entra Connect et l’adhésion au domaine à votre compte de stockage permettent à vos applications et utilisateurs d’utiliser leur identité AD pour l’authentification.
• Autorisation : Les ACL au niveau du partage pour chaque partage de fichiers Azure permettent aux utilisateurs et groupes AD d’accéder à un partage donné, et dans un partage de fichiers Azure, les ACL NTFS natifs prennent le relais. L’autorisation basée sur les listes de contrôle d’accès des fichiers et des dossiers fonctionne alors comme sur des partages SMB locaux.
• Continuité des activités : L’intégration des partages de fichiers Azure dans un environnement existant implique souvent la préservation des adresses de partage existantes. Si vous n’utilisez pas déjà DFS-Namespaces, envisagez d’établir cela dans votre environnement. Vous pouvez garder les adresses de partage utilisées par vos utilisateurs et scripts, inchangées. Vous pouvez utiliser DFS-N comme service de routage d’espace de noms pour SMB, en redirigeant les cibles DFS-Namespace vers des partages de fichiers Azure après leur migration.

Phase 6 : Copiez les fichiers dans votre Data Box

Lorsque votre Data Box arrivera, configurez-la avec une connectivité réseau sans entrave à votre appareil NAS. Suivez la documentation d’installation du type de Data Box que vous avez commandé.

• Configurer Data Box
• Configurer Data Box Disk
• Configurer Data Box Heavy

Selon le type de Data Box, vous pourriez avoir accès aux outils de copie Data Box. À ce stade, ne les utilisez pas pour les migrations vers les partages de fichiers Azure car ils ne copient pas vos fichiers en pleine fidélité vers la Data Box. Privilégiez RoboCopy.

Lorsque votre Data Box arrive, elle dispose de parts PME pré-provisionnées disponibles pour chaque compte de stockage que vous avez spécifié au moment de la commande.

• Si vos fichiers vont dans un partage de fichiers SSD Azure, il y a un partage SMB par compte de stockage SSD « Stockage de fichiers ».
• Si vos fichiers sont stockés dans un compte de stockage HDD, il existe trois partages SMB par compte de stockage HDD avec paiement à l’utilisation. Seul le partage de fichiers se terminant par _AzFile est pertinent pour votre migration. Ignorez les partages d’objets blob de blocs et de pages.

Comment Data Box mappe les dossiers vers les partages de fichiers Azure

Sous le partage d’appareils <storage-account-name>_AzFile, chaque dossier de premier niveau est associé à un partage de fichiers Azure sur le compte de stockage cible :

• Le nom du dossier de premier niveau devient le nom du partage de fichiers Azure lors de l’ingestion. Si un partage portant ce nom n’existe pas déjà dans le compte de stockage cible, Data Box le crée. S’il existe, Data Box copie les données dans ce partage existant.

• Ne copiez pas les fichiers directement à la racine du partage _AzFile. Toutes les données doivent être placées dans un dossier de premier niveau.

• Pour un mappage un-à-un avec vos partages SMB source, créez un dossier de premier niveau pour chaque partage source (en utilisant le nom souhaité du partage Azure) et copiez chaque partage source dans son dossier correspondant. Par exemple:

  \\<DataBox-IP>\<storage-account-name>_AzFile\Share1
  \\<DataBox-IP>\<storage-account-name>_AzFile\Share2
  \\<DataBox-IP>\<storage-account-name>_AzFile\Share3
  

Pour plus d’informations, voir Connect to Data Box.

Suivez les étapes décrites dans la documentation Azure Data Box :

1. Se connecter à Data Box
2. Copier des données sur Data Box
3. Vérifiez le fichier journal RoboCopy pour détecter des erreurs afin de confirmer que tous les fichiers ont été copiés avec succès.
4. Préparez votre Data Box pour le départ vers Azure

La documentation liée à la Data Box spécifie une commande RoboCopy. Cependant, la commande n’est pas adaptée pour préserver la fidélité complète des fichiers et des dossiers. Cette commande est utilisée /MT:32 car il s’agit d’une copie locale en LAN vers la Data Box avec une latence négligeable, donc un nombre de threads plus élevé est approprié ici que pour la copie de rattrapage basée sur WAN en Phase 7 :

Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path> 

• Pour en savoir plus sur les détails des différents indicateurs RoboCopy, consultez le tableau dans la section Robocopy.
• Pour en savoir plus sur la façon de dimensionner correctement le nombre de threads /MT:n, d’optimiser la vitesse de Robocopy et de faire de Robocopy un bon adjuvant pour votre centre de données, consultez la section d’aide à la résolution des problèmes affectant Robocopy.

Phase 7 : Mettre à jour RoboCopy à partir de votre NAS

Après que votre Data Box ait signalé qu’elle a placé tous les fichiers et dossiers dans les partages Azure prévus, continuez cette phase. Vous n’avez besoin d’un RoboCopy de rattrapage que si les données sur le NAS ont pu changer depuis le début de la copie Data Box. Dans certains scénarios où vous utilisez un partage à des fins d’archivage, vous pouvez être en mesure d’arrêter les modifications du partage sur votre NAS jusqu’à la fin de la migration. Vous pouvez aussi être en mesure de répondre aux besoins de votre entreprise en définissant les partages NAS en lecture seule pendant la migration.

Dans les cas où vous avez besoin qu’un partage reste en lecture-écriture pendant la migration et où vous ne pouvez tolérer qu’une courte fenêtre d’indisponibilité, il est important d’effectuer cette étape de rattrapage RoboCopy avant le basculement de l’accès des utilisateurs directement vers le partage de fichiers Azure.

Dans cette étape, exécutez des tâches RoboCopy pour mettre à jour vos partages dans le cloud avec les dernières modifications apportées à votre NAS depuis que vous avez copié vos partages vers la Data Box. Cette mise à jour RoboCopy peut se terminer rapidement ou prendre un certain temps selon le volume de modifications intervenues sur vos partages NAS.

Exécutez la première copie locale vers votre dossier Windows Server cible :

1. Identifiez le premier emplacement sur votre appliance NAS.
2. Identifiez le partage de fichiers Azure correspondant.
3. Montez le partage de fichiers Azure en tant que lecteur réseau local sur votre serveur Windows Server temporaire.
4. Démarrez la copie à l’aide de RoboCopy comme décrit.

Montage d’un partage de fichiers Azure

Avant de pouvoir utiliser RoboCopy, vous devez rendre le partage de fichiers Azure accessible sur SMB. Le moyen le plus simple consiste à monter le partage en tant que lecteur réseau local sur l’instance Windows Server que vous envisagez d’utiliser avec RoboCopy.

Quand vous êtes prêt, consultez l’article pratique expliquant comment utiliser un partage de fichiers Azure avec Windows et montez le partage de fichiers Azure pour lequel vous souhaitez lancer la copie de rattrapage RoboCopy du NAS.

RoboCopy

La commande RoboCopy suivante copie uniquement les différences (fichiers et dossiers mis à jour) de votre stockage NAS vers votre partage de fichiers Azure.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName> 

Transfert de l’utilisateur

Quand vous exécutez la commande RoboCopy pour la première fois, les utilisateurs et applications ont toujours accès aux fichiers sur l’appliance NAS et peuvent éventuellement les modifier. Il est possible que RoboCopy traite un répertoire, passe au répertoire suivant, puis qu’un utilisateur accédant à l’emplacement source (NAS) ajoute, modifie ou supprime un fichier qui ne sera pas traité durant cette exécution de RoboCopy. Il s’agit du comportement attendu.

La première exécution consiste à déplacer la majeure partie des données évolutives vers votre partage de fichiers Azure. Cette première copie peut prendre beaucoup de temps. Pour en savoir plus sur les éléments susceptibles d’affecter la vitesse de Robocopy, consultez cette section d’aide à la résolution de problèmes.

Après la première exécution, relance la commande.

Elle se termine plus rapidement la deuxième fois que vous exécutez RoboCopy pour le même partage. En effet, elle doit déplacer uniquement les éléments modifiés depuis la dernière exécution. Vous pouvez exécuter des travaux répétés pour le même partage.

Dès lors que vous considérez que le temps d’arrêt est acceptable, vous devez supprimer l’accès utilisateur à vos partages NAS. Pour ce faire, vous pouvez utiliser n’importe quelle étape empêchant les utilisateurs de modifier la structure des fichiers et des dossiers, ainsi que leur contenu. Par exemple, vous pouvez faire pointer votre DFS-Namespace vers un emplacement non existant ou modifier les listes de contrôle d’accès racine sur le partage.

Exécutez une dernière fois la commande RoboCopy Il détecte les changements qui auraient pu être manqués. La durée de cette dernière étape dépend de la vitesse d’analyse de Robocopy. Vous pouvez estimer la durée d’exécution (correspondant au temps d’arrêt) en mesurant la durée de l’exécution précédente.

Créez un partage dans le dossier Windows Server et, le cas échéant, ajustez votre déploiement DFS-N pour qu’il pointe vers celui-ci. Veillez à définir les mêmes autorisations au niveau du partage que celles de votre partage SMB NAS. Si vous aviez un NAS joint à un domaine d’entreprise, les SID de l’utilisateur correspondent automatiquement à mesure que la présence des utilisateurs est vérifiée dans Active Directory et que RoboCopy copie fidèlement les fichiers et les métadonnées. Si vous avez utilisé des utilisateurs locaux sur votre emplacement NAS, vous devez recréer ces utilisateurs en tant qu’utilisateurs locaux de Windows Server et mapper les SID existants que RoboCopy a déplacés sur votre Windows Server avec les SID de vos nouveaux utilisateurs locaux de Windows Server.

Vous avez terminé la migration d’un partage ou d’un groupe de partages dans une racine commune ou un volume commun.

Vous pouvez essayer d’exécuter quelques-unes de ces copies en parallèle. Traitez la portée d’un seul partage de fichiers Azure à la fois.

Dépanner

La rapidité et le taux de réussite d’une exécution RoboCopy dépendent de plusieurs facteurs :

• les IOPS sur le stockage source et le stockage cible ;
• la bande passante réseau disponible entre la source et la cible ;
• la capacité de traiter rapidement des fichiers et des dossiers dans un espace de noms ;
• le nombre de modifications entre les exécutions de RoboCopy.
• la taille et le nombre de fichiers que vous devez copier

Remarques relatives à la bande passante et aux IOPS

Dans cette catégorie, vous devez prendre en compte les capacités du stockage source, du stockage cible et du réseau qui les connecte. Le débit maximal possible est déterminé par le plus lent de ces trois composants. Vérifiez que votre infrastructure réseau est configurée pour prendre en charge des vitesses de transfert optimales au mieux de ses possibilités.

Une copie aussi rapide que possible peut ne pas être souhaitable lorsqu’il existe un risque de monopolisation des ressources disponibles par la migration.

• Réfléchissez au moment qui sera le plus approprié dans votre environnement pour effectuer des migrations : dans la journée, pendant les heures creuses ou au cours des week-ends.
• Pensez également à la mise en réseau de la Qualité de service sur un serveur Windows pour limiter la vitesse de RoboCopy.
• Évitez les tâches inutiles pour les outils de migration.

RoboCopy peut insérer des délais inter-paquets, en spécifiant le commutateur /IPG:n, sachant que n est mesuré en millisecondes entre les paquets de Robocopy. L’utilisation de ce commutateur peut aider à éviter la monopolisation des ressources à la fois sur les dispositifs contraints d’E/S et sur les liaisons réseau encombrées.

/IPG:n ne permet pas de limiter avec précision le réseau à un certain nombre de Mbits/s près. Utilisez plutôt la Qualité de service du réseau Windows Server. RoboCopy s’appuie entièrement sur le protocole SMB pour tous les besoins réseau. Cette utilisation de SMB est la raison pour laquelle RoboCopy ne peut pas influer sur le débit du réseau lui-même, par contre il peut ralentir son utilisation.

Un raisonnement similaire s’applique aux E/S par seconde (IOPS) observées sur l’appliance NAS. La taille du cluster sur le volume NAS, les tailles de paquets et un ensemble d’autres facteurs affectent les IOPS observées. L’introduction d’un délai entre des paquets constitue souvent le moyen le plus simple de contrôler la charge sur le NAS. Tester plusieurs valeurs, par exemple d’environ 20 millisecondes (n=20) jusqu’à des multiples de ce nombre. Après avoir introduit un délai, vous pouvez évaluer si vos autres applications fonctionnent désormais comme prévu. Cette stratégie d’optimisation vous aide à trouver la vitesse optimale de RoboCopy dans votre environnement.

Vitesse de traitement

RoboCopy parcourt l’espace de noms que vous spécifiez et évalue chaque fichier et dossier pour copie. Il évalue chaque fichier lors d’une copie initiale et lors des copies de rattrapage. Par exemple, des exécutions répétées de RoboCopy /MIR sur les mêmes emplacements de stockage source et cible. Ces exécutions répétées minimisent les temps d’arrêt pour les utilisateurs et les applications, et améliorent le taux global de réussite des fichiers migrés.

La bande passante est souvent considérée comme le facteur le plus limitant lors d’une migration, et cela peut être vrai. Toutefois, la possibilité d’énumérer un espace de noms peut influencer encore plus la durée totale de la copie pour les espaces de noms plus grands avec des fichiers de plus petite taille. Considérons que copier 1 TiB de petits fichiers prend beaucoup plus de temps que de copier 1 TiB de fichiers moins nombreux mais plus volumineux, en supposant que toutes les autres variables restent les mêmes. Par conséquent, vous pouvez rencontrer un transfert lent si vous migrez un grand nombre de petits fichiers. Cette différence est attendue.

La cause de cette différence réside dans la puissance de traitement nécessaire pour parcourir un espace de noms. RoboCopy prend en charge les copies multithread par le biais du paramètre /MT:n, où n représente le nombre de threads à utiliser. Ainsi, lors du provisionnement d’une machine plus particulièrement destinée à RoboCopy, tenez compte du nombre de cœurs de processeur et de leur relation avec le nombre de threads qu’ils fournissent. Le plus souvent, il est question de deux threads par cœur. Le nombre de cœurs et de threads d’une machine constitue un point de données important pour déterminer les valeurs multithread /MT:n que vous devez spécifier. Tenez également compte du nombre de tâches de RoboCopy que vous prévoyez d’exécuter en parallèle sur une machine donnée.

Plus de threads copient l’exemple de 1 TiB de petits fichiers beaucoup plus rapidement que moins de threads. En même temps, l’investissement supplémentaire en ressources sur le 1 TiB de fichiers plus volumineux pourrait ne pas apporter de bénéfices proportionnels. Un nombre élevé de threads tente de copier simultanément davantage de gros fichiers sur le réseau. Cette activité réseau supplémentaire augmente la probabilité d’être limité par les IOPS de débit ou de stockage.

Pendant un premier RoboCopy dans une cible vide ou une exécution différentielle avec un grand nombre de fichiers modifiés, vous êtes probablement limité par le débit de votre réseau. Démarrez avec un nombre élevé de threads pour une série initiale. Un nombre élevé de threads, même au-delà des threads actuellement disponibles sur votre machine, permet de saturer la bande passante réseau disponible. Les exécutions suivantes de /MIR sont affectées progressivement par les éléments traités. Un nombre moindre de modifications dans une exécution différentielle signifie moins de transport des données sur le réseau. Votre vitesse est désormais plus dépendante de votre capacité à traiter les éléments d’espace de noms que de leur déplacement sur la liaison réseau. Pour les exécutions suivantes, associez votre valeur de nombre de threads au nombre de cœurs du processeur et au nombre de threads par cœur. Déterminez si les cœurs doivent être réservés pour les autres tâches qu’un serveur de production peut prendre en charge.

Éviter les tâches inutiles

Évitez les modifications à grande échelle dans votre espace de noms. Par exemple, le déplacement de fichiers entre des répertoires, la modification de propriétés à grande échelle ou la modification des autorisations (ACL NTFS). En particulier, les modifications de liste de contrôle d’accès (ACL, access-control list) peuvent avoir un impact important, car elles ont souvent un effet de modification en cascade sur les fichiers situés plus bas dans l’arborescence des dossiers. Les conséquences peuvent être les suivantes :

• Un temps d’exécution de la tâche RoboCopy prolongé, car chaque fichier et dossier concerné par une modification ACL doit être mis à jour
• La réutilisation de données déplacées auparavant demandera peut-être que celles-ci soient recopiées. Par exemple, il faut copier davantage de données lorsque la structure des dossiers change après que les fichiers ont déjà été copiés. Une tâche RoboCopy ne peut pas « lire » une modification d’espace de noms. La tâche suivante doit donc purger les fichiers précédemment transportés vers l’ancienne structure de dossiers, et charger de nouveau les fichiers dans la nouvelle structure de dossiers.

Un autre aspect important consiste à utiliser efficacement l’outil RoboCopy. En utilisant le script recommandé RoboCopy, vous créez et sauvegardez un fichier journal pour les erreurs. Les erreurs de copie peuvent se produire et c’est normal. Ces erreurs rendent souvent nécessaire l’exécution de plusieurs séquences d’un outil de copie tel que RoboCopy. Par exemple, une première exécution, disons d'un NAS vers Data Box ou d'un serveur vers un partage de fichiers Azure, et une ou plusieurs exécutions supplémentaires avec le /MIR switch pour attraper et réessayer des fichiers qui n'ont pas été copiés.

Soyez prêt(e) à exécuter plusieurs séquences de RoboCopy sur une étendue d’espace de noms déterminée. Les exécutions successives s’achèvent plus rapidement, car elles ont moins de données à copier, mais elles sont de plus en plus limitées par la vitesse de traitement de l’espace de noms. Lorsque vous exécutez plusieurs séquences, vous pouvez accélérer chacune d’elles en évitant que RoboCopy n’essaie exagérément de tout copier dans une exécution donnée. Ces commutateurs RoboCopy peuvent faire une grande différence :

• /R:n n = fréquence à laquelle vous réessayez de copier un fichier ayant échoué et
• /W:n n = fréquence d’attente, en secondes, entre les tentatives

/R:5 /W:5 est un paramètre raisonnable que vous pouvez adapter à votre convenance. Dans cet exemple, un fichier ayant échoué sera retenté cinq fois, avec un délai d’attente de cinq secondes entre chaque tentative. Si la copie du fichier échoue toujours, la tâche RoboCopy suivante fera une nouvelle tentative. Souvent, les fichiers qui ont échoué parce qu’ils sont en cours d’utilisation ou en raison de problèmes de délai d’expiration peuvent éventuellement être copiés avec succès de cette façon.

Voir aussi

• Présentation de la migration
• Considérations réseau pour l’accès direct
• Instantanés de partage de fichiers Azure