Bash + rclone · OneDrive ↔ Google Drive · Guía operativa de código abierto

Transferencia en la nube de solo copia con Bash y rclone

rclone ya gestiona la paginación en la nube, los reintentos, las transferencias reanudables y los hashes de los proveedores. La tarea de ingeniería consiste en integrar esas primitivas en un procedimiento operativo que se detenga de forma segura ante fallos y tenga en cuenta la capacidad.

Actualizado ; 20 min de lectura.

Respuesta breve

FileArk es la opción gestionada más sencilla para migraciones grandes o desatendidas: ejecuta la transferencia en línea, se ha probado con cargas de trabajo de varios terabytes y comprueba cada resultado antes de finalizar. Para los operadores que quieran controlar la ruta de los datos desde el shell, este script contenedor en Bash con licencia MIT copia lotes limitados mediante almacenamiento provisional local, verifica ambas etapas byte a byte y nunca elimina los archivos de origen.

Por qué utilizar un script contenedor para rclone en lugar de reconstruir el cliente de cada proveedor

rclone proporciona a un flujo de trabajo de shell una abstracción madura de los proveedores, configuración de OAuth, paginación, gestión de reintentos, transferencias reanudables, controles de concurrencia y comandos de inventario y verificación. De este modo, el script contenedor puede centrarse en los invariantes de la migración: comandos que solo copian, almacenamiento provisional limitado, reservas de capacidad, listas deterministas de archivos y progreso persistente.

Eso no automatiza el trabajo. El operador sigue siendo responsable de la configuración de los remotos, la seguridad de los tokens, la disponibilidad de la red, la supervisión del proceso, el disco local, los registros, los límites de los proveedores, la revisión de los objetos fallidos y la aceptación del destino. FileArk está pensado para quienes prefieren que este procedimiento se ejecute como un flujo de trabajo gestionado en línea, en lugar de hacerlo en su propio equipo o servidor.

El script no invoca en ningún caso rclone move, sync, delete, purge ni rmdirs. Utiliza lsf y about para la detección, copy en cada etapa y check --download para la verificación completa de los bytes. Lo único que elimina es un archivo verificado del directorio de almacenamiento provisional local.

Descarga la edición en Bash y la licencia MIT

Descarga el programa de transferencia con Bash y rclone
Un script contenedor que solo copia, con límites de lote, reservas locales y en el destino, verificación completa de los bytes, puntos de control, controles de reintentos y una demostración sin conexión a la red.
fileark-cloud-transfer.sh · Bash 4+ · rclone · jq · Licencia MIT

Descargar la licencia MIT
Aviso de licencia aplicable a los dos scripts de transferencia manual de FileArk.
LICENSE-fileark-cloud-transfer.txt · MIT · texto sin formato

Ejecutar la demostración para operadores sin conexión a la red

Terminal que ejecuta en modo de demostración el script de transferencia en la nube de FileArk con Bash y rclone
La demostración muestra un lote limitado que atraviesa ambos límites de verificación. No inspecciona la configuración de rclone, no se conecta a ningún servicio en la nube ni escribe datos remotos.

Es seguro ejecutar la demostración antes de instalar rclone o jq porque el análisis de argumentos finaliza antes de comprobar las dependencias. La salida enumera las operaciones destructivas prohibidas, muestra ambas reservas de capacidad y termina con el número de eliminaciones en el origen.

Inspeccionar la descarga y realizar una prueba básica
chmod +x fileark-cloud-transfer.sh
bash -n fileark-cloud-transfer.sh
./fileark-cloud-transfer.sh --demo
./fileark-cloud-transfer.sh --help

Instalar y configurar las dependencias para el operador

Instale una versión actual de rclone siguiendo sus instrucciones oficiales e instale jq mediante el gestor de paquetes de su sistema operativo. Se requiere Bash 4 o posterior porque el script contenedor usa un control de errores estricto y expresiones condicionales modernas.

Ejecuta rclone config y crea dos remotos con nombres independientes, por ejemplo, onedrive: y gdrive:. Introduce tu propio ID y secreto de cliente del proveedor cuando las políticas o los límites de frecuencia requieran aplicaciones OAuth específicas. rclone guarda los tokens de OAuth en su archivo de configuración; protege ese archivo con permisos restrictivos y nunca lo distribuyas junto con el script.

Confirma cada remoto con un comando de consulta de cuota y un listado de solo lectura antes de ejecutar el script contenedor. Utiliza rutas como onedrive:Department/Archive cuando solo se vaya a incluir un subárbol.

Configura e inspecciona ambos remotos
rclone version
rclone config
rclone lsd onedrive:
rclone lsd gdrive:
rclone about onedrive: --json | jq
rclone about gdrive: --json | jq

Inmoviliza un inventario determinista antes de transferir los bytes

El script contenedor utiliza rclone lsf de forma recursiva con un separador de tabulación explícito y el formato sp, lo que genera el tamaño seguido de la ruta. Valida que cada tamaño sea numérico y cada ruta sea relativa; después, excluye las rutas que ya figuran en el punto de control verificado.

La edición en Bash rechaza los nombres de archivo que contienen tabulaciones, retornos de carro o saltos de línea porque las listas --files-from-raw delimitadas por saltos de línea no pueden representarlos sin ambigüedad. Utiliza la edición en Python o un formato de inventario específico si existen nombres de ese tipo.

Un punto de control basado en rutas es sencillo y fácil de inspeccionar de forma intencionada. Presupone que las rutas de origen permanecen estables durante la ejecución. Impide las escrituras en el origen si es posible; si se esperan cambios simultáneos, vuelve a generar y concilia el inventario.

Primitiva de inventario utilizada por el script contenedor
rclone lsf "$SOURCE" \
  --recursive \
  --files-only \
  --format "sp" \
  --separator 
    
  

\t' > "$inventory"

Detener el proceso antes de que un lote consuma la reserva

Los bytes locales disponibles se obtienen mediante df en el sistema de archivos del almacenamiento provisional. Los bytes disponibles en el destino se obtienen mediante rclone about --json: el script utiliza free cuando se proporciona; de lo contrario, resta used de total. Comprueba el total de bytes pendientes antes de iniciar el trabajo y vuelve a comprobar la capacidad local y la del destino antes de cada lote.

Algunos proveedores o tipos de cuenta no publican una cuota finita mediante rclone. El script contenedor muestra esta limitación y continúa sujeto a los límites impuestos por el proveedor. Considérelo un requisito de supervisión, no una prueba de que hay espacio suficiente.

El límite del lote no es un máximo estricto para un solo objeto. Un archivo que supere el tamaño de lote configurado puede formar su propio lote, por lo que el espacio local disponible debe bastar para el archivo más grande más la reserva. La verificación completa del destino lee los bytes del destino, pero no conserva una segunda copia local en la edición para rclone.

Verificar ambos lados del límite del almacenamiento temporal local

Cada lote recorre dos etapas independientes. Primero, rclone copia las rutas de origen seleccionadas al almacenamiento provisional local con --ignore-existing; después, check --download lee ambos lados y compara el contenido real. A continuación, rclone copia esas rutas provisionales en el destino y repite la misma comprobación completa de los bytes.

--ignore-existing evita que las ejecuciones interrumpidas sean destructivas: los objetos existentes no se sobrescriben. Aun así, la verificación debe completarse correctamente antes de que la ruta pueda añadirse al punto de control. Si el contenido existente en el destino es diferente, rclone check falla y la gestión estricta de errores de Bash detiene la ejecución.

Usar --download es más lento y consume operaciones de salida o lectura del proveedor, pero evita depender únicamente de que ambos proveedores ofrezcan un algoritmo hash común. El comando no modifica ninguno de los dos lados.

Las dos etapas de copia y verificación
rclone copy "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$SOURCE" "$STAGING_DIR" \
  --files-from-raw "$batch_list" --one-way --download

rclone copy "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" \
  --ignore-existing --retries 6 --low-level-retries 20

rclone check "$STAGING_DIR" "$DESTINATION_ROOT" \
  --files-from-raw "$batch_list" --one-way --download

Ejecutar la transferencia de OneDrive a Google Drive con almacenamiento temporal limitado

El ejemplo mantiene intactos 15 GiB del disco local, deja 10 GiB libres en Google Drive, limita un lote normal a 8 GiB o 200 archivos y utiliza cuatro transferencias simultáneas. El contenido de destino se guarda en una nueva carpeta con fecha.

Use primero --dry-run. Realiza el inventario del origen y la comprobación previa de la cuota del destino sin descargar ni subir nada. El script contenedor muestra todos los bytes pendientes, que deben cotejarse con el alcance de la migración antes del primer lote real.

Realizar la comprobación previa y ejecutar después el mismo alcance
./fileark-cloud-transfer.sh \
  --source onedrive: \
  --destination gdrive: \
  --destination-folder "OneDrive archive 2026-07-25" \
  --staging-dir /srv/fileark-staging \
  --state-file ./onedrive-to-google-verified.txt \
  --batch-gib 8 \
  --batch-files 200 \
  --local-reserve-gib 15 \
  --destination-reserve-gib 10 \
  --transfers 4 \
  --checkers 8 \
  --dry-run

# Remove only --dry-run after reviewing the preflight.

Invertir la dirección sin reutilizar el estado

El script contenedor es independiente del proveedor porque rclone se encarga de los adaptadores remotos. Intercambia los argumentos de los remotos para copiar Google Drive en OneDrive y asigna a esa ejecución una nueva carpeta de destino, una ruta de almacenamiento provisional y un archivo de puntos de control.

Los formatos nativos de Google, como Docs, Sheets y Slides, y otros formatos virtuales requieren configurar la exportación en rclone y revisarla detenidamente. Confirme las extensiones exportadas y el comportamiento de la conversión con un conjunto de prueba. Una copia mediante shell no conserva el historial de colaboración de Google, los accesos directos, los permisos ni los metadatos específicos de Microsoft.

De Google Drive a OneDrive
./fileark-cloud-transfer.sh \
  --source gdrive: \
  --destination onedrive: \
  --destination-folder "Google archive 2026-07-25" \
  --staging-dir /srv/google-staging \
  --state-file ./google-to-onedrive-verified.txt \
  --batch-gib 8 \
  --local-reserve-gib 15

Añade el punto de control solo después de verificar el destino

Cuando la comprobación del destino finaliza correctamente, el script contenedor añade cada ruta relativa a un punto de control en texto sin formato. A continuación, elimina ese archivo del almacenamiento provisional local y borra los directorios locales vacíos. El remoto de origen no se modifica.

Durante una ejecución, el punto de control solo admite datos añadidos y es fácil de auditar con herramientas estándar. Consérvalo junto con la línea de comandos, la versión de rclone, la huella digital de la configuración, el inventario, los registros, las marcas de tiempo y las notas de aceptación. No lo edites para ocultar un fallo salvo que el archivo de destino se haya verificado de forma independiente.

Un punto de control basado únicamente en la ruta no puede detectar un objeto de origen cuyo contenido cambie sin que cambie su ruta. Para conjuntos de datos modificables, suspenda las escrituras, capture por separado los ID del proveedor y los metadatos de modificación, o use el punto de control más estricto basado en ID y tamaño de la edición en Python. Para migraciones reguladas o colaborativas, use un flujo de trabajo gestionado con un control de cambios explícito.

Trata cada salida distinta de cero como un lote sin resolver

  • El modo estricto finaliza la ejecución cuando falla un comando o una canalización, o cuando se encuentra una variable no definida; el directorio temporal del inventario se elimina automáticamente.
  • rclone reintenta las transferencias que sufren errores transitorios, pero los errores persistentes de permisos, cuota, red, conflictos o integridad detienen el lote.
  • Los archivos del almacenamiento provisional que no figuran en el punto de control siguen disponibles para su inspección, y una repetición idéntica utiliza --ignore-existing antes de comprobar sus bytes.
  • Un archivo de destino diferente nunca se sobrescribe. Resuelva el conflicto o elija una raíz de destino vacía.
  • No conviertas una copia fallida en rclone sync o move. Esos comandos tienen reglas de eliminación diferentes.
  • Conserva los registros y el punto de control hasta completar la aceptación manual del destino.

Proteger el host que se convierte en el plano de datos

El host de almacenamiento temporal contiene durante un tiempo copias legibles de los datos de origen y tokens de actualización de OAuth. Use cifrado de disco completo, permisos de archivo restrictivos, una cuenta dedicada del sistema operativo, dependencias actualizadas, acceso de administrador controlado y una política de copias de seguridad cifradas que no conserve de forma imprevista el contenido temporal.

Evita incluir secretos en la línea de comandos, ya que las listas de procesos y el historial del shell pueden exponerlos. La configuración protegida de rclone puede ocultar los tokens almacenados, pero no sustituye la seguridad del sistema anfitrión. Tras aceptar la migración, elimina los datos de los tokens y los restos del almacenamiento provisional de acuerdo con tu política de conservación.

Supervisa los registros de auditoría del proveedor, el tráfico saliente de la red, el estado del disco, la disponibilidad de inodos, el estado del proceso y la salida de rclone. Dejar un terminal abierto no equivale a supervisar el proceso; utiliza un gestor de servicios o multiplexor de terminal aprobado y conserva los registros de forma persistente.

Cierra la migración con pruebas, no solo con un comando en verde

  • Archiva el inventario inmovilizado, el comando exacto, la suma de comprobación del script, la versión de rclone, la huella digital de la configuración de los remotos y el punto de control verificado.
  • Coteje por carpeta el número de archivos y los bytes conocidos, no solo el total de la unidad.
  • Abre una muestra basada en el riesgo que incluya documentos grandes, pequeños, antiguos, nuevos, con Unicode, ubicados en estructuras muy anidadas, archivados y convertidos.
  • Prueba el acceso al destino desde cuentas de usuario representativas y vuelve a crear por separado los recursos compartidos necesarios.
  • Revisa los paquetes omitidos, accesos directos, enlaces, documentos nativos, conflictos y advertencias de los proveedores.
  • Mantenga un periodo de solapamiento con el origen y obtenga la aceptación explícita del propietario antes de tomar posteriormente cualquier decisión sobre conservación o eliminación.

Preguntas frecuentes

¿Por qué el script de Bash usa rclone copy en lugar de sync?

La copia no elimina objetos del origen ni objetos del destino que no estén presentes en el origen. La sincronización tiene otras reglas de conciliación y eliminación, por lo que queda fuera de este flujo de trabajo de forma intencionada.

¿Cambia rclone check --download el contenido de alguna de las nubes?

No. Lee y compara el contenido de los archivos. El script lo usa después de cada tramo de la copia, de modo que solo se registra una ruta en el punto de control cuando los bytes del destino coinciden con los almacenados temporalmente.

¿Qué ocurre cuando el destino ya contiene un archivo?

La copia utiliza --ignore-existing y, a continuación, una verificación completa de los bytes. Un objeto idéntico puede superar la comprobación; uno diferente hace que falle. El script nunca sobrescribe el archivo en conflicto.

¿Puede el script gestionar archivos más grandes que un lote?

Sí. Un archivo que supere el tamaño máximo se convierte en un lote independiente. El sistema de archivos de almacenamiento temporal debe tener espacio para ese archivo y para la reserva local configurada.

¿Se migran los permisos, las versiones o los datos de colaboración nativos de la nube?

No. Copia el contenido y las rutas de los archivos mediante rclone. El control de acceso, las versiones, las etiquetas, los comentarios, los accesos directos, los enlaces, las reglas de conservación y el comportamiento nativo del proveedor requieren una planificación y verificación independientes.

Recursos oficiales utilizados para esta guía

Leer la guía