Large migrations · Verification · La prueba detrás de la barra de progreso

Mover cientos de GB entre nubes: ¿cómo se sabe que ha llegado cada archivo?

Con 500 GB, "la carga parecía terminada" no es prueba. Una migración confiable necesita un inventario duradero, una transición de estado para cada objeto, una recuperación repetible después de las interrupciones y pruebas del propio destino.

Actualizado ; 16 min de lectura.

Respuesta breve

FileArk divide la biblioteca en registros por archivo y mensajes de cola duraderos. Un trabajador copia una entrega, almacena el ID de destino devuelto, valida el tamaño, lee ese objeto exacto y compara SHA-256 con la carga útil de origen. El registro se verifica (y se confirma el mensaje) solo después de que esas comprobaciones y la actualización de la base de datos sean exitosas.

Por qué la escala cambia el significado de "trabajado"

Diez archivos son fáciles de inspeccionar. Diez mil archivos no lo son. Una gran biblioteca personal puede combinar documentos pequeños, vídeos de varios gigabytes, archivos vacíos, carpetas anidadas, nombres Unicode, proyectos archivados y formatos nativos de la nube. Un fracaso puede esconderse dentro de un porcentaje impresionante.

Los totales son útiles pero incompletos. Dos bibliotecas pueden mostrar el mismo tamaño aparente mientras que a una le falta un objeto o contiene un objeto truncado equilibrado por algún archivo no relacionado. Los recuentos de archivos también pueden diferir después de la exportación de documentos nativos o de los objetos de proveedor excluidos.

La unidad de verdad útil es el trabajo del archivo: qué objeto de origen se leyó, qué objeto de destino se creó, qué bytes se compararon, cuándo se completó la verificación y si algún intento queda sin resolver.

El ciclo de vida completo de FileArk, anotado

Ciclo de vida anotado que muestra el trabajador de cola duradero de la base de datos del escáner de configuración del navegador FileArk y la verificación SHA-256
El navegador inicia el flujo de control; el escáner, la cola persistente, la base de datos y el trabajador realizan la migración de larga duración.

Cuando se acepta Inicio, la API primero escribe un trabajo de escaneo en MongoDB y luego publica un mensaje de escaneo persistente en una cola RabbitMQ duradera con la confirmación del editor habilitada. Si la publicación falla, el trabajo se marca como Error y la API informa que no pudo poner en cola el análisis de manera segura.

El escáner autentica a ambos proveedores, realiza un inventario del origen seleccionado, compara la cuota de destino finita con los bytes descubiertos e inserta un registro de base de datos para cada archivo de origen. Publica mensajes de migración persistentes y marca el análisis como completo solo después de que dichas publicaciones se realicen correctamente.

El trabajador de migración utiliza reconocimientos manuales y un recuento de captura previa de uno. Una entrega permanece sin reconocimiento mientras el contenido se lee, carga, relee, verifica y persiste. Por lo tanto, una conexión o proceso detenido puede devolver trabajo inacabado a la cola.

Una fila de la base de datos es un elemento de la lista de verificación, no una contabilidad desechable

Cada registro de archivo comienza como Pendiente, pasa a En progreso durante un intento y llega a Cargado solo después de la verificación. El recuento de intentos, la hora del último intento, los detalles del error, el ID del objeto de destino, los resúmenes SHA-256, el método de verificación y VerifiedAt permanecen adjuntos al registro.

Los registros completos permanecen en la base de datos como seguimiento del progreso y de auditoría. “Tachar un expediente” significa un cambio de estado controlado, sin eliminar la evidencia. Las entregas de cola duplicadas inspeccionan ese estado y reconocen inmediatamente un registro ya marcado como Subido con VerifiedAt.

Después de tres intentos fallidos, un problema persistente se convierte en Fallido con una marca de tiempo de finalización para el ciclo de intento. Esto hace que las excepciones sean visibles y evita que un mensaje dudoso siga girando indefinidamente mientras el tablero parece bloqueado.

La puerta de finalización de un archivo
Pending
  → InProgress (attempt recorded)
  → destination ID stored
  → destination size matches
  → exact destination object re-downloaded
  → source SHA-256 == destination SHA-256
  → Uploaded + VerifiedAt persisted
  → queue message acknowledged

Por qué un archivo puede entregarse más de una vez

Las colas confiables generalmente brindan al menos una entrega, no una promesa mágica de exactamente una vez a través de una API en la nube, un intermediario de mensajes y una base de datos. Puede ocurrir un bloqueo después de que OneDrive o Google Drive acepte una carga, pero antes de que el trabajador complete la escritura.

FileArk maneja esa incertidumbre con registros idempotentes y recuperación de destino. El trabajador primero verifica si el registro ya está verificado. De lo contrario, puede utilizar el ID de destino almacenado o buscar la ruta de destino esperada y el tamaño exacto del resultado interrumpido antes de decidir cargarlo nuevamente.

Los candidatos a recuperación luego se someten a la misma verificación de hash del objeto exacto. Encontrar un nombre de archivo familiar no es suficiente. La cuestión es convertir un intento interrumpido nuevamente en evidencia, no en un éxito optimista.

La capacidad se comprueba en el destino y en el trabajador.

Antes de publicar los trabajos por archivo, el escáner totaliza los tamaños de metadatos de origen no negativos y compara el requisito con el almacenamiento restante informado del destino siempre que el proveedor proporcione una cuota finita. Un destino de tamaño insuficiente falla en el escaneo en lugar de enviar trabajo a un callejón sin salida conocido.

La cifra es una verificación previa, no una garantía: la actividad de la cuenta puede consumir espacio durante una ejecución, los informes de cuota del proveedor pueden retrasarse y los archivos nativos de la nube exportados pueden no tener un tamaño de origen convencional. La aplicación de medidas por parte del proveedor y el manejo de errores por archivo permanecen activos.

El disco de su computadora no se utiliza para la preparación. En el trabajador de migración, los archivos que superan el umbral de memoria se colocan en un directorio temporal aislado sólo después de que el volumen tenga espacio para el objeto esperado más una reserva de dos gigabytes. El contenido temporal se elimina durante la limpieza, ya sea que el intento sea exitoso o fallido.

Por qué es importante el ID de destino más SHA-256

Un nombre de archivo no es una identidad única. Es posible que el destino ya contenga dos archivos con el mismo nombre visible o que la lista de metadatos tarde un tiempo en establecerse. La respuesta de carga proporciona un ID de objeto del proveedor y FileArk almacena ese ID antes de la etapa de verificación final.

El trabajador calcula SHA-256 a través del flujo de carga útil de origen, lo carga, luego abre el objeto de destino exacto con esa ID y vuelve a calcular SHA-256. El mismo tamaño capta el truncamiento obvio; El resumen criptográfico igual es la verificación a nivel de bytes más sólida.

Sólo se cubre la representación del archivo transferido. Un resumen no puede validar reglas de uso compartido, comentarios, versiones, etiquetas, accesos directos, configuraciones de retención o cómo se muestra un documento de Google exportado para un usuario. Esas siguen siendo tareas de aceptación.

La eliminación de la fuente está intencionalmente fuera del camino normal hacia el éxito

El valor predeterminado más seguro es solo copiar y la opción de eliminación de FileArk está desactivada a menos que la habilite. Con la eliminación deshabilitada, un error de verificación no puede eliminar el original porque nunca se solicita la eliminación.

Si habilita deliberadamente la eliminación después del movimiento, el trabajador aún espera la identificación del destino, el tamaño y la validación SHA-256 antes de llamar a la operación de eliminación del proveedor de origen. La mejor opción operativa para bibliotecas irreemplazables o muy grandes sigue siendo mantener la opción desactivada y utilizar un período de superposición aprobado por humanos.

Migración responde “¿llegó una copia verificada?” La retención responde "¿cuándo se puede eliminar la copia anterior?" Trátelas como decisiones separadas con evidencia separada.

El mismo modelo de control funciona en ambas direcciones.

Para OneDrive a Google Drive, la carga útil de origen se lee desde Microsoft Graph y el objeto de destino se verifica a través de Google Drive mediante su ID devuelto. Para Google Drive a OneDrive, la fuente se descarga o exporta a través de Google Drive y el nuevo elemento de OneDrive se vuelve a leer a través de Microsoft Graph.

La cola, los estados de la base de datos, los intentos limitados, la verificación previa de capacidad, el resumen de origen, el ID de destino, el resumen de destino y el orden de confirmación son neutrales en cuanto a dirección. Los adaptadores de proveedor manejan las diferentes API de carga, carpeta y contenido.

La asimetría es la semántica del contenido. Los documentos nativos de Google deben exportarse y ambas plataformas tienen un comportamiento de versión y uso compartido específico del servicio. El contenido del archivo verificado por bytes no debe comercializarse como un clon completo de todas las funciones de colaboración.

Utilice un plan de aceptación de cuatro partes

  1. Conciliar el registro del sistema

    Revise los recuentos completados, pendientes, en curso y fallidos. Ningún elemento fallido debe descartarse porque el porcentaje general sea alto.

  2. Muestra por riesgo

    Abra los archivos que más le dolería perder, además de medios de gran tamaño, archivos, documentos antiguos, nombres que no estén en inglés, rutas anidadas y archivos nativos de la nube convertidos.

  3. Validar el comportamiento del destino

    Pruebe el acceso desde dispositivos y usuarios reales. Reconstruya el uso compartido requerido y confirme que los archivos de Office o Google exportados se abran como se esperaba.

  4. Mantener un período de superposición

    Mantenga la fuente disponible y estable mientras el uso normal ejercita el destino. Tome cualquier decisión de cancelación o eliminación más adelante.

Preguntas frecuentes

¿FileArk utiliza una cola para cada archivo?

Sí. El escáner crea o reutiliza un registro de base de datos por archivo fuente y publica un mensaje de migración persistente. Los trabajadores extraen esos mensajes con reconocimiento manual.

¿Cuándo se reconoce un mensaje en cola?

Después de que se hayan verificado el ID del objeto de destino, el tamaño y SHA-256 y se haya mantenido el estado Cargado y VerifiedAt. Las entregas no finalizadas se pueden volver a entregar.

¿Se eliminan de la base de datos los registros de archivos completos?

No. La finalización es una transición estatal en el registro duradero. La fila mantiene la identidad del destino, la evidencia de verificación, el tiempo y la información de intento para el progreso y la auditoría.

¿Puede SHA-256 demostrar los permisos y las versiones movidas?

No. Demuestra que los bytes del archivo de destino coinciden con la carga útil de origen transferida. El uso compartido, los permisos, las versiones, los comentarios, las etiquetas, los accesos directos y el comportamiento nativo del proveedor necesitan una validación por separado.

¿Se verifica OneDrive a Google Drive de la misma manera que al revés?

La regla básica es la misma en ambas direcciones: resumen de carga útil de origen, identidad del objeto de destino, tamaño de destino, resumen de descarga de objeto exacto, verificación persistente y luego reconocimiento de cola.

Recursos oficiales utilizados para esta guía

Leer la guía