Aller au contenu

AWS Mis à jour le 2026-07-04

aws s3 sync et cp : les patrons CLI que les opérateurs utilisent vraiment

Les patrons aws s3 sync et aws s3 cp qui tiennent la route en production — essais à blanc, suppressions sécuritaires, ordre des filtres exclude/include, flux en continu, classes de stockage, et le réglage des transferts qui change vraiment quelque chose.

aws s3 cp copie ce que vous lui pointez; aws s3 sync compare la source et la destination et ne copie que ce qui diffère — par taille et par date de modification, pas par empreinte de contenu. Sync ne supprime jamais rien à moins de recevoir --delete, et c’est ce drapeau qui transforme une coquille en panne. Les patrons ci-dessous sont ceux qui survivent au contact de la production : essai à blanc d’abord, comprendre les règles de comparaison, ordonner correctement les filtres exclude/include, et régler la concurrence avant de blâmer le réseau.

Ce qui se passe

Les deux commandes reposent sur le même moteur de transfert du CLI. Les fichiers au-dessus du seuil multipart (8 Mo par défaut) sont découpés en morceaux téléversés en parallèle; les plus petits partent entiers, plusieurs à la fois, gouvernés par max_concurrent_requests (10 par défaut). C’est ce moteur qui fait qu’un seul cp d’un fichier de 50 Go sature un lien qu’un script naïf ne saturerait jamais — et qu’une grosse copie interrompue laisse des morceaux multipart incomplets que vous continuez de payer.

La logique de comparaison de sync est la partie que les gens comprennent mal. Un fichier est copié quand les tailles diffèrent ou quand la date de modification de la source est plus récente que celle de la destination. Même taille et date égale ou plus ancienne : sauté — même si les octets ont changé. Il n’y a aucune comparaison de somme de contrôle. --size-only ignore complètement les dates (utile quand un build régénère des fichiers identiques avec des dates fraîches), et --exact-timestamps force les syncs S3-vers-local à retélécharger dès que les dates diffèrent, plutôt que seulement quand le distant est plus récent. La référence complète des drapeaux est dans la documentation S3.

Quoi vérifier d’abord

  • La direction, et ce qui doit arriver aux fichiers en trop à destination. Sync sans --delete ne fait qu’ajouter et mettre à jour; avec, la destination devient un miroir — suppressions incluses.
  • Si la destination est versionnée. Un mauvais --delete sur un compartiment versionné est récupérable; sur un compartiment non versionné, non.
  • Le nombre d’objets. Sync liste les deux côtés avant de copier; sur des millions d’objets, le listage seul prend un temps sérieux et de l’argent en requêtes.
  • Qui vous êtes. aws sts get-caller-identity avant toute action destructrice — l’accident de mauvais profil est un classique.

Comment vérifier

--dryrun imprime chaque opération sans l’exécuter, et fonctionne sur les deux commandes :

# Prévisualiser exactement ce qu'un déploiement changerait — et ce que --delete enlèverait
aws s3 sync ./dist s3://my-bucket/site/ --delete --dryrun

Confirmez ce qui a réellement atterri :

aws s3 ls s3://my-bucket/site/ --recursive --summarize | tail -2

# Vérifier au hasard les métadonnées et la classe de stockage d'un objet
aws s3api head-object --bucket my-bucket --key site/index.html

Le runbook

  1. Essai à blanc pour tout ce qui porte --delete, chaque fois. Le drapeau enlève les fichiers de destination absents de la source. Pointer sync vers la racine du compartiment au lieu d’un préfixe, avec --delete, c’est comme ça que des sites entiers disparaissent :

    aws s3 sync ./dist s3://my-bucket/site/ --delete --dryrun
aws s3 sync ./dist s3://my-bucket/site/ --delete

  2. Ordonnez les filtres exclude/include de gauche à droite — le dernier qui correspond gagne. Pour copier un seul type de fichier, excluez tout d’abord, puis ré-incluez :

    aws s3 sync ./media s3://my-bucket/media/ --exclude "*" --include "*.jpg"

    Inverser l’ordre (--include en premier) copie tout en silence.

  3. Réglez la classe de stockage au téléversement plutôt que de payer une transition plus tard :

    aws s3 cp backup.tar.gz s3://my-bucket/backups/ --storage-class STANDARD_IA

  4. Passez par le CLI en flux continu avec - pour éviter complètement le disque local. Les copies de bases de données sont le cas de tous les jours :

    mysqldump --single-transaction mydb | gzip | aws s3 cp - s3://my-bucket/dumps/mydb.sql.gz

    L’inverse (aws s3 cp s3://... -) envoie un objet vers stdout pour les restaurations.

  5. Réglez le moteur de transfert avant de blâmer la bande passante. Sur une machine qui a de la marge, monter la concurrence est souvent tout le correctif :

    aws configure set default.s3.max_concurrent_requests 20
aws configure set default.s3.multipart_chunksize 64MB

  6. Utilisez --size-only quand les dates mentent. Les checkouts CI et les étapes de build réinitialisent les dates, ce qui fait retéléverser des fichiers identiques; --size-only arrête le gaspillage (au prix de manquer les changements de contenu à taille égale).

Quand ce n’est pas la bonne approche

Sync est le mauvais outil pour des millions d’objets sur un horaire — le double listage domine le temps d’exécution; utilisez S3 Batch Operations, la réplication, ou des tâches pilotées par inventaire à la place. C’est le mauvais outil pour des décisions d’intégrité garantie, parce qu’il ne compare jamais le contenu — si les octets doivent correspondre, vérifiez les sommes de contrôle séparément. Et pour une réplication continue entre compartiments, S3 Replication le fait côté serveur sans machine au milieu.

Erreurs courantes

  • Lancer --delete contre le mauvais préfixe (ou la racine du compartiment) et refléter l’erreur instantanément — l’essai à blanc existe exactement pour ça.
  • Mettre --include avant --exclude "*" et se demander pourquoi tout a été copié — l’ordre des filtres est de gauche à droite, le dernier qui correspond gagne.
  • S’attendre à ce que sync attrape des fichiers modifiés dont la taille et la date n’ont pas changé; il compare des métadonnées, pas du contenu.
  • Lancer un sync par répertoire dans une boucle au lieu d’un seul sync avec filtres — chaque invocation repaie le coût du listage.

Garder le contrôle

  • Enveloppez les syncs de production dans un script qui fixe le profil, la région, le préfixe et une étape d’essai à blanc obligatoire.
  • Activez le versionnement sur tout compartiment qui sert de destination de sync avec --delete à portée.
  • Mettez la règle de cycle de vie d’avortement des multiparts incomplets sur les compartiments de téléversement pour que les transferts interrompus ne facturent pas éternellement.
  • Épinglez les réglages de transfert du CLI (max_concurrent_requests, multipart_chunksize) dans la config de l’automatisation elle-même plutôt que de dépendre de ce que l’hôte a.

Le CLI récompense les opérateurs qui lisent les règles de comparaison une fois et scriptent défensivement pour toujours — la plupart des désastres s3 sync ne sont qu’à un --dryrun manquant d’être des non-événements. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.