Uso de Data Box para migrar de un almacenamiento conectado a la red (NAS) a una implementación de nube híbrida con Azure File Sync

Este artículo de migración es uno de los que se aplican a las palabras clave NAS, Azure File Sync y Azure Data Box. Compruebe si este artículo se aplica a su escenario:

• Origen de datos: almacenamiento conectado a la red (NAS)
• Ruta de migración: NAS ⇒ Data Box ⇒ recurso compartido de archivos de Azure ⇒ sincronización con Windows Server
• Almacenamiento en caché de archivos locales: sí, el objetivo final es una implementación de Azure File Sync

Si el escenario es diferente, examine la tabla de guías de migración.

Azure File Sync funciona en ubicaciones de almacenamiento de conexión directa (DAS). No admite la sincronización con ubicaciones de almacenamiento conectado a la red (NAS). Por esta razón, debe migrar los archivos. Este artículo le guía a través del planeamiento y la implementación de esta migración.

Se aplica a

Tipo de recurso compartido de archivos	SMB	NFS
Recursos compartidos de archivos Estándar (GPv2), LRS/ZRS
Recursos compartidos de archivos Estándar (GPv2), GRS/GZRS
Recursos compartidos de archivos Premium (FileStorage), LRS/ZRS

Objetivos de la migración

El objetivo es trasladar los recursos compartidos que tiene en el dispositivo NAS a Windows Server. Después, usará Azure File Sync para una implementación de nube híbrida. Esta migración se debe realizar de forma que garantice la integridad de los datos de producción y la disponibilidad durante la migración. Esta última requiere que el tiempo de inactividad sea mínimo, para cumplir o solo superar ligeramente las ventanas de mantenimiento regulares.

Información general sobre la migración

El proceso de migración consta de varias fases. Necesitará:

• Implementar cuentas de almacenamiento y recursos compartidos de archivos de Azure
• Implementar un equipo local que ejecute Windows Server
• Configure Azure File Sync.
• Migrar archivos mediante Robocopy
• Realizar la transición

En las secciones siguientes se describen detalladamente las fases del proceso de migración.

Sugerencia

Si vuelve a este artículo, use la navegación del lado derecho de la pantalla para saltar a la fase de migración en la que se quedó.

Fase 1: Determinación del número de recursos compartidos de archivos de Azure que necesita

En este paso, establecerá cuántos recursos compartidos de archivos de Azure se necesitan. Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure.

Es posible que tenga más carpetas en los volúmenes que actualmente comparte localmente como recursos compartidos de SMB en sus usuarios y aplicaciones. La manera más sencilla de visualizar este escenario es imaginar un recurso compartido local que asigne 1:1 a un recurso compartido de archivos de Azure. Si tiene un número suficientemente pequeño de recursos compartidos, por debajo de 30 para una sola instancia de Windows Server, se recomienda una asignación 1:1.

Si tiene más de 30 recursos compartidos, a menudo no es necesaria la asignación 1:1 de recursos compartidos locales a un recurso compartido de archivos de Azure. Considere las opciones siguientes.

Agrupación de recursos compartidos

Por ejemplo, si el departamento de RR. HH. tiene 15 recursos compartidos, podría considerar la posibilidad de almacenar todos los datos de RR. HH. en un solo recurso compartido de archivos de Azure. El almacenamiento de varios recursos compartidos locales en un recurso compartido de archivos de Azure no evita que tenga que crear los 15 recursos compartidos de SMB habituales en la instancia local de Windows Server. Solo significa que organiza las carpetas raíz de estos 15 recursos compartidos como subcarpetas en una carpeta común. A continuación, sincronizará esta carpeta común con un recurso compartido de archivos de Azure. De este modo, solo se necesita un único recurso compartido de archivos de Azure en la nube para este grupo de recursos compartidos locales.

Sincronización de volúmenes

Azure File Sync admite la sincronización de la raíz de un volumen con un recurso compartido de archivos de Azure. Si sincroniza la raíz del volumen, todas las subcarpetas y los archivos van al mismo recurso compartido de archivos de Azure.

La sincronización de la raíz del volumen no siempre es la mejor opción. La sincronización de varias ubicaciones ofrece varias ventajas. Por ejemplo, ayuda a disminuir el número de elementos por ámbito de sincronización. Probamos los recursos compartidos de archivos de Azure y Azure File Sync con 100 millones de elementos (archivos y carpetas) por recurso compartido. Pero un procedimiento es intentar mantener el número por debajo de 20 o 30 millones en un solo recurso compartido. La configuración de Azure File Sync con un número de elementos menor no solo es beneficiosa para la sincronización de archivos. Un menor número de elementos también beneficia a escenarios como estos:

• El examen inicial del contenido de la nube puede realizarse más rápido, lo que a su vez reduce la espera de que aparezca el espacio de nombres en un servidor habilitado para Azure File Sync.
• La restauración en la nube a partir de una instantánea de recursos compartidos de archivos de Azure se hará con mayor rapidez.
• La recuperación ante desastres de un servidor local puede acelerarse de forma considerable.
• Los cambios hechos directamente en un recurso compartido de archivos de Azure (sin sincronización) se pueden detectar y sincronizar más rápido.

Sugerencia

Si no está seguro de cuántos archivos y carpetas tiene, consulte la herramienta TreeSize de JAM Software GmbH.

Un enfoque estructurado de una asignación de implementación

Antes de implementar el almacenamiento en la nube en un paso posterior, es importante crear una asignación entre carpetas locales y recursos compartidos de archivos de Azure. Esta asignación informará de cuántos recursos del grupo de sincronización de Azure File Sync se van a aprovisionar y de cuáles van a ser. Un grupo de sincronización está relacionado con el recurso compartido de archivos de Azure y la carpeta de su servidor, y establece una conexión de sincronización.

Para decidir cuántos recursos compartidos de archivos de Azure necesita, revise los límites y procedimientos recomendados siguientes. Eso le va a ayudar a optimizar la asignación.

• Un servidor donde está instalado el agente de Azure File Sync puede sincronizarse con hasta 30 recursos compartidos de archivos de Azure.

• Un recurso compartido de archivos de Azure se implementa en una cuenta de almacenamiento. Esta disposición hace que la cuenta de almacenamiento sea un destino de escalado para los números de rendimiento, como IOPS y rendimiento.

  Preste atención a las limitaciones de IOPS de una cuenta de almacenamiento al implementar recursos compartidos de archivos de Azure. Lo ideal sería asignar recursos compartidos de archivos 1:1 con cuentas de almacenamiento. Pero quizás no sea posible debido a diversos límites y restricciones, tanto de su organización como de Azure. Cuando no sea posible tener un solo recurso compartido de archivos implementado en una cuenta de almacenamiento, tenga en cuenta qué recursos compartidos estarán muy activos y cuales estarán menos activos, con el fin de asegurarse de que los recursos compartidos de archivos más activos no se colocan en la misma cuenta de almacenamiento.

  Si tiene previsto mover una aplicación a Azure que usará el recurso compartido de archivos de Azure de forma nativa, es posible que necesite un mayor rendimiento del recurso compartido de archivos de Azure. Si este tipo de uso es una posibilidad, incluso en el futuro, lo mejor es crear un único recurso compartido de archivos de Azure estándar en su propia cuenta de almacenamiento.

• Hay un límite de 250 cuentas de almacenamiento por suscripción por cada región de Azure.

Sugerencia

Teniendo en cuenta esta información, suele ser necesario agrupar varias carpetas de nivel superior de sus volúmenes en un nuevo directorio raíz común. Luego se sincroniza este nuevo directorio raíz y todas las carpetas agrupadas en él, en un solo recurso compartido de archivos de Azure. Esta técnica permite permanecer dentro del límite de 30 sincronizaciones de recursos compartidos de archivos de Azure por servidor.

Esta agrupación bajo una raíz común no afecta al acceso a sus datos. Las ACL se mantienen como están. Solo tiene que ajustar algunas rutas de acceso a los recursos compartidos (como las de los recursos compartidos SMB o NFS) que podría haber en las carpetas de servidor locales que ahora han cambiado a una raíz común. No cambia nada más.

Importante

El vector de escala más importante para Azure File Sync es el número de elementos (archivos y carpetas) que tienen que sincronizarse. Para más información, revise los objetivos de escala de Azure File Sync.

Se recomienda mantener bajo el número de elementos por ámbito de sincronización. Ese es un factor importante que se debe tener en cuenta en la asignación de carpetas a recursos compartidos de archivos de Azure. Azure File Sync se prueba con 100 millones elementos (archivos y carpetas) por recurso compartido. Pero a menudo es mejor mantener el número de elementos por debajo de 20 o 30 millones en un solo recurso compartido. Divida el espacio de nombres en varios recursos compartidos si empieza a superar estos números. Puede seguir agrupando varios recursos compartidos locales en el mismo recurso compartido de archivos de Azure, siempre y cuando se mantenga aproximadamente por debajo de estos números. Esto le proporcionará más espacio para crecer.

En una situación tal, es posible que un conjunto de carpetas pueda sincronizarse de forma lógica con el mismo recurso compartido de archivos de Azure (mediante el nuevo enfoque de carpeta raíz común mencionado anteriormente). Pero puede que siga siendo mejor reagrupar carpetas de modo que se sincronicen con dos recursos compartidos de archivos de Azure en lugar de uno. Puede usar este enfoque para mantener equilibrado el número de archivos y carpetas por recurso compartido de archivos en el servidor. También puede dividir los recursos compartidos locales y sincronizarlos entre más servidores locales, lo que agrega la posibilidad de sincronizar 30 recursos compartidos de archivos de Azure más por cada servidor adicional.

Escenarios y consideraciones comunes de sincronización de archivos

#	Escenario de sincronización	Compatible	Consideraciones (o limitaciones)	Solución (o solución alternativa)
1	Servidor de archivos con varios discos o volúmenes y varios recursos compartidos en el mismo recurso compartido de archivos de Azure de destino (consolidación)	No	Un recurso compartido de archivos de Azure de destino (punto de conexión en la nube) solo admite la sincronización con un grupo de sincronización. Un grupo de sincronización solo admite un punto de conexión de servidor por servidor registrado.	1) Comience con la sincronización de un disco (su volumen raíz) para el recurso compartido de archivos de Azure de destino. Empezar con el disco o volumen más grande, ayudará con los requisitos de almacenamiento locales. Configure la nube por niveles para organizar en capas todos los datos en la nube, lo que libera espacio en el disco del servidor de archivos. Mueva datos de otros volúmenes o recursos compartidos al volumen actual que se está sincronizando. Continúe los pasos uno por uno hasta que todos los datos estén en capas en la nube o migrados. 2) Tenga un solo volumen raíz (disco) como destino a la vez. Use la nube por niveles para organizar en capas todos los datos para tener como destino el recurso compartido de archivos de Azure. Quite el punto de conexión de servidor del grupo de sincronización, vuelva a crear el punto de conexión con el siguiente volumen o disco raíz, sincronice y repita el proceso. Nota: Es posible que sea necesario volver a instalar el agente. 3) Se recomienda usar varios recursos compartidos de archivos de Azure de destino (misma o diferente cuenta de almacenamiento en función de los requisitos de rendimiento)
2	Servidor de archivos con un único volumen y varios recursos compartidos en el mismo recurso compartido de archivos de Azure de destino (consolidación)	Sí	No se pueden tener varios puntos de conexión de servidor por servidor registrado que se sincronicen con el mismo recurso compartido de archivos de Azure de destino (igual que anteriormente)	Sincronice la raíz del volumen que contiene varios recursos compartidos o carpetas de nivel superior. Consulte Concepto de agrupación de recursos compartidos y Sincronización de volúmenes para obtener más información.
3	Servidor de archivos con varios recursos compartidos o volúmenes en varios recursos compartidos de archivos de Azure en una sola cuenta de almacenamiento (asignación de recursos compartidos de 1:1)	Sí	Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure. Una cuenta de almacenamiento es un destino de escalado para el rendimiento. IOPS y el rendimiento se comparten entre recursos compartidos de archivos. Mantenga el número de elementos por grupo de sincronización por debajo de 100 millones de elementos (archivos y carpetas) por recurso compartido. Idealmente, es mejor permanecer por debajo de 20 o 30 millones por recurso compartido.	1) Use varios grupos de sincronización (número de grupos de sincronización = número de recursos compartidos de archivos de Azure con los que sincronizar). 2) Solo se pueden sincronizar 30 recursos compartidos en este escenario a la vez. Si tiene más de 30 recursos compartidos en ese servidor de archivos, use el concepto de agrupación de recursos compartidos y la sincronización de volúmenes para reducir el número de carpetas raíz o de nivel superior en el origen. 3) Use servidores File Sync adicionales locales y divida o mueva datos a estos servidores para solucionar las limitaciones del servidor Windows de origen.
4	Servidor de archivos con varios recursos compartidos o volúmenes en varios recursos compartidos de archivos de Azure en una cuenta de almacenamiento diferente (asignación de recursos compartidos de 1:1)	Sí	Una sola instancia de Windows Server (o clúster) puede sincronizar hasta 30 recursos compartidos de archivos de Azure (la misma cuenta de almacenamiento o una diferente). Mantenga el número de elementos por grupo de sincronización por debajo de 100 millones de elementos (archivos y carpetas) por recurso compartido. Idealmente, es mejor permanecer por debajo de 20 o 30 millones por recurso compartido.	El mismo enfoque que más arriba
5	Varios servidores de archivos con un único (volumen raíz o recurso compartido) en el mismo recurso compartido de archivos de Azure de destino (consolidación)	No	Un grupo de sincronización no puede usar el punto de conexión en la nube (recurso compartido de archivos de Azure) ya configurado en otro grupo de sincronización. Aunque un grupo de sincronización puede tener puntos de conexión de servidor en distintos servidores de archivos, los archivos no pueden ser distintos.	Siga las instrucciones del escenario n.º 1 anterior con una consideración adicional sobre tener un único servidor de archivos como destino a la vez.

Creación de una tabla de asignación

Use la información anterior para decidir cuántos recursos compartidos de archivos de Azure necesita, y qué partes de los datos existentes terminarán en cuál recurso compartido de archivos de Azure.

Cree una tabla para registrar sus ideas, de modo que pueda consultarla cuando sea necesario. La organización es importante, ya que puede ser fácil perder detalles del plan de asignación cuando se aprovisionan muchos recursos de Azure a la vez. Descargue el siguiente archivo de Excel para usarlo como plantilla para ayudar a crear la asignación.

Descargue una plantilla de asignación de espacios de nombres.

Fase 2: Implementación de recursos de almacenamiento de Azure

En esta fase, consulte la tabla de asignación de la fase 1 y úsela para aprovisionar el número correcto de cuentas de almacenamiento de Azure y recursos compartidos de archivos que contienen.

Un recurso compartido de archivos de Azure en la nube en una cuenta de almacenamiento de Azure. Aquí se aplica otro nivel de consideraciones relativas al rendimiento.

Si tiene recursos compartidos muy activos (recursos compartidos que usan muchos usuarios o aplicaciones), dos recursos compartidos de archivos de Azure podrían alcanzar el límite de rendimiento de una cuenta de almacenamiento.

Un procedimiento recomendado es implementar cuentas de almacenamiento con un recurso compartido de archivos cada una. Puede agrupar varios recursos compartidos de archivos de Azure en la misma cuenta de almacenamiento si tiene recursos compartidos de archivo o que espera que tengan escasa actividad diaria.

Estas consideraciones se aplican más al acceso directo a la nube (a través de una VM de Azure) que a Azure File Sync. Si tiene pensado usar solo Azure File Sync en estos recursos compartidos, es correcta la agrupación de varios en una sola cuenta de almacenamiento de Azure.

Si ha creado una lista de recursos compartidos, tiene que asignar cada recurso compartido a la cuenta de almacenamiento en la que se encontrará.

En la fase anterior, estableció el número adecuado de recursos compartidos. En este paso, tiene una asignación de cuentas de almacenamiento a recursos compartidos de archivos. Ahora debe implementar el número adecuado de cuentas de almacenamiento de Azure con el número adecuado de recursos compartidos de archivos de Azure en ellas.

Asegúrese de que la región de cada una de las cuentas de almacenamiento sea la misma y coincida con la región del recurso del servicio de sincronización de almacenamiento que ya ha implementado.

Precaución

Si crea un recurso compartido de archivos de Azure con un límite de 100 TiB, ese recurso compartido puede usar solo las opciones de redundancia de almacenamiento con redundancia local o de zona. Tenga en cuenta sus necesidades de redundancia de almacenamiento antes de usar recursos compartidos de archivos de 100 TiB.

Los recursos compartidos de archivos de Azure todavía se crean con un límite de 5 TiB de forma predeterminada. Para crear un recurso compartido de archivos grande, siga los pasos de Creación de un recurso compartido de archivos de Azure.

Otra consideración a la hora de implementar una cuenta de almacenamiento es la redundancia de Azure Storage. Consulte las Opciones de redundancia de Azure Storage.

Los nombres de los recursos también son importantes. Por ejemplo, si agrupa varios recursos compartidos para el Departamento de Recursos Humanos en una cuenta de almacenamiento de Azure, debe asignar el nombre adecuado a la cuenta de almacenamiento. Del mismo modo, al asignar el nombre a los recursos compartidos de archivos de Azure, tiene que usar nombres similares a los que se usan para sus homólogos locales.

Fase 3: Determinación del número de dispositivos de Azure Data Box que necesita

Inicie este paso solo después de haber finalizado la fase anterior. Los recursos de almacenamiento de Azure Storage (cuentas de almacenamiento y recursos compartidos de archivos) se deben crear en este momento. Al solicitar su Data Box, debe especificar las cuentas de almacenamiento a las que Data Box se mueve.

En esta fase, debe asignar los resultados del plan de migración de la fase anterior a los límites de las opciones de Data Box disponibles. Estas consideraciones le ayudarán a crear un plan para las opciones de Data Box que se van a elegir, así como cuántas necesitará para mover los recursos compartidos de NAS a recursos compartidos de archivos de Azure.

Para determinar el número de dispositivos que necesita y sus tipos, tenga en cuenta estos límites importantes:

• Cualquier dispositivo de Azure Data Box puede mover datos a un máximo de 10 cuentas de almacenamiento.
• Cada opción de Data Box viene con su propia capacidad utilizable. Consulte opciones de Data Box.

Consulte el plan de migración para encontrar el número de cuentas de almacenamiento que ha decidido crear y los recursos compartidos en cada una de ellas. A continuación, examine el tamaño de cada uno de los recursos compartidos de NAS. La combinación de esta información le permitirá optimizar y decidir qué dispositivo debe enviar datos a las cuentas de almacenamiento. Dos dispositivos de Data Box pueden trasladar los archivos a la misma cuenta de almacenamiento, pero no divida el contenido de un solo recurso compartido de archivos en dos instancias de Data Box.

Opciones de Data Box

Para una migración estándar, elija una combinación de estas opciones de Data Box:

• Data Box Disk. Data Box Disks: Microsoft le enviará entre uno y cinco discos SSD con una capacidad de 8 TiB cada uno, con un total de 40 TiB como máximo. La capacidad utilizable es aproximadamente un 20 % menor debido al cifrado y la sobrecarga del sistema de archivos. Para más información, consulte la documentación de Data Box Disk.
• Data Box. Esta opción es la más común. Microsoft le enviará un dispositivo de Data Box resistente que funciona de forma similar a un NAS. Tiene una capacidad utilizable de 80 TiB. Para más información, consulte la documentación de Data Box.
• Data Box Heavy. Esta opción presenta un dispositivo Data Box resistente en ruedas, que funciona de forma similar a un NAS. Tiene una capacidad de 1 PiB. La capacidad utilizable es aproximadamente un 20 % menor debido al cifrado y la sobrecarga del sistema de archivos. Para más información, consulte la documentación de Data Box Heavy.

Fase 4: Aprovisionamiento de una instancia de Windows Server adecuada en el entorno local

Mientras espera a que lleguen los dispositivos Azure Data Box, puede empezar a revisar las necesidades de una o más instancias de Windows Server que va a usar con Azure File Sync.

• Cree una instancia de Windows Server 2022 (como mínimo, Windows Server 2012 R2) como una máquina virtual o un servidor físico. También se admite un clúster de conmutación por error de Windows Server.
• Aprovisione o agregue almacenamiento de conexión directa NAS no es compatible.

La configuración de recursos (de proceso y RAM) de la instancia de Windows Server que implemente depende principalmente del número de archivos y carpetas que se van a sincronizar. Se recomienda una configuración de rendimiento más alto si tiene problemas.

Aprenda a cambiar el tamaño de una instancia de Windows Server según el número de elementos que necesite sincronizar.

Nota:

El artículo vinculado anteriormente incluye una tabla con un intervalo de memoria del servidor (RAM). Puede usar los números del extremo inferior del intervalo para el servidor, pero probablemente la sincronización inicial tardará mucho más.

Fase 5: Copia de archivos en el dispositivo Data Box

Cuando llegue el dispositivo Data Box, deberá configurarlo con conectividad de red no impedida a su dispositivo NAS. Siga la documentación de establecimiento del tipo de Data Box que solicitó:

• Configuración de Data Box.
• Configuración de Data Box Disk.
• Configuración de Data Box Heavy.

Dependiendo del tipo de Data Box, las herramientas de copia de Data Box podrían estar disponibles. En este punto, no se recomiendan para las migraciones a recursos compartidos de archivos de Azure porque no copian los archivos en el dispositivo Data Box con total fidelidad. En su lugar, use RoboCopy.

Cuando llegue el dispositivo Data Box, tendrá recursos compartidos de SMB aprovisionados previamente disponibles para cada cuenta de almacenamiento que especificó cuando lo solicitó.

• Si los archivos entran en un recurso compartido de archivos prémium de Azure, habrá un recurso compartido de SMB por cuenta de almacenamiento de "almacenamiento de archivos" prémium.
• Si los archivos entran en una cuenta de almacenamiento estándar, habrá tres recursos compartidos de SMB por cuenta de almacenamiento estándar (GPv1 y GPv2). Solo los recursos compartidos de archivos que terminan con _AzFiles son pertinentes para la migración. Omita los recursos compartidos de blob en bloques y en páginas.

Siga los pasos descritos en la documentación de Azure Data Box:

1. Conexión a un dispositivo Data Box.
2. Copia de datos a un dispositivo Data Box.
   Puede usar Robocopy (siga las instrucciones que se incluyen a continuación) o el nuevo servicio de copia de datos de Data Box.
3. Preparación del dispositivo Data Box para cargarlo en Azure.

Sugerencia

Como alternativa a Robocopy, Data Box ha creado un servicio de copia de datos. Puede usar este servicio para cargar archivos en Data Box con plena fidelidad. Siga este tutorial sobre el servicio de copia de datos y asegúrese de establecer el destino correcto del recurso compartido de archivos de Azure.

La documentación de Data Box especifica un comando Robocopy. Ese comando no es adecuado para conservar la fidelidad completa de archivos y carpetas. En su lugar, use este comando:

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> 

Conmutador	Significado
/MT:n	Permite que Robocopy se ejecute en modo multiproceso. El valor predeterminado para n es 8. La cantidad máxima es de 128 subprocesos. Aunque un número elevado de subprocesos contribuye a saturar el ancho de banda disponible, no significa que la migración sea siempre más rápida con más subprocesos. Las pruebas realizadas con Azure Files indican que entre 8 y 20 proporcionan un rendimiento equilibrado para la ejecución de una copia inicial. Las ejecuciones subsiguientes de /MIR se ven afectadas progresivamente por el proceso disponible en comparación con el ancho de banda de red disponible. Para las ejecuciones posteriores, haga coincidir más estrechamente el valor del número de subprocesos con el número de núcleos del procesador y el número de subprocesos por núcleo. Considere si es necesario reservar los núcleos para otras tareas que quizá tenga un servidor de producción. Las pruebas realizadas con Azure Files han demostrado que, con un máximo de 64 subprocesos, se obtiene un buen rendimiento, pero solo si los procesadores pueden mantenerlos activos al mismo tiempo.
/R:n	Número máximo de reintentos para un archivo que no se puede copiar en el primer intento. Robocopy prueba n veces antes de determinar que el archivo, definitivamente, no se copia en la ejecución. Para optimizar el rendimiento de la ejecución, elija un valor de dos o tres si cree que hubo problemas de tiempo de espera que causaron errores en el pasado. Esto puede ser más habitual a través de vínculos WAN. Elija no reintentarlo o un valor de uno si cree que el archivo no se pudo copiar porque estaba en uso de forma activa. Volver a intentarlo unos segundos más tarde puede no ser suficiente tiempo para que cambie el estado de “en uso” del archivo. Es posible que los usuarios o aplicaciones que tienen abierto el archivo necesiten más tiempo. En este caso, puede que, si acepta que el archivo no se ha copiado y lo incluye en una ejecución posterior planeada de Robocopy, el archivo se copie finalmente. Esto ayuda a que la ejecución en curso finalice más rápido al no prolongarla con muchos reintentos que, al final, dan lugar a una mayoría de errores de copia porque los archivos siguen abiertos después del tiempo de espera de reintento.
/W:n	Especifica el tiempo que espera Robocopy antes de intentar copiar un archivo que no se ha copiado correctamente en el último intento. n es el número de segundos de espera entre reintentos. /W:n a menudo se usa junto con /R:n.
/B	Ejecuta Robocopy en el mismo modo que usaría una aplicación de copia de seguridad. Este conmutador permite que Robocopy mueva los archivos para los que el usuario actual no tiene permisos. El modificador de la copia de seguridad depende de la ejecución del comando Robocopy en una consola con privilegios elevados de administrador o en una ventana de PowerShell. Si usa Robocopy para Azure Files, asegúrese de montar el recurso compartido de archivos de Azure con la clave de acceso de la cuenta de almacenamiento en lugar de una identidad de dominio. Si no lo hace, es posible que los mensajes de error no lo lleven intuitivamente a una solución del problema.
/MIR	(Reflejar origen en destino). Permite que Robocopy solo tenga que copiar las diferencias entre el origen y el destino. Se copiarán los subdirectorios vacíos. Se copiarán los elementos (archivos o carpetas) que hayan cambiado o no existan en el destino. Los elementos que existan en el destino, pero no en el origen, se purgarán (se eliminarán) del destino. Cuando use este conmutador, haga coincidir exactamente con las estructuras de carpetas de origen y de destino. Coincidencia significa que se copia desde el nivel de carpeta y origen correctos en el nivel de carpeta del destino coincidente. Solo entonces se puede realizar correctamente una copia de "puesta al día". Cuando el origen y el destino no coinciden, el uso de /MIR dará lugar a eliminaciones y nuevas copias a gran escala.
/IT	Garantiza que se conserve la fidelidad en ciertos escenarios de reflejo. Por ejemplo, si un archivo experimenta un cambio de ACL y una actualización de atributo entre dos ejecuciones de Robocopy, se marca como oculto. Sin /IT, Robocopy podría omitir el cambio de ACL y no se transferiría a la ubicación de destino.
/COPY:[copyflags]	Fidelidad de la copia del archivo. Predeterminado: /COPY:DAT. Marcas de copia: D = datos, A = atributos, T = marcas de tiempo, S = seguridad = ACL de NTFS, O = información del propietario, U = información de aDditoría. No se puede almacenar la información de auditoría en un recurso compartido de archivos de Azure.
/DCOPY:[copyflags]	Fidelidad de la copia de directorios. Predeterminado: /DCOPY:DA. Marcas de copia: D = Datos, A = Atributos, T = Marcas de tiempo.
/NP	Especifica que no se mostrará el progreso de la copia de cada archivo y carpeta. Mostrar el progreso reduce significativamente el rendimiento de la copia.
/NFL	Especifica que los nombres de archivo no se han registrado. Mejora el rendimiento de la copia.
/NDL	Especifica que los nombres de directorio no se han registrado. Mejora el rendimiento de la copia.
/XD	Especifica los directorios que se excluirán. Cuando ejecute Robocopy en la raíz de un volumen, considere la posibilidad de excluir la carpeta System Volume Information oculta. Si se usa como está previsto, toda la información que contiene es específica del volumen exacto en este sistema exacto y se puede recompilar a petición. Copiar esta información no será útil en la nube ni cuando los datos se vuelvan a copiar en otro volumen Windows. Dejar este contenido atrás no debe considerarse una pérdida de datos.
/UNILOG:<file name>	Escribe el estado en el archivo de registro como Unicode. (Sobrescribe el registro existente).
/L	Solo para una ejecución de prueba Los archivos solo se mostrarán en la lista. No se copiarán, no se eliminarán y no tendrán marca de tiempo. Por lo general, se usa con /TEE para la salida de la consola. Es posible que las marcas del script de ejemplo, como /NP, /NFL y /NDL, se tengan que quitar para lograr los resultados de la prueba documentados correctamente.
/LFSM	Solo para destinos con almacenamiento en niveles. No se admite cuando el destino sea un recurso compartido de SMB remoto. Especifica que Robocopy funciona en "modo de espacio libre bajo". Este conmutador solo es útil para destinos con almacenamiento en capas que pueden quedarse sin capacidad local antes de que Robocopy finalice. Se agregó específicamente para su uso con un destino habilitado de nube por niveles de Azure File Sync. Se puede usar con independencia de Azure File Sync. En este modo, Robocopy se pondrá en pausa siempre que una copia de archivo haga que el espacio disponible del volumen de destino se sitúe por debajo de un valor de "suelo". El formato /LFSM:n de la marca puede especificar este valor. El parámetro n se especifica en la base 2: nKB, nMB o nGB. Si /LFSM se especifica sin ningún valor floor explícito, floor se establece en el 10 por ciento del tamaño del volumen de destino. El modo de espacio libre bajo no es compatible con /MT, /EFSRAW ni /ZB. Se agregó compatibilidad con /B en Windows Server 2022. Consulte la sección Windows Server 2022 y RoboCopy LFSM a continuación para obtener más información, incluidos detalles sobre un error y una solución alternativa relacionados.
/Z	Usar con precaución Copia los archivos en modo de reinicio. Este conmutador solo se recomienda en un entorno de red inestable. Reduce significativamente el rendimiento de la copia debido al registro adicional.
/ZB	Usar con precaución Usa el modo de reinicio. Si se deniega el acceso, esta opción utiliza el modo de copia de seguridad. Esta opción reduce significativamente el rendimiento de la copia debido a los puntos de control.

Importante

Se recomienda usar Windows Server 2022. Cuando use Windows Server 2019, asegúrese de que está instalado con el nivel de revisión más reciente o, al menos, la actualización KB5005103 del sistema operativo. Contiene correcciones importantes para determinados escenarios de Robocopy.

Fase 6: Implementación del recurso de nube de Azure File Sync

Antes de continuar con esta guía, espere hasta que todos los archivos hayan llegado a los recursos compartidos de archivos de Azure correctos. El proceso de envío e ingesta de datos de Data Box llevará tiempo.

Para completar este paso, necesita las credenciales de la suscripción a Azure.

El recurso principal para configurar Azure File Sync se denomina servicio de sincronización de almacenamiento. Se recomienda implementar solo uno para todos los servidores que sincronizan el mismo conjunto de archivos ahora o en el futuro. Solo debe crear varios servicios de sincronización de almacenamiento si tiene distintos conjuntos de servidores que nunca deben intercambiar datos. Por ejemplo, podría tener servidores que nunca deben sincronizar el mismo recurso compartido de archivos de Azure. De lo contrario, el procedimiento recomendado es contar con un único servicio de sincronización de almacenamiento.

Elija una región de Azure para el servicio de sincronización de almacenamiento que esté cerca de su ubicación. Todos los demás recursos de nube se deben implementar en la misma región. Para simplificar el proceso de administración, cree un nuevo grupo de recursos en la suscripción para hospedar los recursos de sincronización y almacenamiento.

Para más información, consulte la sección sobre la implementación del servicio de sincronización de almacenamiento en el artículo sobre la implementación de Azure File Sync. Siga solo esta sección del artículo. En pasos posteriores, tendrá vínculos a otras secciones del artículo.

Fase 7: Implementación del agente de Azure File Sync

En esta sección se instala el agente de Azure File Sync en una instancia de Windows Server.

En la guía de implementación se explica que es preciso desactivar la configuración de seguridad mejorada de Internet Explorer. Esta medida de seguridad no se puede aplicar con Azure File Sync. Si la desactiva, puede autenticarse en Azure sin ningún problema.

Abra PowerShell. Instale los módulos de PowerShell necesarios mediante los siguientes comandos. Asegúrese de instalar el módulo completo y el proveedor de NuGet cuando se le solicite hacerlo.

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

Si tiene algún problema para conectarse a Internet desde el servidor, ahora es el momento de solucionarlo. Azure File Sync usa cualquier conexión de red disponible a Internet. También se admite la exigencia de un servidor proxy para tener acceso a Internet. Ya puede configurar un proxy en toda la máquina, o bien, durante la instalación del agente, especificar un proxy que solo va a usar Azure File Sync.

Si para configurar un proxy debe abrir los firewalls del servidor, es posible que ese enfoque le resulte aceptable. Al final de la instalación del servidor, después de haber completado el registro del servidor, un informe de conectividad de red le mostrará las direcciones URL exactas de los puntos de conexión en Azure, con las que Azure File Sync necesita comunicarse en la región que ha seleccionado. El informe también indica por qué se necesita la comunicación. Puede usar el informe para bloquear los firewalls del servidor en direcciones URL específicas.

También puede adoptar un enfoque más conservador y no abrir totalmente los firewalls. En su lugar puede limitar el servidor para que se comunique con espacios de nombres DNS de nivel superior. Para más información, consulte Configuración del proxy y el firewall de Azure File Sync. Siga sus propios procedimientos recomendados de redes.

Al final del Asistente para la instalación del servidor, se abrirá un Asistente para el registro del servidor. Registre el servidor en el recurso de Azure del servicio de sincronización de almacenamiento anterior.

Estos pasos se describen con más detalle en la guía de implementación, que incluye los módulos de PowerShell que se deben instalar primero: Instalación de agente de Azure File Sync.

Use el agente más reciente. Puede descargarlo del Centro de descarga de Microsoft: Agente de Azure File Sync.

Después de una instalación y un registro del servidor correctos, puede confirmar que ha completado correctamente este paso. Vaya al recurso de Storage Sync Service en Azure Portal. En el menú de la izquierda, vaya a Servidores registrados. Verá que el servidor aparece en esa lista.

Fase 8: Configuración de Azure File Sync en la instancia de Windows Server

La instancia registrada de Windows Server local debe estar preparada y conectada a Internet para este proceso.

Este paso une todos los recursos y carpetas que ha configurado en la instancia de Windows Server durante los pasos anteriores.

1. Inicie sesión en Azure Portal.
2. Busque el recurso del servicio de sincronización de almacenamiento.
3. Cree un nuevo grupo de sincronización en el recurso del servicio de sincronización de almacenamiento para cada recurso compartido de archivos de Azure. En la terminología de Azure File Sync, el recurso compartido de archivos de Azure se convertirá en punto de conexión de la nube en la topología de sincronización que describe con la creación de un grupo de sincronización. Cuando cree el grupo de sincronización, asígnele un nombre descriptivo para poder reconocer qué conjunto de archivos se sincroniza allí. Asegúrese de hacer referencia al recurso compartido de archivos de Azure con un nombre coincidente.
4. Después de haber creado el grupo de sincronización, aparecerá una fila para él en la lista de grupos de sincronización. Seleccione el nombre (un vínculo) para mostrar el contenido del grupo de sincronización. Verá el recurso compartido de archivos de Azure en Puntos de conexión en la nube.
5. Busque el botón Agregar punto de conexión de servidor. La carpeta del servidor local que ha aprovisionado se convertirá en la ruta de acceso de este punto de conexión del servidor.

Active la característica de nube por niveles y seleccione Namespace only (Solo espacio de nombres) en la sección de descarga inicial.

Importante

La nube por niveles es la característica de Azure File Sync que permite al servidor local tener menos capacidad de almacenamiento de la que está almacenada en la nube pero disponer de todo el espacio de nombres. Los datos de interés local también se almacenan en caché para conseguir un rendimiento de acceso rápido. La nube por niveles es opcional. Puede establecerla individualmente para cada punto de conexión de Azure File Sync servidor. Debe usar esta característica si no tiene suficiente capacidad de disco local en una instancia de Windows Server para contener todos los datos en la nube y si quiere evitar la descarga de todos los datos de la nube.

Para todos los recursos compartidos de archivos de Azure o las ubicaciones de servidor que necesita configurar para la sincronización, repita los pasos para crear grupos de sincronización y agregar las carpetas de servidor correspondientes como puntos de conexión de servidor. Espere hasta que se complete la sincronización del espacio de nombres. En la sección siguiente se explica cómo puede asegurarse de que la sincronización se haya completado.

Nota:

Después de crear un punto de conexión de servidor, la sincronización funciona. Aun así, la sincronización debe enumerar (detectar) los archivos y las carpetas que se movieron a través de Data Box al recurso compartido de archivos de Azure. Según el tamaño del espacio de nombres, puede pasar mucho tiempo antes de que el espacio de nombres de la nube aparezca en el servidor.

Fase 9: Espera para que el espacio de nombres aparezca por completo en el servidor

Antes de continuar con los pasos siguientes de la migración, espere a que el servidor haya descargado por completo el espacio de nombres del recurso compartido de nube. Si empieza a mover archivos demasiado pronto al servidor, corre el riesgo de que se realicen cargas innecesarias e incluso de que se produzcan conflictos de sincronización de archivos.

Para determinar si el servidor ha completado la sincronización inicial de la descarga, abra el Visor de eventos en la instancia de Windows Server que se está sincronizando y use el registro de eventos de telemetría de Azure File Sync. El registro de eventos de telemetría se encuentra en el Visor de eventos en Applications and Services\Microsoft\FileSync\Agent.

Busque el evento 9102 más reciente. El identificador de evento 9102 se registra cuando finaliza una sesión de sincronización. En el texto del evento, hay un campo para la dirección de sincronización de la descarga. (HResult debe ser cero y los archivos deben descargarse).

Debería ver dos eventos consecutivos de este tipo y con este contenido para asegurarse de que el servidor haya terminado de descargar el espacio de nombres. No hay ningún problema si hay otros eventos entre los dos eventos 9102.

Fase 10: Ejecución de Robocopy desde el NAS

Una vez que el servidor haya completado la sincronización inicial del espacio de nombres completo desde el recurso compartido en la nube, puede continuar con este paso. La sincronización inicial debe completarse antes de continuar con este paso. Consulte la sección anterior para obtener más información.

En este paso, ejecutará trabajos de Robocopy para sincronizar los recursos compartidos en la nube con los cambios más recientes del NAS que se produjeron desde el momento en que bifurcó los recursos compartidos en el dispositivo Data Box. Esta ejecución de Robocopy puede finalizar rápidamente o tardar unos minutos, en función de la cantidad de abandonos que se hayan producido en los recursos compartidos de NAS.

Advertencia

Debido al comportamiento con regresión de Robocopy en Windows Server 2019, el modificador /MIR de Robocopy no es compatible con los directorios de destino en capas. No puede usar Windows Server 2019 ni un cliente Windows 10 para esta fase de la migración. Use Robocopy en una instancia intermedia de Windows Server 2016.

Este es el enfoque de migración básico:

• Ejecute Robocopy desde el dispositivo NAS para sincronizar la instancia de Windows Server.
• Use Azure File Sync para sincronizar los recursos compartidos de archivos de Azure desde Windows Server.

Ejecute la primera copia local en la carpeta de destino de Windows Server:

1. Identifique la primera ubicación en el dispositivo NAS.
2. Identifique la carpeta coincidente en la instancia de Windows Server, que ya tiene Azure File Sync configurado.
3. Inicie la copia con Robocopy.

El comando de Robocopy siguiente solo copiará las diferencias (archivos y carpetas actualizados) desde el almacenamiento NAS a la carpeta de destino de la instancia de Windows Server. Después, la instancia de Windows Server los sincronizará con los recursos compartidos de archivos de 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> 

Conmutador	Significado
/MT:n	Permite que Robocopy se ejecute en modo multiproceso. El valor predeterminado para n es 8. La cantidad máxima es de 128 subprocesos. Aunque un número elevado de subprocesos contribuye a saturar el ancho de banda disponible, no significa que la migración sea siempre más rápida con más subprocesos. Las pruebas realizadas con Azure Files indican que entre 8 y 20 proporcionan un rendimiento equilibrado para la ejecución de una copia inicial. Las ejecuciones subsiguientes de /MIR se ven afectadas progresivamente por el proceso disponible en comparación con el ancho de banda de red disponible. Para las ejecuciones posteriores, haga coincidir más estrechamente el valor del número de subprocesos con el número de núcleos del procesador y el número de subprocesos por núcleo. Considere si es necesario reservar los núcleos para otras tareas que quizá tenga un servidor de producción. Las pruebas realizadas con Azure Files han demostrado que, con un máximo de 64 subprocesos, se obtiene un buen rendimiento, pero solo si los procesadores pueden mantenerlos activos al mismo tiempo.
/R:n	Número máximo de reintentos para un archivo que no se puede copiar en el primer intento. Robocopy prueba n veces antes de determinar que el archivo, definitivamente, no se copia en la ejecución. Para optimizar el rendimiento de la ejecución, elija un valor de dos o tres si cree que hubo problemas de tiempo de espera que causaron errores en el pasado. Esto puede ser más habitual a través de vínculos WAN. Elija no reintentarlo o un valor de uno si cree que el archivo no se pudo copiar porque estaba en uso de forma activa. Volver a intentarlo unos segundos más tarde puede no ser suficiente tiempo para que cambie el estado de “en uso” del archivo. Es posible que los usuarios o aplicaciones que tienen abierto el archivo necesiten más tiempo. En este caso, puede que, si acepta que el archivo no se ha copiado y lo incluye en una ejecución posterior planeada de Robocopy, el archivo se copie finalmente. Esto ayuda a que la ejecución en curso finalice más rápido al no prolongarla con muchos reintentos que, al final, dan lugar a una mayoría de errores de copia porque los archivos siguen abiertos después del tiempo de espera de reintento.
/W:n	Especifica el tiempo que espera Robocopy antes de intentar copiar un archivo que no se ha copiado correctamente en el último intento. n es el número de segundos de espera entre reintentos. /W:n a menudo se usa junto con /R:n.
/B	Ejecuta Robocopy en el mismo modo que usaría una aplicación de copia de seguridad. Este conmutador permite que Robocopy mueva los archivos para los que el usuario actual no tiene permisos. El modificador de la copia de seguridad depende de la ejecución del comando Robocopy en una consola con privilegios elevados de administrador o en una ventana de PowerShell. Si usa Robocopy para Azure Files, asegúrese de montar el recurso compartido de archivos de Azure con la clave de acceso de la cuenta de almacenamiento en lugar de una identidad de dominio. Si no lo hace, es posible que los mensajes de error no lo lleven intuitivamente a una solución del problema.
/MIR	(Reflejar origen en destino). Permite que Robocopy solo tenga que copiar las diferencias entre el origen y el destino. Se copiarán los subdirectorios vacíos. Se copiarán los elementos (archivos o carpetas) que hayan cambiado o no existan en el destino. Los elementos que existan en el destino, pero no en el origen, se purgarán (se eliminarán) del destino. Cuando use este conmutador, haga coincidir exactamente con las estructuras de carpetas de origen y de destino. Coincidencia significa que se copia desde el nivel de carpeta y origen correctos en el nivel de carpeta del destino coincidente. Solo entonces se puede realizar correctamente una copia de "puesta al día". Cuando el origen y el destino no coinciden, el uso de /MIR dará lugar a eliminaciones y nuevas copias a gran escala.
/IT	Garantiza que se conserve la fidelidad en ciertos escenarios de reflejo. Por ejemplo, si un archivo experimenta un cambio de ACL y una actualización de atributo entre dos ejecuciones de Robocopy, se marca como oculto. Sin /IT, Robocopy podría omitir el cambio de ACL y no se transferiría a la ubicación de destino.
/COPY:[copyflags]	Fidelidad de la copia del archivo. Predeterminado: /COPY:DAT. Marcas de copia: D = datos, A = atributos, T = marcas de tiempo, S = seguridad = ACL de NTFS, O = información del propietario, U = información de aDditoría. No se puede almacenar la información de auditoría en un recurso compartido de archivos de Azure.
/DCOPY:[copyflags]	Fidelidad de la copia de directorios. Predeterminado: /DCOPY:DA. Marcas de copia: D = Datos, A = Atributos, T = Marcas de tiempo.
/NP	Especifica que no se mostrará el progreso de la copia de cada archivo y carpeta. Mostrar el progreso reduce significativamente el rendimiento de la copia.
/NFL	Especifica que los nombres de archivo no se han registrado. Mejora el rendimiento de la copia.
/NDL	Especifica que los nombres de directorio no se han registrado. Mejora el rendimiento de la copia.
/XD	Especifica los directorios que se excluirán. Cuando ejecute Robocopy en la raíz de un volumen, considere la posibilidad de excluir la carpeta System Volume Information oculta. Si se usa como está previsto, toda la información que contiene es específica del volumen exacto en este sistema exacto y se puede recompilar a petición. Copiar esta información no será útil en la nube ni cuando los datos se vuelvan a copiar en otro volumen Windows. Dejar este contenido atrás no debe considerarse una pérdida de datos.
/UNILOG:<file name>	Escribe el estado en el archivo de registro como Unicode. (Sobrescribe el registro existente).
/L	Solo para una ejecución de prueba Los archivos solo se mostrarán en la lista. No se copiarán, no se eliminarán y no tendrán marca de tiempo. Por lo general, se usa con /TEE para la salida de la consola. Es posible que las marcas del script de ejemplo, como /NP, /NFL y /NDL, se tengan que quitar para lograr los resultados de la prueba documentados correctamente.
/LFSM	Solo para destinos con almacenamiento en niveles. No se admite cuando el destino sea un recurso compartido de SMB remoto. Especifica que Robocopy funciona en "modo de espacio libre bajo". Este conmutador solo es útil para destinos con almacenamiento en capas que pueden quedarse sin capacidad local antes de que Robocopy finalice. Se agregó específicamente para su uso con un destino habilitado de nube por niveles de Azure File Sync. Se puede usar con independencia de Azure File Sync. En este modo, Robocopy se pondrá en pausa siempre que una copia de archivo haga que el espacio disponible del volumen de destino se sitúe por debajo de un valor de "suelo". El formato /LFSM:n de la marca puede especificar este valor. El parámetro n se especifica en la base 2: nKB, nMB o nGB. Si /LFSM se especifica sin ningún valor floor explícito, floor se establece en el 10 por ciento del tamaño del volumen de destino. El modo de espacio libre bajo no es compatible con /MT, /EFSRAW ni /ZB. Se agregó compatibilidad con /B en Windows Server 2022. Consulte la sección Windows Server 2022 y RoboCopy LFSM a continuación para obtener más información, incluidos detalles sobre un error y una solución alternativa relacionados.
/Z	Usar con precaución Copia los archivos en modo de reinicio. Este conmutador solo se recomienda en un entorno de red inestable. Reduce significativamente el rendimiento de la copia debido al registro adicional.
/ZB	Usar con precaución Usa el modo de reinicio. Si se deniega el acceso, esta opción utiliza el modo de copia de seguridad. Esta opción reduce significativamente el rendimiento de la copia debido a los puntos de control.

Importante

Se recomienda usar Windows Server 2022. Cuando use Windows Server 2019, asegúrese de que está instalado con el nivel de revisión más reciente o, al menos, la actualización KB5005103 del sistema operativo. Contiene correcciones importantes para determinados escenarios de Robocopy.

Si ha aprovisionado menos almacenamiento en la instancia de Windows Server que el que usan los archivos del dispositivo NAS, ha configurado la nube por niveles. A medida que el volumen local de Windows Server se llena, la nube por niveles se iniciará y organizará por niveles los archivos que ya se han sincronizado correctamente. La nube por niveles generará espacio suficiente para continuar con la copia desde el dispositivo NAS. La nube por niveles realiza comprobaciones cada hora para determinar qué se ha sincronizado y liberar espacio en disco a fin de alcanzar el 99 % de espacio libre del volumen.

Robocopy podría tener que trasladar más archivos de los que se pueden almacenar localmente en la instancia de Windows Server. Puede esperar que Robocopy realice el traslado más rápido de lo que Azure File Sync puede cargar los archivos y cambiarlos de nivel del volumen local. En esta situación, Robocopy producirá un error. Se recomienda trabajar con los recursos compartidos en una secuencia que impida esta situación. Por ejemplo, mueva solo los recursos compartidos que quepan en el espacio disponible en la instancia de Windows Server. Otra opción es evitar iniciar trabajos de Robocopy en todos los recursos compartidos al mismo tiempo. La buena noticia es que el modificador /MIR garantizará que solo se muevan los valores delta. Una vez que se haya movido un valor delta, un trabajo reiniciado no tendrá que volver a mover el archivo.

Realización de la transición

Al ejecutar por primera vez el comando Robocopy, los usuarios y las aplicaciones seguirán accediendo a los archivos en la ubicación del NAS y podrán modificarlos. Robocopy procesará un directorio y, luego, pasará al siguiente. A continuación, un usuario del NAS podría agregar, cambiar o eliminar un archivo del primer directorio que no se procesará durante la ejecución actual de Robocopy. Este comportamiento es normal.

La primera ejecución consiste en mover la mayor parte de los datos perdidos a la instancia de Windows Server y, después, a la nube mediante Azure File Sync. Esta primera copia puede tardar mucho tiempo, en función de lo siguiente:

• El ancho de banda de carga.
• La velocidad de la red local y lo óptimamente que los subprocesos de Robocopy coinciden con ella.
• El número de elementos (archivos y carpetas) que deben procesar Robocopy y Azure File Sync.

Una vez completada la ejecución inicial, vuelva a ejecutar el comando.

Robocopy finalizará más rápido la segunda vez que lo ejecute para un recurso compartido, ya que solo necesita transportar los cambios posteriores a la última ejecución. Puede ejecutar trabajos repetidos para el mismo recurso compartido.

Si considera que el tiempo de inactividad es aceptable, debe quitar el acceso de usuario a los recursos compartidos basados en NAS. Hágalo de cualquier forma que impida que los usuarios cambien el contenido y la estructura de archivos y carpetas. Por ejemplo, puede apuntar el espacio de nombres DFS a una ubicación que no existe o cambiar las ACL raíz en el recurso compartido.

Ejecute Robocopy una última vez. Recuperará todos los cambios que se hayan omitido. El tiempo necesario para hacer este último paso depende de la velocidad del análisis de Robocopy. Para realizar un cálculo estimado del tiempo (que equivale al tiempo de inactividad), averigüe cuánto duró la ejecución anterior.

Cree un recurso compartido en la carpeta de Windows Server y, eventualmente, ajuste esta carpeta como destino de la implementación de DFS-N. Asegúrese de establecer los mismos permisos de nivel de recurso compartido que en el recurso compartido de SMB de NAS. Si tuviera un NAS unido a un dominio de clase empresarial, los SID de usuario coincidirían automáticamente porque los usuarios se encuentran en Active Directory y Robocopy copia los archivos y metadatos con total fidelidad. Si ha empleado usuarios locales en el NAS, debe hacer lo siguiente:

• Vuelva a crear estos usuarios como usuarios locales de Windows Server.
• Asigne los SID existentes que Robocopy ha migrado a su instancia de Windows Server a los SID de los usuarios locales nuevos de Windows Server.

Ha completado la migración de un recurso compartido o un grupo de recursos compartidos a una raíz o un volumen común (en función de la asignación de la fase 1).

Puede intentar ejecutar algunas de estas copias en paralelo. Se recomienda procesar el ámbito de un recurso compartido de archivos de Azure de cada vez.

Opción en desuso: "transferencia de datos sin conexión"

Antes de la publicación del agente de Azure File Sync versión 13, la integración con Data Box se realizaba mediante un proceso denominado "transferencia de datos sin conexión". Este proceso está en desuso y ya no puede crear un punto de conexión de servidor en el modo "transferencia de datos sin conexión". Con la versión 13 del agente, se ha reemplazado por los pasos mucho más sencillos y rápidos que se describen en este artículo.

Solución de problemas

El problema más común es que el comando Robocopy genere un error de tipo "Volumen lleno" en el lado de Windows Server. La nube por niveles actúa una vez cada hora para evacuar el contenido del disco local de Windows Server, que se ha sincronizado. Su objetivo es alcanzar el 99 % de espacio libre en el volumen.

Permita que el progreso de la sincronización y la nube por niveles liberen espacio en disco. Puede observarlo en el Explorador de archivos en la instancia de Windows Server.

Cuando la instancia de Windows Server tenga capacidad suficiente disponible, vuelva a ejecutar el comando para resolver el problema. Si se da esta situación, no se interrumpe nada y puede avanzar con plena confianza. La única consecuencia es el inconveniente de tener que volver a ejecutar el comando.

Para solucionar problemas de Azure File Sync, consulte el artículo que se indica en la sección siguiente.

Pasos siguientes

Los siguientes artículos le ayudarán a comprender las opciones avanzadas y los procedimientos recomendados para Azure Files y Azure File Sync.

• Información general acerca de la migración
• Planeamiento de una implementación de Azure File Sync
• Creación de un recurso compartido de archivos
• Solución de problemas de Azure File Sync