Migración de datos sin conexión a Azure File Sync con Azure Data Box
Este artículo de migración es uno de los varios que se aplican a las palabras clave Azure File Sync y Azure Data Box. Compruebe si este artículo se aplica a su escenario:
- Origen de datos: Windows Server 2012 R2 o posterior donde Azure File Sync se instalará y apuntará al conjunto original de archivos.
- Ruta de migración: Windows Server 2012 R2 o posterior ⇒ Data Box ⇒ recurso compartido de archivos de Azure ⇒ sincronizar con la ubicación del archivo original de Windows Server
- Almacenamiento en caché de archivos en local: sí, el objetivo final es una implementación de Azure File Sync que sincronice los archivos desde donde están ahora.
Azure Data Box es una ruta de acceso viable para mover la mayor parte de los datos de Windows Server local a recursos compartidos de archivos de Azure independientes y luego, opcionalmente, agregar Azure File Sync en el servidor de origen original.
Hay diferentes rutas de migración disponibles; es importante seguir la correcta:
- Los datos se encuentran en Windows Server 2012 R2 o posterior y tiene previsto instalar AFS en ese servidor y sincronizar la ubicación original. En este escenario, no quiere cargar todos los archivos y usar Data Box en su lugar y, a continuación, usar la sincronización de archivos para los cambios en curso. Si este es su escenario, en este artículo se describe la ruta de migración.
- Tiene datos en un origen en el que no instalará o no puede instalar AFS. Un NAS (almacenamiento conectado a la red) por ejemplo o un servidor diferente. En su lugar, creará un nuevo servidor vacío y usará Azure File Sync en ese servidor. Si ese es su escenario, esta no es la guía de migración adecuada para usted. En su lugar, consulte: Migración desde NAS a través de Data Box a Azure File Sync o busque la mejor guía para su escenario en la página de información general de la migración.
- Para todos los demás escenarios, consulte la tabla de guías de migración de recursos compartidos de archivos de Azure. Esta página de información general proporciona un buen punto de partida para todos los escenarios de migración.
Información general sobre la migración
El proceso de migración consta de varias fases. Necesitará:
- Implemente cuentas de almacenamiento y recursos compartidos de archivos.
- Implemente uno o más dispositivos de Azure Data Box para mover los datos desde Windows Server 2012 R2 o posterior.
- Configure Azure File Sync con carga autoritativa.
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
Con esta guía de migración, debe seguir usando el almacenamiento de conexión directa (DAS) local que contiene los archivos. Data Box se alimentará desde esa ubicación y Azure File Sync también se configurará en esa ubicación. NAS (Network Attached Storage) no funciona con esta ruta de acceso de migración.
Usted determina qué se sincroniza configurando grupos de sincronización de Azure File Sync, cada uno de los cuales determina dónde se sincroniza un conjunto de archivos. Cada grupo de sincronización tiene al menos una ubicación de servidor, denominada punto de conexión de servidor, y un recurso compartido de archivos de Azure, llamado punto de conexión de nube.
Puede sincronizar rutas de acceso secundarias de un conjunto de archivos con cada uno de sus propios recursos compartidos de archivos de Azure. Esto significa configurar varios grupos de sincronización para cubrir completamente un conjunto de archivos. En el resto de la sección se describen las opciones. Si necesita reestructurar los datos, debe hacerlo como primer paso. A antes de continuar con esta guía, solicite una instancia de Data Box o sincronice la configuración.
Precaución
Es imperativo que la estructura de sus archivos y carpetas sea como desea que sea a largo plazo, antes de comenzar la migración. Evite cualquier reestructuración innecesaria de carpetas durante la migración. Esto reducirá los efectos positivos del uso de Azure Data Box para el transporte masivo inicial de archivos a Azure.
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.
Nota:
El disco de DataBox no es compatible porque no conserva la fidelidad del archivo.
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. 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.
Nota:
En el caso de Data Box y Data Box Heavy, solo se admite la copia de datos a través de SMB. La copia de datos a través del servicio de copia de datos no se admite, ya que no conserva la fidelidad del archivo.
Fase 4: 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ó:
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
_AzFilesson 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:
- Conexión a un dispositivo Data Box.
- Copia de datos a un dispositivo Data Box.
- Preparación del dispositivo Data Box para cargarlo en Azure.
La documentación vinculada 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 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. |
/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 modificador solo es útil para los destinos con almacenamiento en niveles que podrían quedarse sin capacidad local antes de que finalice Robocopy. 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 5: 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 6: 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 7: Configuración de Azure File Sync en el servidor de Windows Server existente
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.
- Inicie sesión en Azure Portal.
- Busque el recurso del servicio de sincronización de almacenamiento.
- 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.
- 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.
- 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.
Una vez que se encuentra en el asistente Crear un punto de conexión de servidor, use la casilla proporcionada debajo de la ruta de acceso de la carpeta. Realice esta selección solamente si ha escrito una ruta de acceso que apunta a la misma estructura de archivos y carpetas que se puede encontrar en el recurso compartido de archivos de Azure (donde el dispositivo Data Box ha movido los archivos y las carpetas para este espacio de nombres).
Si hay un error de coincidencia en la jerarquía de carpetas, eso se presentará como diferencias que no se pueden resolver automáticamente. Evitar desajustes o cualquier inversión en el proceso de Data Box se traducirá en un beneficio cero para usted. Todos los datos se eliminarán en el recurso compartido de archivos de Azure. Todos los datos tendrán que cargarse desde el servidor local. Las estructuras de directorio deben coincidir para obtener las ventajas de una migración masiva con Azure Data Box y una actualización sin problemas del recurso compartido en la nube con los cambios más recientes del servidor.
Nota:
Al habilitar esta casilla se establecerá el modo Sincronización inicial en Authoritatively overwrite files and folders in the Azure file share with content in this server’s path (Sobrescribir de manera autorizada archivos y carpetas en el recurso compartido de archivos de Azure con contenido en la ruta de acceso de este servidor). Esta opción solo está disponible para el primer punto de conexión de servidor de un grupo de sincronización.
Una vez configurada la carga autoritativa para este nuevo punto de conexión de servidor, puede habilitar la nube por niveles si así lo desea.
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. Use esta característica para lograr una superficie de almacenamiento fija en el entorno local, pero sin dejar de proporcionar a los usuarios una memoria caché de rendimiento local y almacenar datos más fríos en la nube.
Obtenga más información consultando la información general de la nube por niveles o eche un vistazo más de cerca a las diferentes directivas de la nube por niveles que puede usar para ajustar lo que se almacena en caché en niveles en el servidor local.
Completar la migración
Después de crear un punto de conexión de servidor, la sincronización funciona. Sin embargo, la sincronización debe enumerar (detectar) los archivos y las carpetas que se movieron a través de Azure 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 los cambios más recientes del servidor se sincronicen en la nube. Los usuarios no se verán afectados y podrán seguir trabajando con los datos en el servidor. Esta estrategia logra una migración a la nube sin tiempo de inactividad.
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. Ha usado Azure Data Box para mover los archivos a varios recursos compartidos de archivos de Azure. La migración se completa una vez creados todos los puntos de conexión de servidor que conectan los datos locales a estos recursos compartidos de archivos de Azure.
Pasos siguientes
Hay más información sobre los recursos compartidos de archivos de Azure y Azure File Sync. Los artículos siguientes lo ayudarán a comprender las opciones avanzadas y los procedimientos recomendados. También proporcionan ayuda para solucionar problemas. Estos artículos contienen vínculos a la documentación del recurso compartido de archivos de Azure cuando corresponda.