Exporter des fichiers vers Wasabi avec rclone

Kevin van Zonneveld

Cofondateur · Amsterdam, Pays-Bas · Afficher la bio

Utilisez rclone copy pour exporter un répertoire local vers Wasabi tout en conservant les fichiers qui existent déjà uniquement à la destination. Utilisez ensuite rclone check --download --one-way pour comparer les octets téléversés avec vos fichiers locaux. Cette procédure choisit un bucket privé et un préfixe spécifique, prévisualise le transfert, puis transforme les mêmes commandes en une exportation reproductible.

Choisir un bucket et vérifier les coûts

Vous avez besoin d’un compte Wasabi, d’un bucket privé existant, de sa région de stockage et de clés d’accès autorisées à lister, téléverser et lire des objets dans le préfixe choisi. Si vous n’avez pas de bucket, créez-en d’abord un dans la console Wasabi. Laissez l’accès public désactivé. La configuration d’un remote rclone ne crée pas de bucket ; les commandes ci-dessous utilisent délibérément un bucket existant.

Wasabi expose une API compatible S3. Sa tarification standard Pay-Go impose un minimum mensuel de 1 TB et une durée de stockage minimale de 90 jours ; supprimer des objets plus tôt peut entraîner des frais pour les jours restants. Le trafic sortant (egress) gratuit est prévu pour des téléchargements mensuels ne dépassant pas votre volume de stockage actif, et des dépassements répétés peuvent entraîner des limitations ou une suspension du service. Les requêtes API gratuites sont également soumises à une politique d’utilisation raisonnable. Comparez la FAQ tarifaire de Wasabi⁠ avec votre forfait avant de téléverser des données de test. Une toute petite exportation n’implique pas une toute petite facture mensuelle.

Configurer rclone pour Wasabi

Installation

Installez rclone en suivant ses instructions d’installation officielles⁠, puis vérifiez la version :

rclone version

Les exemples shell utilisent Bash sous Linux. Les commandes de transfert ont été testées avec rclone 1.75.1 sur un service local compatible S3 ; cela ne vérifie ni les permissions d’un compte Wasabi réel ni sa connectivité régionale. Ne modifiez pas le répertoire source pendant la copie et la vérification. Ces exemples exportent des fichiers ordinaires, et non une sauvegarde complète du système de fichiers avec ses permissions et ses liens symboliques.

Configuration

Lancez la configuration interactive :

rclone config

Utilisez ces valeurs, en suivant le guide de configuration rclone de Wasabi⁠. Saisissez les valeurs du backend et du fournisseur plutôt que de vous fier aux numéros de menu, qui peuvent changer :

1. Créez un remote nommé wasabi.
2. Définissez le backend de stockage sur s3, puis le fournisseur sur Wasabi.
3. Définissez env_auth sur false et saisissez votre clé d’accès et votre clé secrète Wasabi aux invites. Les invites les appellent identifiants AWS, car il s’agit du backend S3.
4. Laissez region vide comme dans le guide de Wasabi, et définissez endpoint sur l’URL du service correspondant à la région réelle de votre bucket.
5. Laissez location_constraint vide pour ce bucket existant. Ce paramètre sert lors de la création de buckets.
6. Définissez acl sur private, laissez les autres options à leurs valeurs par défaut, puis enregistrez le remote.

Par exemple, US East 1 accepte s3.us-east-1.wasabisys.com ou s3.wasabisys.com ; Amsterdam utilise s3.eu-central-1.wasabisys.com. Faites correspondre l’emplacement du bucket au tableau des points de terminaison de Wasabi⁠. L’URL de la console n’est pas un point de terminaison S3. Une ACL d’objet privée n’annule pas une politique de bucket publique.

Considérations de sécurité

Gardez les identifiants hors des scripts et des arguments de commandes shell. Trouvez le fichier de configuration réellement utilisé avec :

rclone config file

Restreignez l’accès à ce fichier et à ses sauvegardes. Pour les tâches planifiées, utilisez un chemin de configuration explicite via RCLONE_CONFIG ou --config ; consultez la documentation de configuration⁠ de rclone. Utilisez une identité Wasabi dédiée dont l’accès est limité au bucket/préfixe prévu. Une tâche de copie n’a pas besoin de l’autorisation de supprimer des objets de destination. Le miroir facultatif présenté plus loin dans cet article, lui, en a besoin.

Copier un répertoire et vérifier son contenu

Copier les fichiers

Dans une même session Bash, définissez un chemin source local absolu et remplacez le nom du bucket ci-dessous. Utilisez un préfixe réservé à cette exportation, tel que exports/project-a, plutôt que la racine du bucket :

src='/absolute/path/to/export'
dst='wasabi:your-existing-bucket/exports/project-a'
rclone lsf "$dst" --recursive

Une liste vide peut indiquer un nouveau préfixe ; un code de sortie non nul signifie que vous devez résoudre l’erreur avant de continuer. Prévisualisez les fichiers sélectionnés sans les téléverser :

rclone copy "$src" "$dst" --s3-no-check-bucket --checksum --exclude '*.tmp' --dry-run

L’option --s3-no-check-bucket⁠ empêche rclone de vérifier l’existence d’un bucket ou d’essayer d’en créer un. Un nom de bucket mal orthographié échoue tout de même lors de l’accès. --checksum compare la taille et les sommes de contrôle disponibles pour décider s’il faut remplacer un fichier. copy conserve les objets présents uniquement à la destination, mais peut écraser un objet existant portant le même nom. Il ne s’agit pas d’une sauvegarde versionnée. Consultez la référence de la commande copy⁠.

Lorsque la prévisualisation affiche la source et le préfixe prévus, lancez la copie, puis la vérification :

rclone copy "$src" "$dst" --s3-no-check-bucket --checksum --exclude '*.tmp' &&
  rclone check "$src" "$dst" --download --one-way --exclude '*.tmp'

Le contenu du répertoire est placé directement dans le préfixe : report.pdf devient exports/project-a/report.pdf, sans répertoire export/ supplémentaire. Les répertoires vides ne deviennent pas des objets. Une source vide peut se terminer avec succès sans rien transférer ; vérifiez que vous avez sélectionné les fichiers attendus.

Relire les octets téléversés

check --download⁠ lit les données distantes et les compare aux fichiers locaux. Cette commande ne s’appuie pas uniquement sur les métadonnées des objets ni sur les ETags. --one-way autorise les fichiers supplémentaires à la destination, conformément à la politique de copie. La même exclusion doit figurer dans les deux commandes.

En cas de succès, les fichiers source inclus correspondent à leurs équivalents distants au moment de la vérification. Une différence, un objet manquant ou une erreur de lecture produit un code de sortie non nul. La vérification télécharge les objets inclus ; prévoyez donc du temps et de la bande passante, et tenez compte de ce trafic au regard de la politique de trafic sortant de Wasabi. Pour une source non vide, attendez-vous à un nombre de fichiers correspondants et à aucune différence.

Ajuster ce qui est transféré

Filtrer les fichiers

Le motif --exclude '*.tmp' entre guillemets ignore les fichiers temporaires à n’importe quelle profondeur. Les guillemets empêchent Bash d’étendre le motif avant que rclone ne le reçoive. Exclure un fichier de copy laisse intacte toute copie distante existante. Si vous modifiez la sélection, appliquez le même filtre⁠ à la prévisualisation, à la copie et à la vérification.

Transferts parallèles

Par défaut, rclone effectue quatre transferts de fichiers simultanés. Ajoutez --transfers=8 à la commande de copie si des mesures montrent que cela profite à votre charge de travail ; une concurrence plus élevée peut aussi augmenter la consommation de ressources. Consultez l’option --transfers⁠.

Contrôle de la bande passante

Ajoutez --bwlimit=10M pour plafonner la bande passante de transfert à 10 MiB/s. Appliquez-le également à la vérification par téléchargement si celle-ci doit respecter la même limite. La documentation sur la bande passante⁠ de rclone couvre aussi les plannings.

Répéter l’exportation vérifiée

Enregistrez ce script sous export-to-wasabi.sh. Il accepte la même source et la même destination que les commandes manuelles, rejette un répertoire source manquant et s’arrête si la copie ou la vérification échoue :

#!/usr/bin/env bash
set -euo pipefail

src=${1:?Pass a local source directory}
dst=${2:?Pass a wasabi:bucket/prefix destination}

if [[ ! -d "$src" ]]; then
  printf 'Source directory does not exist: %s\n' "$src" >&2
  exit 1
fi

rclone copy "$src" "$dst" --s3-no-check-bucket --checksum --exclude '*.tmp'
rclone check "$src" "$dst" --download --one-way --exclude '*.tmp'

Exécutez-le avec les chemins déjà sélectionnés :

bash ./export-to-wasabi.sh "$src" "$dst"

Pour un planificateur, fournissez des chemins absolus vers Bash, le script, la source et le fichier de configuration. Assurez-vous que rclone figure dans le PATH de la tâche, capturez sa sortie et considérez un code de sortie non nul comme un échec de l’exportation. Évitez les exécutions qui se chevauchent. Une nouvelle exécution peut remplacer les fichiers modifiés, mais les fichiers supprimés localement restent dans le bucket. Ne planifiez ce script de copie que si ce comportement de conservation correspond à vos besoins.

Synchroniser les fichiers

N’utilisez un miroir que lorsque les fichiers présents uniquement à la destination doivent être supprimés. Avec les mêmes src et dst, rclone sync⁠ ne modifie que le préfixe de destination choisi. S’il contient old-report.pdf qui est absent localement, copy le conserve et sync le supprime. Les objets situés hors de exports/project-a/ sont hors de la portée de cette commande.

Prévisualisez le miroir séparément :

rclone sync "$src" "$dst" --s3-no-check-bucket --checksum --exclude '*.tmp' --dry-run

Lisez les suppressions prévues et revérifiez les deux chemins. Une source existante mais vide peut supprimer tous les objets inclus dans le préfixe de destination. Les objets .tmp exclus restent en place, car cette commande n’utilise pas --delete-excluded. Une prévisualisation ne fige ni la source ni la destination.

Uniquement si ces suppressions sont intentionnelles, exécutez :

rclone sync "$src" "$dst" --s3-no-check-bucket --checksum --exclude '*.tmp'

Cette opération nécessite l’autorisation de suppression. Les paramètres de rétention des objets peuvent bloquer la suppression, et la durée de stockage minimale de Wasabi peut entraîner des frais après la suppression. Gardez ce choix distinct du script d’exportation sans suppression.

Diagnostiquer un échec d’exportation

Problèmes courants

• Accès refusé : vérifiez les identifiants et les permissions pour ce bucket/préfixe. Une liste réussie n’établit pas l’autorisation de téléverser ou de télécharger. Lister tous les buckets avec rclone lsd wasabi: peut être refusé même lorsque l’accès à votre bucket choisi fonctionne.
• Mauvais point de terminaison ou erreurs de signature : comparez le point de terminaison du remote avec la région du bucket et vérifiez l’horloge de la machine. Une réinitialisation de connexion ne suffit pas à elle seule à identifier une incohérence de région.
• Configuration manquante dans une tâche : exécutez-la avec le chemin RCLONE_CONFIG ou --config prévu et vérifiez que l’utilisateur de la tâche peut le lire.
• Différences lors de la vérification : gardez les fichiers source stables, vérifiez que les deux commandes utilisent les mêmes filtres et examinez les noms de fichiers signalés avant d’accepter l’exportation.

Débogage

Ajoutez -v à la commande qui échoue pour obtenir des informations au niveau des fichiers. Utilisez -vv pour la journalisation de débogage si nécessaire, et masquez les identifiants, les chemins sensibles et les noms d’objets avant de partager des journaux. Une simulation (dry run) vérifie les actions prévues ; elle ne prouve pas que Wasabi autorisera les écritures ultérieures.

Si vous devez exporter les résultats d’un flux de travail Transloadit, consultez le Robot 🤖 /wasabi/store EN (English) de notre service d’exportation de fichiers.