Uso de RoboCopy para migrar a recursos compartidos de archivos de Azure

  • Artículo

En este artículo de migración se describe el uso de RoboCopy para mover o migrar archivos a un recurso compartido de archivos SMB de Azure. RoboCopy es una utilidad de copia de archivos de confianza y conocida con un conjunto de características que la hace adecuada para las migraciones. Usa el protocolo SMB, por lo que se puede aplicar de forma amplia a cualquier combinación de origen y destino compatible con SMB.

  • Orígenes de datos: cualquier origen que admita el protocolo SMB, como Almacenamiento conectado a la red (NAS), servidores Windows o Linux, otro recurso compartido de archivos de Azure y muchos más.
  • Ruta de migración: desde el almacenamiento de origen ⇒ máquina Windows con RoboCopy ⇒ recurso compartido de archivos.
  • Sin almacenamiento en caché de archivos en el entorno local: dado que el objetivo final es usar los recursos compartidos de archivos de Azure directamente en la nube, no hay ningún plan para usar Azure File Sync.

Hay muchas rutas de migración diferentes para diversas combinaciones de origen e implementación. Consulte la tabla de guías de migración para encontrar la migración que mejor se adapte a sus necesidades.

Se aplica a

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

AzCopy frente a RoboCopy

AzCopy y RoboCopy son dos herramientas de copia de archivos radicalmente diferentes. RoboCopy usa cualquier versión del protocolo SMB. AzCopy es una herramienta nativa de la nube que se puede usar para mover datos siempre que el destino esté en Azure Storage. AzCopy depende de un protocolo REST.

RoboCopy, como herramienta de copia basada en Windows de confianza, tiene la ventaja de copiar archivos con plena fidelidad. RoboCopy admite muchos escenarios de migración debido a su amplio conjunto de características y a la capacidad de copiar archivos y carpetas con plena fidelidad. Consulte la sección fidelidad de archivos del artículo de información general sobre la migración para obtener más información sobre la importancia de copiar archivos con la máxima fidelidad posible.

AzCopy, por otro lado, se ha expandido recientemente para admitir la copia de archivos con cierta fidelidad y ha agregado las primeras características necesarias para considerarse como una herramienta de migración. Sin embargo, todavía hay lagunas y pueden surgir malentendidos con facilidad en relación con la funcionalidad al comparar las marcas de AzCopy con las de RoboCopy.

Un ejemplo: RoboCopy /MIR reflejará el origen en el destino, lo que significa que se tienen en cuenta los archivos agregados, modificados y eliminados. Una diferencia importante en el uso de AzCopy -sync es que los archivos eliminados en el origen no se eliminan del destino. Por ello, el conjunto de características de copia diferencial es incompleto. AzCopy continuará evolucionando. En este momento, no se recomienda usar AzCopy para escenarios de migración con recursos compartidos de archivos de Azure como destino.

Objetivos de la migración

El objetivo es mover los datos de ubicaciones de recursos compartidos de archivos existentes a Azure. En Azure, almacenará los datos en recursos compartidos de archivos nativos de Azure que puede usar sin necesidad de Windows Server. 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 ajustarse 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. Primero, deberá implementar cuentas de almacenamiento y recursos compartidos de archivos de Azure. Después, configurará las redes, considerará una implementación de espacio de nombres DFS (DFS-N) o actualizará la existente. Una vez que haya llegado el momento de la copia de datos real, deberá tener en cuenta las ejecuciones diferenciales de RoboCopy repetidas para minimizar el tiempo de inactividad y, por último, deberá migrar a los usuarios a los recursos compartidos de archivos de Azure recién creados. En las secciones siguientes se describen detalladamente las fases del proceso de migración.

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

En esta fase, aprovisionará las cuentas de almacenamiento de Azure y los recursos compartidos de archivos SMB de Azure que se encuentren en estas.

Recuerde que un recurso compartido de archivos de Azure se implementa en la nube en una cuenta de almacenamiento de Azure. En el caso de los recursos compartidos de archivos, esta disposición hace que la cuenta de almacenamiento sea un destino de escalado para los números de rendimiento, como IOPS y rendimiento. Si coloca varios recursos compartidos de archivos en una única cuenta de almacenamiento, está creando un grupo compartido de IOPS y rendimiento para esos recursos compartidos.

Como regla general, 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. Sin embargo, si tiene recursos compartidos muy activos (recursos compartidos usados por muchos usuarios o aplicaciones), es conveniente implementar cuentas de almacenamiento con un recurso compartido de archivos cada una. Estas limitaciones no se aplican a las cuentas de almacenamiento de FileStorage (prémium), donde el rendimiento se aprovisiona y garantiza explícitamente para cada recurso compartido.

Nota

Hay un límite de 250 cuentas de almacenamiento por suscripción por cada región de Azure. Con un aumento de cuota, podría crear hasta 500 cuentas de almacenamiento por región. Para obtener más información, consulte Aumento de las cuotas de la cuenta de Azure Storage.

Otra consideración a la hora de implementar una cuenta de almacenamiento es la redundancia. Consulte Redundancia de Azure Files.

Los recursos compartidos de archivos de Azure Estándar se crean con un límite de 5 TiB de forma predeterminada. Si necesita más capacidad, puede crear un recurso compartido de archivos grande (hasta 100 TiB). Sin embargo, ese recurso compartido solo puede las opciones de redundancia de almacenamiento con redundancia local o de almacenamiento con redundancia de zona. Tenga en cuenta sus necesidades de redundancia de almacenamiento antes de usar recursos compartidos de archivos de 100 TiB.

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

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.

Ahora, implemente el número adecuado de cuentas de almacenamiento de Azure con el número adecuado de recursos compartidos de archivos de Azure en estas. Para ello, siga las instrucciones de Creación de un recurso compartido de archivos SMB. En la mayoría de los casos, se recomienda asegurarse de que la región de cada una de las cuentas de almacenamiento es la misma.

Fase 2: Preparación para el uso de recursos compartidos de archivos de Azure

Con la información de esta fase, podrá decidir cómo se habilitarán los servidores y los usuarios dentro y fuera de Azure para usar los recursos compartidos de archivos de Azure. Las decisiones más críticas son las siguientes:

  • Redes: habilite las redes para enrutar el tráfico SMB.
  • Autenticación: configure cuentas de almacenamiento de Azure para la autenticación Kerberos. El uso de la autenticación basada en identidades y unir a un dominio la cuenta de almacenamiento permitirá que las aplicaciones y los usuarios usen su identidad de AD para la autenticación.
  • Autorización: las ACL de nivel de recurso compartido para cada recurso compartido de archivos de Azure permitirán a los usuarios y grupos de AD acceder a un recurso compartido determinado. Además, dentro de un recurso compartido de archivos de Azure, las ACL nativas de NTFS asumirán el control. La autorización basada en ACL de archivos y carpetas funciona del mismo modo que en los recursos compartidos SMB locales.
  • Continuidad empresarial: la integración de recursos compartidos de archivos de Azure en un entorno existente suele implicar la conservación de las direcciones de recursos compartidos existentes. Si aún no está usando los espacios de nombres DFS, considere la posibilidad de configurarlos en su entorno. De este modo, podría conservar sin cambios las direcciones de recursos compartidos que usan los usuarios y los scripts. DFS-N proporciona un servicio de enrutamiento de espacios de nombres para SMB mediante el redireccionamiento de los clientes a los recursos compartidos de archivos de Azure.

Este vídeo es una guía y demostración sobre cómo exponer de forma segura recursos compartidos de archivos de Azure directamente para las aplicaciones y trabajadores de la información en cinco sencillos pasos.
La documentación dedicada del vídeo hace referencia a la documentación dedicada para los temas siguientes. Tenga en cuenta que Azure Active Directory es ahora Microsoft Entra ID. Para obtener más información, consulte Nuevo nombre para Azure AD.

Montaje de un recurso compartido de archivos de Azure

Antes de que pueda usar RoboCopy, debe hacer que el recurso compartido de archivos de Azure sea accesible a través de SMB. La manera más fácil consiste en montar el recurso compartido como una unidad de red local en la instancia de Windows Server que está planeando usar para RoboCopy.

Importante

Asegúrese de montar el recurso compartido de archivos de Azure usando la clave de acceso de la cuenta de almacenamiento. No use una identidad de dominio. Antes de que pueda montar correctamente un recurso compartido de archivos de Azure en una instancia local de Windows Server, debe haber completado la fase 2: Preparación para el uso de recursos compartidos de archivos de Azure.

Una vez todo listo, revise Uso de un recurso compartido de archivos de Azure con Windows. A continuación, monte el recurso compartido de archivos de Azure para el que desea iniciar RoboCopy.

Fase 3: RoboCopy

El siguiente comando RoboCopy solo copiará las diferencias (archivos y carpetas actualizados) desde el almacenamiento de origen al recurso compartido 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 serie de pruebas
Los archivos solo se muestran 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.
/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.

Sugerencia

Consulte la sección de solución de problemas si RoboCopy está afectando a su entorno de producción, si notifica un gran número de errores o si no progresa tan rápido como se espera.

Fase 4: Migración total de los usuarios

Al ejecutar por primera vez el comando RoboCopy, los usuarios y las aplicaciones siguen accediendo a los archivos en el origen de la migración y pueden modificarlos. Es posible que RoboCopy haya procesado un directorio, haya pasado al siguiente y, después, un usuario en la ubicación de origen agregue, cambia o elimina un archivo que no se procesará en esta ejecución actual de RoboCopy. Este comportamiento es normal.

La primera ejecución consiste en migrar la mayor parte de los datos renovados al recurso compartido de archivos de Azure. Esta primera copia puede tardar unos minutos. Consulte la sección de solución de problemas para obtener más información acerca de lo que puede afectar a la velocidad de RoboCopy.

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

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

Después de considerar la cantidad de tiempo de inactividad aceptable, debe quitar el acceso de usuario a los recursos compartidos de origen. Para ello, siga los pasos que impidan que los usuarios cambien el contenido y la estructura de archivos y carpetas. Un ejemplo es dirigir DFS-Namespace a una ubicación no existente o cambiar las ACL de cada recurso compartido.

Ejecute una última ronda de RoboCopy. Recuperará todos los cambios que puedan haberse 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 tardó en realizarse la ejecución anterior.

En la fase 2, configuró a los usuarios para acceder al recurso compartido con su identidad y debería haber establecido una estrategia para que los usuarios usen rutas de acceso establecidas a los nuevos recursos compartidos de archivos de Azure (DFS-N).

Puede intentar ejecutar algunas de estas copias entre distintos recursos compartidos de origen y destino en paralelo. Al hacerlo, tenga en cuenta el rendimiento de la red y la relación de número de subprocesos y núcleos para no sobrecargar el sistema.

Solución de problemas y optimización

La velocidad y la tasa de éxito de una ejecución determinada de RoboCopy dependerán de varios factores:

  • El número de IOPS en el almacenamiento de origen y de destino.
  • El ancho de banda de red disponible entre el origen y el destino.
  • La capacidad de procesar rápidamente archivos y carpetas en un espacio de nombres.
  • El número de cambios entre ejecuciones de RoboCopy.
  • el tamaño y el número de archivos que debe copiar

Consideraciones sobre el ancho de banda y el número de IOPS.

En esta categoría, debe tener en cuenta la capacidad del almacenamiento de origen, el almacenamiento de destinoy la red que los conecta. El mayor rendimiento posible viene determinado por el más lento de estos tres componentes. Asegúrese de que la infraestructura de red se haya configurado para admitir las mejores velocidades de transferencia.

Precaución

Aunque es deseable copiar lo más rápido posible, tenga en cuenta el uso de la red local y el dispositivo NAS en otras tareas que suelen ser críticas para la empresa.

Copiar lo más rápido posible podría no ser deseable si existe el riesgo de que la migración acapare los recursos disponibles.

  • Tenga en cuenta cuándo es mejor para su entorno hacer migraciones: durante el día, fuera del horario laboral o en los fines de semana.
  • Considere también la calidad de servicio de redes en Windows Server para limitar la velocidad de RoboCopy.
  • Evite trabajo innecesario a las herramientas de migración.

RoboCopy puede introducir retrasos entre paquetes al especificar el modificador /IPG:n, en donde el valor n se calcula en milisegundos entre los paquetes de RoboCopy. El uso de este modificador puede ayudar a evitar el acaparamiento de los recursos en dispositivos de E/S restringidos y vínculos de red saturados.

/IPG:n no se puede usar para limitar la red a un número exacto de megabits por segundo. En su lugar, use la calidad de servicio de red de Windows Server. RoboCopy se basa íntegramente en el protocolo SMB para todas las necesidades de red. El uso de SMB es el motivo por el que RoboCopy no puede influir en el propio rendimiento de la red, pero puede ralentizar su uso.

Un enfoque similar se aplica a las operaciones de IOPS observadas en el dispositivo NAS. El tamaño del clúster en el volumen de NAS y los tamaños de paquete, entre otros factores, influyen en las IOPS observadas. La introducción de retraso entre paquetes suele ser la manera más fácil de controlar la carga en el dispositivo NAS. Pruebe varios valores, por ejemplo, de 20 milisegundos (n = 20) a múltiplos de ese número. Una vez que introduzca un retraso, podrá valorar si las otras aplicaciones funcionan según lo esperado. Esta estrategia de optimización le permitirá encontrar la velocidad de RoboCopy óptima para su entorno.

Velocidad de procesamiento

RoboCopy recorrerá el espacio de nombres al que se apunta y evaluará cada archivo y carpeta con fines de copia. Los archivos se evaluarán durante una copia inicial y durante las copias de puesta al día. Por ejemplo, ejecuciones repetidas de RoboCopy/MIR en las mismas ubicaciones de almacenamiento de origen y de destino. Estas ejecuciones repetidas son útiles para minimizar el tiempo de inactividad de los usuarios y las aplicaciones, así como para mejorar la tasa de éxito general de los archivos migrados.

A menudo, el ancho de banda suele considerarse como el factor más restrictivo en una migración, algo que puede ser cierto. Pero la posibilidad de enumerar un espacio de nombres puede influir en el tiempo total de copia para espacios de nombres más largos con archivos más pequeños. Tenga en cuenta que copiar 1 TiB de archivos pequeños tardará mucho más que copiar 1 TiB de un número inferior de archivos de mayor tamaño, si se supone que todas las demás variables permanecen iguales. Por lo tanto, es posible que se experimente una transferencia lenta si va a migrar una gran cantidad de archivos pequeños. Este es un comportamiento esperado.

La razón de esta diferencia es la potencia de procesamiento necesaria para recorrer un espacio de nombres. RoboCopy admite copias multiproceso mediante el parámetro /MT:n, donde n indica el número de subprocesos que se van a usar. Por lo tanto, al aprovisionar una máquina específicamente para RoboCopy, tenga en cuenta el número de núcleos de procesador y su relación con el número de subprocesos que proporcionan. Lo más habitual son dos subprocesos por núcleo. El número de núcleos y subprocesos de una máquina es un punto de datos importante para determinar qué valores multiproceso /MT:n se deberían especificar. Tenga en cuenta también cuántos trabajos de RoboCopy tiene previsto ejecutar al mismo tiempo en una máquina determinada.

Un número mayor de subprocesos copiarán nuestro ejemplo de 1 TiB de archivos pequeños considerablemente más rápido que un número menor de subprocesos. Al mismo tiempo, la inversión adicional en recursos en 1 TiB de archivos de más grandes podría no aportar ventajas proporcionales. Un número mayor de subprocesos intentará copiar simultáneamente más archivos grandes a través de la red. Esta actividad de red adicional aumentará la probabilidad de sufrir restricciones asociadas al rendimiento o a las operaciones de IOPS de almacenamiento.

Durante una primera ejecución de RoboCopy en un destino vacío o una ejecución diferencial con una gran cantidad de archivos modificados, es probable que el rendimiento de la red plantee restricciones. Comience con un número elevado de subprocesos para una ejecución inicial. Un alto número de subprocesos, incluso más allá de los subprocesos disponibles actualmente en la máquina, ayuda a saturar el ancho de banda de red disponible. Las ejecuciones /MIR posteriores se verán afectadas progresivamente por el procesamiento de elementos. Menos cambios en una ejecución diferencial significa menos transporte de datos a través de la red. La velocidad ahora depende más de la capacidad de procesar elementos de espacio de nombres que de moverlos a través del vínculo de red. Para las ejecuciones posteriores, haga coincidir 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.

Sugerencia

Regla general: la primera ejecución de RoboCopy, que moverá una gran cantidad de datos de una red de mayor latencia, se beneficia del aprovisionamiento excesivo del número de subprocesos (/MT:n). Las ejecuciones posteriores copiarán menos diferencias y es más probable que se cambie de un rendimiento restringido de red a otro restringido por proceso. En estas circunstancias, a menudo es mejor que el número de subprocesos de RoboCopy coincida con los subprocesos disponibles realmente en la máquina. El aprovisionamiento excesivo en ese escenario puede generar más cambios de contexto en el procesador, lo que podría ralentizar la copia.

Evitar el trabajo innecesario

Evite cambios a gran escala en el espacio de nombres, como mover archivos entre directorios, cambiar las propiedades a gran escala o cambiar los permisos de directorio y de nivel de archivo (ACL de NTFS). Los cambios en la ACL en especial pueden tener una importante repercusión, ya que con frecuencia tienen un efecto de cambio en cascada en los archivos de nivel inferior en la jerarquía de carpetas. Entre las consecuencias, cabe destacar las siguientes:

  • La ampliación del tiempo de ejecución del trabajo de RoboCopy, ya que será necesario actualizar cada archivo y carpeta a los que afecte un cambio de ACL.
  • Es posible que haya que volver a copiar los datos que se migraron anteriormente. Por ejemplo, habrá que copiar más datos si cambian las estructuras de carpetas, aunque los archivos se hubieran copiado anteriormente. Un trabajo de RoboCopy no puede "reproducir" un cambio del espacio de nombres. El siguiente trabajo debe purgar los archivos transportados previamente en la estructura de carpetas antigua y volver a cargar los archivos en la nueva estructura de carpetas.

Otro aspecto importante es usar la herramienta RoboCopy de forma eficaz. Con el script de RoboCopy recomendado, se creará y guardará un archivo de registro de los errores. Es normal que puedan producirse errores de copia. Estos errores suelen hacer que sea necesario ejecutar varias rondas de una herramienta de copia como RoboCopy: una ejecución inicial, por ejemplo, desde un NAS a DataBox o un servidor a un recurso compartido de archivos de Azure, y una o varias ejecuciones adicionales con el modificador /MIR para detectar y volver a intentar archivos que no se copiaron.

Debe estar preparado para ejecutar varias rondas de RoboCopy en el ámbito de un espacio de nombres determinado. Las sucesivas ejecuciones finalizarán más rápido, ya que tienen menos que copiar, pero cada vez tendrán más restricciones debido a la velocidad de procesamiento del espacio de nombres. Cuando ejecute varias rondas, puede acelerar cada una de ellas si evita que RoboCopy intente copiarlo todo en una misma ejecución. Los siguientes modificadores RoboCopy pueden marcar una diferencia importante:

  • /R:n n = la frecuencia con la que se vuelve a intentar copiar un archivo con errores
  • /W:n n = el número de segundos que hay que esperar entre reintentos

/R:5 /W:5 es un valor razonable que puede ajustar a su gusto. En este ejemplo, un archivo con errores se intentará volver a copiar cinco veces, con un tiempo de espera de cinco segundos entre un reintento y otro. Si el archivo sigue sin copiarse, el siguiente trabajo de RoboCopy lo volverá a intentar. A menudo, los archivos que generan errores por estar en uso o debido a problemas de tiempo de espera se pueden copiar correctamente de esta manera.

Cálculo de los cargos de transacción de almacenamiento

A medida que comience la migración a Azure Files, RoboCopy copia los archivos y carpetas en Azure. En función del modelo de facturación de Azure Files, es posible que se apliquen cargos por transacción. Consulte Descripción del de facturación.

Si usa un modelo de facturación de pago por uso para recursos compartidos de archivos de Azure estándar, es posible que sea difícil calcular el número de transacciones que generará la migración.

  • No es posible calcular el número de transacciones en función de la capacidad de almacenamiento utilizada del origen. El número de transacciones se escala con el número de elementos de espacio de nombres (archivos y carpetas) y sus propiedades que se migran, no su tamaño. Por ejemplo, se requieren más transacciones para migrar 1 GiB de archivos pequeños que 1 GiB de archivos más grandes.
  • Para minimizar el tiempo de inactividad, es posible que tenga que ejecutar operaciones de copia varias veces desde el origen al destino. Todos los elementos de origen y de destino se procesan durante cada operación de copia, aunque las ejecuciones posteriores finalicen más rápido. Después de las operaciones iniciales, solo las diferencias introducidas entre las ejecuciones de copia se transportan a través de la red. Es importante comprender que, aunque se transportan menos datos, el número de transacciones necesarias podría seguir siendo el mismo.
  • Copiar el mismo archivo dos veces podría no dar lugar al mismo número de transacciones. El procesamiento de un elemento migrado en una ejecución de copia anterior podría dar lugar a solo algunas transacciones de lectura. En cambio, los cambios en los metadatos o el contenido entre ejecuciones de copia pueden requerir un mayor número de transacciones para actualizar el destino. Cada archivo del espacio de nombres puede tener requisitos únicos, lo que da lugar a un número diferente de transacciones.

Es aconsejable ejecutar algunas pruebas iniciales en sus propios datos para comprender mejor cuántas transacciones se incurren. Esto le dará una mejor idea del número total de transacciones que podría generar una migración de archivos.

Pasos siguientes

Los siguientes artículos le ayudarán a comprender las opciones avanzadas y los procedimientos recomendados.