rclone : copier, synchroniser et migrer des fichiers entre clouds

Ce qu'est rclone, et ce pour quoi il est bon

rclone est un programme en ligne de commande gratuit et open source pour copier, synchroniser et déplacer des fichiers entre votre disque et un stockage cloud, ou entre deux clouds. On l'appelle souvent « rsync pour le stockage cloud » : un seul binaire, écrit en Go, qui parle plus de 70 backends de stockage, dont Amazon S3 et tous les services compatibles S3, Google Drive, OneDrive, Dropbox, Azure Blob, Backblaze B2, SFTP et WebDAV.

L'idée qui le rend utile est le remote. Vous décrivez chaque compte de stockage une seule fois, lui donnez un nom court comme s3old ou gdrive, et à partir de là chaque commande fonctionne de la même façon avec n'importe lequel d'entre eux : rclone copy ./backups s3old:my-bucket/backups se lit exactement comme rclone copy gdrive:Photos ./photos. Un chemin est remote:chemin, et pour le stockage objet, la première partie du chemin est le bucket.

En pratique, rclone est utilisé pour quatre tâches : les sauvegardes nocturnes vers un stockage objet, les migrations ponctuelles d'un fournisseur à un autre, l'extraction de fichiers depuis Google Drive ou d'autres clouds grand public, et le montage d'un bucket comme s'il s'agissait d'un dossier local. Il compare les fichiers avant de les transférer, donc une seconde exécution n'envoie que ce qui a changé, retente les opérations échouées, et peut tout chiffrer côté client avant que ça ne quitte la machine.

Ce qu'il n'est pas : un client de synchronisation bidirectionnelle comme l'application Dropbox (la commande plus récente bisync existe, mais c'est un outil délibéré, pas un service en arrière-plan), ni un programme de sauvegarde avec snapshots dédupliqués. Pour des sauvegardes versionnées et dédupliquées, des outils comme restic utilisent rclone comme transport sous-jacent.

Installer rclone sous Linux, macOS et Windows

rclone est un exécutable unique sans dépendances, donc l'installer revient surtout à choisir d'où vient le binaire. Les paquets des distributions (apt install rclone) sont souvent en retard de plusieurs versions ; pour tout ce qui parle aux API cloud actuelles, préférez la version officielle.

Linux et macOS : le script d'installation du projet télécharge la dernière version pour votre plateforme et la place dans /usr/bin (ou /usr/local/bin sous macOS). Sous macOS, Homebrew fonctionne aussi, mais la version Homebrew ne peut pas exécuter rclone mount ; si vous avez besoin du montage, utilisez le binaire officiel avec macFUSE.

Windows : winget install Rclone.Rclone est le moyen le plus rapide ; Scoop et Chocolatey le proposent aussi. Sans gestionnaire de paquets, téléchargez le zip depuis rclone.org/downloads, décompressez rclone.exe dans un dossier tel que C:\rclone, et ajoutez ce dossier à votre PATH. Exécutez-le depuis PowerShell ou cmd ; il n'a ni installeur ni interface graphique propre. Pour utiliser rclone mount sous Windows, vous avez aussi besoin de WinFsp.

Vérifiez le résultat avec rclone version. Un binaire installé depuis la version officielle peut se mettre à jour lui-même plus tard avec rclone selfupdate ; un binaire packagé doit être mis à jour via son gestionnaire de paquets.

# Linux / macOS: official install script
sudo -v ; curl https://rclone.org/install.sh | sudo bash

# macOS with Homebrew (no rclone mount support)
brew install rclone

# Windows (PowerShell)
winget install Rclone.Rclone

# everywhere
rclone version

rclone config et le concept de remote

rclone config démarre un assistant interactif : n pour un nouveau remote, un nom, le type de stockage, puis les questions que ce type nécessite (clés, endpoint, région, ou une connexion via navigateur pour Google Drive et d'autres services OAuth). Les réponses sont écrites dans un fichier INI simple, rclone.conf. rclone config file affiche son emplacement : généralement ~/.config/rclone/rclone.conf sous Linux et macOS, et %APPDATA%\rclone\rclone.conf sous Windows.

Comme c'est un simple fichier texte, vous pouvez aussi écrire des remotes à la main, copier le fichier sur un serveur, ou le garder dans votre outillage de secrets. Traitez-le comme un secret : il contient des clés d'accès et des jetons OAuth. Les secrets que rclone écrit lui-même sont seulement masqués, pas chiffrés ; rclone config propose un mot de passe de configuration si le fichier doit résider sur une machine partagée.

Chaque [section] est un remote. Vous l'adressez ensuite comme name: suivi d'un chemin. Avec le stockage objet, name: seul désigne le compte, name:bucket un bucket et name:bucket/prefix un « dossier » à l'intérieur. rclone lsd name: est le test le plus rapide pour vérifier que les clés et l'endpoint fonctionnent.

Le fichier n'est pas la seule méthode. Chaque option peut venir d'une variable d'environnement nommée RCLONE_CONFIG_<REMOTE>_<OPTION>, ce qui convient aux conteneurs et à la CI où vous préférez injecter des secrets plutôt que livrer un fichier de configuration.

Deux remotes dans rclone.conf : AWS S3 et Google Drive

[s3old]
type = s3
provider = AWS
access_key_id = AKIA...
secret_access_key = ...
region = eu-central-1

[gdrive]
type = drive
scope = drive.readonly
token = {"access_token":"...","expiry":"..."}

# the same S3 remote from environment variables instead
# RCLONE_CONFIG_S3OLD_TYPE=s3
# RCLONE_CONFIG_S3OLD_PROVIDER=AWS
# RCLONE_CONFIG_S3OLD_ACCESS_KEY_ID=AKIA...

Les commandes principales, et copy contre sync

rclone copy copie les fichiers de la source vers la destination et ignore les fichiers déjà identiques là-bas. Il ne supprime jamais rien à la destination, ce qui en fait le choix sûr par défaut.

rclone sync rend la destination identique à la source, ce qui inclut la suppression des fichiers de destination absents de la source. Pointez-le vers le mauvais dossier, ou inversez source et destination, et il supprimera des données, et le stockage objet n'a pas de corbeille sauf si le versioning est activé. Lancez toujours une nouvelle commande sync avec --dry-run d'abord, lisez ce qu'elle supprimerait, et seulement ensuite exécutez-la pour de vrai. --max-delete 100 est une ceinture de sécurité utile pour les tâches planifiées : l'exécution s'arrête plutôt que de supprimer plus que ce chiffre.

rclone move copie puis supprime chaque fichier de la source une fois arrivé ; ajoutez --delete-empty-src-dirs pour nettoyer aussi les dossiers. rclone check compare source et destination et signale les différences sans rien changer (plus de détails ci-dessous).

Pour regarder autour : rclone lsd remote: liste les buckets ou répertoires, rclone ls remote:bucket liste chaque objet avec sa taille, rclone lsf donne une liste adaptée aux scripts, et rclone size remote:bucket affiche le nombre d'objets et le total d'octets, le premier chiffre à comparer après une migration. rclone tree et rclone ncdu aident quand vous devez voir où va l'espace.

Un comportement fait trébucher presque tout le monde : comme rsync avec une barre oblique finale, rclone copie le contenu du répertoire source, pas le répertoire lui-même. rclone copy ./photos remote:bucket place les fichiers à la racine du bucket ; écrivez remote:bucket/photos si vous voulez le dossier. Pour copier ou renommer un seul fichier, utilisez copyto ou moveto.

rclone lsd s3old:                       # buckets this key can see
rclone ls s3old:media/2026/             # objects and sizes
rclone size s3old:media                 # count + total bytes

rclone copy ./site s3old:media/site -P  # upload, never deletes
rclone sync ./site s3old:media/site --dry-run   # preview first
rclone sync ./site s3old:media/site -P  # then for real

rclone move ./outbox s3old:media/inbox --delete-empty-src-dirs
rclone copyto ./logo.png s3old:media/img/logo-v2.png

Les options qui comptent : dry run, vitesse et bande passante

--dry-run (-n) montre ce qui serait copié ou supprimé sans rien toucher. --interactive (-i) demande confirmation avant chaque action destructrice, pratique pour un nettoyage ponctuel.

--progress (-P) affiche le débit en direct, les comptes et l'ETA. Pour les tâches qui s'exécutent sans surveillance, utilisez plutôt --log-file rclone.log --log-level INFO, pour pouvoir lire ensuite ce qui s'est passé.

--transfers (4 par défaut) indique combien de fichiers se déplacent en parallèle, et --checkers (8 par défaut) combien de comparaisons s'exécutent en parallèle. Le stockage objet est lent par requête et rapide en agrégat, donc beaucoup de petits fichiers bénéficient de --transfers 16 à 32 et --checkers 32 ou plus. Augmentez-les progressivement : les fournisseurs limitent le débit, et trop de requêtes parallèles se transforment en nouvelles tentatives.

--bwlimit limite la bande passante, par exemple --bwlimit 20M (octets par seconde, donc 20 Mio/s), ou un planning tel que --bwlimit "08:00,10M 19:00,off" qui bride pendant les heures de bureau et tourne librement la nuit.

--s3-chunk-size (5 Mio par défaut) définit la taille des parties des envois multipart, et --s3-upload-concurrency (4 par défaut) combien de parties d'un même fichier s'envoient en même temps. Pour de gros fichiers sur une liaison rapide, --s3-chunk-size 64M réduit considérablement le nombre de requêtes. L'usage mémoire croît avec transfers × upload-concurrency × chunk-size, donc un chunk de 64 Mio avec 16 transfers peut consommer plusieurs gigaoctets de RAM. S3 autorise au plus 10 000 parties par objet ; rclone augmente lui-même la taille de chunk quand il connaît la taille d'un fichier, mais pas pour les envois en flux (rcat).

Pour les buckets avec des millions d'objets, --fast-list liste tout le bucket en moins de requêtes au prix de la mémoire, et --checksum ou --size-only empêchent rclone de lire la date de modification de chaque objet, ce qui sur S3 coûte une requête supplémentaire par objet.

rclone copy /srv/backups s3old:backups/db \
  --transfers 16 --checkers 32 \
  --s3-chunk-size 64M --s3-upload-concurrency 4 \
  --bwlimit "08:00,20M 20:00,off" \
  --log-file /var/log/rclone-backup.log --log-level INFO

Configurer un remote compatible S3, avec CDN.com.tr comme exemple

Tout service qui implémente l'API S3 utilise le type s3 de rclone. Les champs qui changent d'un fournisseur à l'autre sont provider, endpoint et parfois region. Utilisez le fournisseur nommé quand rclone en a un (AWS, Cloudflare, Minio, Wasabi et d'autres) ; il active les particularités de ce service. Pour un service que rclone ne liste pas, utilisez provider = Other.

Le stockage objet de CDN.com.tr est compatible S3, et rclone est l'un des clients qui fonctionnent avec tel quel. L'endpoint est https://s3.cdn.com.tr ; les outils qui demandent une région peuvent rester sur la valeur par défaut, et le service attend un adressage de style chemin (path-style), qui est le comportement par défaut de rclone pour provider = Other. Les buckets et clés d'accès se créent dans le panneau (l'onglet Access Keys) ou avec cdnctl. La clé secrète n'est affichée qu'une seule fois, à la création, donc copiez-la directement dans la configuration rclone ou votre gestionnaire de secrets.

Les clés sont mieux limitées au bucket qu'elles servent. Une clé de ce type n'est pas autorisée à créer des buckets, donc dites à rclone de ne pas essayer : no_check_bucket = true ignore la vérification de création de bucket que rclone effectue sinon avant l'envoi. Pour la même raison, testez une clé limitée à un bucket avec rclone lsd cdntr:my-bucket plutôt qu'en listant tout le compte.

cdnctl gère ici le plan de contrôle : buckets, clés et liaisons vers les applications conteneurisées. Lire et écrire les objets eux-mêmes est le travail d'un client S3 tel que rclone. (La commande séparée cdnctl cp envoie vers le stockage de fichiers du CDN, qui est un produit différent ; voir CDN file storage.)

rclone.conf : un remote de stockage objet CDN.com.tr

[cdntr]
type = s3
provider = Other
access_key_id = <access key from the panel>
secret_access_key = <secret, shown once at creation>
endpoint = https://s3.cdn.com.tr
no_check_bucket = true

# test it
# rclone lsd cdntr:my-bucket
# rclone copy ./smoke.txt cdntr:my-bucket/ -v

Migrer entre fournisseurs : R2, B2 ou AWS S3 vers un autre S3

Une migration entre deux services S3, c'est deux remotes et une commande. rclone liste les deux côtés, les compare et copie ce qui manque, donc vous pouvez relancer la même commande plusieurs fois : la première exécution déplace le gros volume, les suivantes ne traitent que les changements, et l'exécution finale pendant votre bascule est courte.

Les données passent par la machine qui exécute rclone : elle télécharge depuis la source et envoie vers la destination. Exécutez-la sur un serveur avec une bonne bande passante vers les deux côtés plutôt que sur un ordinateur portable, et vérifiez d'abord la tarification de sortie du fournisseur source. AWS facture le transfert sortant, Backblaze B2 inclut une sortie gratuite jusqu'à un multiple de ce que vous stockez, et Cloudflare R2 ne facture rien pour la sortie. La copie côté serveur ne se produit qu'au sein d'un même fournisseur.

Les réglages qui rendent les grosses migrations plus rapides et moins coûteuses : --fast-list pour réduire les requêtes de listing, --checksum pour que rclone compare les tailles et les hachages au lieu de récupérer les dates de modification objet par objet, et des --transfers et --checkers plus élevés si la source le permet. Commencez par copy, pas sync, pour qu'une erreur ne puisse rien supprimer ; passez à sync (avec --dry-run d'abord) seulement pour la dernière passe si des objets ont été supprimés côté source en attendant.

Pour Backblaze B2, vous pouvez utiliser soit le type natif b2 de rclone, soit l'endpoint S3 de B2 ; les deux fonctionnent. Les clés R2 se créent dans le tableau de bord Cloudflare, et son endpoint contient votre identifiant de compte. Nos pages de comparaison détaillent ces migrations : Cloudflare R2 alternative, Backblaze B2 alternative et IDrive e2 alternative. Côté application, seules l'endpoint et les clés changent.

# rclone.conf (source)
[r2]
type = s3
provider = Cloudflare
access_key_id = ...
secret_access_key = ...
endpoint = https://<ACCOUNT_ID>.r2.cloudflarestorage.com
region = auto

# 1. preview, 2. bulk copy, 3. repeat until the delta is small
rclone copy r2:media cdntr:media --dry-run
rclone copy r2:media cdntr:media \
  --fast-list --checksum --transfers 32 --checkers 64 -P

# cutover: stop writes, final pass, then compare
rclone sync r2:media cdntr:media --fast-list --checksum -P
rclone check r2:media cdntr:media --one-way

Vérifier une migration avec rclone check

rclone check source: dest: compare les deux côtés objet par objet et affiche un résumé : combien de fichiers correspondent, combien diffèrent, et lesquels n'existent que d'un seul côté. Cela ne change rien. --one-way ne recherche que les fichiers source manquants ou différents à la destination, ce que vous voulez quand la destination a déjà des données supplémentaires.

La comparaison utilise les tailles et, quand les deux côtés partagent un type de hachage, les hachages. Sur S3, ce hachage est le MD5, et voici le piège : un objet envoyé en plusieurs parties a un ETag qui n'est pas son MD5. rclone stocke le vrai MD5 dans les métadonnées de l'objet quand il envoie lui-même des fichiers multipart, mais les objets écrits par d'autres outils n'en ont souvent aucun, donc pour ceux-là check ne peut comparer que les tailles et le signale dans sa sortie (« hashes could not be checked »). Quand vous avez besoin d'une certitude octet par octet, --download lit les deux copies et compare le contenu, au prix de tout retransférer.

Pour des rapports que vous pouvez conserver, écrivez les listes dans des fichiers avec --combined, --missing-on-dst et --differ. Comparez rclone size des deux côtés comme vérification de bon sens finale, et pour un remote chiffré utilisez rclone cryptcheck, qui vérifie la copie chiffrée par rapport à la source en clair.

rclone size r2:media && rclone size cdntr:media

rclone check r2:media cdntr:media --one-way \
  --combined check-report.txt \
  --missing-on-dst missing.txt --differ differ.txt

# slow but exact: download and compare the bytes
rclone check r2:media cdntr:media --download

Google Drive, chiffrement et montage, en bref

Google Drive. Choisissez drive dans rclone config, sélectionnez une portée (drive.readonly suffit pour télécharger), et approuvez l'accès dans le navigateur. Sur un serveur sans navigateur, répondez n à la config automatique et exécutez rclone authorize "drive" sur une machine qui en a un, puis collez le jeton en retour. L'ID client intégré de rclone est partagé par tous les utilisateurs et subit une limitation de débit ; pour un usage intensif, créez votre propre client OAuth dans Google Cloud et saisissez-le pendant la configuration. Les fichiers Google Docs ne sont pas de vrais fichiers, donc rclone les exporte (vers docx, xlsx, etc.) lors du téléchargement. Google limite aussi les envois à environ 750 Go par utilisateur par jour, donc une grosse migration *vers* Drive prend plusieurs jours.

Chiffrement. Un remote crypt enveloppe un autre remote et chiffre le contenu des fichiers, et optionnellement les noms, avant l'envoi. Vous le créez par-dessus, disons, cdntr:backups, puis écrivez via le remote crypt ; le fournisseur ne voit jamais que du texte chiffré. Le mot de passe et le sel vivent dans votre rclone.conf : perdez-les et les données sont irrécupérables, sauvegardez-les donc séparément des données.

Montage. rclone mount remote:bucket /mnt/bucket fait ressembler un bucket à un dossier (sous Windows, montez sur une lettre de lecteur telle que X: avec WinFsp installé). Ajoutez --vfs-cache-mode writes ou full pour que les applications qui réécrivent des fichiers fonctionnent correctement. Un montage convient pour parcourir, les bibliothèques multimédias et les lectures occasionnelles ; ce n'est pas un disque, donc n'y mettez pas de bases de données ou quoi que ce soit ayant besoin de verrouillage de fichiers.

Télécharger depuis Drive ; ajouter un remote chiffré par-dessus un bucket

rclone copy gdrive:Projects ./projects -P

# rclone.conf: encrypted backups inside an existing bucket remote
[secure]
type = crypt
remote = cdntr:backups/encrypted
filename_encryption = standard
password = <obscured by rclone config>
password2 = <obscured by rclone config>

rclone copy /srv/backups secure: -P

Planifier rclone : cron, systemd et Task Scheduler

rclone n'a pas de planificateur propre ; il est fait pour être exécuté par un autre. Sous Linux, une entrée cron suffit pour la plupart des tâches. Enveloppez la commande dans flock pour qu'une exécution lente ne se superpose pas à la suivante, journalisez dans un fichier, et faites pointer --config vers un chemin explicite, car cron s'exécute avec un HOME différent et ne trouverait sinon pas vos remotes.

Pour un sync qui supprime, ajoutez les ceintures de sécurité : --max-delete pour arrêter une exécution qui supprimerait bien plus que d'habitude, et --backup-dir pour déplacer les fichiers écrasés et supprimés dans un dossier daté au lieu de les perdre. Le code de sortie de rclone est 0 en cas de succès et non nul en cas d'échec, donc le script wrapper ou l'unité systemd peut déclencher une alerte ; une tâche qui échoue silencieusement depuis un mois est la façon habituelle dont les sauvegardes échouent.

Sur les machines systemd, un service plus un timer vous donne la journalisation dans le journal et Persistent=true, qui exécute une tâche manquée après un redémarrage. Sous Windows, créez une tâche Task Scheduler qui exécute rclone.exe avec le chemin complet de la config et un fichier de log, sous un compte ayant accès à la fois aux fichiers et à la config.

# crontab -e  (02:30 every night)
30 2 * * * flock -n /tmp/rclone-backup.lock \
  rclone sync /srv/backups cdntr:backups/nightly \
  --config /home/backup/.config/rclone/rclone.conf \
  --max-delete 200 \
  --backup-dir cdntr:backups/deleted/$(date +\%F) \
  --log-file /var/log/rclone-backup.log --log-level INFO