Bash + rclone · OneDrive ↔ Google Drive · Guide opérationnel open source

Un transfert cloud limité à la copie en Bash avec rclone

rclone gère déjà la pagination des services cloud, les nouvelles tentatives, la reprise des transferts et les empreintes fournies par les fournisseurs. Le travail d’ingénierie consiste à intégrer ces primitives dans une procédure opérationnelle qui échoue de manière sûre et tient compte des capacités.

Mis à jour ; 20 min de lecture.

En bref

FileArk est la solution gérée la plus simple pour les migrations volumineuses ou sans surveillance : le transfert s’exécute en ligne, la solution a été testée avec des charges de plusieurs téraoctets et chaque résultat est vérifié avant la fin de l’opération. Pour les opérateurs qui souhaitent contrôler le cheminement des données depuis le shell, ce script enveloppe Bash sous licence MIT copie des lots de taille limitée via une zone de transit locale, vérifie les deux étapes octet par octet et ne supprime jamais les fichiers sources.

Pourquoi intégrer rclone plutôt que recréer le client de chaque fournisseur

rclone fournit à un workflow shell une abstraction mature des fournisseurs, la configuration OAuth, la pagination, la gestion des nouvelles tentatives, la reprise des transferts, le contrôle de la concurrence ainsi que des commandes d’inventaire et de vérification. Le script enveloppe peut ainsi se concentrer sur les invariants de la migration : commandes de copie uniquement, zone de transit limitée, réserves de capacité, listes de fichiers déterministes et progression persistante.

Cela ne rend pas l’opération automatique. L’opérateur reste responsable de la configuration des espaces distants, de la sécurité des jetons, de la disponibilité du réseau, de la supervision des processus, du disque local, des journaux, des limites des fournisseurs, de l’examen des objets en échec et de la validation de la destination. FileArk s’adresse aux utilisateurs qui préfèrent que cette procédure soit exécutée sous la forme d’un workflow en ligne géré plutôt que sur leur poste de travail ou leur serveur.

Le script n’appelle explicitement jamais rclone move, sync, delete, purge ou rmdirs. Il utilise lsf et about pour la découverte, copy pour chaque étape et check --download pour la vérification intégrale des octets. La seule suppression concerne un fichier vérifié dans le répertoire de transit local.

Télécharger l’édition Bash et la licence MIT

Télécharger le programme de transfert Bash et rclone
Un script enveloppe limité à la copie, avec limites de lots, réserves locales et à destination, vérification intégrale des octets, points de contrôle, réglages des nouvelles tentatives et démonstration sans connexion réseau.
fileark-cloud-transfer.sh · Bash 4+ · rclone · jq · licence MIT

Télécharger la licence MIT
Avis d’autorisation couvrant les deux scripts de transfert manuel de FileArk.
LICENSE-fileark-cloud-transfer.txt · MIT · texte brut

Exécuter la démonstration opérateur sans accès réseau

Terminal exécutant en mode démonstration le script de transfert cloud Bash et rclone de FileArk
La démonstration montre un lot de taille limitée franchissant les deux étapes de vérification. Elle n’inspecte pas la configuration de rclone, ne contacte aucun service cloud et n’écrit aucune donnée distante.

La démonstration peut être exécutée en toute sécurité avant l’installation de rclone ou de jq, car l’analyse des arguments se termine avant la vérification des dépendances. La sortie nomme les opérations destructrices interdites, affiche les deux réserves de capacité et se termine par le nombre de suppressions à la source.

Inspecter et tester rapidement le téléchargement
chmod +x fileark-cloud-transfer.sh
bash -n fileark-cloud-transfer.sh
./fileark-cloud-transfer.sh --demo
./fileark-cloud-transfer.sh --help

Installer et configurer les dépendances nécessaires à l’opérateur

Installez une version récente de rclone en suivant ses instructions officielles, puis installez jq à partir du gestionnaire de paquets de votre système d’exploitation. Bash 4 ou une version ultérieure est requis, car le script d’encapsulation utilise une gestion stricte des erreurs et des expressions conditionnelles modernes.

Exécutez rclone config et créez deux espaces distants portant des noms distincts, par exemple onedrive: et gdrive:. Saisissez votre propre ID client et votre propre secret auprès du fournisseur lorsque les règles ou les limites de débit nécessitent des applications OAuth dédiées. rclone stocke les jetons OAuth dans son fichier de configuration : protégez ce fichier avec des autorisations restrictives et ne le distribuez jamais avec le script.

Validez chaque espace distant avec une commande de listage en lecture seule et une commande de quota avant d’exécuter le script enveloppe. Utilisez des chemins tels que onedrive:Department/Archive lorsque seul un sous-arbre est concerné.

Configurer et examiner les deux espaces distants
rclone version
rclone config
rclone lsd onedrive:
rclone lsd gdrive:
rclone about onedrive: --json | jq
rclone about gdrive: --json | jq

Figer un inventaire déterministe avant de transférer les octets

Le script enveloppe utilise rclone lsf de manière récursive, avec une tabulation comme séparateur explicite et le format sp, ce qui produit la taille suivie du chemin. Il vérifie que chaque taille est numérique et que chaque chemin est relatif, puis exclut les chemins déjà présents dans le point de contrôle vérifié.

L’édition Bash refuse les noms de fichiers contenant des tabulations, des retours chariot ou des sauts de ligne, car les listes --files-from-raw délimitées par des sauts de ligne ne peuvent pas les représenter sans ambiguïté. Utilisez l’édition Python ou un format d’inventaire conçu à cet effet lorsque de tels noms existent.

Un point de contrôle fondé sur les chemins est volontairement simple et vérifiable. Il suppose que les chemins sources restent stables pendant l’exécution. Si possible, bloquez les écritures sur la source ; sinon, régénérez et rapprochez l’inventaire si des modifications simultanées sont attendues.

Primitive d’inventaire utilisée par le script enveloppe
rclone lsf "$SOURCE" \
  --recursive \
  --files-only \
  --format "sp" \
  --separator 
    
  

\t' > "$inventory"

Interrompre avant qu’un lot n’entame la réserve

Le nombre d’octets libres localement provient de df sur le système de fichiers de la zone de transit. Le nombre d’octets libres à destination provient de rclone about --json : le script utilise free lorsque cette valeur est fournie, sinon il soustrait used de total. Il vérifie le nombre total d’octets en attente avant de commencer, puis contrôle à nouveau les capacités locale et de destination avant chaque lot.

Certains fournisseurs ou types de comptes ne publient pas de quota fini via rclone. Le script d’encapsulation signale cette limite et poursuit l’opération sous le contrôle des restrictions du fournisseur. Considérez cela comme une exigence de surveillance, et non comme la preuve que l’espace disponible est suffisant.

La limite de lot ne constitue pas une taille maximale stricte pour un objet. Un fichier plus volumineux que le lot configuré peut former son propre lot ; l’espace libre local doit donc suffire pour le plus gros fichier et la réserve. La vérification intégrale de la destination lit les octets depuis celle-ci, mais l’édition rclone ne conserve pas de seconde copie locale.

Vérifier chaque côté de la limite de stockage intermédiaire local

Chaque lot suit deux étapes indépendantes. Tout d’abord, rclone copie les chemins sources sélectionnés dans la zone de transit locale avec --ignore-existing, puis check --download lit les deux côtés et compare leur contenu réel. Ensuite, rclone copie ces chemins depuis la zone de transit vers la destination et répète la même vérification intégrale des octets.

--ignore-existing rend les exécutions interrompues non destructrices : un objet existant n’est pas écrasé. La vérification doit néanmoins réussir avant que le chemin puisse être ajouté au point de contrôle. Si le contenu déjà présent à destination diffère, rclone check échoue et la gestion stricte des erreurs Bash interrompt l’exécution.

L’utilisation de --download est plus lente et consomme des opérations de lecture ou de transfert sortant chez les fournisseurs, mais elle évite de dépendre uniquement de l’existence d’un algorithme de hachage commun exposé par les deux fournisseurs. La commande ne modifie aucun des deux côtés.

Les deux étapes de copie et de vérification
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

Effectuer un transfert de OneDrive vers Google Drive avec un stockage intermédiaire limité

L’exemple laisse 15 GiB du disque local inutilisés et 10 GiB libres sur Google Drive, limite un lot normal à 8 GiB ou 200 fichiers et utilise quatre transferts simultanés. Le contenu de destination est écrit dans un nouveau dossier daté.

Utilisez d’abord --dry-run. Cette option inventorie la source et vérifie au préalable le quota de la destination, sans téléchargement ni téléversement. Le script d’encapsulation affiche le volume total en octets restant à transférer, qui doit être rapproché du périmètre de votre migration avant le premier lot réel.

Effectuer les vérifications préalables, puis exécuter le même périmètre
./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.

Inverser le sens sans réutiliser l’état

Le script enveloppe est indépendant des fournisseurs, car rclone gère les adaptateurs distants. Inversez les arguments des espaces distants pour copier Google Drive vers OneDrive, puis attribuez à cette exécution un nouveau dossier de destination, un nouveau chemin de transit et un nouveau fichier de points de contrôle.

Les formats natifs de Google, tels que Docs, Sheets et Slides, ainsi que les autres formats virtuels, nécessitent de configurer l’exportation dans rclone et de procéder à un examen attentif. Confirmez les extensions exportées et le comportement de conversion à l’aide d’un jeu de test. Une copie par script shell ne préserve ni l’historique de collaboration Google, ni les raccourcis, ni les autorisations, ni les métadonnées propres à Microsoft.

De Google Drive vers 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

Créer un point de contrôle uniquement après la vérification de la destination

Lorsque la vérification de la destination se termine avec succès, le script enveloppe ajoute chaque chemin relatif à un point de contrôle en texte brut. Il supprime ensuite ce fichier de la zone de transit locale, puis les répertoires locaux vides. L’espace distant source reste intact.

Pendant une exécution, le point de contrôle fonctionne uniquement par ajout et peut facilement être audité avec des outils standard. Conservez-le avec la ligne de commande, la version de rclone, l’empreinte de la configuration, l’inventaire, les journaux, les horodatages et les notes de validation. Ne le modifiez pas pour masquer un échec, sauf si le fichier de destination a fait l’objet d’une vérification indépendante.

Un point de contrôle fondé uniquement sur le chemin ne peut pas détecter un objet source dont le contenu change sans modification du chemin. Pour les jeux de données modifiables, suspendez les écritures, enregistrez séparément les identifiants du fournisseur et les métadonnées de modification, ou utilisez le point de contrôle plus strict basé sur l’identifiant et la taille de l’édition Python. Pour les migrations réglementées ou collaboratives, utilisez un processus géré avec un contrôle explicite des modifications.

Traiter toute sortie non nulle comme un lot non résolu

  • Le mode strict interrompt l’exécution en cas d’échec d’une commande ou d’un pipeline, ou lorsqu’une variable n’est pas définie ; le répertoire d’inventaire temporaire est automatiquement supprimé.
  • rclone relance les transferts affectés par des erreurs temporaires, mais les erreurs persistantes d’autorisation, de quota, de réseau, de conflit ou d’intégrité interrompent le lot.
  • Les fichiers de transit non ajoutés au point de contrôle restent disponibles pour examen, et une nouvelle exécution identique utilise --ignore-existing avant de vérifier leurs octets.
  • Un fichier différent présent à destination n’est jamais écrasé. Résolvez le conflit ou choisissez une racine de destination vierge.
  • Ne transformez pas une copie ayant échoué en rclone sync ou move. Ces commandes appliquent des règles de suppression différentes.
  • Conservez les journaux et le point de contrôle jusqu’à la fin de la validation manuelle de la destination.

Sécuriser l’hôte qui devient le plan de données

L’hôte de stockage intermédiaire contient temporairement des copies lisibles des données sources et des jetons d’actualisation OAuth. Utilisez le chiffrement intégral du disque, des autorisations de fichiers restrictives, un compte de système d’exploitation dédié, des dépendances à jour, un accès administrateur contrôlé et une politique de sauvegarde chiffrée qui ne conserve pas de manière inattendue le contenu intermédiaire.

Évitez de saisir des secrets en ligne de commande, car les listes de processus et l’historique du shell peuvent les exposer. La configuration protégée de rclone peut masquer les jetons au repos, mais elle ne remplace pas la sécurisation de l’hôte. Après la validation de la migration, supprimez les données de jetons et les résidus de la zone de transit conformément à votre politique de conservation.

Surveillez les journaux d’audit des fournisseurs, le trafic réseau sortant, l’état du disque, la disponibilité des inodes, l’état des processus et la sortie de rclone. Laisser un terminal ouvert ne constitue pas une supervision des processus : utilisez un gestionnaire de services ou un multiplexeur de terminaux approuvé et assurez la conservation durable des journaux.

Clore la migration avec des preuves, pas avec une commande affichée en vert

  • Archivez l’inventaire figé, la commande exacte, la somme de contrôle du script, la version de rclone, l’empreinte de la configuration des espaces distants et le point de contrôle vérifié.
  • Rapprochez le nombre de fichiers et le volume connu en octets dossier par dossier, et pas seulement au niveau du total du lecteur.
  • Ouvrez un échantillon fondé sur les risques comprenant des documents volumineux, petits, anciens, récents, en Unicode, profondément imbriqués, archivés et convertis.
  • Testez l’accès à la destination depuis des comptes utilisateurs représentatifs et recréez séparément les partages nécessaires.
  • Examinez les paquets ignorés, les raccourcis, les liens, les documents natifs, les conflits et les avertissements des fournisseurs.
  • Maintenez une période de coexistence avec la source et obtenez l’accord explicite du propriétaire avant toute décision ultérieure de conservation ou de suppression.

Questions fréquentes

Pourquoi le script Bash utilise-t-il rclone copy plutôt que sync ?

La copie ne supprime ni les objets sources ni les objets de destination absents de la source. La synchronisation applique des règles de rapprochement et de suppression différentes ; elle est donc volontairement exclue de ce workflow.

La commande rclone check --download modifie-t-elle l’un des deux espaces cloud ?

Non. Cette commande lit et compare le contenu des fichiers. Le script l’utilise après chaque étape de copie afin qu’un chemin ne soit enregistré comme point de contrôle qu’une fois que les octets à destination correspondent à ceux du stockage intermédiaire.

Que se passe-t-il lorsque la destination contient déjà un fichier ?

La copie utilise --ignore-existing, puis effectue une vérification intégrale des octets. Un objet identique peut réussir la vérification ; un objet différent la fait échouer. Le script n’écrase jamais le fichier en conflit.

Le script peut-il traiter des fichiers plus volumineux qu’un lot ?

Oui. Un fichier surdimensionné constitue à lui seul un lot. Le système de fichiers de stockage intermédiaire doit disposer de suffisamment d’espace pour ce fichier, en plus de la réserve locale configurée.

Ce processus migre-t-il les autorisations, les versions ou les données de collaboration natives du cloud ?

Non. Il copie le contenu et les chemins des fichiers à l’aide de rclone. Le contrôle d’accès, les versions, les libellés, les commentaires, les raccourcis, les liens, les règles de conservation et les comportements propres aux fournisseurs nécessitent une planification et une vérification distinctes.

Ressources officielles utilisées pour ce guide

Lire le guide