Partager via

Utiliser Data Box pour migrer de Network Attached Storage (NAS) vers un déploiement cloud hybride avec Azure File Sync

  • Article

Comme d’autres, cet article relatif à la migration comporte les mots clés NAS, Azure File Sync et Azure Data Box. Vérifiez qu’il s’applique à votre scénario :

  • Source de données : stockage NAS (Network-Attached Storage)
  • Itinéraire de migration : NAS ⇒ Data Box ⇒ Partage de fichiers Azure ⇒ synchronisation avec Windows Server
  • Mise en cache de fichiers localement : Oui, l’objectif final étant un déploiement Azure File Sync

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

Azure File Sync fonctionne sur les emplacements avec stockage en attachement direct (DAS, Direct Attached Storage). Il ne prend pas en charge les emplacements avec stockage en réseau (NAS, Network Attached Storage). Vous devez donc migrer vos fichiers. Cet article vous guide tout au long de la planification et de l’implémentation de cette migration.

S’applique à

Type de partage de fichiers SMB NFS
Partages de fichiers Standard (GPv2), LRS/ZRS Oui Non
Partages de fichiers Standard (GPv2), GRS/GZRS Oui Non
Partages de fichiers Premium (FileStorage), LRS/ZRS Oui Non

Objectifs de la migration

L’objectif est de déplacer les partages que vous avez sur votre appliance NAS vers Windows Server. Vous utiliserez ensuite Azure File Sync pour un déploiement cloud hybride. 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.

Vue d’ensemble de la migration

Le processus de migration se compose de plusieurs phases : Plusieurs actions sont nécessaires :

  • Déployer des comptes de stockage et des partages de fichiers Azure.
  • Déployer un ordinateur local exécutant Windows Server.
  • Configurez Azure File Sync.
  • Migrer des fichiers avec Robocopy.
  • Effectuer le basculement.

Les sections suivantes décrivent en détail les phases du processus de migration.

Conseil

Si vous revenez à cet article, utilisez la navigation à droite de l’écran pour accéder à la phase de migration là où vous vous étiez arrêté.

Phase 1 : Déterminer le nombre de partages de fichiers Azure dont vous avez besoin

Dans cette étape, vous allez déterminer le nombre de partages de fichiers Azure dont vous avez besoin. Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure.

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. La solution la plus simple pour décrire ce scénario consiste à envisager un mappage 1:1 entre un partage local et un partage de fichiers Azure. Si vous avez un nombre suffisamment petit de partages, inférieur à 30 pour une seule instance Windows Server, nous vous recommandons un mappage 1:1.

Si vous avez plus de 30 partages, il est souvent inutile de mapper un partage local 1:1 à un partage de fichiers Azure. Tenez compte des options suivantes.

Regroupement de 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. Le stockage de plusieurs partages locaux dans un partage de fichiers Azure ne vous empêche pas de créer les 15 partages SMB habituels sur votre instance locale de Windows Server. Cela signifie simplement que vous organisez les dossiers racine de ces 15 partages en sous-dossiers sous un dossier commun. Vous synchronisez ensuite ce dossier commun avec un partage de fichiers Azure. Ainsi, un seul partage de fichiers Azure dans le cloud est nécessaire pour ce groupe de partages locaux.

Synchronisation de volume

Azure File Sync prend en charge la synchronisation de la racine d’un volume avec un partage de fichiers Azure. Si vous synchronisez la racine du volume, tous les sous-dossiers et fichiers se retrouvent dans le même partage de fichiers Azure.

La synchronisation de la racine du volume n’est pas toujours la meilleure option. Il y a des avantages à synchroniser plusieurs emplacements. Par exemple, cela permet de maintenir un nombre d’éléments plus bas par étendue de synchronisation. Nous testons les partages de fichiers Azure et Azure File Sync avec 100 millions d’éléments (fichiers et dossiers) par partage. Cela dit, la bonne pratique est d’essayer de garder le nombre au-dessous de 20 ou 30 millions dans un même partage. La configuration d’Azure File Sync avec un nombre d’éléments inférieur n’est pas seulement avantageuse pour la synchronisation de fichiers. Un nombre inférieur d’éléments présente également des avantages pour d’autres scénarios comme :

  • L’analyse initiale du contenu cloud peut se terminer plus rapidement, ce qui réduit l’attente de l’affichage de l’espace de noms sur un serveur activé pour Azure File Sync.
  • La restauration côté cloud à partir d’un instantané de partage de fichiers Azure sera plus rapide.
  • La reprise d’activité d’un serveur local peut être considérablement accélérée.
  • Les modifications apportées directement dans un partage de fichiers Azure (en dehors de la synchronisation) peuvent être détectées et synchronisées plus rapidement.

Conseil

Si vous ne savez pas combien de fichiers et de dossiers vous avez, consultez l’outil d’arborescence de JAM Software GmbH.

Approche structurée d’un plan de déploiement

Avant de déployer un stockage cloud par la suite, vous devez créer un mappage entre des dossiers locaux et des partages de fichiers Azure. Ce mappage indique le nombre et la nature des ressources de groupe de synchronisation Azure File Sync à provisionner. Un groupe de synchronisation lie le partage de fichiers Azure et le dossier sur votre serveur et établit une connexion de synchronisation.

Pour déterminer le nombre de partages de fichiers Azure dont vous avez besoin, passez en revue les limites et bonnes pratiques suivantes. Cela vous permet d’optimiser votre mappage.

  • Un serveur sur lequel l’agent Azure File Sync est installé peut se synchroniser avec un maximum de 30 partages de fichiers Azure.

  • Un partage de fichiers Azure est déployé dans un compte de stockage. Cet arrangement fait du compte de stockage une cible de mise à l’échelle pour les chiffres des performances comme les IOPS et le débit.

    Lors du déploiement de partages de fichiers Azure, soyez attentif aux limitations d’IOPS d’un compte de stockage. Dans l’idéal, une correspondance 1:1 doit être respectée entre les partages de fichiers et les comptes de stockage. Mais cela n’est pas toujours possible en raison des différentes limites et restrictions imposées par votre organisation et Azure. Lorsqu’il est impossible de déployer un seul partage de fichiers dans un seul compte de stockage, il convient d’identifier les partages qui seront plus ou moins actifs afin de veiller à ce que les plus actifs ne soient pas regroupés sur le même compte de stockage.

    Si vous envisagez d’intégrer une application dans Azure qui utilisera le partage de fichiers Azure en mode natif, vous devrez peut-être augmenter les performances de votre partage de fichiers Azure. Si ce type d’utilisation est une éventualité, même future, il est préférable de créer un partage de fichiers Azure standard dans son propre compte de stockage.

  • Il existe une limite de 250 comptes de stockage par abonnement et par région Azure.

Conseil

Au vu de ces informations, il est souvent nécessaire de regrouper plusieurs dossiers de niveau supérieur sur vos volumes dans un nouveau répertoire racine commun. Vous synchronisez ensuite ce nouveau répertoire racine et tous les dossiers que vous y avez regroupés dans un seul partage de fichiers Azure. Cette technique vous permet de rester dans la limite de 30 synchronisations de partage de fichiers Azure par serveur.

Ce regroupement sous une racine commune n’affecte pas l’accès à vos données. Vos listes de contrôle d’accès restent telles quelles. Vous avez seulement besoin d’ajuster les chemins de partage (par exemple, des partages SMB ou NFS) que vous pouvez avoir sur les dossiers de serveur locaux et que vous avez maintenant changés en racine commune. Rien d’autre ne change.

Important

Le vecteur d’échelle le plus important pour Azure File Sync est le nombre d’éléments (fichiers et dossiers) qui doivent être synchronisés. Pour plus d’informations, consultez Cibles de mise à l’échelle Azure File Sync.

Il est recommandé de maintenir un petit nombre d’éléments par étendue de synchronisation. C’est un facteur important à prendre en compte quand vous mappez des dossiers aux partages de fichiers Azure. Azure File Sync est testé avec 100 millions d’éléments (fichiers et dossiers) par partage. Cela dit, il est souvent préférable de garder le nombre d’éléments au-dessous de 20 ou 30 millions dans un même partage. Fractionnez votre espace de noms en plusieurs partages si vous commencez à dépasser ces nombres. Vous pouvez continuer à regrouper plusieurs partages locaux dans le même partage de fichiers Azure, à condition que vous restiez plus ou moins en dessous de ces chiffres. Cette méthode vous donne de la marge pour évoluer.

Dans votre situation, il est possible qu’un ensemble de dossiers puisse logiquement se synchroniser avec le même partage de fichiers Azure (en utilisant la nouvelle approche de dossier racine commun mentionnée plus haut). Toutefois, il peut être préférable de regrouper les dossiers de manière à ce qu’ils se synchronisent avec deux partages de fichiers Azure au lieu d’un. Vous pouvez utiliser cette approche pour conserver l’équilibre entre le nombre de fichiers et de dossiers par partage de fichiers sur le serveur. Vous pouvez également diviser vos partages locaux et synchroniser sur d’autres serveurs locaux, en ajoutant la possibilité de synchroniser avec 30 autres partages de fichiers Azure par serveur supplémentaire.

Scénarios fréquents de synchronisation de fichiers et observations

# Scénario de synchronisation Prise en charge Observations (ou limitations) Solution (ou solution de contournement)
1 Serveur de fichiers avec plusieurs disques/volumes et plusieurs partages sur le même partage de fichiers Azure cible (consolidation) Non Un partage de fichiers Azure cible (point de terminaison cloud) ne prend en charge la synchronisation qu’avec un seul groupe de synchronisation.

Un groupe de synchronisation ne prend en charge qu’un seul point de terminaison de serveur par serveur inscrit.		 1) Commencez par synchroniser un disque (son volume racine) pour cibler le partage de fichiers Azure. Le fait de commencer par le disque/volume le plus important aidera à déterminer les besoins de stockage au niveau local. Configurez la hiérarchisation cloud pour répartir toutes les données sur le cloud, libérant ainsi de l’espace sur le disque du serveur de fichiers. Déplacez les données d’autres volumes/partages vers le volume actuel qui est synchronisé. Suivez les étapes une par une jusqu’à ce que toutes les données soient transférées vers le cloud ou migrées.
2) Ciblez un volume racine (disque) à la fois. Utilisez la hiérarchisation cloud pour répartir toutes les données dans le partage de fichiers Azure cible. Supprimez le point de terminaison de serveur du groupe de synchronisation, recréez le point de terminaison avec le volume/disque racine suivant, synchronisez et répétez le processus. Remarque : il peut être nécessaire de réinstaller l’agent.
3) Recommandez l’utilisation de plusieurs partages de fichiers Azure cibles (compte de stockage identique ou différent en fonction des exigences de performances)
2 Serveur de fichiers avec un volume unique et plusieurs partages sur le même partage de fichiers Azure cible (consolidation) Oui Impossible de synchroniser plusieurs points de terminaison de serveur par serveur inscrit avec le même partage de fichiers Azure cible (identique à celui ci-dessus) Synchronisez la racine du volume contenant plusieurs partages ou dossiers de niveau supérieur. Pour plus d’informations, consultez Concept de regroupement de partages et Synchronisation du volume.
3 Serveur de fichiers avec plusieurs partages et/ou volumes vers plusieurs partages de fichiers Azure sous un seul compte de stockage (mappage de partage 1:1) Oui Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure.

Un compte de stockage est une cible de mise à l’échelle pour les performances. Les IOPS et le débit sont partagés entre les partages de fichiers.

Conservez le nombre d’éléments par groupe de synchronisation dans les 100 millions d’éléments (fichiers et dossiers) par partage. Dans l’idéal, il est préférable de rester en dessous de 20 ou 30 millions par partage.		 1) Utilisez plusieurs groupes de synchronisation (nombre de groupes de synchronisation = nombre de partages de fichiers Azure à synchroniser).
2) Seuls 30 partages à la fois peuvent être synchronisés dans ce scénario. Si vous avez plus de 30 partages sur ce serveur de fichiers, utilisez le Concept de regroupement de partages et la Synchronisation du volume pour réduire le nombre de dossiers racine ou de niveau supérieur à la source.
3) Utilisez des serveurs File Sync supplémentaires locaux et fractionnez/déplacez les données vers ces serveurs pour contourner les limitations sur le serveur Windows source.
4 Serveur de fichiers avec plusieurs partages et/ou volumes vers plusieurs partages de fichiers Azure sous un compte de stockage différent (mappage de partage 1:1) Oui Une seule instance Windows Server (ou cluster) peut synchroniser jusqu’à 30 partages de fichiers Azure (compte de stockage identique ou différent).

Conservez le nombre d’éléments par groupe de synchronisation dans les 100 millions d’éléments (fichiers et dossiers) par partage. Dans l’idéal, il est préférable de rester en dessous de 20 ou 30 millions par partage.		 Même approche que précédemment
5 Plusieurs serveurs de fichiers avec un seul (volume ou partage racine) sur le même partage de fichiers Azure cibles (consolidation) Non Un groupe de synchronisation ne peut pas utiliser le point de terminaison cloud (partage de fichiers Azure) déjà configuré dans un autre groupe de synchronisation.

Bien qu’un groupe de synchronisation puisse avoir des points de terminaison de serveur sur des serveurs de fichiers différents, les fichiers ne peuvent pas être distincts.		 Suivez les instructions du scénario n° 1 ci-dessus en tenant compte de la nécessité de cibler un serveur de fichiers à la fois.

Créer une table de mappage

Diagramme montrant un exemple d’une table de mappage. Téléchargez le fichier suivant pour découvrir et utiliser le contenu de cette image.

Utilisez les informations précédentes pour déterminer le nombre de partages de fichiers Azure dont vous avez besoin, ainsi que les parties de vos données existantes finissant dans ces différents partages.

Créez un tableau regroupant vos réflexions pour pouvoir vous y référer quand vous en avez besoin. Veillez à rester organisé pour ne perdre aucun détail de votre plan de mappage quand vous approvisionnez simultanément un grand nombre de ressources Azure. Téléchargez le fichier Excel suivant à utiliser comme modèle pour vous aider à créer votre mappage.


Icône Excel qui définit le contexte du téléchargement Téléchargez un modèle de mappage d’espace de noms.

Phase 2 : Déployer des ressources de stockage Azure

Au cours de cette phase, consultez la table de mappage de la phase 1 et utilisez-la pour approvisionner le nombre correct de comptes de stockage Azure et de partages de fichiers dans ceux-ci.

Un partage de fichiers Azure est stocké dans le cloud dans un compte de stockage Azure. Les performances doivent être considérées à un autre niveau ici.

Si vous avez des partages très actifs (utilisés par de nombreux utilisateurs et/ou applications), la limite de performances d’un compte de stockage peut être atteinte avec deux partages de fichiers Azure.

Une meilleure pratique consiste à déployer les comptes de stockage avec un partage de fichiers pour chaque. 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.

Ces considérations s’appliquent davantage à l’accès direct au cloud (par le biais d’une machine virtuelle Azure) qu’à Azure File Sync. Si vous envisagez d’utiliser Azure File Sync sur ces partages uniquement, le regroupement de plusieurs partages dans le même compte de stockage Azure est une bonne idée.

Si vous avez établi la liste de vos partages, vous devez mapper chaque partage au compte de stockage dans lequel il résidera.

Durant la phase précédente, vous avez déterminé le nombre de partages approprié. Au cours de cette étape, vous avez un mappage des comptes de stockage aux partages de fichiers. Déployez maintenant le nombre approprié de comptes de stockage Azure avec le nombre approprié de partages de fichiers Azure contenus.

Vérifiez que la région est la même pour tous vos comptes de stockage et qu’elle correspond à la région de la ressource de service de synchronisation de stockage que vous avez déjà déployée.

Attention

Si vous créez un partage de fichiers Azure limité à 100 Tio, il peut utiliser deux options de redondance seulement : un stockage localement redondant ou un stockage redondant interzone. Tenez compte de vos besoins en termes de redondance du stockage avant d’utiliser des partages de fichiers de 100 Tio.

Les partages de fichiers Azure sont toujours créés avec une limite de 5 Tio par défaut. Suivez les étapes de la section Créer un partage de fichiers Azure pour créer un partage de fichiers volumineux.

Quand vous déployez un compte de stockage, vous devez également tenir compte de la redondance du stockage Azure. Consultez Options de redondance de stockage Azure.

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

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

Démarrez cette étape uniquement après avoir terminé la phase précédente. À ce stade, vos ressources de stockage Azure (comptes de stockage et partages de fichiers) doivent être créées. Quand vous commandez votre Data Box, vous devez spécifier les comptes de stockage dans lesquels la Data Box déplace les données.

Au cours de cette phase, vous devez mapper les résultats du plan de migration de la phase précédente aux limites des options Data Box disponibles. Ces considérations vous aideront à établir un plan correspondant aux options Data Box que vous devez choisir et combien d’entre elles vous seront nécessaires pour déplacer vos partages NAS vers des partages de fichiers Azure.

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

  • Une appliance Azure Data Box peut déplacer des données dans un maximum de 10 comptes de stockage.
  • Chaque option Data Box a sa propre capacité utilisable. Consultez Options Data Box.

Consultez votre plan de migration pour trouver le nombre de comptes de stockage que vous avez décidé de créer, ainsi que les partages dans chacun d’entre eux. Examinez ensuite la taille de chaque partage sur votre NAS. La combinaison de ces informations vous sera utile à des fins d’optimisation, ainsi que pour choisir appliance qui devra envoyer des données vers les comptes de stockage. Deux appareils Data Box peuvent déplacer des fichiers dans le même compte de stockage, mais ne répartissent pas le contenu d’un partage de fichiers unique sur deux Data Box.

Options Data Box

Pour une migration standard, choisissez une option ou une combinaison des options Data Box suivantes :

  • Data Box Disk. Microsoft vous enverra entre un et cinq disques SSD avec une capacité de 8 Tio chacun, pour un total maximal de 40 Tio. La capacité utilisable est environ 20 % inférieure en raison du chiffrement et de la surcharge du système de fichiers. Pour plus d’informations, consultez la documentation de Data Box Disk.
  • Data Box. Cette option est la plus courante. Microsoft vous enverra une appliance Data Box renforcée qui fonctionne de façon similaire à un NAS. Elle dispose d’une capacité utilisable de 80 Tio. Pour plus d’informations, consultez la documentationde Data Box.
  • Data Box Heavy. Cette option comprend une appliance Data Box renforcée sur roues qui fonctionne de façon similaire à un NAS. Sa capacité est de 1 Pio. La capacité utilisable est 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 : Provisionner une instance Windows Server locale appropriée

En attendant de recevoir vos appareils Azure Data Box, vous pouvez commencer à examiner les besoins d’une ou plusieurs instances Windows Server que vous utiliserez avec Azure File Sync.

  • Créez une instance Windows Server 2022 (au minimum, Windows Server 2012 R2) comme machine virtuelle ou serveur physique. Un cluster de basculement Windows Server est également pris en charge.
  • Provisionnez ou ajoutez un stockage en attachement direct NAS n’est pas pris en charge.

La configuration des ressources (capacité de calcul et RAM) de l’instance Windows Server que vous déployez dépend principalement du nombre de fichiers et de dossiers que vous allez synchroniser. Nous vous recommandons une configuration haute performance si vous rencontrez des problèmes.

Découvrez comment dimensionner une instance Windows Server en fonction du nombre de fichiers et de dossiers que vous devez synchroniser.

Notes

L’article précédemment lié comprend un tableau avec une plage pour la mémoire du serveur (RAM). Vous pouvez utiliser des nombres dans la partie inférieure de la plage pour votre serveur, mais attendez-vous à ce que la synchronisation initiale prenne beaucoup plus de temps.

Phase 5 : Copier des fichiers sur votre Data Box

Une fois votre DataBox reçue, vous devez la configurer avec une connectivité réseau sans entrave à votre appliance NAS. Suivez la documentation d’installation pour le type de Data Box que vous avez commandé :

Selon le type de Data Box, des outils de copie Data Box peuvent être disponibles. À ce stade, nous ne les recommandons pas pour des migrations vers des partages de fichiers Azure, car ils ne copient pas vos fichiers assez fidèlement sur la Data Box. Utilisez Robocopy à la place.

Quand votre Data Box arrive, elle dispose de partages SMB préprovisionnés pour chaque compte de stockage spécifié au moment de la commande.

  • Si vos fichiers sont placés dans un partage de fichiers Azure Premium, vous disposerez d’un partage SMB par compte de stockage « stockage de fichiers » Premium.
  • Si vos fichiers sont placés dans un compte de stockage standard, vous disposerez de trois partages SMB par compte de stockage standard (GPv1 et GPv2). Seuls les partages de fichiers se terminant par _AzFiles sont pertinents pour votre migration. Ignorez les partages d’objets blob de blocs et de pages.

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

  1. Connectez-vous à Data Box.
  2. Copiez des données sur Data Box.
    Vous pouvez utiliser Robocopy (suivez les instructions ci-dessous) ou le nouveau service de copie de données Data Box.
  3. Préparez votre Data Box pour le chargement sur Azure.

Conseil

En guise d’alternative à Robocopy, Data Box a créé un service de copie de données. Vous pouvez utiliser ce service pour charger des fichiers sur votre Data Box avec une fidélité totale. Suivez ce tutoriel de service de copie de données et veillez à définir la bonne cible de partage de fichiers Azure.

La documentation Data Box spécifie une commande Robocopy. Cette commande ne convient pas pour préserver les fichiers et les dossiers avec fidélité. Utilisez plutôt la commande suivante :

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>
Commutateur Signification
/MT:n Autorise Robocopy à fonctionner en multithread. La valeur par défaut de n est 8. La valeur maximale est de 128 threads. Bien qu’un nombre élevé de threads permette de saturer la bande passante disponible, cela ne signifie pas que votre migration sera toujours plus rapide avec plus de threads. Les tests avec Azure Files indiquent qu’entre 8 et 20 threads affichent des performances équilibrées pour une exécution de copie initiale. Les exécutions suivantes de /MIR sont progressivement affectées par le calcul disponible par rapport à la bande passante réseau disponible. Pour les exécutions suivantes, associez votre valeur de nombre de threads avec plus de précision 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. Les tests avec Azure Files ont montré qu’un nombre maximal de 64 threads offraient de bonnes performances, mais uniquement si vos processeurs peuvent les maintenir actifs en même temps.
/R:n Nombre maximal de tentatives pour un fichier dont la copie échoue à la première tentative. Robocopy s’y prendra à n reprises avant que la copie du fichier n’échoue définitivement lors de l’exécution. Vous pouvez optimiser les performances de votre exécution : choisissez une valeur de deux ou trois si vous pensez que des problèmes de dépassement de délai ont causé des défaillances dans le passé. Cela peut être plus courant sur les liaisons WAN. Choisissez de ne faire aucune nouvelle tentative ou choisissez la valeur 1 si vous pensez que le fichier n’a pas pu être copié parce qu’il était activement utilisé. Une nouvelle tentative quelques secondes plus tard risque de ne pas suffire pour que l’état d’utilisation du fichier change. Les utilisateurs ou les applications qui maintiennent le fichier ouvert peuvent avoir besoin de plus de temps. Dans ce cas, accepter que le fichier n’ait pas été copié et l’intercepter dans l’une de vos exécutions Robocopy ultérieures peut aboutir à la copie du fichier. Cela permet à l’exécution en cours de se terminer plus rapidement sans être prolongée par de nombreuses tentatives qui se terminent principalement en échecs de copie en raison de fichiers toujours ouverts au-delà du délai d’expiration de la nouvelle tentative.
/W:n Spécifie la durée d’attente de Robocopy, avant de tenter la copie d’un fichier qui n’a pas pu être copié à la dernière tentative. n est le nombre de secondes d’attente entre les tentatives. /W:n est souvent utilisé avec /R:n.
/B Exécute Robocopy dans le même mode qu’une application de sauvegarde. Ce commutateur permet à Robocopy de déplacer des fichiers pour lesquels l’utilisateur actuel n’a pas d’autorisations. Le commutateur de sauvegarde dépend de l’exécution de la commande Robocopy dans une console administrateur avec élévation de privilèges ou une fenêtre PowerShell. Si vous utilisez Robocopy pour Azure Files, veillez à monter le partage de fichiers Azure à l’aide de la clé d’accès du compte de stockage et d’une identité de domaine. Si vous ne le faites pas, les messages d’erreur peuvent ne pas vous amener à résoudre le problème de manière intuitive.
/MIR (Mettre en miroir la source sur la cible) Permet à Robocopy de n’avoir à copier que les deltas entre la source et la cible. Les sous-répertoires vides sont copiés. Les éléments (fichiers ou dossiers) qui ont été modifiés ou qui n’existent pas sur la cible sont copiés. Les éléments qui existent sur la cible, mais pas sur la source, sont vidés (supprimés) de la cible. Lorsque vous utilisez ce commutateur, faites correspondre exactement les structures de dossiers source et cible. Correspondance signifie que vous copiez du niveau de source et de dossier qui convient vers le niveau de dossier correspondant sur la cible. C’est la conditions requise pour qu’une copie de « rattrapage » aboutisse. Si la source et la cible ne correspondent pas, l’utilisation de /MIR entraîne des suppressions et des recopies à grande échelle.
/IT Garantit la fidélité dans certains scénarios de mise en miroir.
Par exemple, si un fichier fait l’objet d’une modification de liste de contrôle d’accès et d’une mise à jour d’attribut entre deux exécutions de Robocopy, il est également marqué masqué. Sans /IT, la modification de la liste de contrôle d’accès peut être ignorée par Robocopy et pas transférée vers l’emplacement cible.
/COPY:[copyflags] Fidélité de la copie de fichier. Par défaut : /COPY:DAT. Indicateurs de copie : D=Données, A=Attributs, T=Horodatages, S=Sécurité=ACL NTFS, O=Informations propriétaire, U=Informations aDdit. Les informations d’audit ne peuvent pas être stockées dans un partage de fichiers Azure.
/DCOPY:[copyflags] Fidélité pour la copie de répertoires. Par défaut : /DCOPY:DA. Indicateurs de copie : D = Données, A = Attributs, T = Horodatages.
/NP Spécifie que la progression de la copie de chaque fichier et dossier ne s’affiche pas. L’affichage de la progression réduit considérablement les performances de copie.
/NFL Indique que les noms de fichiers ne sont pas enregistrés dans le journal. Améliore les performances de copie.
/NDL Indique que les noms de répertoires ne sont pas enregistrés dans le journal. Améliore les performances de copie.
/XD Spécifie les répertoires à exclure. Quand vous exécutez Robocopy à la racine d’un volume, envisagez d’exclure le dossier System Volume Information masqué. S’il est utilisé comme il a été conçu, toutes les informations contenues dans celui-ci sont spécifiques au volume exact sur ce système exact et peuvent être reconstruites à la demande. La copie de ces informations n’est pas utile dans le cloud ou lorsque les données sont recopiées sur un autre volume Windows. Le fait de laisser ce contenu ne doit pas être considéré comme une perte de données.
/UNILOG:<file name> Écrit l’état dans le fichier journal au format Unicode. (Remplace le journal existant.)
/L Seulement pour une série de tests
Les fichiers sont seulement répertoriés. Ils ne sont pas copiés ni supprimés, et ne sont pas horodatées. Souvent utilisé avec /TEE pour la sortie de console. Les indicateurs de l’exemple de script, comme /NP, /NFL et /NDL, peuvent devoir être supprimés pour obtenir des résultats de tests dûment documentés.
/LFSM Uniquement pour les cibles avec stockage hiérarchisé. Non pris en charge lorsque la destination est un partage SMB distant.
Spécifie que Robocopy fonctionne en mode « espace libre faible ». Ce commutateur est utile uniquement pour les cibles avec stockage hiérarchisé, susceptibles de manquer de capacité locale avant que Robocopy puisse se terminer. Il a été spécifiquement ajouté à des fins d’utilisation avec une cible de hiérarchisation cloud Azure File Sync activée. Il peut être utilisé indépendamment d’Azure File Sync. Dans ce mode, Robocopy s’interrompt chaque fois qu’une copie de fichier réduit l’espace libre du volume de destination en dessous d’une valeur « plancher ». Cette valeur peut être spécifiée par la forme /LFSM:n de l’indicateur. Le paramètre n est spécifié en base 2 : nKB, nMB ou nGB. Si /LFSM est spécifié sans valeur plancher explicite, le plancher est défini sur 10 % de la taille du volume de destination. Le mode d’espace libre faible n’est pas compatible avec /MT, /EFSRAW ou /ZB. La prise en charge de /B a été ajoutée à Windows Server 2022. Pour plus d’informations, consultez la section Windows Server 2022 et RoboCopy LFSM ci-dessous pour plus d’informations, notamment sur un bogue associé et une solution de contournement.
/Z Utiliser avec prudence
Copie les fichiers en mode de redémarrage. Ce commutateur est recommandé uniquement dans un environnement réseau instable. Elle réduit considérablement les performances de copie en raison d’une journalisation supplémentaire.
/ZB Utiliser avec prudence
Utilise le mode redémarrage. En cas d’accès refusé, cette option utilise le mode de sauvegarde. Cette option réduit considérablement les performances de copie en raison des points de contrôle.

Important

Nous vous recommandons d’utiliser un Windows Server 2022. Lors de l’utilisation d’un Windows Server 2019, vérifiez que le niveau de correctif le plus récent ou au minimum la mise à jour du système d’exploitation KB5005103 est installée. Celle-ci contient des correctifs importants pour certains scénarios Robocopy.

Phase 6 : Déployer la ressource cloud Azure File Sync

Avant de poursuivre, attendez que tous vos fichiers soient arrivés dans les partages de fichiers Azure qui conviennent. Le processus de transmission et d’ingestion des données Data Box prend du temps.

Pour terminer cette étape, vous avez besoin des informations d’identification de votre abonnement Azure.

La ressource principale permettant de configurer Azure File Sync est un service de synchronisation de stockage. Nous vous recommandons d’en déployer un seul pour tous les serveurs synchronisant le même ensemble de fichiers maintenant ou à l’avenir. Ne créez plusieurs services de synchronisation de stockage que si vous avez des ensembles de serveurs distincts qui ne doivent jamais échanger de données. Par exemple, vous pouvez avoir des serveurs qui ne doivent jamais synchroniser le même partage de fichiers Azure. Dans le cas contraire, la meilleure pratique consiste à utiliser un seul service de synchronisation de stockage.

Pour votre service de synchronisation de stockage, choisissez une région Azure proche de votre emplacement. Toutes les autres ressources cloud doivent être déployées dans la même région. Afin de simplifier la gestion, créez un nouveau groupe de ressources dans votre abonnement pour héberger les ressources de synchronisation et de stockage.

Pour plus d’informations, consultez la section concernant le déploiement du service de synchronisation de stockage dans l’article sur le déploiement d’Azure File Sync. Suivez uniquement cette section de l’article. Des liens vers d’autres sections de l’article sont proposés dans des étapes ultérieures.

Phase 7 : Déployer l’agent Azure File Sync

Dans le cadre de cette section, vous allez installer l’agent Azure File Sync sur votre instance Windows Server.

Le Guide de déploiement explique que vous devez désactiver la configuration de sécurité renforcée d’Internet Explorer. Cette mesure de sécurité n’est pas applicable avec Azure File Sync. La désactivation de cette option vous permet de vous authentifier auprès d’Azure sans aucun problème.

Ouvrez PowerShell. Installez les modules PowerShell nécessaires à l’aide des commandes suivantes. Veillez à installer le module complet et le fournisseur NuGet quand vous y êtes invité.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

Si vous rencontrez des problèmes pour accéder à Internet à partir de votre serveur, vous devez les résoudre dès à présent. Azure File Sync peut utiliser n’importe quelle connexion réseau à Internet disponible. L’exigence d’un serveur proxy pour accéder à Internet est également prise en charge. Vous pouvez configurer un proxy au niveau des machines dès maintenant ou spécifier un proxy que la fonctionnalité Azure File Sync sera la seule à utiliser lors de l’installation de l’agent.

Si la configuration d’un proxy implique l’ouverture de vos pare-feu pour le serveur, cette approche est peut-être acceptable pour vous. À la fin de l’installation du serveur, une fois l’inscription du serveur effectuée, un rapport de connectivité réseau indique les URL de point de terminaison exactes dans Azure avec lesquelles Azure File Sync doit communiquer pour la région que vous avez sélectionnée. Le rapport indique également la raison pour laquelle la communication est nécessaire. Vous pouvez utiliser le rapport pour verrouiller les pare-feu autour du serveur sur des URL spécifiques.

Vous pouvez également adopter une approche plus conservatrice dans laquelle vous n’ouvrez pas les pare-feu en grand. Vous pouvez à la place limiter le serveur pour qu’il communique avec des espaces de noms DNS de niveau supérieur. Pour plus d’informations, consultez Paramètres de proxy et de pare-feu d’Azure File Sync. Appliquez vos bonnes pratiques relatives aux réseaux.

À la fin de l’Assistant Installation du serveur, un Assistant Inscription du serveur s’affiche. Inscrivez le serveur auprès de la ressource Azure de votre service de synchronisation du stockage déployée précédemment.

Le guide de déploiement décrit ces étapes plus en détail et traite notamment des modules PowerShell que vous devez installer en premier : Installation de l’agent Azure File Sync.

Utilisez l’agent le plus récent. Vous pouvez aussi le télécharger à partir du Centre de téléchargement Microsoft : Agent Azure File Sync.

Une fois l’installation et l’inscription du serveur terminées, vous pouvez confirmer que vous avez correctement accompli cette étape. Accédez à la ressource du service de synchronisation de stockage dans le portail Azure. Dans le menu de gauche, accédez à Serveurs inscrits. Votre serveur y est répertorié.

Phase 8 : Configurer Azure File Sync sur l’instance Windows Server

Votre instance Windows Server locale inscrite doit être prête et connectée à Internet pour ce processus.

Cette étape lie l’ensemble des ressources et dossiers que vous avez configurés sur votre instance Windows Server au cours des étapes précédentes.

  1. Connectez-vous au portail Azure.
  2. Localisez votre ressource de service de synchronisation de stockage.
  3. Créez un groupe de synchronisation au sein de la ressource de service de synchronisation de stockage pour chaque partage de fichiers Azure. Dans la terminologie Azure File Sync, le partage de fichiers Azure devient un point de terminaison cloud dans la topologie de synchronisation que vous décrivez lors de la création d’un groupe de synchronisation. Lorsque vous créez le groupe de synchronisation, donnez-lui un nom familier qui vous permette de reconnaître le groupe de fichiers qui se synchronise ici. Veillez à référencer le partage de fichiers Azure avec un nom correspondant.
  4. Une fois que vous avez créé le groupe de synchronisation, une ligne apparaît pour lui dans la liste des groupes de synchronisation. Cliquez sur le nom (un lien) du groupe de synchronisation pour afficher son contenu. Votre partage de fichiers Azure apparaît sous Points de terminaison cloud.
  5. Recherchez le bouton Ajouter un point de terminaison de serveur. Le dossier situé sur le serveur local que vous avez approvisionné devient le chemin d’accès pour ce point de terminaison de serveur.

Activez la fonctionnalité de hiérarchisation cloud et sélectionnez Espace de noms uniquement dans la section de téléchargement initial.

Important

La hiérarchisation cloud désigne la fonctionnalité Azure File Sync qui permet au serveur local d’avoir moins de capacité de stockage que ce qui est stocké dans le cloud, tout en ayant l’espace de noms complet disponible. Les données intéressantes localement sont également mises en cache localement pour des performances d’accès rapides. La hiérarchisation cloud est facultative. Vous pouvez la définir individuellement pour chaque point de terminaison de serveur Azure File Sync. Vous devez utiliser cette fonctionnalité si vous ne disposez pas de suffisamment de capacité de disque local sur l’instance Windows Server pour conserver toutes les données cloud et si vous souhaitez éviter de télécharger toutes les données à partir du cloud.

Pour tous les partages de fichiers/emplacements de serveur Azure à configurer pour la synchronisation, effectuez de nouveau les étapes permettant de créer des groupes de synchronisation et d’ajouter les dossiers serveur correspondants comme points de terminaison de serveur. Attendez que la synchronisation de l’espace de noms soit terminée. La section suivante explique comment vérifier que la synchronisation est terminée.

Notes

Après la création d’un point de terminaison de serveur, la synchronisation fonctionne. Toutefois, la synchronisation doit énumérer (découvrir) les fichiers et dossiers que vous avez déplacés par le biais de Data Box dans le partage de fichiers Azure. Selon la taille de l’espace de noms, il peut s’écouler beaucoup de temps avant que l’espace de noms du cloud n’apparaisse sur le serveur.

Phase 9 : Attendre que l’espace de noms apparaisse complètement sur le serveur

Avant de passer aux étapes suivantes de votre migration, attendez que le serveur ait entièrement téléchargé l’espace de noms à partir du partage cloud. Si vous commencez à déplacer des fichiers trop tôt sur le serveur, vous risquez de vous heurter à des téléchargements inutiles voire de provoquer des conflits de synchronisation de fichiers.

Pour déterminer si votre serveur a terminé la synchronisation du téléchargement initial, ouvrez l’observateur d’événements sur votre instance Windows Server en cours de synchronisation et utilisez le journal des événements de télémétrie Azure File Sync. Le journal des événements de télémétrie se trouve dans l’observateur d’événements, sous Applications and Services\Microsoft\FileSync\Agent.

Recherchez l’événement 9102 le plus récent. L’ID d’événement 9102 est enregistré une fois que la session de terminaison se termine. Dans le texte de l’événement, un champ correspond à la direction de synchronisation du téléchargement. (HResult doit être égal à zéro et les fichiers doivent être téléchargés.)

Vous devez voir deux événements consécutifs de ce type, avec ce contenu, pour savoir que le serveur a terminé le téléchargement de l’espace de noms. Il est possible que d’autres événements se trouvent entre les deux événements 9102.

Phase 10 : Exécuter Robocopy à partir de votre NAS

Une fois que votre serveur a terminé la synchronisation initiale de l’espace de noms entier à partir du partage cloud, vous pouvez passer à cette étape. Vous devez vérifier que la synchronisation initiale est terminée avant de passer à cette étape. Pour plus d’informations, consultez la section précédente.

Dans cette étape, vous allez exécuter des travaux Robocopy pour synchroniser vos partages cloud avec les dernières modifications apportées à votre NAS depuis la duplication de vos partages sur la Data Box. Cette exécution de Robocopy peut se terminer rapidement ou prendre un certain temps selon le volume de modifications intervenues sur vos partages NAS.

Avertissement

En raison de la régression du comportement Robocopy dans Windows Server 2019, le commutateur Robocopy /MIR n’est pas compatible avec les répertoires cibles hiérarchisés. Vous ne pouvez pas utiliser le client Windows Server 2019 ou Windows 10 pour cette phase de la migration. Utilisez Robocopy sur une instance Windows Server 2016 intermédiaire.

Voici l’approche de la migration de base :

  • Exécutez Robocopy à partir de votre appliance NAS pour synchroniser votre instance Windows Server.
  • Utilisez Azure File Sync pour synchroniser les partages de fichiers Azure à partir de Windows Server.

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 dossier correspondant sur l’instance Windows Server où Azure File Sync est déjà configuré.
  3. Démarrez la copie à l’aide de Robocopy.

La commande Robocopy suivante copie uniquement les différences (fichiers et dossiers mis à jour) de votre stockage NAS vers votre dossier cible Windows Server. L’instance Windows Server les synchronise ensuite avec les partages 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>
Commutateur Signification
/MT:n Autorise Robocopy à fonctionner en multithread. La valeur par défaut de n est 8. La valeur maximale est de 128 threads. Bien qu’un nombre élevé de threads permette de saturer la bande passante disponible, cela ne signifie pas que votre migration sera toujours plus rapide avec plus de threads. Les tests avec Azure Files indiquent qu’entre 8 et 20 threads affichent des performances équilibrées pour une exécution de copie initiale. Les exécutions suivantes de /MIR sont progressivement affectées par le calcul disponible par rapport à la bande passante réseau disponible. Pour les exécutions suivantes, associez votre valeur de nombre de threads avec plus de précision 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. Les tests avec Azure Files ont montré qu’un nombre maximal de 64 threads offraient de bonnes performances, mais uniquement si vos processeurs peuvent les maintenir actifs en même temps.
/R:n Nombre maximal de tentatives pour un fichier dont la copie échoue à la première tentative. Robocopy s’y prendra à n reprises avant que la copie du fichier n’échoue définitivement lors de l’exécution. Vous pouvez optimiser les performances de votre exécution : choisissez une valeur de deux ou trois si vous pensez que des problèmes de dépassement de délai ont causé des défaillances dans le passé. Cela peut être plus courant sur les liaisons WAN. Choisissez de ne faire aucune nouvelle tentative ou choisissez la valeur 1 si vous pensez que le fichier n’a pas pu être copié parce qu’il était activement utilisé. Une nouvelle tentative quelques secondes plus tard risque de ne pas suffire pour que l’état d’utilisation du fichier change. Les utilisateurs ou les applications qui maintiennent le fichier ouvert peuvent avoir besoin de plus de temps. Dans ce cas, accepter que le fichier n’ait pas été copié et l’intercepter dans l’une de vos exécutions Robocopy ultérieures peut aboutir à la copie du fichier. Cela permet à l’exécution en cours de se terminer plus rapidement sans être prolongée par de nombreuses tentatives qui se terminent principalement en échecs de copie en raison de fichiers toujours ouverts au-delà du délai d’expiration de la nouvelle tentative.
/W:n Spécifie la durée d’attente de Robocopy, avant de tenter la copie d’un fichier qui n’a pas pu être copié à la dernière tentative. n est le nombre de secondes d’attente entre les tentatives. /W:n est souvent utilisé avec /R:n.
/B Exécute Robocopy dans le même mode qu’une application de sauvegarde. Ce commutateur permet à Robocopy de déplacer des fichiers pour lesquels l’utilisateur actuel n’a pas d’autorisations. Le commutateur de sauvegarde dépend de l’exécution de la commande Robocopy dans une console administrateur avec élévation de privilèges ou une fenêtre PowerShell. Si vous utilisez Robocopy pour Azure Files, veillez à monter le partage de fichiers Azure à l’aide de la clé d’accès du compte de stockage et d’une identité de domaine. Si vous ne le faites pas, les messages d’erreur peuvent ne pas vous amener à résoudre le problème de manière intuitive.
/MIR (Mettre en miroir la source sur la cible) Permet à Robocopy de n’avoir à copier que les deltas entre la source et la cible. Les sous-répertoires vides sont copiés. Les éléments (fichiers ou dossiers) qui ont été modifiés ou qui n’existent pas sur la cible sont copiés. Les éléments qui existent sur la cible, mais pas sur la source, sont vidés (supprimés) de la cible. Lorsque vous utilisez ce commutateur, faites correspondre exactement les structures de dossiers source et cible. Correspondance signifie que vous copiez du niveau de source et de dossier qui convient vers le niveau de dossier correspondant sur la cible. C’est la conditions requise pour qu’une copie de « rattrapage » aboutisse. Si la source et la cible ne correspondent pas, l’utilisation de /MIR entraîne des suppressions et des recopies à grande échelle.
/IT Garantit la fidélité dans certains scénarios de mise en miroir.
Par exemple, si un fichier fait l’objet d’une modification de liste de contrôle d’accès et d’une mise à jour d’attribut entre deux exécutions de Robocopy, il est également marqué masqué. Sans /IT, la modification de la liste de contrôle d’accès peut être ignorée par Robocopy et pas transférée vers l’emplacement cible.
/COPY:[copyflags] Fidélité de la copie de fichier. Par défaut : /COPY:DAT. Indicateurs de copie : D=Données, A=Attributs, T=Horodatages, S=Sécurité=ACL NTFS, O=Informations propriétaire, U=Informations aDdit. Les informations d’audit ne peuvent pas être stockées dans un partage de fichiers Azure.
/DCOPY:[copyflags] Fidélité pour la copie de répertoires. Par défaut : /DCOPY:DA. Indicateurs de copie : D = Données, A = Attributs, T = Horodatages.
/NP Spécifie que la progression de la copie de chaque fichier et dossier ne s’affiche pas. L’affichage de la progression réduit considérablement les performances de copie.
/NFL Indique que les noms de fichiers ne sont pas enregistrés dans le journal. Améliore les performances de copie.
/NDL Indique que les noms de répertoires ne sont pas enregistrés dans le journal. Améliore les performances de copie.
/XD Spécifie les répertoires à exclure. Quand vous exécutez Robocopy à la racine d’un volume, envisagez d’exclure le dossier System Volume Information masqué. S’il est utilisé comme il a été conçu, toutes les informations contenues dans celui-ci sont spécifiques au volume exact sur ce système exact et peuvent être reconstruites à la demande. La copie de ces informations n’est pas utile dans le cloud ou lorsque les données sont recopiées sur un autre volume Windows. Le fait de laisser ce contenu ne doit pas être considéré comme une perte de données.
/UNILOG:<file name> Écrit l’état dans le fichier journal au format Unicode. (Remplace le journal existant.)
/L Seulement pour une série de tests
Les fichiers sont seulement répertoriés. Ils ne sont pas copiés ni supprimés, et ne sont pas horodatées. Souvent utilisé avec /TEE pour la sortie de console. Les indicateurs de l’exemple de script, comme /NP, /NFL et /NDL, peuvent devoir être supprimés pour obtenir des résultats de tests dûment documentés.
/LFSM Uniquement pour les cibles avec stockage hiérarchisé. Non pris en charge lorsque la destination est un partage SMB distant.
Spécifie que Robocopy fonctionne en mode « espace libre faible ». Ce commutateur est utile uniquement pour les cibles avec stockage hiérarchisé, susceptibles de manquer de capacité locale avant que Robocopy puisse se terminer. Il a été spécifiquement ajouté à des fins d’utilisation avec une cible de hiérarchisation cloud Azure File Sync activée. Il peut être utilisé indépendamment d’Azure File Sync. Dans ce mode, Robocopy s’interrompt chaque fois qu’une copie de fichier réduit l’espace libre du volume de destination en dessous d’une valeur « plancher ». Cette valeur peut être spécifiée par la forme /LFSM:n de l’indicateur. Le paramètre n est spécifié en base 2 : nKB, nMB ou nGB. Si /LFSM est spécifié sans valeur plancher explicite, le plancher est défini sur 10 % de la taille du volume de destination. Le mode d’espace libre faible n’est pas compatible avec /MT, /EFSRAW ou /ZB. La prise en charge de /B a été ajoutée à Windows Server 2022. Pour plus d’informations, consultez la section Windows Server 2022 et RoboCopy LFSM ci-dessous pour plus d’informations, notamment sur un bogue associé et une solution de contournement.
/Z Utiliser avec prudence
Copie les fichiers en mode de redémarrage. Ce commutateur est recommandé uniquement dans un environnement réseau instable. Elle réduit considérablement les performances de copie en raison d’une journalisation supplémentaire.
/ZB Utiliser avec prudence
Utilise le mode redémarrage. En cas d’accès refusé, cette option utilise le mode de sauvegarde. Cette option réduit considérablement les performances de copie en raison des points de contrôle.

Important

Nous vous recommandons d’utiliser un Windows Server 2022. Lors de l’utilisation d’un Windows Server 2019, vérifiez que le niveau de correctif le plus récent ou au minimum la mise à jour du système d’exploitation KB5005103 est installée. Celle-ci contient des correctifs importants pour certains scénarios Robocopy.

Si vous avez provisionné moins de stockage sur votre instance Windows Server que ce que vos fichiers utilisent sur l’appliance NAS, vous avez configuré la hiérarchisation cloud. À mesure que le volume Windows Server local se remplit, la hiérarchisation cloud intervient et hiérarchise les fichiers qui ont déjà été correctement synchronisés. La hiérarchisation cloud génère suffisamment d’espace pour poursuivre la copie à partir de l’appliance NAS. La hiérarchisation cloud effectue une vérification toutes les heures pour déterminer ce qui a été synchronisé et libérer de l’espace disque pour atteindre l’espace de volume libre de 99 %.

Robocopy devra peut-être déplacer plus de fichiers que vous ne pouvez en stocker localement sur l’instance Windows Server. Vous pouvez vous attendre à ce que Robocopy déplace les fichiers plus rapidement qu’Azure File Sync, lequel ne peut pas les charger et les hiérarchiser à temps sur votre volume local. Dans ce cas, Robocopy échoue. Nous vous recommandons de traiter les partages dans une séquence qui permet d’éviter ce scénario. Par exemple, déplacez uniquement les partages qui tiennent dans l’espace libre disponible sur l’instance Windows Server. Ou évitez de démarrer des tâches Robocopy pour tous les partages en même temps. La bonne nouvelle, c’est que le commutateur /MIR garantit que seuls les deltas sont déplacés. Une fois qu’un delta a été déplacé, un travail redémarré n’a plus besoin de déplacer à nouveau le fichier.

Effectuer le basculement

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. Robocopy traite un répertoire, puis passe au suivant. Un utilisateur sur le NAS peut ensuite ajouter, modifier ou supprimer un fichier sur le premier répertoire qui ne sera pas traité pendant l’exécution actuelle de Robocopy. Il s’agit du comportement attendu.

La première exécution consiste à déplacer la majeure partie des données traitées vers votre instance Windows Server et dans le cloud à l’aide d’Azure File Sync. Cette première copie peut prendre beaucoup de temps selon les paramètres suivants :

  • La bande passante de chargement.
  • La vitesse du réseau local, ainsi que le nombre de threads Robocopy qui y correspondent de manière optimale.
  • Le nombre d’éléments (fichiers et dossiers) qui doivent être traités par Robocopy et Azure File Sync.

Une fois l’exécution initiale terminée, réexécutez la commande.

Robocopy se termine plus rapidement la deuxième fois que vous l’exécutez pour un partage. En effet, seules les modifications effectuées depuis la dernière exécution doivent être déplacées. 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 méthode empêchant les utilisateurs de modifier la structure des fichiers et des dossiers, ainsi que leur contenu. Par exemple, vous pouvez pointer votre espace de noms DFS vers un emplacement qui n’existe pas ou changer les ACL racine sur le partage.

Exécutez Robocopy une dernière fois pour traiter toutes les modifications qui n’ont pas encore été prises en compte. 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 car les utilisateurs sont dans Active Directory et Robocopy copie fidèlement les fichiers et les métadonnées. Si vous avez utilisé des utilisateurs locaux sur votre NAS, vous devez :

  • Recréer ces utilisateurs en tant qu’utilisateurs locaux de Windows Server.
  • Mapper les SID existants déplacés par Robocopy vers votre instance Windows Server aux SID de vos nouveaux utilisateurs locaux de Windows Server.

Vous avez terminé la migration d’un partage ou d’un groupe de partages vers une racine ou un volume commun (selon votre mappage dans la phase 1).

Vous pouvez essayer d’exécuter quelques-unes de ces copies en parallèle. Nous vous recommandons de traiter l’étendue d’un partage de fichiers Azure à la fois.

Option obsolète : « transfert de données hors connexion »

Avant la sortie de la version 13 de l’agent Azure File Sync, l’intégration de Data Box était réalisée par un processus appelé « transfert de données hors connexion ». Ce processus est déconseillé et vous ne pouvez plus créer un point de terminaison de serveur en mode « transfert de données hors connexion ». Avec la version 13 de l’agent, il a été remplacé par la procédure bien plus simple et rapide décrite dans cet article.

Dépannage

Le problème le plus courant est un échec de la commande Robocopy de type « Volume plein » côté Windows Server. Toutes les heures, la hiérarchisation cloud retire le contenu du disque Windows Server local qui a été synchronisé. Son objectif est d’atteindre 99 % d’espace libre sur le volume.

Laissez la synchronisation s’effectuer et la hiérarchisation cloud libérer l’espace disque. Vous pouvez observer l’opération dans l’Explorateur de fichiers sur votre instance Windows Server.

Quand la capacité disponible de votre instance Windows Server est suffisante, réexécutez la commande pour résoudre le problème. Tout fonctionne dans cette situation. Vous pouvez continuer en toute confiance. La nécessité de réexécuter la commande représente le seul inconvénient.

Pour résoudre les problèmes liés à Azure File Sync, consultez l’article indiqué dans la section suivante.

Étapes suivantes

Les articles suivants vous aideront à comprendre les options avancées et les meilleures pratiques pour Azure Files et Azure File Sync.