Microsoft Azure Files: Migrar Contenido con Robocopy o AzCopy + Token SAS
Recientemente he publicado un artículo sobre Azure Files y la integración con nuestro ADDS (Active Directory Domain Services), algo que resulta esencial cuando queremos migrar nuestros servidores de ficheros a Azure en modo SaaS utilizando Azure Files. Aquí os dejo algunos artículos por si alguien no los ha podido ver en su momento y que tienen relación de una u otra forma con este artículo:
- Azure Private Link: configuración del Private Link
- Microsoft Azure: Infraestructura VDI con Azure Files, DFS, GPOs y Licenciamiento Usuarios Automático: integración de una cuenta de almacenamiento con nuestro ADDS
- Microsoft Azure: Always On VPN + Windows 10 Pro + GPO: configuración de los clientes VPN con Azure
- Moviendo nuestros servicios y máquinas virtuales a Azure (Parte II): configuración de una VPN Site-to-Site entre Azure y On-Premises
- Microsoft Azure: VPN S2S en Alta Disponibilidad desde On-Premises ajustando Pesos de Rutas en Azure: configuración de Alta Disponibilidad de una VPN Site-to-Site de Azure
La idea, para este nuevo artículo es mostraros como podéis copiar/migrar vuestro contenido de On-Premises hacia Azure Files, además de mostrar como copiar contenido entre cuentas de almacenamiento. En este caso, no tengo una infografía/topología como tal, pero siempre me gusta “dibujar” algo al respecto para tener una idea gráfica de lo que estamos haciendo, aquí va:
Como se aprecia en el dibujo, la idea es comentar varios escenarios:
- Copiar información vía SMB utilizando Private Links directamente sobre la cuenta de almacenamiento
- Copiar información entre cuentas de almacenamiento
- Copiar información hacia una cuenta de almacenamiento directamente por internet
Vamos a empezar por copiar información entre nuestro servidor de ficheros y Azure Files en un recurso compartido, lo primero que debemos hacer es conectarnos al recurso compartido. Siendo una carpeta compartida, es posible que la opción más “rápida” sea conectarse vía recurso compartido y para ello desde el portal de Azure nos vamos al recurso compartido, pulsamos sobre los tres puntos suspensivos y pulsamos en Conectar:
Y ahora en el icono de portapapeles que tenemos dentro del código de conexión que nos muestra:
Lo normal, es conectar al servidor de origen y desde allí conectarnos al destino para, posteriormente copiar la información que queramos. Comentaros antes que, para conectarse al recurso compartido debemos cumplir algunos requisitos:
- Estar conectado directamente en la red de Azure
- Estar conectado vía VPN (Site-to-Site o Point-to-Site)
Esto sería lo básico, sin contar ya la implementación de Private Link y configuraciones de DNS explicadas en este artículo: Microsoft Azure Files: Migración, Conexión Privada vía Private Link utilizando DNS Privados para Clientes VPN en Azure. Esto es así, porque la conexión al recurso compartido utiliza el puerto 445/TCP, algo que está súper filtrado por todos los operadores del mundo, vamos que directamente por Internet no te permiten el puerto 445 de salida. De ahí, la necesidad de estar conectado de algunas de las formas anteriormente citadas.
Si vemos el código de conexión que nos hemos copiado, fijaros en la primera línea del mismo, es un test de conexión al puerto 445 de la cuenta de almacenamiento:
$connectTestResult = Test-NetConnection -ComputerName smbxxxx.file.core.windows.net -Port 445
if ($connectTestResult.TcpTestSucceeded) {
# Montar la unidad
New-PSDrive -Name Z -PSProvider FileSystem -Root “\\smbxxx.file.core.windows.net\corpdata” -Persist
} else {
Write-Error -Message “Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port.”
}
Pues bien, nos conectamos utilizando dicho acceso y luego con robocopy podemos copiar la información que queramos desde On-Premises hacia Azure Files (o la revés). El comando es muy sencillo:
- Robocopy <<Ruta Origen>> <<Ruta Destino>> /Copyall /e
Aquí os dejo todos los argumentos que tiene el comando robocopy: https://docs.microsoft.com/es-es/windows-server/administration/windows-commands/robocopy, yo básicamente utilizo los que veis:
- Copyall: copia los permisos del origen hacia el destino (por esto que la cuenta de almacenamiento esté integrada con nuestro ADDS)
- E: Copiar subdirectorios, incluidos los vacíos
De esta forma, podemos ir copiando poco a poco los ficheros y los usuarios que sigan trabajando sobre el almacenamiento actual, simplemente iremos haciendo ejecuciones posteriores del comando robocopy justo cuando queramos cambiarles la ruta de acceso a los usuarios. Una vez que robocopy finalice, nos dará un pequeño resumen de sus tareas:
Si queremos tener un fichero LOGS, simplemente añadimos diferentes modificadores al robocopy: Sintaxis
- /log<logfile> Escribe la salida del estado en el archivo de registro (sobrescribe el archivo de registro existente).
- /log +:<logfile> Escribe la salida de estado en el archivo de registro (anexa la salida al archivo de registro existente).
Si utilizáis DFS, algo que recomiendo siempre, únicamente debéis cambiar el estado de referencia una vez copiada la información y los usuarios no dejarán nunca de tener acceso ni se darán cuenta del cambio.
Aquí os muestro una estructura DFS sencilla, donde tenemos una carpeta Comercial en una ruta local ahora mismos pero ya con un destino deshabilitado para la ruta de Azure Files. De esta forma, los usuarios siguen trabajando en la ruta local hasta que terminemos de copiar el contenido y de asegurarnos que todos los usuarios tienen acceso a la ruta de Azure:
Una vez que hayamos terminado de copiar la información a Azure Files vía SMB, simplemente habilitamos el destino de la ruta de Azure y deshabilitamos la antigua, ya dejando activa la nueva ruta:
Los usuarios con este proceso ni se enteran, además, mientras ejecutamos robocopy los usuarios pueden seguir trabajando con normalidad. El día anterior al cambio, volvemos a ejecutar robocopy y solo copiará (con el mismo comando) solo lo nuevo, así que tardará mucho menos tiempo en dejar actualizado el destino (Azure Files).
Hasta aquí es sencillo, nos conectamos vía SMB al destino y vía robocopy nos copiamos el contenido y con DFS cambiamos las rutas activas para que este cambio tenga impacto cero con respecto a la experiencia del usuario final. Pero que ocurre si el servidor de origen es un Windows Server muy antiguo que no soporte el TLS que tenemos configurado en nuestra cuenta de almacenamiento como valor mínimo:
Y lo peor, que por le motivo que sea no podemos realizar ningún tipo de actualización a dicho servidor .. pues cuando nos queramos conectar podemos encontrarnos con este error:
Si no podemos actualizar nada de ninguna forma, una de las formas de “solventarlo” es cambiando la exigencia de transferencia segura:
Cambiando la configuración de Se requiere una transferencia segura a Deshabilitado:
Si ahora volvéis a intentar conectaros nuevamente al recurso compartido, veréis que podéis hacerlo sin problema vía HTTP (captura de los dos intentos antes y después del cambio)
Claramente no es lo esperado, pero sino se puede hacer nada al respecto, podéis utilizar este procedimiento y tan pronto hayáis migrado, volver a revertir el cambio.
Pues hasta aquí el como copiar información entre nuestro servidor de ficheros y Azure Files vía SMB utilizando robocopy, pero y si queremos ahora copiar información entre cuentas de almacenamiento? Para esto, lo mejor es utilizar otra herramienta: AzCopy. AzCopy es una utilidad de línea de comandos que puede usar para copiar blobs o archivos a una cuenta de almacenamiento o desde una cuenta de almacenamiento.
La idea es sencilla, tengo una información en una cuenta de almacenamiento para ficheros en producción (nivel de acceso: Transacción optimizada) y quiero mover cierta información a otra cuenta de almacenamiento para guardarla como histórico (nivel de acceso: Esporádico). Primero nos debemos descarga AzCopy en instalarlo en algún equipo, mi recomendación en algún equipo en Azure (luego veréis porqué).
Lo primero que haremos será conseguir una firma de acceso compartido, antes de seguir, aquí os dejo un enlace que os explicará mejor que yo que es un enlace SAS: https://docs.microsoft.com/es-es/azure/storage/common/storage-sas-overview. Yo os mostraré el proceso, el cual debéis hacerlo en la cuenta de origen y destino.
El proceso es ir a la sección de Firma de acceso compartido, habilitar como mínimo el servicio de Archivo como servicios permitidos, definir las fechas en la que va a estar activo el token y luego elegir la Key del acceso a la cuenta de almacenamiento que vamos a utilizar y pulsamos en Generar la cadena de conexión y SAS.
Si os habéis fijado, este token de acceso también puede incluir las direcciones IP desde las cuales vamos a permitir el acceso. Una vez generado, elegimos el token que nosotros vamos a utilizar en base a nuestras necesidades, en mi caso la URL de SAS del servicio de archivo:
Una vez que, tenemos los dos tokens (uno por cuenta de almacenamiento), tenemos que modificar mínimamente el token de acceso, porque debemos añadir la ruta de la carpeta compartida después de la URL de la cuenta de almacenamiento como muestro marcado en amarillo (entre el / y el ? ahí debemos poner el nombre de la carpeta compartida que está en dicha cuenta de almacenamiento). Además, en mi caso, como estoy copiando información entre cuentas SMB que tienen permisos SMB que quiero conservar, tenemos que añadir al final del comando el siguiente modificador: –preserve-smb-permissions=true.
Información adicional sobre AzCopy Sync: https://docs.microsoft.com/es-es/azure/storage/common/storage-ref-azcopy-sync
El comando quería así: AzCopy Sync TokenSAS-Origen TokenSAS-Destino –preserve-smb-permissions=true y automáticamente se pondrá a escanear la cuenta de origen para contar los ficheros que tendrá que copiar:
Y en breve se podrán a copiar entre cuentas de almacenamiento y fijaros que velocidad .. llegando a picos de 2400Mb/s!!!
Mirad como ha llegado a picos de 2024,0874Mb/s!!
Una vez que termine de copiar, se mostrará un pequeño resumen de la transferencia. Aquí os muestro dos proceso de copiado y veréis que la transferencias son muy interesantes:
Todo esto se puede automatizar con tareas programadas, PowerShell, procesos .bat o .cmd, alertas, etc.. pero eso ya os lo dejo a vosotros.
Espero que os sea de utilidad!!!
Pepe / 11 mayo, 2021
Muy buenas,
Muy buen articulo, justamente estoy realizando un trabajo igual donde debo copiar 1TB de datos. Lo quiero hacer poco a poco debido a la cantidad, pero en las pruebas el robocopy me falla:
NOTE: no se puede copiar la seguridad NTFS; el destino no puede ser NTFS.
2021/05/11 12:34:35 ERROR 3 (0x00000003) Creando directorio de destino
Si copio y pego arrastrando pues pierdo todos los permisos…se te ocurre por qué puede ser??
Santiago Buitrago Reis / Autor / 16 mayo, 2021
Hola Pepe:
Para copiar los ficheros con los permisos, tienes que conectarte utilizando las conexiones con las Key no directamente con robocopy desde las unidades locales hacia las cuentas de almacenamiento.
Un saludo
Alex / 14 septiembre, 2021
Buen día, se les ocurre una forma de copiar archivos de un servidor a un blob sin que se genere tanto cobro en la subida de estos archivos.
Santiago Buitrago Reis / Autor / 25 septiembre, 2021
Hola Alex:
¿A qué te refieres con tanto cobro? ¿Coste o configuración? Si es copiar contenido, la forma es la que he expuesto, pero hay algunas más pero no serán más “sencillas”.
Un saludo