Migrer Dropbox vers Google Drive avec rclone

Tu veux migrer un compte Dropbox vers Google Drive avec rclone, et le transfert stagne à quelques centaines de kilo-octets par seconde alors que ta connexion tient des centaines de mégabits. Voici ce qu’on a découvert en cherchant pourquoi, et la méthode qui a fini par fonctionner.

Précision : migration réalisée avec l’aide de Claude.ai et parfois Gemini aussi. Cet article a été préparé par Claude.ai sur la base des essais que j’ai réalisé et de ce qui a fonctionné.

Le symptôme

J’ai d’abord essayé sur un dossier Dropbox Pilote, appelé « A-TRANSFERER ». L’idée c’était d’identifier la meilleure façon de faire avec un « petit » dossier avant de transférer l’ensemble de ma Dropbox (quelques centaines de giga-octets). Et tout de suite l’essai s’est heurté à des difficultés.

le problème : un dossier Dropbox de plus de 50 000 fichiers à transférer vers Google Drive, pour une taille totale de quelques dizaines de giga-octets. La commande de départ, sur un petit serveur Linux (un mini PC sous Ubuntu) :

rclone copy dropbox:"A-TRANSFERER" gdrive:/ANCIEN-DROPBOX --progress --transfers 4 --checkers 8 --tpslimit 10 --fast-list --log-file=/home/user/rclone-migration.log

Résultat : un débit de 263 Ko/s (kilo-octets par seconde), et une estimation de temps restant (ETA, « estimated time of arrival ») de plusieurs heures pour quelques giga-octets. Un test de débit de la connexion (speedtest-cli) confirmait pourtant 397 Mbit/s en envoi (upload), soit environ 47 Mo/s. Le débit réel était donc mille fois inférieur à ce que la connexion permettait.

Les fausses pistes (et pourquoi elles n’ont pas suffi)

Augmenter le parallélisme. Première réaction logique : monter --transfers et --checkers, et supprimer la limite --tpslimit. Le débit a un peu progressé (jusqu’à 1,5 Mio/s par moments), mais restait très instable, avec des chutes à quelques kilo-octets par seconde et des ETA remontant parfois à plusieurs semaines.

--drive-chunk-size. Ce paramètre découpe les fichiers volumineux en blocs pour accélérer leur envoi vers Google Drive. Sur le papier, ça semble pertinent. En pratique, il ne s’applique qu’aux fichiers dépassant --drive-upload-cutoff (8 Mo par défaut) : en dessous, rclone envoie le fichier en un seul appel. Pour un lot de dizaines de milliers de petits fichiers (quelques centaines de kilo-octets en moyenne), ce réglage n’a strictement aucun effet.

Changer de machine pour plus de bande passante. L’hypothèse suivante : et si le goulot d’étranglement venait de la connexion du mini PC ? Un test sur Google Cloud Shell (un terminal Linux temporaire fourni gratuitement par Google, accessible depuis un navigateur) a permis de vérifier. Sur un fichier unique volumineux, le débit obtenu (1,5 Mio/s) n’était pas meilleur que ce qu’on avait déjà. La bande passante n’était donc pas non plus en cause.

Le vrai diagnostic

rclone copy entre deux services cloud distincts n’est pas un transfert serveur à serveur : chaque fichier est téléchargé depuis la source puis envoyé vers la destination, en passant par la machine qui exécute la commande. Avec des dizaines de milliers de petits fichiers, chaque aller-retour compte, et l’API de Dropbox s’est révélée nettement plus sensible à la concurrence que celle de Google Drive. Les recommandations généralement admises pour Dropbox vont d’ailleurs à l’inverse de ce qu’on avait tenté : réduire la concurrence (2 à 3 transferts, 4 vérificateurs), pas l’augmenter.

Un signal confirmait cette hypothèse : des erreurs sporadiques du type suivant, dans le journal (log) de transfert :

ERROR : chemin/vers/un/fichier: Failed to copy: failed to open source object: invalid character '<' looking for beginning of value

Cette erreur signifie que Dropbox a renvoyé une page HTML d’erreur au lieu de la réponse JSON attendue, un signe classique de sursollicitation de l’API.

La méthode qui a fonctionné : passer par un disque local

Plutôt que de faire transiter chaque fichier directement entre les deux services cloud, la solution a été de synchroniser d’abord Dropbox sur un disque dur externe (via le client Dropbox classique, sur un PC Windows ou macOS), puis de transférer ce disque vers Google Drive avec rclone, sans repasser par l’API Dropbox.

Étape 1 : synchroniser Dropbox sur un disque local

Rien de spécifique à rclone ici : il s’agit d’utiliser le client Dropbox habituel (application de bureau) pour synchroniser sélectivement les dossiers voulus sur un disque, idéalement externe pour ne pas saturer le disque principal.

Point de vigilance avant de désactiver ensuite la synchronisation Dropbox : le client Dropbox traite le contenu synchronisé comme un simple reflet du cloud. Décocher un dossier dans la synchronisation sélective supprime les fichiers correspondants en local, sans avertissement particulier. Il faut donc s’assurer que la copie de sécurité (le disque externe, dans ce cas) est bien complète et vérifiée avant de toucher à quoi que ce soit côté Dropbox.

Étape 2 : monter le disque sur le serveur Linux

lsblk

Cette commande liste les périphériques de stockage connectés, pour repérer le nouveau disque (généralement /dev/sdX, où X est une lettre).

sudo blkid /dev/sda1

Vérifie le système de fichiers du disque. Pour un disque formaté sous Windows, ce sera le plus souvent ntfs.

sudo apt install ntfs-3g
sudo mkdir -p /mnt/disque-externe
sudo mount /dev/sda1 /mnt/disque-externe

Si le disque n’a pas été démonté proprement avant d’être débranché (ça arrive), un message de ce type peut apparaître au montage :

The disk contains an unclean file system (0, 0).
The file system wasn't safely closed on Windows. Fixing.

Pas d’inquiétude : c’est le mécanisme de correction automatique de ntfs-3g, qui répare les petites incohérences avant de monter le disque.

Étape 3 : exclure ce qui ne doit pas partir vers le cloud

Avant de tout copier, il vaut mieux vérifier le contenu à la racine du disque. Il n’est pas rare d’y trouver des fichiers isolés qui n’ont rien à faire dans une migration cloud : mots de passe en clair, clés privées, bases de données de gestionnaire de mots de passe. Un fichier de filtre permet d’exclure ce type d’éléments proprement :

cat > /home/user/exclude-disque-externe.txt << 'EOF'
/$RECYCLE.BIN/**
/System Volume Information/**
/.dropbox
/.dropbox.cache/**
/.dropbox.device
/desktop.ini
/cle-ssh-ancienne.pem
/mots-de-passe.kdbx
EOF

Chaque ligne commençant par / cible un élément à la racine du dossier source, ** couvrant tout le contenu d’un dossier.

Étape 4 : transférer vers Google Drive

nohup rclone copy /mnt/disque-externe gdrive:/NOUVEAU-DOSSIER --exclude-from /home/user/exclude-disque-externe.txt --transfers 12 --checkers 16 --fast-list --log-file=/home/user/rclone-disque-externe.log &

Différence notable avec la tentative initiale : la concurrence est ici volontairement élevée (12 transferts, 16 vérificateurs), parce que la destination est Google Drive, qui tolère bien mieux ce type de charge que Dropbox. Le débit obtenu avec cette méthode a dépassé 2 Mio/s en continu, contre 79 à 143 KiB/s lors des essais directs Dropbox vers Google Drive, soit un facteur supérieur à 15.

Le nohup ... & en début de commande permet de fermer la session SSH ou d’éteindre le poste depuis lequel elle a été lancée, sans interrompre le transfert sur le serveur.

Étape 5 : vérifier l’intégrité du transfert

rclone check /mnt/disque-externe gdrive:/NOUVEAU-DOSSIER --exclude-from /home/user/exclude-disque-externe.txt --one-way --fast-list

--fast-list réduit fortement le nombre de requêtes nécessaires pour parcourir l’arborescence de destination, un point important : sans cette option, la vérification d’un grand nombre de dossiers peut elle-même déclencher une limitation de l’API Google (erreur 403 Quota exceeded, avec la mention RATE_LIMIT_EXCEEDED). Ce paramètre fonctionne côté Google Drive, mais pas côté Dropbox, qui ne le prend pas en charge (rclone l’ignore silencieusement s’il est utilisé sur un remote Dropbox).

Résultat attendu en cas de succès :

NOTICE: Google drive root 'NOUVEAU-DOSSIER': 0 differences found
NOTICE: Google drive root 'NOUVEAU-DOSSIER': 55653 matching files

Deux pièges annexes, utiles à connaître

Un dossier de destination qui n’est pas à la racine attendue. Si le remote gdrive: a été configuré pour un autre usage au préalable (une sauvegarde automatisée, par exemple), il peut pointer vers un sous-dossier précis plutôt que vers la racine réelle du Drive, via un paramètre caché nommé root_folder_id. Un dossier créé avec gdrive:/MonDossier peut alors atterrir plusieurs niveaux plus bas que prévu, invisible à première vue dans l’interface web. Pour vérifier :

rclone config show gdrive

La présence d’une ligne root_folder_id confirme ce comportement.

Deux configurations rclone distinctes, deux dossiers distincts. Autoriser rclone sur deux machines différentes (un serveur et Cloud Shell, par exemple) crée deux configurations indépendantes. Si elles ne pointent pas vers le même compte Google, ou si l’une a un root_folder_id différent de l’autre, un même nom de dossier de destination peut désigner deux emplacements complètement différents. Google Drive autorisant les doublons de noms, l’interface web peut alors sembler afficher un contenu incohérent selon le moment où elle est consultée. En cas de doute, mieux vaut vérifier directement avec rclone lsd et rclone size plutôt que de se fier au rendu de l’interface, qui peut aussi simplement mettre du temps à se rafraîchir.

Ce qu’on ferait différemment en repartant de zéro

• Mesurer la structure du contenu avant de choisir une méthode (rclone size, rclone lsd) : beaucoup de petits fichiers oriente d’emblée vers un passage par disque local, peu de fichiers volumineux se prête bien à un transfert direct.
• Vérifier le root_folder_id du remote gdrive: avant le premier transfert.
• Protéger systématiquement toute commande longue avec nohup dès le premier lancement, pas après une mauvaise surprise.
• Exclure les fichiers sensibles ou indésirables avant de copier, pas après avoir découvert le mélange.
• Toujours vérifier avec rclone check --fast-list en fin de transfert, jamais se contenter d’une comparaison de volumes ou de comptage de fichiers.

Pour aller plus loin

Cet article fait partie de la série projets Ubuntu, qui documente les projets techniques menés sur mon infrastructure Linux personnelle.