Migración a la nube: estrategia de transferencia de archivos

Una estrategia de transferencia de archivos para la migración a la nube depende de tres decisiones: la ruta de transporte (internet pública, Direct Connect o dispositivo físico), el modelo de transición (big-bang, por fases o ejecución en paralelo) y las comprobaciones de integridad en las que confiarás. Para un parque de 50 TB en una línea de 1 Gbps, espera aproximadamente 5 días de tiempo de transferencia puro a velocidad de línea, menos si comprimes, más si la línea es compartida. El artículo 5, apartado 1, letra f) del RGPD exige que los datos personales se traten "de tal manera que se garantice una seguridad adecuada", lo que significa que la integridad durante la migración no es opcional: necesitas hashes verificados en origen y destino para demostrar que ningún byte se alteró en tránsito.

Planifica la secuencia antes de planificar las herramientas, y presupuesta un 20 % de margen para reintentos y reconciliación.

Dimensionar el conjunto de datos antes de tocar ningún cable

Antes de elegir AWS DataSync, Azure AzCopy o Google Storage Transfer Service, haz un inventario de lo que realmente tienes. Ejecuta du -sh en los recursos compartidos de archivos, consulta los catálogos de bases de datos para contar filas y exporta los manifiestos del almacenamiento de objetos. Una empresa mediana que audité pensaba que tenía 8 TB en su NAS; el número real era 34 TB una vez contados los snapshots y los archivos de bloqueo ~$ de Office.

Clasifica el inventario por tres ejes: tamaño, tasa de cambio y peso regulatorio. Los archivos de menos de 1 MB se mueven lentamente por byte debido al overhead por objeto: un bucket con 200 millones de archivos pequeños puede tardar más que uno con 10 TB de vídeo. Clasifica los datos calientes (cambian a diario) por separado de los datos fríos (archivos .pdf, facturas de 2017). Los datos fríos pueden enviarse semanas antes; los datos calientes necesitan lógica de sincronización hasta el momento del corte.

Elegir un transporte que se ajuste a tu plazo

Para menos de 10 TB con una buena línea de fibra, la transferencia online con TLS 1.3 suele ganar. Entre 10 TB y 500 TB, reserva ancho de banda o aprovisiona AWS Direct Connect / Azure ExpressRoute para evitar saturar la WAN corporativa. Por encima de 500 TB, la siembra física supera a internet: AWS Snowball Edge contiene 80 TB, Snowmobile mueve exabytes en un contenedor de transporte, y Azure Data Box Heavy almacena 1 PB.

Haz los cálculos honestamente. A 1 Gbps (125 MB/s sostenido, en realidad unos 80 MB/s tras el overhead), 100 TB tardan unos 14 días de transferencia ininterrumpida. Si tu ventana de operaciones es de 48 horas, la línea no es viable: envía discos. Ten en cuenta el egreso: mover 100 TB fuera de un proveedor más antiguo a 0,09 $/GB cuesta 9.000 $ antes de llegar al destino.

Integridad: confía pero comprueba con hash

Cada migración necesita verificación de integridad de extremo a extremo, no solo TLS en la capa de transporte. Genera hashes SHA-256 o xxHash64 en el origen, transmitiéndolos junto con la carga útil, y vuelve a calcularlos en el destino. AWS DataSync hace esto por defecto; rsync con --checksum lo fuerza; rclone admite --check-first y backends crypt.

Para cargas de trabajo de cumplimiento, conserva el manifiesto (un CSV de ruta, número de bytes y hash) durante toda la ventana de retención. El artículo 5, apartado 1, letra f) del RGPD exige que puedas demostrar que los archivos no fueron alterados en tránsito. Un solo byte desalineado en un estudio DICOM puede hacer que el visor de un radiólogo rechace abrirlo.

Minimizar el tiempo de inactividad con sincronización delta

Los cortes big-bang son el enemigo del descanso. En su lugar, realiza una copia masiva inicial semanas antes y luego ejecuta deltas incrementales nocturnos hasta la ventana de corte. Herramientas como rclone (--update --use-server-modtime), AzCopy (--overwrite=ifSourceNewer) y gsutil rsync -d de Google detectan archivos modificados por mtime o hash y mueven solo el delta.

Las bases de datos necesitan su propio plan. Para una instancia de PostgreSQL de 2 TB, usa pg_basebackup más WAL shipping; para MySQL, configura una réplica en el destino y promociónala durante el corte. Los deltas del sistema de archivos mediante rsync pueden reducir la sincronización final de horas a minutos, lo que generalmente cabe dentro de una ventana de mantenimiento de sábado por la noche.

Modelado del ancho de banda y transferencias en horario programado

Las migraciones que consumen todo el ancho de banda de la WAN terminan mal: los tickets del servicio de ayuda se acumulan antes del desayuno. Limita de forma agresiva. AzCopy acepta --cap-mbps, rclone admite --bwlimit 50M:100M para tasas de día/noche, y DataSync programa tareas con límites de ancho de banda por hora. Una política sensata: 30 % del enlace durante el horario de oficina, 90 % por las noches, 100 % los fines de semana.

Segmenta el tráfico también en el cortafuegos. Etiqueta los flujos de migración con un valor DSCP para que las políticas de QoS no asfixien las llamadas de Zoom. Si usas MPLS a sucursales, considera la salida SD-WAN local para que el tráfico de migración salga localmente en lugar de pasar por la sede central.

Gestionar datos sensibles en tránsito

Cualquier migración que incluya datos personales, PHI o datos de titulares de tarjetas necesita cifrado que cumpla con el estándar correspondiente. TLS 1.3 es el mínimo; para archivos en reposo durante la fase de preparación, envuélvelos con AES-256-GCM antes de subir. El RGPD, en su artículo 32, exige medidas apropiadas para garantizar la seguridad durante el tratamiento, lo que incluye la fase de migración. El requisito 4.2.1 de PCI DSS 4.0 exige criptografía fuerte para datos de titulares de tarjetas en redes públicas.

Para transferencias ad hoc de pequeños lotes durante la migración (por ejemplo, un consultor que exporta una tabla de Salesforce o un DBA que mueve un almacén de credenciales), las herramientas con cifrado de extremo a extremo mantienen las claves fuera del alcance del proveedor de transporte. HexaTransfer gestiona esto de forma limpia para archivos individuales durante una migración: el cifrado ocurre en el navegador antes de que nada toque un servidor.

Ensayar el corte antes del corte

Practica la migración en un subconjunto. Elige un departamento (digamos, 300 GB de la unidad compartida de Marketing) y ejecuta todo el proceso: inventario de origen, transferencia, verificación de hash, mapeo de permisos y conmutación por error de la aplicación. Cronometra cada paso y documenta qué falló.

Sorpresas habituales: ACL de NTFS que no se mapean limpiamente a las políticas de bucket de S3, symlinks que rclone trata como archivos, rutas de recursos compartidos SMB integradas en configuraciones de aplicación, y diferencias de sensibilidad a mayúsculas/minúsculas entre destinos Windows y Linux. Resuelve esos problemas en la fase de preparación, no a las 2 de la madrugada del día del lanzamiento. Un ensayo que lleva una semana ahorra una reversión que lleva un mes.

Reconciliación posimigración

Declara el éxito solo después de la reconciliación. Compara los recuentos de objetos en origen y destino, los bytes totales y una muestra aleatoria del 1 % de hashes. Consulta las métricas de la aplicación: si un sistema de gestión documental reportaba 4,2 millones de archivos y el destino muestra 4,19 millones, encuentra los 10.000 que faltan antes de apagar el origen.

Mantén el origen en modo de solo lectura durante al menos 30 días después del corte. Los usuarios inevitablemente necesitarán un archivo que no migró porque estaba en ~/Desktop/viejos_archivos/ en lugar del recurso compartido inventariado. Presupuéstalo, no te sorprendas, y escribe el runbook de reversión antes de necesitarlo.

Pruébalo en hexatransfer.com, gratis, sin cuenta, hasta 10 GB.