Migración de las series 8100 y 8600 de StorSimple a Azure File Sync

La serie StorSimple 8000 incluye los dispositivos físicos y locales 8100 u 8600 y sus componentes de servicios en la nube. Las aplicaciones virtuales StorSimple 8010 y 8020 también se tratan en esta guía de migración. Es posible migrar los datos de cualquiera de estos dispositivos a recursos compartidos de archivos de Azure con la aplicación Azure File Sync opcional. Azure File Sync es el servicio de Azure a largo plazo predeterminado y estratégico que reemplaza la funcionalidad local de StorSimple. En este artículo se proporcionan los conocimientos básicos y los pasos de migración necesarios para realizar una migración correcta a Azure File Sync.

Nota

El servicio StorSimple (incluido el Administrador de dispositivos de StorSimple para las series 8000 y 1200 y StorSimple Data Manager) ha llegado al final de la fase de soporte técnico. El final del soporte técnico de StorSimple se publicó en 2019 en las páginas Política del ciclo de vida de Microsoft y Comunicaciones de Azure. Se enviaron notificaciones adicionales por correo electrónico y se publicaron en Azure Portal y en la información general de StorSimple. Póngase en contacto con el servicio de Soporte técnico de Microsoft para obtener más información.

En este vídeo se proporciona información general sobre:

• Azure Files
• Azure File Sync
• Comparación de StorSimple y Azure Files
• Información general sobre la herramienta de migración y el proceso de StorSimple Data Manager

Fase 1: Preparación para la migración

Esta sección contiene los pasos que debe seguir al principio de la migración de volúmenes de StorSimple a recursos compartidos de archivos de Azure.

El vídeo trata de:

• Selección del nivel de almacenamiento
• Selección de redundancia de almacenamiento.
• Selección de acceso directo a recursos compartidos de archivos o Azure File Sync
• Clave de cifrado de datos del servicio StorSimple y número de serie
• Migración de copia de seguridad de volúmenes de StorSimple
• Asignación de volúmenes y recursos compartidos de StorSimple a recursos compartidos de archivos de Azure
• Agrupación de recursos compartidos dentro de recursos compartidos de archivos de Azure
• Consideraciones de asignación
• Hoja de cálculo de planificación de iteración
• Hoja de cálculo de asignación de espacios de nombres

Tema de

Cuando empiece a planear la migración, identifique primero todos los dispositivos y volúmenes de StorSimple que necesita migrar. Después, puede decidir la mejor ruta de migración.

• Los dispositivos físicos de StorSimple (serie 8000) usan esta guía de migración.
• Los dispositivos virtuales StorSimple (serie 1200) usan una guía de migración diferente.

Resumen de costos de migración

Las migraciones a recursos compartidos de archivos de Azure desde volúmenes de StorSimple a través de trabajos de migración en un recurso de StorSimple Data Manager son gratuitas. Pueden producirse otros costos durante y después de la migración:

• Salida de red: los archivos de StorSimple residen en una cuenta de almacenamiento dentro de una región de Azure específica. Si aprovisiona los recursos compartidos de archivos de Azure que migra a una cuenta de almacenamiento que se encuentra en la misma región de Azure, no se incurrirá en ningún costo de salida. Sin embargo, si mueve los archivos a una cuenta de almacenamiento en otra región como parte de esta migración, se aplicarán costos de salida.
• Transacciones de recursos compartido de archivos de Azure: cuando los archivos se copian en un recurso compartido de archivos de Azure (como parte de una migración o fuera de una), los costos de transacción se aplican a medida que se escriben archivos y metadatos. Como procedimiento recomendado, inicie el recurso compartido de archivos de Azure del nivel optimizado para transacciones durante la migración. Cambie al nivel deseado después de finalizar la migración. Las fases descritas en este artículo mencionan esto en el punto adecuado.
• Cambio del nivel de un recurso compartido de archivos de Azure: cambiar el nivel de un recurso compartido de archivos de Azure conlleva transacciones. En la mayoría de los casos, es más rentable seguir los consejos del punto anterior.
• Coste de almacenamiento: cuando esta migración comienza a copiar archivos en un recurso compartido de archivos de Azure, se consume y se factura almacenamiento. Las copias de seguridad migradas se convierten en instantáneas de recurso compartido de archivos de Azure. Las instantáneas de recurso compartido de archivos solo consumen la capacidad de almacenamiento para las diferencias que contienen.
• StorSimple: hasta que desaprovisione las cuentas de almacenamiento y los dispositivos de StorSimple, se seguirá incurriendo en el costo de StorSimple por almacenamiento, copias de seguridad y dispositivos.

Acceso directo de recursos compartidos frente a Azure File Sync

Los recursos compartidos de archivos de Azure proporcionan un sinfín de oportunidades para estructurar la implementación de servicios de archivo. Un recurso compartido de archivos de Azure es un recurso compartido de SMB en la nube que puede configurar para que los usuarios tengan acceso directo a través del protocolo SMB con la autenticación Kerberos conocida y los permisos NTFS existentes (ACL de archivos y carpetas) funcionen de forma nativa. Obtenga más información sobre el acceso basado en identidad a recursos compartidos de archivos de Azure.

Una alternativa al acceso directo es Azure File Sync. Azure File Sync es un análogo directo de la capacidad de StorSimple de almacenar en caché los archivos que se usan con frecuencia de forma local.

Azure File Sync es un servicio en la nube de Microsoft, que se basa en dos componentes principales:

• Sincronización de archivos y nube por niveles para crear una caché de acceso de rendimiento en cualquier servidor de Windows.
• Recursos compartidos de archivos como almacenamiento nativo en Azure, a los que se puede acceder a través de varios protocolos, como SMB y REST de archivos.

Los recursos compartidos de archivos de Azure conservan aspectos importantes de la fidelidad de archivos como atributos, permisos y marcas de tiempo. Con los recursos compartidos de Azure, ya no es necesario una aplicación o servicio que interprete los archivos y carpetas que están almacenados en la nube. Puede acceder a ellos de forma nativa a través de protocolos y clientes conocidos. Los recursos compartidos de archivos de Azure permiten almacenar datos de aplicaciones y de servidores de archivos de uso general en la nube.

Este artículo se centra en los pasos de migración. Si desea obtener más información sobre Azure File Sync antes de la migración, consulte los siguientes artículos:

• Guía de plan de Azure File Sync
• Guía de implementación de Azure File Sync

Clave de cifrado de datos del servicio de StorSimple

La primera vez que se configura el dispositivo de StorSimple, se genera una clave de cifrado de datos del servicio y se le indica que almacene la clave de forma segura. Esta clave se usa para cifrar todos los datos de la cuenta de almacenamiento de Azure asociada, en la que el dispositivo de StorSimple almacena los archivos.

La clave de cifrado de datos del servicio es necesaria para llevar a cabo una migración correcta. Recupere esta clave de sus registros, una para cada dispositivo del inventario.

Si no puede encontrar las claves en los registros, puede recuperar una nueva clave desde el dispositivo. Cada dispositivo tiene una clave de cifrado única.

Cambiar la clave de cifrado de datos de servicio

Las claves de cifrado de datos del servicio se usan para cifrar datos confidenciales de los clientes, como las credenciales de la cuenta de almacenamiento, que se envían desde el servicio StorSimple Manager al dispositivo de StorSimple. Necesitará cambiar estas claves periódicamente si su organización de TI tiene una directiva de rotación de claves en los dispositivos de almacenamiento. El proceso de cambio de clave puede ser ligeramente diferente dependiendo de si el servicio StorSimple Manager administra uno o varios dispositivos. Para más información, vaya a StorSimple security and data protection (Protección de datos y seguridad de StorSimple).

El cambio de la clave de cifrado de datos del servicio se realiza en 3 pasos:

1. Mediante scripts de Windows PowerShell para Azure Resource Manager, autorice a un dispositivo cambiar la clave de cifrado de datos del servicio.
2. En Windows PowerShell para StorSimple, inicie el cambio de claves de cifrado de datos del servicio.
3. Si tiene más de un dispositivo de StorSimple, actualice la clave de cifrado de datos del servicio en los demás dispositivos.

Paso 1: Usar un script de Windows PowerShell para autorizar a un dispositivo a cambiar la clave de cifrado de datos del servicio

Normalmente, el administrador de dispositivos solicitará que el administrador de servicios autorice que un dispositivo cambie las claves de cifrado de datos del servicio. A continuación, el administrador de servicios autorizará que el dispositivo cambie la clave.

Este paso se realiza con el script basado en Azure Resource Manager. El administrador de servicios puede seleccionar un dispositivo que sea apto para la autorización. A continuación, se autoriza que el dispositivo inicie el proceso de cambio de las claves de cifrado de datos del servicio.

Para más información sobre el uso del script, vaya a Authorize-ServiceEncryptionRollover.ps1

¿Qué dispositivos se pueden autorizar para que cambien las claves de cifrado de datos del servicio?

Para poder autorizar que un dispositivo inicie los cambios de las claves de cifrado de datos del servicio debe cumplir los siguientes criterios:

• Para que sea válido para la autorización de cambio de claves de cifrado de datos del servicio, el dispositivo debe estar en línea.
• Si el cambio de claves no se ha iniciado, es posible autorizar el mismo dispositivo 30 minutos después.
• Se puede autorizar otro dispositivo, siempre que el dispositivo autorizado anteriormente no haya iniciado el cambio de claves. Una vez que se haya autorizado el nuevo dispositivo, el anterior no puede iniciar el cambio.
• No se puede autorizar un dispositivo mientras la sustitución de la clave de cifrado de datos del servicio esté en curso.
• Se puede autorizar un dispositivo cuando algunos de los dispositivos registrados en el servicio hayan sustituido el cifrado, mientras que otros no lo hayan hecho.

Paso 2: Usar Windows PowerShell para StorSimple a fin de iniciar el cambio de claves de cifrado de datos del servicio

Este paso se realiza en la interfaz de Windows PowerShell para StorSimple del dispositivo de StorSimple autorizado.

Nota

Hasta que se complete la sustitución de claves no se pueden realizar operaciones en Azure Portal del servicio StorSimple Manager.

Si utiliza la consola serie del dispositivo para conectarse a la interfaz de Windows PowerShell, realice los pasos siguientes.

Para iniciar el cambio de claves de cifrado de datos del servicio

1. Seleccione la opción 1 para iniciar sesión con acceso total.

2. En el símbolo del sistema, escriba:

   Invoke-HcsmServiceDataEncryptionKeyChange

3. Una vez que se haya completado correctamente el cmdlet, obtendrá una nueva clave de cifrado de datos del servicio. Copie y guarde esta clave para usarla en el paso 3 de este proceso. Esta clave se utilizará para actualizar todos los dispositivos restantes registrados en el servicio StorSimple Manager.

   Nota

   Este proceso debe iniciarse en las cuatro horas siguientes a la autorización de un dispositivo de StorSimple.

   A continuación, esta nueva clave se envía al servicio de inserción en todos los dispositivos que están registrados en el servicio. Seguidamente, aparecerá una alerta en el panel del servicio. El servicio deshabilitará todas las operaciones en los dispositivos registrados y, a continuación, el administrador de dispositivos tendrá que actualizar la clave de cifrado de datos del servicio en el resto de dispositivos. Sin embargo, las E/S (hosts que envían datos a la nube) no se interrumpirán.

   Si tiene un único dispositivo registrado en el servicio, el proceso de sustitución habrá finalizado y puede omitir el paso siguiente. Si tiene varios dispositivos registrados en el servicio, vaya al paso 3.

Paso 3: Actualizar la clave de cifrado de datos del servicio en otros dispositivos de StorSimple

Estos pasos deben realizarse en la interfaz de Windows PowerShell del dispositivo de StorSimple si tiene varios dispositivos registrados en el servicio StorSimple Manager. La clave que obtuvo en el paso 2 se debe usar para actualizar todos los dispositivos de StorSimple restantes registrados con el servicio StorSimple Manager.

Realice los pasos siguientes para actualizar el cifrado de datos del servicio en el dispositivo.

Para actualizar la clave de cifrado de datos del servicio en dispositivos físicos

1. Use Windows PowerShell para StorSimple para conectarse a la consola. Seleccione la opción 1 para iniciar sesión con acceso total.
2. En el símbolo del sistema, escriba: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
3. Proporcione la clave de cifrado de datos del servicio que obtuvo en Paso 2: Usar Windows PowerShell para StorSimple a fin de iniciar el cambio de claves de cifrado de datos del servicio.

Para actualizar la clave de cifrado de datos del servicio en todas las aplicaciones en la nube 8010/8020

1. Descargue y configure el script de PowerShell Update-CloudApplianceServiceEncryptionKey.ps1.
2. Abra PowerShell y, en el símbolo del sistema, escriba: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Este script asegurará de que esa clave de cifrado de datos del servicio se establece en todas las aplicaciones en la nube 8010/8020 en el administrador de dispositivos.

Precaución

Cuando decida cómo conectarse a su dispositivo de StorSimple, tenga en cuenta lo siguiente:

• La conexión a través de una sesión HTTPS es la opción más segura y la recomendada.
• Es seguro conectarse directamente a la consola serie del dispositivo, pero la conexión a la consola serie a través conmutadores de red no lo es.
• Las conexiones de sesión HTTP son una opción, pero no están cifradas. No se recomiendan a menos que se usen en una red cerrada y de confianza.

Limitaciones conocidas

Los recursos compartidos de StorSimple Data Manager y Azure tienen algunas limitaciones que debe tener en cuenta antes de comenzar, ya que pueden impedir una migración:

• Solo se admiten volúmenes NTFS desde el dispositivo StorSimple. No se admiten volúmenes ReFS.
• No se admite ningún volumen ubicado en discos dinámicos de Windows Server.
• El servicio no funciona con volúmenes cifrados con BitLocker o que tengan habilitada la opción Desduplicación de datos.
• Las copias de seguridad de StorSimple dañadas no se pueden migrar.
• Las opciones de red especiales, como los firewalls o la comunicación solo a través de punto de conexión privado, no se pueden habilitar ni en la cuenta de almacenamiento de origen donde se almacenan las copias de seguridad de StorSimple ni en la cuenta de almacenamiento de destino que contiene los recursos compartidos de archivos de Azure.

Fidelidad de archivos

Si ninguna de las limitaciones de limitaciones conocidas impide una migración, todavía hay limitaciones en lo que se puede almacenar en los recursos compartidos de archivos de Azure.

La fidelidad de los archivos hace referencia a la gran cantidad de atributos, marcas de tiempo y datos que componen un archivo. En una migración, la fidelidad de los archivos es una medida de lo bien que se puede trasladar (migrar) la información del origen (volumen StorSimple) al recurso compartido de archivos de Azure de destino.

Azure Files admite un subconjunto de las propiedades del archivo NTFS. Las ACL de Windows, los metadatos comunes y algunas marcas de tiempo se migran.

Los siguientes elementos no impedirán una migración, pero provocarán problemas por elementos durante la misma:

• Marcas de tiempo: no se establecerá el tiempo de cambio de archivo. Actualmente es de solo lectura a través del protocolo REST. La marca de tiempo de último acceso de un archivo no se trasladará ya que no es un atributo admitido en los archivos almacenados en un recurso compartido de archivos de Azure.
• Los flujos de datos alternativos no se pueden almacenar en recursos compartidos de archivos de Azure. Los archivos que contienen flujos de datos alternativos se copiarán, pero los flujos de datos alternativos se eliminarán del archivo en el proceso.
• Los vínculos simbólicos, los vínculos duros, las uniones y los puntos de análisis se omiten durante una migración. Los registros de copia de la migración enumeran cada elemento omitido y el motivo de su omisión.
• Los archivos cifrados de EFS no se pudieron copiar. Los registros de copia muestran que el elemento no se pudo copiar con “Acceso denegado”.
• Los archivos dañados se omiten. Los registros de copia pueden enumerar errores diferentes para cada elemento dañado en el disco de StorSimple: “Error en la solicitud debido a un error irrecuperable de hardware del dispositivo” o “El archivo o directorio está dañado o no se puede leer” o “La estructura de la lista de control de acceso (ACL) no es válida”.
• Se omitirán los archivos individuales de más de 4 TiB.
• Las longitudes de ruta de acceso a archivos deben ser iguales o inferiores a 2048 caracteres. Se omiten los archivos y carpetas con rutas de acceso más largas.
• Se omiten los puntos de repetición de análisis. El motor de migración no puede resolver ningún punto de repetición de análisis de datos de SIS o Desduplicación de datos de Microsoft, o los de terceros, y evitará una migración de los archivos y carpetas afectados.

La sección de solución de problemas al final de este artículo tiene más detalles sobre el nivel de elemento y los códigos de error de nivel de trabajo de migración y, siempre que sea posible, sus opciones de mitigación.

Copias de seguridad de volúmenes de StorSimple

StorSimple ofrece copias de seguridad diferenciales en el nivel de los volúmenes. Los recursos compartidos de archivos de Azure también tienen esta capacidad, denominada "instantáneas de recurso compartido".

Los trabajos de migración solo pueden migrar copias de seguridad, nunca datos del volumen activo. Por lo tanto, la copia de seguridad más reciente es más cercana a los datos activos y, por lo tanto, debe formar parte de la lista de copias de seguridad que se trasladarán en una migración.

Decida si necesita trasladar alguna copia de seguridad anterior durante la migración. El procedimiento recomendado consiste en mantener esta lista lo más breve posible, de modo que los trabajos de migración se completen más rápido.

Para identificar las copias de seguridad críticas que se deben migrar, realice una lista de comprobación de las directivas de copia de seguridad. Por ejemplo:

• La copia de seguridad más reciente.
• Una copia de seguridad al mes durante 12 meses.
• Una copia de seguridad al año durante tres años.

Al crear los trabajos de migración, puede usar esta lista para identificar las copias de seguridad del volumen de StorSimple exactas que se deben migrar para cumplir los requisitos.

Es mejor suspender todas las directivas de retención de copia de seguridad de StorSimple antes de seleccionar una copia de seguridad para la migración. La migración de las copias de seguridad puede tardar varios días o semanas. StorSimple ofrece directivas de retención de copias de seguridad que eliminan las copias de seguridad. Las copias de seguridad que ha seleccionado para esta migración pueden eliminarse antes de que tengan la oportunidad de migrarse.

Precaución

No se admite la selección de más de 50 copias de seguridad de volumen de StorSimple.

Asignación de volúmenes de StorSimple a recursos compartidos de archivos de 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.

Número de cuentas de almacenamiento

Es probable que la migración se beneficie de una implementación de varias cuentas de almacenamiento, cada una con un número de recursos compartidos de archivos de Azure más reducido.

Si tiene recursos compartidos muy activos (utilizados por muchos usuarios o aplicaciones), dos recursos compartidos de archivos de Azure podrían alcanzar el límite de rendimiento de una cuenta de almacenamiento. Por este motivo, suele ser mejor migrar a varias cuentas de almacenamiento, cada una con sus propios recursos compartidos de archivos y, por lo general, no más de dos o tres recursos compartidos por 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, en caso de que tenga recursos compartidos de archivo.

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 exclusivamente Azure File Sync en estos recursos compartidos, es correcta la agrupación de varios en una sola cuenta de almacenamiento de Azure. En el futuro, se recomienda migrar mediante lift-and-shift una aplicación a la nube que, a continuación, tendrá acceso directo a un recurso compartido de archivos, ya que este escenario se beneficiará de tener más IOPS y rendimiento. También puede empezar a usar un servicio de Azure que también se beneficiará de tener un mayor IOPS y rendimiento.

Después de crear una lista de recursos compartidos, asigne cada recurso compartido a la cuenta de almacenamiento en la que residirá. Seleccione una región de Azure y asegúrese de que cada cuenta de almacenamiento y recurso de Azure File Sync coinciden con la región que ha seleccionado.

Importante

No configure ahora las opciones de la red y del firewall para las cuentas de almacenamiento. Realizar estas configuraciones en este momento haría imposible la migración. Configure estas opciones de Azure Storage una vez completada la migración.

Configuración de cuentas de almacenamiento

Hay muchas configuraciones que puede realizar en una cuenta de almacenamiento. Use la siguiente lista de comprobación para confirmar las opciones de configuración de la cuenta de almacenamiento. Puede cambiar la configuración de red una vez completada la migración.

• Firewall y redes virtuales: deshabilitado. No configure restricciones de IP ni limite el acceso de la cuenta de almacenamiento a una red virtual específica. El punto de conexión público de la cuenta de almacenamiento se usa durante la migración. Se deben permitir todas las direcciones IP de las máquinas virtuales de Azure. Es mejor configurar las reglas de firewall en la cuenta de almacenamiento después de la migración. Configure las cuentas de almacenamiento de origen y de destino de esta manera.
• Puntos de conexión privados: admitido. Puede habilitar puntos de conexión privados, pero el punto de conexión público se usa para la migración y debe permanecer disponible. Esto se aplica a las cuentas de almacenamiento de origen y de destino.

Resumen de la fase 1

Al final de la fase 1:

• Conocerá bien sus volúmenes y dispositivos de StorSimple.
• El servicio de Data Manager está listo para acceder a los volúmenes de StorSimple en la nube, ya que ha recuperado la clave de cifrado de datos del servicio de cada dispositivo de StorSimple.
• Tendrá un plan para el que se deben migrar los volúmenes y las copias de seguridad (si hay alguno después de los más recientes).
• Sabrá cómo asignar los volúmenes al número adecuado de recursos compartidos de archivo y cuentas de almacenamiento de Azure.

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

En esta sección se explican las consideraciones sobre la implementación de los diferentes tipos de recursos que se necesitan en Azure. Algunos contendrán los datos después de la migración y otros solo se necesitan para la migración. No empiece a implementar recursos hasta que haya finalizado el plan de implementación. Es difícil, y a veces imposible, cambiar determinados aspectos de los recursos de Azure una vez que se han implementado.

En este vídeo se describe la implementación de:

• Cuentas de almacenamiento
• Suscripciones y grupos de recursos
• Cuentas de almacenamiento
• Tipos y nombres
• Rendimiento y tamaño de recurso compartido
• Tipos de ubicación y replicación
• Recursos compartidos de archivos de Azure
• Servicio de StorSimple Data Manager

Implementación de cuentas de almacenamiento

Probablemente, tendrá que implementar varias cuentas de Azure Storage. Cada uno contendrá un número menor de recursos compartidos de archivos de Azure, según el plan de implementación. Vaya a Azure Portal para implementar las cuentas de almacenamiento planeadas. Considere la posibilidad de seguir la configuración básica de a continuación en cualquier cuenta de almacenamiento nueva.

Importante

No configures antes o durante la migración las opciones de la red y del firewall para tus cuentas de almacenamiento. Realizar esas configuraciones en este momento haría imposible la migración. El punto de conexión público debe ser accesible en las cuentas de almacenamiento de origen y de destino. No se admite la limitación a intervalos IP específicos o redes virtuales. Puedes cambiar las configuraciones de red de la cuenta de almacenamiento después de que se complete la migración.

Subscription

Puede usar la misma suscripción que usó para la implementación de StorSimple o puede usar una diferente. La única limitación es que la suscripción debe estar en el mismo inquilino de Microsoft Entra que la suscripción de StorSimple. Considere la posibilidad de mover la suscripción a StorSimple al inquilino adecuado antes de iniciar una migración. Solo puede trasladar la suscripción en su conjunto, ya que los recursos individuales de StorSimple no se pueden trasladar a otro inquilino o suscripción.

Resource group

Los grupos de recursos de Azure ayudan con la organización de recursos y los permisos de administración de administradores. Más información.

Nombre de la cuenta de almacenamiento

El nombre de la cuenta de almacenamiento formará parte de una dirección URL que se usa para acceder al recurso compartido de archivos y tiene ciertas limitaciones de caracteres. En su convención de nomenclatura, tenga en cuenta que los nombres de las cuentas de almacenamiento deben ser únicos, tener solo letras en minúsculas y números, contener entre 3 y 24 caracteres y no usar caracteres especiales como guiones o guiones bajos. Consulte Reglas de nomenclatura de recursos de almacenamiento de Azure.

Location

La región de Azure de una cuenta de almacenamiento es importante. Si usa Azure File Sync, todas las cuentas de almacenamiento deben estar en la misma región que el recurso del servicio de sincronización de almacenamiento. La región de Azure que elija debe ser cercana a los servidores y usuarios locales o ubicarse en un punto céntrico. Después de implementar el recurso, no puede cambiar su región.

Puede elegir una región diferente desde la que residen actualmente los datos de StorSimple (cuenta de almacenamiento), pero si lo hace, se aplicarán cargos de salida durante la migración. Los datos dejarán la región de StorSimple y entrarán en la nueva región de la cuenta de almacenamiento. No se aplican cargos de ancho de banda si permanece dentro de la misma región de Azure.

Rendimiento

Tiene la opción de elegir Premium Storage (SSD) para recursos compartidos de archivos de Azure o almacenamiento estándar. El almacenamiento estándar incluye varios niveles para un recurso compartido de archivos. Standard Storage es la opción adecuada para la mayoría de los clientes que migran desde StorSimple.

• Elija Premium Storage si necesita el rendimiento de un recurso compartido de archivos Premium de Azure.
• Elija almacenamiento estándar para cargas de trabajo de servidor de archivos de uso general, incluidos los datos de acceso frecuente y los datos de archivo. Elija también almacenamiento estándar si la única carga de trabajo en el recurso compartido en la nube será Azure File Sync.
• En el caso de los recursos compartidos de archivos premium, elija Recursos compartidos de archivos en el asistente para crear cuentas de almacenamiento.

Replicación

Hay varias configuraciones de replicación disponibles. Elija solo entre las dos opciones siguientes:

• Almacenamiento con redundancia local (LRS) .
• Almacenamiento con redundancia de zona (ZRS) , que no está disponible en todas las regiones de Azure.

Nota:

No se admite el almacenamiento con redundancia geográfica (GRS) ni el almacenamiento con redundancia de zona geográfica.

Recursos compartidos de archivos de Azure

Después de crear las cuentas de almacenamiento, puede ir a la sección Recurso compartido de archivos de la cuenta de almacenamiento e implementar el número adecuado de recursos compartidos de archivos de Azure según el plan de migración de la fase 1. Considere la posibilidad de usar la siguiente configuración básica para los nuevos recursos compartidos de archivos de Azure.

Se admiten letras en minúsculas, números y guiones.



En este caso la cuota es comparable a una cuota fija de SMB en una instancia de Windows Server. El procedimiento recomendado es no establecer una cuota en este caso, ya que la migración y otros servicios producirán un error cuando se alcance.



Seleccione
para el nuevo recurso compartido de archivos. Durante la migración, se producirán muchas transacciones. Es más rentable cambiar el nivel más adelante al nivel más adecuado para la carga de trabajo.

StorSimple Data Manager

El recurso de Azure que contiene los trabajos de migración se llama StorSimple Data Manager. Seleccione Nuevo recurso y búsquelo. Seleccione Crear.

Este recurso temporal se usa para la orquestación. Se desaprovisiona una vez finalizada la migración. Asegúrese de implementarlo en la misma suscripción, grupo de recursos y región que la cuenta de almacenamiento de StorSimple.

Azure File Sync

Con Azure File Sync, puede agregar almacenamiento en caché local de los archivos a los que se accede con más frecuencia. De forma similar a las funcionalidades de almacenamiento en caché de StorSimple, la característica de nube por niveles de Azure File Sync ofrece latencia de acceso local en combinación con el control mejorado de la funcionalidad de caché disponible en la instancia de Windows Server y en la sincronización de varios sitios. Si el objetivo es tener una caché local, prepare una máquina virtual de Windows Server (también se admiten servidores físicos y clústeres de conmutación por error) en su red local con capacidad de almacenamiento conectado directamente suficiente.

Importante

No configure Azure File Sync todavía. La implementación de Azure File Sync no debe iniciarse antes de la fase 4 de una migración.

Resumen de la fase 2

Al final de la fase 2, habrá implementado sus cuentas de almacenamiento y todos los recursos compartidos de archivos de Azure en ellas. También tendrá un recurso StorSimple Data Manager. Usará este último en la fase 3, cuando configure los trabajos de migración.

Fase 3: Creación y ejecución de un trabajo de migración

En esta sección se describe cómo configurar un trabajo de migración y asignar los directorios de un volumen de StorSimple que debe copiarse en el recurso compartido de archivos de Azure de destino que seleccione.

El vídeo trata de:

• Creación de un trabajo de migración
• Resumen
• Source
• Selección de copias de seguridad de volumen para migrar
• Destino
• Asignación de directorios
• Reglas semánticas
• Ejecución de un trabajo de migración
• Ejecución de a definición de trabajo
• Visualización del estado del trabajo
• Ejecución de trabajos en paralelo
• Interpretación de los archivos de registro

Para empezar, vaya a StorSimple Data Manager, busque Definiciones de trabajo en el menú y seleccione + Definición de trabajo. El tipo de almacenamiento de destino correcto es el valor predeterminado: Recurso compartido de archivos de Azure.

Nombre de definición de trabajo
Este nombre indica el conjunto de archivos que se van a mover. Le recomendamos que le asigne un nombre similar al recurso compartido de archivos de Azure.



Al seleccionar una región, debe seleccionar la misma que la cuenta de almacenamiento de StorSimple o, si no está disponible, otra cercana a ella.

Origen

Suscripción de origen
Seleccione la suscripción en la que almacena el recurso de StorSimple Device Manager.



Seleccione la instancia de StorSimple Device Manager en la que el dispositivo esté registrado.



Consulte
en caso de que no localice la clave en sus registros.



Seleccione el dispositivo de StorSimple que contiene el volumen que desee migrar.



Seleccione el volumen de origen. Más adelante decidirá si desea migrar el volumen o los subdirectorios completos al recurso compartido de archivos de Azure de destino.

Volumen de copias de seguridad
Puede seleccionar Seleccionar volumen de las copias de seguridad para escoger copias de seguridad específicas para mover como parte de esta tarea. En una sección específica de este artículo se describe más adelante el proceso de manera detallada.

Destino

Seleccione la suscripción, la cuenta de almacenamiento y el recurso compartido de archivos de Azure como destino de este trabajo de migración.

Asignación de directorios

En una sección dedicada de este artículo, se describen todos los detalles pertinentes.

Selección de copias de seguridad de volumen para migrar

Hay algunos aspectos importantes relacionados con la elección de las copias de seguridad que se deben migrar:

• Los trabajos de migración solo pueden migrar copias de seguridad, no datos de un volumen activo. Por lo tanto, la copia de seguridad más reciente es más cercana a los datos activos y siempre debe incluirse en la lista de copias de seguridad que se han trasladado en una migración. Al abrir el cuadro de diálogo Selección de copia de seguridad, se selecciona de manera predeterminada.
• Asegúrese de que la última copia de seguridad sea reciente para mantener el tamaño del delta en el recurso compartido activo lo más pequeño posible. Podría ser conveniente desencadenar y completar manualmente otra copia de seguridad del volumen antes de crear un trabajo de migración. Un pequeño delta en el recurso compartido activo mejora la experiencia de migración. Si este delta puede ser cero, esto significa que no se han producido más cambios en el volumen de StorSimple después de que se realizara la copia de seguridad más reciente en la lista; a continuación, el recorte del usuario se simplificará y acelerá drásticamente.
• Las copias de seguridad se deben reproducir en el recurso compartido de archivos de Azure de la más antigua a la más reciente. Una copia de seguridad antigua no se puede "ordenar" en la lista de copias de seguridad del recurso compartido de archivos de Azure después de ejecutar un trabajo de migración. Por lo tanto, debe asegurarse de que la lista de copias de seguridad se ha completado antes de crear un trabajo.
• Esta lista de copias de seguridad de un trabajo no se puede modificar una vez crear el trabajo, si este nunca se ejecutó.
• Para seleccionar copias de seguridad, el volumen de StorSimple que se quiere migrar debe estar en línea.

Para seleccionar copias de seguridad del volumen de StorSimple para el trabajo de migración, seleccione la opción Select volume backups (seleccionar copias de seguridad del volumen) en el formulario de creación de trabajos.

Cuando se abre la hoja de selección de copias de seguridad, está dividida en dos listas. En la primera lista, se muestran todas las copias de seguridad disponibles. Puede expandir y reducir el conjunto de resultados al usar un intervalo de tiempo específico como filtro. (consulte la siguiente sección)

Una copia de seguridad seleccionada se mostrará atenuada y se agregará a una segunda lista en la parte inferior de la hoja. La segunda lista muestra todas las copias de seguridad seleccionadas para la migración. Una copia de seguridad seleccionada accidentalmente también se puede volver a quitar.

Precaución

Debe seleccionar todas las copias de seguridad que quiera migrar. No se pueden agregar copias de seguridad anteriores más adelante. No se puede modificar el trabajo para cambiar la selección una vez que se ha creado el trabajo.

De manera predeterminada, la lista se filtra para mostrar las copias de seguridad de volúmenes de StorSimple de los últimos siete días. La copia de seguridad más reciente está seleccionada de manera predeterminada aunque no se haya hecho en los últimos siete días. Para las copias de seguridad anteriores, use el filtro de intervalo de tiempo en la parte superior de la hoja. Puede seleccionar uno de los filtros existentes o establecer un intervalo de tiempo personalizado para filtrar solo las copias de seguridad realizadas durante ese período.

Precaución

No se admite la selección de más de 50 copias de seguridad de volumen de StorSimple. Se puede producir un error en los trabajos con un gran número de copias de seguridad. ¡Asegúrese de que las directivas de retención de copia de seguridad no eliminen una copia de seguridad seleccionada antes de poder migrarla!

Asignación de directorios

La asignación de directorios es opcional para el trabajo de migración. Si deja la sección vacía, todos los archivos y las carpetas de la raíz del volumen de StorSimple se moverán a la raíz del recurso compartido de archivos de Azure de destino. En la mayoría de los casos, almacenar el contenido de un volumen completo en un recurso compartido de archivos de Azure no es el mejor enfoque. A menudo, es mejor dividir el contenido de un volumen en varios recursos compartidos de archivos de Azure. Si aún no ha hecho un plan, consulte antes Asignación del volumen de StorSimple a recursos compartidos de archivos de Azure.

Como parte del plan de migración, es posible que haya decidido que las carpetas de un volumen de StorSimple deben dividirse en varios recursos compartidos de archivos de Azure. En ese caso, puede realizar esa división de la siguiente manera:

1. Definiendo varios trabajos para migrar las carpetas de un volumen, cada uno tendrá el mismo origen de volumen de StorSimple, pero un recurso compartido de archivos de Azure diferente como destino.
2. Especificando con precisión qué carpetas del volumen de StorSimple se deben migrar al recurso compartido de archivos especificado, mediante la sección de asignación de directorios del formulario de creación del trabajo y siguiendo la semántica de asignación específica.

Importante

Las rutas de acceso y las expresiones de asignación de este formulario no se pueden validar cuando se envía el formulario. Si se especifican las asignaciones incorrectamente, puede producirse un error en el trabajo o un resultado no deseado. En ese caso, suele ser mejor eliminar el recurso compartido de archivos de Azure, volver a crearlo y, a continuación, corregir las instrucciones de asignación en un nuevo trabajo de migración del recurso compartido. La ejecución de un nuevo trabajo con instrucciones de asignación fija puede corregir carpetas omitidas y colocarlas en el recurso compartido existente. Sin embargo, solo las carpetas que se omitieron debido a errores de escritura en la ruta de acceso se pueden solucionar de esta manera.

Elementos semánticos

Una asignación se expresa de izquierda a derecha: [\ruta de acceso de origen] > [\ruta de acceso de destino].

Carácter semántico	Significado
\	Indicador de nivel raíz.
>	Operador de asignación de [origen] y [destino].
| o RETURN (nueva línea)	Separador de dos instrucciones de asignación de carpetas. También puede omitir este carácter y seleccionar para obtener la siguiente expresión de asignación en su propia línea.

Ejemplos

Mueve el contenido de la carpeta Datos de usuario a la raíz del recurso compartido de archivos de destino:

\User data > \

Mueve todo el contenido del volumen a una nueva ruta de acceso en el recurso compartido de archivos de destino:

\ > \Apps\HR tracker

Mueve el contenido de la carpeta de origen a una nueva ruta de acceso en el recurso compartido de archivos de destino:

\HR resumes-Backup > \Backups\HR\resumes

Ordena varias ubicaciones de origen en una nueva estructura de directorios:

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Reglas semánticas

• Especifique siempre las rutas de acceso de la carpeta en relación con el nivel raíz.
• Comience cada ruta de acceso de carpeta con un indicador de nivel de raíz "\".
• No incluya letras de unidad.
• Si especifica varias rutas de acceso, las rutas de origen o destino no se pueden superponer:
  Ejemplo de superposición de ruta de origen no válida:
  
  
  
  
  Ejemplo de superposición de ruta de destino no válida:
  >
  
  
  
• Se omiten las carpetas de origen que no existen.
• Se crean las estructuras de carpetas que no existen en el destino.
• Al igual que Windows, los nombres de carpeta no distinguen mayúsculas de minúsculas, pero sí se conservan.

Nota:

El trabajo de migración no copiará el contenido de la carpeta \System Volume Information y $Recycle.Bin en el volumen de StorSimple.

Ejecución de un trabajo de migración

Los trabajos de migración aparecen debajo de Definiciones de trabajos en el recurso de Data Manager que ha implementado en un grupo de recursos. En la lista de definiciones de trabajos, seleccione el trabajo que quiere ejecutar.

En la hoja de trabajo que se abre, puede ver el estado actual del trabajo y una lista de las copias de seguridad que ha seleccionado. La lista de copias de seguridad se ordena de más antigua a más reciente y se migrará al recurso compartido de archivos de Azure en este orden.

Inicialmente, el trabajo de migración tendrá el estado: Never ran (Nunca ejecutado).
Cuando esté listo, inicie el trabajo de migración. Seleccione la imagen para ver una versión con mayor resolución.
Cuando una copia de seguridad se migra correctamente, se hace una instantánea automática del recurso compartido de archivos de Azure. La fecha de la copia de seguridad original de la copia de seguridad de StorSimple se coloca en la sección Comentarios de la instantánea del recurso compartido de archivos de Azure. El uso de este campo le permite ver cuándo se ha realizado originalmente la copia de seguridad de los datos en comparación con el momento en que se hizo la instantánea del recurso compartido de archivos.

Precaución

Las copias de seguridad deben procesarse de más antigua a más reciente. Una vez creado un trabajo de migración, no se puede cambiar la lista de copias de seguridad de volúmenes StorSimple seleccionados. No inicie el trabajo si la lista de copias de seguridad es incorrecta o está incompleta. Elimine el trabajo y realice uno nuevo con las copias de seguridad correctas seleccionadas. Para cada copia de seguridad seleccionada, compruebe las programaciones de retención. ¡Es posible que una o varias de las directivas de retención eliminen las copias de seguridad antes de que puedan migrarse!

Per-item errors (Errores por elemento)

Los trabajos de migración tienen dos columnas en la lista de copias de seguridad que enumeran cualquier problema que se pueda haber producido durante la copia:

• Errores de copia
  En esta columna se enumeran los archivos o carpetas que no se han copiado pero deberían haberlo hecho. Estos errores suelen ser recuperables. Cuando una copia de seguridad muestra problemas de elementos en esta columna, revise los registros de copia. Si necesita migrar estos archivos, seleccione Retry backup (Reintentar copia de seguridad). Esta opción estará disponible una vez que la copia de seguridad termine de procesarse. En la sección Managing a migration job (Administración de un trabajo de migración) se explican las opciones con más detalle.
• Archivos no admitidos
  En esta columna se enumeran los archivos o carpetas que no se pueden migrar. Azure Storage tiene limitaciones en los nombres de archivo, las longitudes de ruta de acceso y los tipos de archivo que no se pueden almacenar actualmente o de forma lógica en un recurso compartido de archivos de Azure. Un trabajo de migración no se pausará ante este tipo de errores. Volver a intentar la migración de la copia de seguridad no cambiará el resultado. Cuando una copia de seguridad muestra problemas de elementos en esta columna, revise los registros de copia y tome nota de ellos. Si estos problemas surgen en la última copia de seguridad y en el registro de la copia observa que el error se debió a un nombre de archivo, una longitud de ruta de acceso u otro problema sobre el que tiene influencia, es posible que quiera solucionar el problema en el volumen de StorSimple activo, hacer una copia de seguridad del volumen de StorSimple y crear un nuevo trabajo de migración solo con esa copia de seguridad. A continuación, migrará este espacio de nombres corregido y se convertirá en la versión activa/más reciente del recurso compartido de archivos de Azure. Se trata de un proceso manual y lento. Revise cuidadosamente los registros de copia y evalúe si merece la pena.

Estos registros son archivos *.csv en los que se muestran los elementos de espacio de nombres correctos y los elementos que no se han podido copiar. Los errores se dividen aún más en las categorías que se han analizado anteriormente. En la ubicación del archivo de registro, puede buscar registros de archivos con errores buscando "error". El resultado debería ser un conjunto de registros de los archivos que no se pudieron copiar. Ordene estos registros por tamaño. Puede haber registros adicionales generados con un tamaño de 17 bytes. Están vacíos y se pueden omitir. Mediante la ordenación, puede concentrarse en los registros con contenido.

El mismo proceso se aplica a los archivos de registro que graban copias correctas.

Administración de un trabajo de migración

Los trabajos de migración tienen los siguientes estados:

• Nunca ejecutado
  Nuevo trabajo que se ha definido, pero que nunca se ha ejecutado.
• En espera
  Un trabajo en este estado está esperando a que los recursos se aprovisionen en el servicio de migración. Cambiará automáticamente a un estado diferente cuando esté listo.
• Con error
  Un trabajo ha generado un error irrecuperable que impide que se procesen más copias de seguridad. No se espera que un trabajo entre en este estado. La mejor forma de actuar es enviar una solicitud de soporte técnico.
• Cancelado / Cancelando
  Es posible cancelar un trabajo de migración completo o copias de seguridad específicas dentro del trabajo. Las copias de seguridad canceladas no se procesarán, ya que un trabajo de migración cancelado dejará de procesar las copias de seguridad. Tenga en cuenta que la cancelación de un trabajo llevará mucho tiempo. Esto no impedirá que cree un nuevo trabajo. Lo mejor es permitir que un trabajo llegue completamente al estado Cancelado. Puede ignorar los trabajos con errores/cancelados o eliminarlos más adelante. No tendrá que eliminar trabajos antes de poder eliminar el recurso Data Manager al final de la migración de StorSimple.

En ejecución

Un trabajo en ejecución es aquel que está procesando una copia de seguridad. Consulte la tabla de la mitad inferior de la hoja para ver qué copia de seguridad se está procesando actualmente y cuáles pueden haber sido ya migradas.
Las copias de seguridad ya migradas tienen una columna con un vínculo a un registro de copia. Si una copia de seguridad notifica errores, debe revisar su registro de copia.

En pausa

Un trabajo de migración se pausa cuando se necesita tomar una decisión. Esta situación habilita dos botones de comando en la parte superior de la hoja:
Elija
cuando la copia de seguridad muestre los archivos que deberían haberse movido pero no lo hicieron (columna Errores de copia).
Elija
cuando no haya una copia de seguridad (la ha eliminado la directiva al crear el trabajo de migración) o cuando la copia de seguridad esté dañada. Puede encontrar información de error detallada en la hoja que se abre al hacer clic en la copia de seguridad fallida.

Si
o
la copia de seguridad en curso, el servicio de migración creará una instantánea en el recurso compartido de archivos de Azure de destino. Es posible que quiera eliminar la anterior más adelante, ya que es probable que esté incompleta.

Completado y Completado con advertencias

Un trabajo de migración aparece como Completado cuando todas las copias de seguridad del trabajo se han procesado correctamente.
Se completó con advertencias es un estado que se da en las siguientes situaciones:

• Una copia de seguridad tuvo un problema recuperable. Esta copia de seguridad se marca como parcialmente correcta o con errores.
• Ha decidido continuar con el trabajo en pausa omitiendo la copia de seguridad con estos problemas. (Eligió Omitir la copia de seguridad en lugar de Retry backup [Reintentar copia de seguridad])

Si el trabajo de migración se completa con advertencias, siempre debe revisar el registro de copia de las copias de seguridad pertinentes.

Ejecución de trabajos en paralelo

Es probable que tenga varios volúmenes de StorSimple, cada uno con sus propios recursos compartidos que deben migrarse a un recurso compartido de archivos de Azure. Es importante que comprenda cuánto puede hacer en paralelo. Hay limitaciones que no se aplican en la experiencia del usuario y que degradarán o impedirán una migración completa si los trabajos se ejecutan al mismo tiempo.

No hay límites en la definición de trabajos de migración. Puede definir el mismo volumen de origen de StorSimple, el mismo recurso compartido de archivos de Azure, en el mismo o en distintos dispositivos StorSimple. Sin embargo, su ejecución tiene limitaciones:

• Solo se puede ejecutar un trabajo de migración con el mismo volumen de origen de StorSimple al mismo tiempo.
• Solo se puede ejecutar al mismo tiempo un trabajo de migración con el mismo recurso compartido de archivos de Azure de destino.
• Antes de iniciar el siguiente trabajo, asegúrese de que cualquiera de los trabajos anteriores se encuentra en copy stage y muestra el progreso del movimiento de archivos durante al menos 30 minutos.
• Puede ejecutar hasta cuatro trabajos de migración en paralelo por administrador de dispositivos de StorSimple, siempre y cuando cumpla las reglas anteriores.

Al intentar iniciar un trabajo de migración, se comprueban las reglas anteriores. Si hay trabajos en ejecución, es posible que no pueda iniciar un nuevo trabajo. Recibirá una alerta que muestra el nombre de los trabajos que se están ejecutando actualmente que deben finalizar antes de poder iniciar el nuevo trabajo.

Sugerencia

Es una buena idea comprobar periódicamente los trabajos de migración en la pestaña Definición de trabajo del recurso Data Manager para ver si alguno de ellos se ha pausado y necesita una acción por su parte para completarse.

Resumen de la fase 3

Al final de la fase 3, habrá ejecutado al menos uno de los trabajos de migración desde los volúmenes de StorSimple en recursos compartidos de archivos de Azure. Con la ejecución, habrá migrado las copias de seguridad especificadas a las instantáneas del recurso compartido de archivos de Azure. Ahora puede centrarse en la configuración de Azure File Sync del recurso compartido (cuando se hayan completado los trabajos de migración de un recurso compartido) o el direccionamiento del acceso compartido para las aplicaciones y los trabajadores de la información al recurso compartido de archivos de Azure.

Fase 4: Acceso a los recursos compartidos de archivos de Azure

Hay dos estrategias principales para acceder a los recursos compartidos de archivos de Azure:

• Azure File Sync: implementar Azure File Sync en una instancia de Windows Server local. Azure File Sync tiene todas las ventajas de una memoria caché local, al igual que StorSimple.
• Acceso directo a recursos compartidos: Implementación de acceso directo a recursos compartidos. Use esta estrategia si su escenario de acceso para un recurso compartido de archivos de Azure determinado no se beneficiará del almacenamiento en caché local o ya no es posible hospedar una instancia de Windows Server local. Aquí, los usuarios y las aplicaciones seguirán teniendo acceso a los recursos compartidos de SMB a través del protocolo SMB. Estos recursos compartidos ya no están en un servidor local, sino directamente en la nube.

Ya debe haber decidido qué opción es la más adecuada en la fase 1 de esta guía.

El resto de esta sección se centra en las instrucciones de implementación.

El vídeo trata de:

• Enfoques para acceder a recursos compartidos de archivos de Azure
• Azure File Sync
• Acceso directo a recursos compartidos
• Implementación de Azure File Sync
• Implementación del recurso de nube de Azure File Sync
• Implementación de una instancia de Windows Server local
• Preparación de la instancia de Windows Server para Azure File Sync
• Configuración de Azure File Sync en la instancia de Windows Server
• Supervisión de la sincronización inicial
• Probar Azure File Sync
• Creación de recursos compartidos SMB

Implementación de Azure File Sync

Es el momento de implementar una parte de Azure File Sync.

1. Cree el recurso de nube de Azure File Sync.
2. Implemente el agente de Azure File Sync en el servidor local.
3. Registre el servidor con el recurso de nube.

No cree todavía ningún grupo de sincronización. La configuración de la sincronización con un recurso compartido de archivos de Azure solo debe realizarse una vez que se hayan completado los trabajos de migración a un recurso compartido de archivos de Azure. Si empieza a usar Azure File Sync antes de que se complete la migración, hará que la migración sea innecesariamente difícil, ya que no podrá saber fácilmente cuándo era el momento de iniciar una transición.

Implementación del recurso de nube de Azure File Sync

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.

Sugerencia

Si desea cambiar la región de Azure en la que residen los datos cuando se realiza la migración, implemente el servicio de sincronización de almacenamiento en la misma región que las cuentas de almacenamiento de destino para esta migración.

Implementación de una instancia de Windows Server local

• Cree un servidor de Windows Server 2019 (como mínimo de la edición 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. No reutilice el servidor que tenga delante de StorSimple 8100 u 8600.
• Aprovisione o agregue almacenamiento de conexión directa. No se admite el almacenamiento conectado a la red.

Es un procedimiento recomendado otorgar a la nueva instancia de Windows Server una cantidad igual o superior de almacenamiento de la que dispone la aplicación StorSimple 8100 o 8600 localmente para el almacenamiento en caché. Usará la instancia de Windows Server del mismo modo que usó el dispositivo StorSimple. Si tiene la misma cantidad de almacenamiento que el dispositivo, la experiencia de almacenamiento en caché debe ser similar, si no es la misma. Puede agregar o eliminar almacenamiento de la instancia de Windows Server según lo desee. Esto le permitirá escalar el tamaño del volumen local y la cantidad de almacenamiento local disponible para el almacenamiento en caché.

Preparación de la instancia de Windows Server para la sincronización de archivos

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.

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.

Importante

Antes de continuar, debe completar la migración de archivos y carpetas de StorSimple en el recurso compartido de archivos de Azure. Asegúrese de que no haya más cambios en el recurso compartido de archivos.

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.

Importante

Asegúrese de activar la nube por niveles. 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 y, a pesar de ello, disponer de todo el espacio de nombres. Los datos de interés local también se almacenan en caché para conseguir un rendimiento rápido. Otro motivo para activar la nube por niveles en este paso es que no queremos sincronizar el contenido del archivo en esta fase. En este momento solo se debe mover el espacio de nombres.

Implementación de acceso directo a recursos compartidos

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.

• Introducción a las identidades
• Unión a un dominio de una cuenta de almacenamiento
• Información general sobre redes para recursos compartidos de archivos de Azure
• Configuración de puntos de conexión públicos y privados
• Configuración de una VPN S2S
• Configuración de una VPN de Windows P2S
• Configuración de una VPN P2S de Linux
• Configuración del reenvío de DNS
• Configuración de DFS-N

Resumen de la fase 4

Al final de esta fase ha creado y ejecutado varios trabajos de migración en StorSimple Data Manager. Esos trabajos han migrado los archivos y carpetas y sus copias de seguridad a recursos compartidos de archivos de Azure. También ha implementado Azure File Sync o preparado las cuentas de red y almacenamiento para el acceso directo a recursos compartidos.

Fase 5: Migración total de los usuarios

En esta fase, completará la migración:

• Planee el tiempo de inactividad.
• Póngase al día con cualquier cambio que los usuarios y las aplicaciones hayan generado en StorSimple mientras se han estado ejecutando los trabajos de migración en la fase 3.
• Conmute por error a los usuarios a la nueva instancia de Windows Server con Azure File Sync o los recursos compartidos de archivos de Azure a través del acceso directo a recursos compartidos.

El vídeo trata de:

• Pasos que se deben realizar antes de la transición de la carga de trabajo
• Ejecución de la transición
• Pasos posteriores a la migración

Planeación del tiempo de inactividad

Este enfoque de migración requiere cierto tiempo de inactividad para los usuarios y las aplicaciones. El objetivo es mantener un tiempo de inactividad mínimo. Las siguientes consideraciones pueden ayudar:

• Mantenga los volúmenes de StorSimple disponibles mientras ejecuta los trabajos de migración.
• Cuando haya terminado de ejecutar los trabajos de migración de datos de un recurso compartido, podrá quitar el acceso de usuario (al menos el acceso de escritura) de los volúmenes o recursos compartidos de StorSimple. Un comando RoboCopy final pondrá en marcha el recurso compartido de archivos de Azure. Después, podrá migrar a los usuarios. El lugar en el que se ejecute RoboCopy dependerá de si ha elegido usar Azure File Sync o el acceso directo a recursos compartidos. En la próxima sección se trata ese tema.
• Una vez completada la puesta al día de RoboCopy, está listo para exponer la nueva ubicación a los usuarios mediante el recurso compartido de archivos de Azure directamente o un recurso compartido de SMB en una instancia de Windows Server con Azure File Sync. A menudo, una implementación de DFS-N lo ayudará a realizar una migración rápida y eficaz. Mantendrá coherentes las direcciones de los recursos compartidos actuales y llevará a cabo la redirección a una nueva ubicación que contenga los archivos y carpetas migrados.

Para los datos de archivo, es un enfoque totalmente viable tomar el tiempo de inactividad en el volumen de StorSimple (o subcarpeta), hacer una copia de seguridad más del volumen de StorSimple, migrar y, a continuación, abrir el destino de la migración para que los usuarios y las aplicaciones puedan acceder a ellos. Esto le ahorrará la necesidad de un RoboCopy de puesta al día. Sin embargo, este enfoque conlleva un período de tiempo de inactividad prolongado que podría extenderse a varios días o más dependiendo del número de archivos y copias de seguridad que necesite migrar. Es probable que esto solo sea una opción para las cargas de trabajo de archivo que puedan prescindir del acceso de escritura durante períodos prolongados de tiempo.

Determinación de si el espacio de nombres se ha sincronizado por completo en el servidor

Cuando se usa Azure File Sync para un recurso compartido de archivos de Azure, es importante que se determine que todo el espacio de nombres ha terminado de descargarse en el servidor antes de iniciar cualquier comando RoboCopy local. El tiempo necesario para descargar el espacio de nombres depende del número de elementos del recurso compartido de archivos de Azure. Existen dos métodos para determinar si el espacio de nombres se ha trasladado por completo al servidor.

Azure portal

Puede usar Azure Portal para ver cuándo ha llegado por completo el espacio de nombres.

• Inicie sesión en Azure Portal y vaya al grupo de sincronización. Compruebe el estado de sincronización del grupo de sincronización y el punto de conexión del servidor.
• Se descarga la dirección de interés. Si el punto de conexión del servidor se ha aprovisionado recientemente, se mostrará la sincronización inicial, que indica que el espacio de nombres sigue estando disponible. Una vez que cambia el estado a cualquier valor excepto el de sincronización inicial, el espacio de nombres se rellenará por completo en el servidor.

Está listo para continuar con un comando RoboCopy local.

Visor de eventos de Windows Server

También puede usar el Visor de eventos en la instancia de Windows Server para saber cuándo se ha trasladado por completo el espacio de nombres.

1. Abra el Visor de eventos y vaya a Aplicaciones y servicios.
2. Vaya a Microsoft\FileSync\Agent\Telemetry y ábralo.
3. Busque el evento 9102 más reciente, el cual se corresponde con una sesión de sincronización completada.
4. Seleccione Detalles y confirme que está examinando un evento en el que el valor SyncDirection es Descargar.
5. En el momento en que el espacio de nombres ha finalizado su descarga en el servidor, habrá un único evento con Escenario, valor FullGhostedSync y HResult = 0.
6. Si no está ese evento, también puede buscar otros eventos 9102 con SyncDirection = Descargar y Escenario = "RegularSync". La búsqueda de uno de estos eventos también indica que el espacio de nombres se ha terminado de descargar y la sincronización ha progresado a sesiones regulares de sincronización, haya o no algo que sincronizar, en este momento.

Un comando RoboCopy final.

En este momento, hay diferencias entre el servidor de la instancia de Windows Server local y la aplicación StorSimple 8100 u 8600.

1. Debe ponerse al día con los cambios que los usuarios o las aplicaciones generan en StorSimple mientras la migración estaba en curso.
2. En los casos en los que se usa Azure File Sync: La aplicación StorSimple tiene una memoria caché llena en comparación con la instancia de Windows Server que, en este momento, solo tiene un espacio de nombres sin ningún contenido de archivos almacenado localmente. Por lo tanto, el comando RoboCopy final puede ayudar a iniciar la memoria caché de Azure File Sync local al extraer tanto contenido del archivo almacenado en memoria caché local como esté disponible y puede ajustarse al servidor de Azure File Sync.
3. Es posible que el trabajo de migración haya omitido algunos archivos debido a caracteres no válidos. Si es así, cópielos en la instancia de Windows Server habilitada para Azure File Sync. Más adelante, puede ajustarlos para que se sincronicen. Si no usa Azure File Sync para un recurso compartido determinado, es mejor cambiar el nombre de los archivos por caracteres no válidos en el volumen de StorSimple. Después, ejecute RoboCopy directamente en el recurso compartido de archivos de Azure.

Advertencia

Robocopy en Windows Server 2019 experimentó un problema que provocó que los archivos organizados por niveles con Azure File Sync en el servidor de destino se copien nuevamente desde el origen y se vuelvan a cargar en Azure cuando se usó la función /MIR. Se recomienda ejecutar Robocopy en una instancia de Windows Server que no sea de 2019, como Windows Server 2016.

Advertencia

No debe iniciar RoboCopy antes de que el servidor tenga el espacio de nombres de un recurso compartido de archivos de Azure descargado completamente. Para obtener más información, consulte Determinación de si el espacio de nombres se ha sincronizado por completo en el servidor.

Solo desea copiar los archivos que se cambiaron después de la última vez que se ejecutó el trabajo de migración y los archivos que no se trasladaron antes a través de estos trabajos. Puede solucionar el problema por el que no se trasladaron al servidor, una vez que haya finalizado la migración. Para más información, vea Solución de problemas de Azure File Sync.

RoboCopy tiene varios parámetros. El siguiente ejemplo muestra un comando terminado y una lista de razones para elegir estos parámetros.

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> 

Modificador	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.

Cuando configure las ubicaciones de origen y de destino del comando RoboCopy, asegúrese de revisar la estructura de origen y de destino para asegurarse de que coinciden. Si usó la característica de asignación de directorios del trabajo de migración, la estructura del directorio raíz puede ser diferente de la estructura del volumen de StorSimple. En ese caso, puede que necesite varios trabajos de RoboCopy, uno para cada subdirectorio. Si no está seguro de si el comando se ejecutará según lo previsto, puede usar el parámetro /L, que simulará el comando sin realizar realmente ningún cambio.

Este comando RoboCopy usa /MIR, por lo que no moverá archivos que sean iguales (archivos en niveles, por ejemplo). Pero si obtiene incorrectamente la ruta de acceso de origen y destino, /MIR también purga las estructuras de directorio en su instancia de Windows Server o en el recurso compartido de archivos de Azure que no están presentes en la ruta de acceso de origen de StorSimple. Deben coincidir exactamente para que el trabajo de RoboCopy alcance su objetivo de actualizar el contenido migrado con los últimos cambios realizados durante la migración.

Consulte los archivos de registro de RoboCopy para ver si se han omitido archivos. Si existen problemas, corríjalos y vuelva a ejecutar el comando RoboCopy. No desaprovisione los recursos de StorSimple antes de corregir los problemas pendientes de los archivos o carpetas que le interesan.

Si no usa Azure File Sync para almacenar en caché el recurso compartido de archivos de Azure en cuestión, sino que ha optado por el acceso directo a recursos compartidos:

1. Monte el recurso compartido de archivos de Azure como una unidad de red en una máquina local de Windows.
2. Ejecute el comando de RoboCopy entre StorSimple y el recurso compartido de archivos de Azure montado. Si los archivos no se copian, corrija sus nombres en StorSimple para quitar los caracteres no válidos. A continuación, vuelva a intentar la ejecución de RoboCopy. El comando RoboCopy de la lista anterior se puede ejecutar varias veces sin provocar una recuperación innecesaria en StorSimple.

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. Por ejemplo, mover archivos entre directorios, cambiar propiedades a gran escala o cambiar permisos (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, de un dispositivo NAS a DataBox o de un servidor a un recurso compartido de archivos de Azure. Y una o varias ejecuciones adicionales con el modificador /MIR para identificar los archivos que no se han copiado y volver a intentarlo.

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.

Windows Server 2022 y RoboCopy LFSM

El modificador RoboCopy /LFSM se puede usar para evitar que un trabajo de RoboCopy produzca un error tipo Volumen lleno. 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 mínimo.

Use RoboCopy con Windows Server 2022. Solo esta versión de RoboCopy contiene correcciones de errores importantes y características que hacen que el conmutador sea compatible con marcas adicionales necesarias en la mayoría de las migraciones. Por ejemplo, compatibilidad con la marca /B.

/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.

Normalmente, RoboCopy se puede ejecutar en el origen, en el destino o en una tercera máquina.

Importante

Si tiene previsto usar /LFSM, RoboCopy debe ejecutarse en el servidor de Azure File Sync con Windows Server 2022 de destino.

Tenga en cuenta también que, con /LFSM, también debe usar una ruta de acceso local para el destino, no una UNC. Por ejemplo, como ruta de acceso de destino, debe usar E:\NombreDeLaCarpeta en lugar de una ruta de acceso UNC como \\ServerName\NombreDeLaCarpeta.

Precaución

La versión disponible actualmente de RoboCopy en Windows Server 2022 tiene un error que hace que las pausas se incluyan en el recuento de errores por archivo. Aplique la siguiente solución alternativa.

Las marcas recomendadas /R:2 /W:1 aumentan la probabilidad de que se produzca un error en un archivo debido a una pausa /LFSM inducida. En este ejemplo, un archivo que no se copió después de tres pausas porque /LFSM provocó la pausa, hará que RoboCopy produzca un error incorrecto en el archivo. La solución alternativa para esto es usar valores mayores para /R:n y /W:n. Un buen ejemplo es /R:10 /W:1800 (10 reintentos de 30 minutos cada uno). Esto debe dar tiempo al algoritmo de niveles de Azure File Sync para crear espacio en el volumen de destino.

Este error se ha corregido, pero la corrección aún no está disponible públicamente. Compruebe este párrafo en busca de actualizaciones de disponibilidad de la corrección y cómo implementarla.

Migración total de los usuarios

Si usa Azure File Sync, es probable que tenga que crear los recursos compartidos de SMB en esa instancia de Windows Server habilitada para Azure File Sync que coincida con los recursos compartidos que tenía en los volúmenes de StorSimple. Puede adelantar este paso y hacerlo antes para no perder tiempo aquí. Pero debe asegurarse de que antes de este punto nadie tenga acceso para realizar cambios en la instancia de Windows Server.

Si tiene una implementación de DFS-N, puede apuntar los espacios de nombres de DFN a las nuevas ubicaciones de carpetas del servidor. Si no tiene una implementación de DFS-N y ha adelantado el dispositivo 8100/8600 localmente con una instancia de Windows Server, puede desconectar el servidor del dominio. Después, únase al dominio nuevo en la instancia de Windows Server habilitada para Azure File Sync. Durante ese proceso, asigne al servidor el mismo nombre de servidor y los nombres de los recursos compartidos que en el servidor anterior, de modo que el acceso directo sea transparente para los usuarios, la directiva de grupo y los scripts.

Más información sobre DFS-N.

Fase 6: Desaprovisionar

Cuando se desaprovisiona un recurso, se pierde el acceso a la configuración de ese recurso, así como a sus datos. El aprovisionamiento no se puede deshacer. No continúe hasta que haya confirmado que:

• La migración se ha completado.
• No hay ninguna dependencia en los archivos, carpetas o copias de seguridad del volumen de StorSimple que está a punto de desaprovisionar.

Antes de empezar, es un procedimiento recomendado observar la nueva implementación de Azure File Sync en producción durante un tiempo. Esto le ofrece la oportunidad de corregir los problemas que puedan surgir. Una vez que haya observado la implementación de Azure File Sync durante al menos unos días, puede empezar a desaprovisionar los recursos en este orden:

1. Desaprovisione el recurso de StorSimple Data Manager a través de Azure Portal. Todos los trabajos de DTS se eliminarán con él. No podrá recuperar fácilmente los registros de copia. Si es importante para los registros, puede recuperarlos antes de desaprovisionarlos.
2. Asegúrese de que se han migrado las aplicaciones físicas de StorSimple y, a continuación, anule su registro. Si no está seguro de que se han migrado, no continúe. Si quita el aprovisionamiento de estos recursos mientras siguen siendo necesarios, no podrá recuperar los datos ni su configuración.
   Opcionalmente, puede desaprovisionar primero el recurso de volumen de StorSimple, lo cual limpiará los datos del dispositivo. Este proceso puede tardar varios días y no pondrá a cero los datos del dispositivo de manera forense. Si esto es importante para usted, administre la puesta a cero del disco por separado del desaprovisionamiento de recursos y de acuerdo con sus directivas.
3. Si no quedan más dispositivos registrados en StorSimple Device Manager, puede continuar para quitar ese recurso de Device Manager.
4. Ahora es el momento de eliminar la cuenta de almacenamiento de StorSimple en Azure. Una vez más, deténgase en este punto y confirme que la migración se ha completado y no hay nada que dependa de estos datos antes de continuar.
5. Desconecte el dispositivo físico de StorSimple del centro de datos.
6. Si es el propietario del dispositivo de StorSimple, puede reciclar el equipo. Si el dispositivo está concedido, informe al arrendador y devuélvalo según corresponda.

La migración se ha completado.

---

Nota:

¿Todavía tiene preguntas o ha detectado algún problema?
Estamos aquí para ayudar:

Solución de problemas

Al usar el servicio de migración de StorSimple Data Manager, es posible que se produzca un error en un trabajo de migración completo o en archivos individuales por varios motivos. La sección de fidelidad de archivos tiene más detalles sobre los escenarios admitidos o no admitidos. En las tablas siguientes se enumeran los códigos de error, los detalles de error y, siempre que sea posible, las opciones de mitigación.

Errores de nivel de trabajo

Fase	Error	Detalles / mitigación
Backup	No se pudo encontrar una copia de seguridad de los parámetros especificados	La copia de seguridad seleccionada para la ejecución del trabajo no se encuentra en el momento de "Estimación" o "Copia". Asegúrese de que la copia de seguridad todavía está presente en el catálogo de copia de seguridad de StorSimple. A veces, las directivas de retención de copia de seguridad automáticas eliminan copias de seguridad en los pasos intermedios entre seleccionar las copias para migración y ejecutar el trabajo de migración para su volcado. Considere la posibilidad de deshabilitar cualquier programación de retención de copia de seguridad antes de iniciar una migración.
Configuración de la estimación del proceso	Hubo un error en la instalación de las claves de cifrado	Su clave de cifrado de datos de servicio es incorrecta. Revise la sección de clave de cifrado de este artículo para más detalles y ayuda para recuperar la clave correcta.
	Error de lote	Es posible que iniciar toda la infraestructura interna necesaria para realizar una migración produzca un problema. Muchos otros servicios están implicados en este proceso. Por lo general, estos problemas se resuelven por sí solos al intentar volver a ejecutar el trabajo.
	StorSimple Manager encontró un error interno. Espere unos minutos y vuelva a intentar la operación. Si el problema persiste, póngase en contacto con el Soporte técnico de Microsoft. (Código de error: 1074161829)	Este error genérico tiene varias causas, pero una de las posibilidades es que el administrador de dispositivos de StorSimple alcanzó el límite de 50 dispositivos. Compruebe si los trabajos de ejecución más recientes en el administrador de dispositivos se han iniciado repentinamente para producir este error, lo que sugeriría que este es el problema. La mitigación de este problema en particular consiste en quitar los dispositivos sin conexión de StorSimple 8001 que el servicio de Data Manager ha creado y usado. Puede presentar una incidencia de soporte técnico o eliminarlas manualmente en el portal. Asegúrese de eliminar solo los dispositivos sin conexión de la serie 8001.
Cálculo de archivos	Error en el trabajo de clonación de volumen	Este error probablemente indica que especificó una copia de seguridad que estaba dañada de alguna manera. El servicio de migración no puede montarlo ni leerlo. Puede probar la copia de seguridad manualmente o abrir una incidencia de soporte técnico.
	No se puede continuar porque el volumen está en formato no NTFS	Solo el servicio de migración puede usar volúmenes NTFS, habilitados sin eliminación de réplicas. Si tiene un volumen con formato diferente, como ReFS o un formato de terceros, el servicio de migración no podrá migrar este volumen. Consulte la sección sobre las Restricciones conocidas.
	Póngase en contacto con el servicio de soporte técnico. No se encontró ninguna partición adecuada en el disco	El disco de StorSimple que se supone que tiene el volumen especificado para la migración no parece tener una partición para dicho volumen. Esto es inusual y puede indicar daños o mala alineación de la administración. La única opción para investigar aún más esta incidencia es presentar una incidencia de soporte técnico.
	Tiempo de espera agotado	La fase de estimación que produce un error en tiempo de espera suele ser una incidencia con el dispositivo StorSimple, o que la copia de seguridad del volumen de origen es lenta y a veces incluso está dañada. Si volver a ejecutar la copia de seguridad no lo soluciona, la presentación de una incidencia de soporte técnico es la mejor opción.
	No se encontró la <ruta de acceso> del archivo No se encontró una parte de la ruta de acceso	La definición del trabajo permite proporcionar una subruta de acceso de origen. Este error se muestra cuando esa ruta de acceso no existe. Por ejemplo: \Share1 > \Share\Share1 En este ejemplo ha especificado \Share1 como subruta de acceso en el origen, que asigna otra subruta de acceso en el destino. Pero la ruta de acceso de origen no existe (¿se ha escrito mal?). Nota: Windows conserva mayúsculas y minúsculas, pero no depende de ellas. Lo que significa que especificar \Share1 y \share1 es equivalente. Además: las rutas de acceso de destino que no existen se crearán de forma automática.
	Esta solicitud no está autorizada a realizar esta operación	Este error muestra cuándo la cuenta de almacenamiento de StorSimple de origen o la cuenta de almacenamiento de destino con el recurso compartido de archivos de Azure tiene habilitada una configuración de firewall. Debe permitir el tráfico a través del punto de conexión público y no restringirlo con más reglas de firewall. De lo contrario, el servicio de transformación de datos no podrá acceder a ninguna cuenta de almacenamiento, incluso si lo autorizó. Deshabilite las reglas de firewall y vuelva a ejecutar el trabajo.
Copia de archivos	La cuenta a la que se está accediendo no admite HTTP	Deshabilite el enrutamiento de Internet en la cuenta de almacenamiento de destino o use el punto de conexión de enrutamiento de Microsoft.
	El recurso compartido especificado está lleno	Si el destino es un recurso compartido de archivos premium de Azure, asegúrese de que ha aprovisionado suficiente capacidad para el recurso compartido. El sobreaprovisionamiento temporal es una práctica común.

Errores de nivel de elemento

Durante la fase de copia de una ejecución de trabajo de migración, los elementos de espacio de nombres individuales (archivos y carpetas) pueden detectar errores. En la tabla siguiente se enumeran los errores más comunes y se sugieren opciones de mitigación cuando sea posible.

Fase	Error	Mitigación
Copiar	-2146233088 El servidor está ocupado.	Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay unos pocos errores, puede intentar volver a ejecutar el trabajo, pero a menudo una copia manual de los elementos con errores es más rápida. Después, reanude la migración omitiendo el procesamiento de la siguiente copia de seguridad.
	-2146233088 La operación no se pudo completar en el tiempo especificado.	Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay unos pocos errores, puede intentar volver a ejecutar el trabajo, pero a menudo una copia manual de los elementos con errores es más rápida. Después, reanude la migración omitiendo el procesamiento de la siguiente copia de seguridad.
	Se agotó el tiempo de espera de la carga o no se inició la copia	Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay unos pocos errores, puede intentar volver a ejecutar el trabajo, pero a menudo una copia manual de los elementos con errores es más rápida. Después, reanude la migración omitiendo el procesamiento de la siguiente copia de seguridad.
	-2146233029 Se canceló la operación.	Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay unos pocos errores, puede intentar volver a ejecutar el trabajo, pero a menudo una copia manual de los elementos con errores es más rápida. Después, reanude la migración omitiendo el procesamiento de la siguiente copia de seguridad.
	1920 El sistema no tiene acceso al archivo.	Este es un error común cuando el motor de migración encuentra un punto de repetición de análisis, un vínculo o una unión. No se admiten. Estos tipos de archivos no se pueden copiar. Revise la sección Restricciones conocidas y la sección Fidelidad de archivos de este artículo.
	-2147024891 Acceso denegado	Se trata de un error para los archivos que se cifran de forma que no se puede acceder a ellos en el disco. Los archivos que se pueden leer desde el disco, pero simplemente tienen contenido cifrado, no se ven afectados y se pueden copiar. La única opción es copiarlos de forma manual. Puede encontrar estos elementos mediante el montaje del volumen afectado y la ejecución del siguiente comando: get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes
	No es un parámetro FileTime de Win32 válido. Nombre del parámetro: fileTime	En este caso, se puede tener acceso al archivo, pero no se puede evaluar para la copia porque una marca de tiempo de la que depende el motor de migración está dañada o está escrita por una aplicación en un formato incorrecto. No hay mucho que pueda hacer, ya que no puede cambiar la marca de tiempo de la copia de seguridad. Si conservar este archivo es importante, quizás en la versión más reciente (última copia de seguridad que contiene este archivo), copie manualmente el archivo, corrija la marca de tiempo y, después, muévala al recurso compartido de archivos de Azure de destino. Esta opción no se escala muy bien, pero es una opción para los archivos de alto valor en los que desea tener al menos una versión conservada en el destino.
	-2146232798 Se ha cerrado el controlador seguro	A menudo, un error transitorio. Vuelva a ejecutar el trabajo si hay demasiados errores. Si solo hay unos pocos errores, puede intentar volver a ejecutar el trabajo, pero a menudo una copia manual de los elementos con errores es más rápida. Después, reanude la migración omitiendo el procesamiento de la siguiente copia de seguridad.
	-2147024413 Error de hardware irrecuperable del dispositivo	Este es un error poco frecuente y, de hecho, no se notifica para un dispositivo físico, sino más bien para las aplicaciones virtualizadas de la serie 8001 que usa el servicio de migración. El dispositivo tuvo un problema. Los archivos con este error no impedirán que la migración continúe con la siguiente copia de seguridad. Esto hace que sea difícil realizar una copia manual o volver a intentar la copia de seguridad que contiene archivos con este error. Si los archivos que dejan atrás son muy importantes o hay un gran número de archivos, es posible que tenga que volver a iniciar la migración de todas las copias de seguridad. Abra una incidencia de soporte técnico para una investigación más detallada.
Eliminación (purga de reflejo)	El directorio especificado no está vacío.	Este error se produce cuando el modo de migración se establece en reflejo y el proceso que quita los elementos del recurso compartido de archivos de Azure generó un problema que impidió que eliminara elementos. La eliminación solo se produce en el recurso compartido activo, no en las instantáneas anteriores. La eliminación es necesaria porque los archivos afectados no están en la copia de seguridad actual y, por tanto, deben quitarse del recurso compartido activo antes de la siguiente instantánea. Hay dos opciones: Opción 1: montar el recurso compartido de archivos de Azure de destino y eliminar los archivos con este error de forma manual. Opción 2: puede omitir estos errores y continuar procesando la siguiente copia de seguridad con una expectativa de que el destino no es idéntico al origen y tiene algunos elementos adicionales que no estaban en la copia de seguridad de StorSimple original.
	Solicitud incorrecta	Este error indica que el archivo de origen tiene ciertas características que no se pudieron copiar en el recurso compartido de archivos de Azure. En particular, podría haber caracteres de control invisibles en un nombre de archivo o 1 byte de un carácter de doble byte en el nombre de archivo o la ruta de acceso del archivo. Puede usar los registros de copia para obtener nombres de ruta de acceso, copiar los archivos en una ubicación temporal, cambiar el nombre de las rutas de acceso para quitar los caracteres no admitidos y, luego, volver a usar robocopy en el recurso compartido de archivos de Azure. Después, puede reanudar la migración omitiendo la siguiente copia de seguridad que se va a procesar.

Pasos siguientes

• Obtenga información sobre la flexibilidad de las directivas de nube por niveles.
• Habilite Azure Backup en los recursos compartidos de archivos de Azure para programar instantáneas y definir programaciones de retención de copia de seguridad.
• Si ve en Azure Portal que algunos archivos no se sincronizan de forma permanente, revise la guía de solución de problemas para conocer los pasos necesarios para resolverlos.