Migración de un NAS Synology a un UniFi UNAS Pro 8 con Robocopy y SMB Multichannel

Durante mucho tiempo he tenido un NAS Synology, y recientemente comencé a migrar su contenido a un nuevo Ubiquiti UniFi UNAS Pro 8. Parecía que esta operación sería bastante sencilla. Ambos dispositivos utilizan SMB, mi red es rápida (recientemente actualizada a 10 gigabits internamente), y Windows ha contado con herramientas para copiar archivos de forma fiable entre máquinas durante décadas. Naturalmente, la operación se convirtió en una noche de aprendizaje de cosas que creía saber, ¡lo que explica por qué empecé un blog!

Para mí, esta migración tenía un componente histórico, ya que allá por 2007 escribí un artículo titulado "XCopy considerado perjudicial - Robocopy o XXCopy o SyncBack". En aquel momento, mi argumento era que, una vez que se mueven suficientes archivos, el Explorador de Windows deja de ser la opción adecuada y Robocopy empieza a parecer una buena alternativa. Incluso utilicé /Z, el modo reiniciable de Robocopy, porque la capacidad de reanudar un archivo parcialmente transferido era útil en conexiones poco fiables.

Casi veinte años después, resultó que /Z fue una de las cosas más importantes que tuve que eliminar, ya que ralentizaba todo enormemente.

La migración

La tarea básica era sencilla. Tenía recursos compartidos en el Synology como:

\\server\music

y recursos compartidos correspondientes en el UNAS:

\\UNAS-Pro-8\music

Inicialmente utilicé el Explorador, principalmente porque estaba disponible y porque a veces lo más sencillo es realmente lo más sencillo. Esto duró hasta que el Explorador comenzó a generar errores en archivos individuales:

La operación solicitada no se pudo completar debido a una limitación del sistema de archivos

Mi primer pensamiento fueron los nombres de archivo. Las migraciones de NAS están llenas de oportunidades para descubrir que un sistema de archivos es más permisivo que otro, y había nombres de archivo con paréntesis y otros signos de puntuación.

Entonces falló esto:

\\server\music\Athlete\Tourist\05 Wires.m4p

No hay nada especialmente exótico en 05 Wires.m4p, así que pasé a Robocopy para obtener un poco más de información. Consistentemente llegaba al 92% y devolvía el error de Windows 665:

92%        New File               4.3 m        05 Wires.m4p

ERROR 665 (0x00000299) Copying File
La operación solicitada no se pudo completar debido a una limitación del sistema de archivos

En este punto, la pregunta útil ya no era "¿qué le pasa a ese nombre de archivo?", sino "¿qué parte de la ruta está rechazando este archivo?".

Copié el archivo del Synology a mi escritorio local de Windows. Eso funcionó. Luego copié el archivo local de Windows al UNAS, y eso falló con la misma limitación del sistema de archivos.

Eso aisló el problema: el Synology podía leer el archivo, Windows podía almacenarlo, y algo al escribir este archivo en particular en el UNAS estaba causando problemas.

Flujos de Datos Alternativos, de nuevo

Los archivos NTFS pueden contener Flujos de Datos Alternativos con nombre, además del flujo anónimo ordinario que normalmente consideramos como el contenido de un archivo. Esta es una característica antigua del sistema de archivos de Windows, y casualmente escribí sobre ella en 2007 al discutir Zone.Identifier, que Windows puede usar para registrar de dónde proviene un archivo descargado. ¡Incluso escribí sobre Flujos de Datos Alternativos en 2003! Windows puede exponer estos flujos con DIR /R.

Así que ejecuté:

dir /r '%USERPROFILE%\Desktop\05 Wires.m4p'

y obtuve:

11/30/2011  02:17 PM         4,576,368 05 Wires.m4p
                               360,456 05 Wires.m4p:01APIC_03.jpg:$DATA

Ahí está. Junto al archivo de música normal de 4,5 MB, había un flujo de datos con nombre de aproximadamente 360 KB llamado 01APIC_03.jpg.

Eso también explicaba el extraño fallo al 92%. Robocopy estaba leyendo correctamente el contenido principal del archivo y luego se encontraba con el flujo adicional. Lo que parecía un fallo en algún lugar del medio de un archivo .m4p normal, en realidad ocurría cuando Windows intentaba tratar los datos adicionales del sistema de archivos.

Robocopy tiene soporte para esta situación exacta. Microsoft documenta X como una de las banderas de /COPY, que significa "omitir flujos de datos alternativos". Así que:

/COPY:DATX

significa copiar los datos del archivo, atributos y marcas de tiempo, pero no copiar los flujos alternativos. /DCOPY:DATX aplica el comportamiento correspondiente a los directorios. Volví a intentar el mismo archivo:

robocopy '\\server\music\Athlete\Tourist' '\\UNAS-Pro-8\music\Athlete\Tourist' '05 Wires.m4p' /R:0 /W:0 /COPY:DATX /DCOPY:DATX /V

y se completó con éxito. La distinción importante aquí es que DATX no elimina metadatos almacenados dentro de un archivo MP3, M4A, M4P, JPEG u otro formato. Le dice a Robocopy que no reproduzca flujos de sistema de archivos separados asociados con el archivo. En mi caso, esos flujos adicionales no eran algo que necesitara conservar en el nuevo NAS.

La copia funcionó, pero fue lenta

Una vez comprendido el problema de ADS, comencé la migración más grande con un comando Robocopy de aspecto bastante convencional:

robocopy '\\server\music' '\\UNAS-Pro-8\music' /E /Z /MT:16 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE /LOG:'%USERPROFILE%\Desktop\synology-to-unas.log'

Se ejecutó, pero el rendimiento era irregular. A veces veía unos pocos cientos de megabits por segundo, y luego caía drásticamente. Un archivo pequeño podía permanecer allí mucho tiempo. Empecé a preguntarme si estaba viendo buffering, discos lentos, cálculos de paridad, comportamiento SMB en el UNAS, o tal vez mi Synology finalmente había llegado a sus límites.

Así que ahora es el momento de "simplemente probar cosas al azar (bisección)". Reduje el número de hilos. Probé un solo hilo. Nada de eso ayudó. Entonces quité /Z.

La documentación de Robocopy de Microsoft describe /Z como modo reiniciable, que permite que un archivo interrumpido se reanude en lugar de empezar de nuevo desde el byte cero. Lo que había olvidado es que la guía de migración actual de Microsoft advierte específicamente que /Z debe usarse con precaución, ya que el registro adicional requerido para la reiniciabilidad puede reducir significativamente el rendimiento de la copia.

Mi ejecución exitosa de música terminó usando:

robocopy '\\server\music' '\\UNAS-Pro-8\music' /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /TEE /LOG:'%USERPROFILE%\Desktop\synology-to-unas-DATX.log'

El resumen de esa ejecución fue:

               Total    Copied   Skipped  Mismatch    FAILED
    Files :     15940      6991      8949         0         0
    Bytes :  70.907 g  47.917 g  22.989 g         0         0

   Speed :           187,185,171 Bytes/sec.

Así, la ejecución que copió casi 48 GB de datos restantes promedió unos 187 MB/seg, sin archivos fallidos.

No fue una prueba controlada en la que cambié exactamente una variable mientras todo lo demás permanecía idéntico, así que no voy a fingir que el número demuestra que /Z representó cada bit de la desaceleración anterior. Sin embargo, la diferencia práctica fue lo suficientemente grande como para que /Z ya no sea algo que ponga automáticamente en un comando de migración LAN solo porque la reiniciabilidad suena deseable. En una red local estable, empezaría sin él y lo añadiría solo cuando realmente necesite su semántica.

/MT es útil, pero ayuda a un tipo particular de problema

La opción /MT:n de Robocopy ejecuta copias utilizando múltiples hilos. Admite valores de 1 a 128, con ocho hilos como valor predeterminado si se suministra /MT sin número. La propia guía de migración de Microsoft también señala que más hilos no se traducen automáticamente en una migración más rápida y recomienda medir los recuentos de hilos frente a la carga de trabajo real.

Esto tuvo más sentido una vez que dejé de pensar en /MT:4 como "hacer un archivo cuatro veces más rápido".

Imagina una colección de música con miles de archivos de procedencia cuestionable (yo los ripeé, ¡es broma!). Hay trabajo asociado con la apertura de un archivo, la creación del archivo de destino, la lectura y escritura de su contenido, el manejo de metadatos y su cierre. Una copia de un solo hilo tiene períodos en los que la red o el almacenamiento pueden estar esperando mientras una de esas operaciones se completa. Tener varios archivos en progreso a la vez le da a Robocopy oportunidades para superponer ese trabajo.

Para esta colección en particular, cuatro hilos resultaron ser una buena opción. Dieciséis no ayudaban obviamente más, y un hilo no era una mejora. Me resistiría a convertir /MT en un valor mágico que pertenece a cada línea de comandos, porque un directorio que contiene 50.000 fotografías presenta una carga de trabajo diferente a cuatro imágenes de disco de 900 GB.

También hay un coste de registro que vale la pena recordar. Microsoft recomienda redirigir la salida de Robocopy a un registro cuando se utilizan copias multihilo, y su guía de migración utiliza modificadores como /NP, /NFL y /NDL cuando el objetivo es el rendimiento en lugar de observar cada nombre de archivo que se desplaza.

Para una migración que no estoy supervisando activamente, probablemente usaría algo como:

robocopy '\\server\share' '\\UNAS-Pro-8\share' /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /NP /NFL /NDL /LOG:'%USERPROFILE%\Desktop\nas-migration.log'

Luego vinieron los archivos grandes

Más tarde comencé a copiar algunos archivos de cientos de gigabytes cada uno. Microsoft describe /J como E/S sin búfer y lo recomienda para archivos grandes, por lo que parecía la opción obvia para probar.

Sin embargo, con /J activado, la transferencia de NAS a NAS se ralentizó drásticamente. Lo útil de tener una máquina Windows en el medio es que podía probar cada mitad del viaje por separado. Tomé uno de los mismos archivos grandes y lo copié directamente del Synology a mi máquina local. Eso funcionó a aproximadamente 250 MB/seg, por lo que el Synology era perfectamente capaz de leer el archivo a alta velocidad.

Luego eliminé /J del comando Robocopy directo de Synology a UNAS:

robocopy '\\server\share' '\\UNAS-Pro-8\share' 'huge-file.ext' /R:0 /W:0 /COPY:DATX /NP

y la velocidad volvió.

No creo que la conclusión útil sea que /J sea malo. Microsoft lo recomienda para copias de archivos grandes por una razón, y es totalmente posible que sea exactamente lo que quieres al copiar de disco local a disco local o en otra configuración de red. Lo que importaba aquí era que Windows estaba leyendo simultáneamente de un servidor SMB y escribiendo a otro servidor SMB, y en esta ruta particular, la E/S con búfer funcionó mucho mejor.

Eso es un buen recordatorio de que los modificadores de línea de comandos describen el comportamiento, no las mejoras garantizadas de rendimiento. /J cambia el modelo de E/S. /MT cambia la concurrencia. /Z añade reiniciabilidad. Si esos cambios mejoran una migración depende del resto del sistema.

El Synology fue más rápido de lo que le daba crédito

En varios puntos culmé al Synology envejecido. Es una máquina antigua con discos giratorios, así que fue fácil asumir que unos pocos cientos de megabits por segundo era simplemente todo lo que le quedaba. Entonces recordé que el Synology tiene cuatro interfaces de 1 GbE y que SMB 3 soporta Multichannel. Todavía me sorprende que esto funcionara tan bien.

SMB Multichannel permite que una sesión SMB utilice múltiples rutas de red simultáneamente. Microsoft documenta esto específicamente como una forma de agregar ancho de banda de red disponible, y Synology soporta SMB3 Multichannel por la misma razón.

Windows facilita la inspección de los canales activos:

Get-SmbMultichannelConnection -ServerName server |
                Format-Table ServerName,Selected,ClientIpAddress,ServerIpAddress,ClientLinkSpeed,ServerLinkSpeed,CurrentChannels

Mi máquina informó:

ServerName Selected ClientIpAddress ServerIpAddress ClientLinkSpeed ServerLinkSpeed
---------- -------- --------------- --------------- --------------- ---------------
server         True 192.168.1.45    192.168.1.210        1000000000      1000000000
server         True 192.168.1.45    192.168.1.198        1000000000      1000000000
server         True 192.168.1.45    192.168.1.197        1000000000      1000000000
server         True 192.168.1.45    192.168.1.26         1000000000      1000000000

Las cuatro interfaces de 1 GbE del Synology participaban en la conexión SMB.

Mi máquina Windows tiene actualmente un adaptador de 2,5 GbE (10 gigas próximamente), y durante la copia rápida, veía aproximadamente 250 MB/seg llegando desde el Synology. Eso de repente hizo que el comportamiento del sistema fuera mucho menos misterioso. El Synology no estaba limitado por el rendimiento de una conexión Ethernet de gigabit porque SMB Multichannel permitía a Windows utilizar las cuatro rutas disponibles en el lado del servidor, mientras que el enlace de 2,5 GbE en el PC se convertía en el cuello de botella de red más pequeño.

La documentación de Synology hace una distinción importante aquí entre SMB Multichannel y la agregación de enlaces ordinaria. Multichannel puede aumentar el rendimiento SMB para un cliente utilizando múltiples conexiones de red, mientras que la agregación de enlaces convencional generalmente se trata del rendimiento agregado entre múltiples clientes y servicios.

Como dije, tengo un adaptador de 10 GbE en camino para la máquina Windows, así que hay otro experimento disponible después de la migración. El Synology todavía solo tiene cuatro interfaces de 1 GbE, lo que le da 4 Gb/seg de enlaces de red en agregado, pero eliminar el cuello de botella del cliente de 2,5 GbE actual debería mostrar cuánto más pueden llegar los discos y el propio Synology. Para un NAS más antiguo al que ya había relegado mentalmente a "el NAS de copia de seguridad lenta", funcionó sorprendentemente bien.

También probé rsync

Sí, lo sé, ¿qué pasa con rsync? Estás diciendo que un intermediario de Windows es innecesario. El Synology puede proporcionar rsync, y UniFi Drive puede extraer de un servidor rsync utilizando el modo daemon. Ubiquiti documenta la ruta rsync en las Tareas de Copia de Seguridad de Drive y requiere el modo daemon para este tipo de fuente.

Probé un recurso compartido de películas separado con rsync mientras los otros experimentos estaban en curso. Funcionó, y vi aproximadamente 67 MB/seg. También me dio una disposición de destino con algo de anidación de directorios adicional que necesitaría limpiar después.

Eso no es un argumento de que rsync sea lento en general, ni de que su comportamiento de directorio no pueda configurarse correctamente. Es solo lo que sucedió en esta prueba particular de Synology a UNAS. Una vez que la ruta Robocopy alcanzaba aproximadamente 187 MB/seg y conservaba exactamente la disposición del recurso compartido UNC que quería, no había mucho incentivo para que hiciera de rsync el mecanismo de migración principal.

El resultado ligeramente divertido fue que la ruta aparentemente indirecta:

Synology -> SMB -> Windows -> SMB -> UNAS

fue considerablemente más rápida en mi entorno que pedir a los dos dispositivos NAS que transfirieran el recurso compartido de prueba directamente con la implementación rsync expuesta por UniFi Drive. Mi suposición es que rsync no utilizaba las 4 conexiones de 1 gig. Déjame saber qué piensas en los comentarios.

El comando Robocopy con el que terminé

Para los recursos compartidos normales que contienen muchos archivos, esta es la versión con la que comenzaría ahora:

robocopy '\\server\share' '\\UNAS-Pro-8\share' /E /MT:4 /R:2 /W:2 /COPY:DATX /DCOPY:DATX /XJ /NP /NFL /NDL /LOG:'%USERPROFILE%\Desktop\nas-migration.log'

Los modificadores tienen trabajos bastante específicos:

/E           Copia subdirectorios, incluidos los vacíos
/MT:4        Permite cuatro hilos de copia de archivos
/R:2         Reintenta una copia fallida dos veces
/W:2         Espera dos segundos entre reintentos
/COPY:DATX   Copia datos, atributos y marcas de tiempo, pero omite ADS
/DCOPY:DATX  Aplica los indicadores de copia de directorios correspondientes
/XJ          Excluye puntos de unión
/NP          No imprime el progreso porcentual
/NFL         No registra cada nombre de archivo
/NDL         No registra cada directorio
/LOG         Escribe la salida útil en un archivo

Deliberadamente no tengo /Z ahí. Tampoco añadiría automáticamente /J; para una carga de trabajo dominada por archivos muy grandes, probaría la misma transferencia tanto con como sin él antes de comprometerme a una ejecución de varios terabytes.

El valor de /MT es igualmente empírico. Cuatro funcionó extremadamente bien para este Synology y esta mezcla de archivos, pero probaría 1, 4, 8 u otro número sensato contra una porción representativa de los datos reales en lugar de asumir que el recuento de hilos más alto disponible es el mejor.

Comprobación del resultado

Para los archivos en los que me importa lo suficiente como para demostrar que el destino contiene exactamente los mismos bytes que la fuente, el comando Get-FileHash de PowerShell es una comprobación final conveniente:

Get-FileHash '\\server\share\huge-file.ext' -Algorithm SHA256
Get-FileHash '\\UNAS-Pro-8\share\huge-file.ext' -Algorithm SHA256

Get-FileHash utiliza SHA-256 por defecto, y si los valores SHA-256 coinciden, entonces las dos entradas produjeron el mismo hash. Para archivos enormes, esto requiere leer el archivo completo de nuevo en ambos extremos, por lo que es poco probable que compruebe cada canción de una colección de música, pero es una forma fácil de verificar los archivos de varios cientos de gigabytes particularmente valiosos después de una migración.

Algunas cosas que comprobaría antes de culpar al NAS

Lo que hizo interesante esta migración fue que los síntomas podrían haber respaldado varias explicaciones plausibles. El UNAS tiene una nueva matriz RAID, el Synology es antiguo, Windows actúa como cliente SMB en ambas direcciones, los archivos provenían de años de diferentes aplicaciones, y Robocopy tiene suficientes modificadores para hacer que casi cualquier línea de comandos parezca autorizada.

Cuando un archivo fallaba, lo copiaba de Synology a local y luego de local a UNAS, lo que expuso el problema de ADS en el destino. Cuando los archivos grandes eran lentos, copiaba el mismo archivo de Synology a local, lo que demostraba que el NAS antiguo aún podía entregar aproximadamente 250 MB/seg. Cuando la red se volvió mucho más rápida de repente, Get-SmbMultichannelConnection mostró que las cuatro interfaces Ethernet del Synology participaban. Cuando /J parecía lento, eliminar solo ese comportamiento restauró el rendimiento que esperaba.

El rendimiento final no fue el resultado de encontrar un comando secreto de "Robocopy rápido" de un foro. Vino de pensar en qué características realmente quería para esta migración y eliminar algunas que eran útiles en otras circunstancias pero costosas en la mía.

Esa es probablemente la parte que querré recordar la próxima vez que haga esto. /Z, /J y /MT no son niveles en un control deslizante de rendimiento. Cambian la reiniciabilidad, el buffering y la concurrencia. Los Flujos de Datos Alternativos son datos reales incluso cuando el Explorador normalmente los oculta. SMB Multichannel puede hacer que un NAS antiguo con varias interfaces gigabit sea mucho más capaz de lo que uno podría asumir al mirar cualquier puerto Ethernet individual.

Robocopy terminó siendo lo más rápido que probé. Como con todos los consejos, esto funcionó para mí. Idealmente, encontrarás más valor en los comentarios, ya que expertos de Hacker News y expertos de Windows aportarán herramientas y estrategias mejores. Solo recuerda, hay más de una forma de saturar una red y yo saturé completamente esta, así que estoy bastante contento con el resultado de mi migración.