Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # AWS DataSync Problèmes de résolution des problèmes Utilisez les informations suivantes pour résoudre les AWS DataSync problèmes et les erreurs. **Topics** + [Résolution des problèmes liés aux DataSync agents](troubleshooting-datasync-agents.md) + [Résolution des problèmes liés aux DataSync emplacements](troubleshooting-storage-issues.md) + [Résolution des problèmes liés aux DataSync tâches](troubleshooting-tasks.md) + [Résolution des problèmes de vérification des données](troubleshooting-task-verification.md) + [Résolution des problèmes liés aux coûts de stockage S3 plus élevés que prévu avec DataSync](multipart-upload-policy.md) # Résolution des problèmes liés aux DataSync agents Utilisez les informations suivantes pour résoudre les problèmes liés aux AWS DataSync agents. Certains de ces problèmes peuvent inclure : + Problème de connexion à la console locale d'un agent Amazon EC2 + Impossible de récupérer la clé d'activation d'un agent + Problèmes d'activation d'un agent avec un point de terminaison de service VPC + La découverte d'un agent est hors ligne ## Comment me connecter à la console locale d'un agent Amazon EC2 ? Pour vous connecter à la console locale d'un agent Amazon EC2, vous devez utiliser SSH. Assurez-vous que le groupe de sécurité de votre instance EC2 autorise l'accès via SSH (port TCP 22). Dans un terminal, exécutez la `ssh` commande suivante pour vous connecter à l'instance : ``` ssh -i /path/key-pair-name.pem instance-user-name@instance-public-ip-address ``` + Pour*/path/key-pair-name*, spécifiez le chemin et le nom de fichier (`.pem`) de la clé privée requise pour vous connecter à votre instance. + Pour *instance-user-name*, spécifiez `admin`. + Pour*instance-public-ip-address*, spécifiez l'adresse IP publique de votre instance. ## Que signifie l'erreur « Impossible de récupérer la clé d'activation de l'agent » ? Lorsque vous activez votre DataSync agent, celui-ci se connecte au point de terminaison de service que vous spécifiez pour demander une clé d'activation. Cette erreur signifie probablement que les paramètres de sécurité de votre réseau bloquent la connexion. **Action à exécuter** Si vous utilisez un point de terminaison de service de cloud privé virtuel (VPC), vérifiez que les paramètres de votre groupe de sécurité autorisent votre agent à se connecter au point de terminaison VPC. Pour de plus amples informations sur les ports requis, veuillez consulter [Configuration réseau requise pour les points de terminaison de service VPC ou FIPS VPC](datasync-network.md#using-vpc-endpoint). Si vous utilisez un point de terminaison FIPS (Federal Information Processing Standard) public ou fédéral, vérifiez que les paramètres de votre pare-feu et de votre routeur autorisent votre agent à se connecter au point de terminaison. Pour plus d'informations, consultez [Exigences réseau pour les points de terminaison publics ou de service FIPS](datasync-network.md#using-public-endpoints). ## Je ne parviens toujours pas à activer un agent à l'aide d'un point de terminaison de service VPC Si vous rencontrez toujours des problèmes pour activer un DataSync agent avec un point de terminaison de service VPC, voir [Je ne sais pas ce qui se passe avec mon agent. Quelqu'un peut-il m'aider ?](#enable-support-access) ## Que dois-je faire si mon agent est hors ligne ? Votre DataSync agent peut être hors ligne pour plusieurs raisons, mais vous pourrez peut-être le remettre en ligne. Avant de supprimer l'agent et d'en créer un nouveau, parcourez la liste de contrôle suivante pour vous aider à comprendre ce qui a pu se passer. + **Contactez votre équipe de sauvegarde** : si votre agent est hors ligne parce que sa machine virtuelle (VM) a été restaurée à partir d'un instantané ou d'une sauvegarde, vous devrez peut-être [remplacer l'agent](replacing-agent.md). + **Vérifiez si la machine virtuelle ou l'instance Amazon EC2 de l'agent est désactivée** : selon le type d'agent que vous utilisez, essayez de réactiver la machine virtuelle ou l'instance EC2 si elle est désactivée. Une fois qu'il est de nouveau activé, [testez la connectivité réseau de votre agent](test-agent-connections.md#test-network) à AWS. + **Vérifiez que votre agent répond à la configuration matérielle minimale requise** : votre agent est peut-être hors ligne car la configuration de sa machine virtuelle ou de son instance EC2 a été modifiée accidentellement depuis l'activation de l'agent. Par exemple, si votre machine virtuelle ne dispose plus de la mémoire ou de l'espace minimum requis, l'agent peut apparaître comme étant hors ligne. Pour de plus amples informations, veuillez consulter [Exigences pour les AWS DataSync agents](agent-requirements.md). + **Attendez que les mises à jour logicielles relatives à l'agent soient terminées** : votre agent peut se déconnecter brièvement après les [mises à jour logicielles fournies par](managing-agent.md#managing-agent-updates). AWS Si vous pensez que c'est la raison pour laquelle l'agent est hors ligne, attendez un moment puis vérifiez si l'agent est de nouveau en ligne. + **Vérifiez les paramètres du point de terminaison de votre service VPC** : si votre agent hors ligne utilise un point de terminaison de service public et qu'il se trouve également dans le même VPC pour lequel vous avez créé un point de terminaison de service VPC DataSync, vous devrez peut-être désactiver le [support DNS](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) privé pour ce point de terminaison VPC. Si aucune de ces raisons ne semble être la raison pour laquelle l'agent est hors ligne, vous devrez probablement [le remplacer](replacing-agent.md). ## Je ne sais pas ce qui se passe avec mon agent. Quelqu'un peut-il m'aider ? Vous pouvez autoriser AWS Support l'accès à votre DataSync agent et aider à résoudre les problèmes liés à l'agent. Vous devez activer cet accès via la console locale de l'agent. **Pour donner Support accès à votre agent** 1. [Connectez-vous à la console locale de votre agent](local-console-vm.md#local-console-login). 1. À l'invite, entrez **5** pour ouvrir l'invite de commande (pour VMware VMs, utiliser**6**). 1. Saisissez **h** pour ouvrir la fenêtre **AVAILABLE COMMANDS (COMMANDES DISPONIBLES)**. 1. Dans la fenêtre **COMMANDES DISPONIBLES**, entrez les informations suivantes pour vous connecter à Support : `open-support-channel` Si vous utilisez l'agent avec des points de terminaison VPC, vous devez fournir une adresse IP de point de terminaison VPC pour votre canal de support, comme suit : `open-support-channel vpc-ip-address` Votre pare-feu doit autoriser le port TCP entrant 22 à initier un canal d'assistance vers. AWS Lorsque vous vous connectez à Support, vous DataSync attribue un numéro d'assistance. Notez ce numéro. **Note** Le numéro de canal n'est pas un numéro de TCP/UDP port. Au lieu de cela, il établit une connexion SSH (TCP 22) aux serveurs et fournit le canal de support pour la connexion. 1. Lorsque le canal d'assistance est établi, fournissez votre numéro de service d'assistance Support afin qu'il puisse fournir une assistance en matière de dépannage. 1. Lorsque la session d'assistance est terminée, appuyez dessus **Enter** pour y mettre fin. 1. Entrez **exit** pour vous déconnecter de la console DataSync locale. 1. Suivez les invites pour quitter la console locale. # Résolution des problèmes liés aux DataSync emplacements Utilisez les informations suivantes pour vous aider à résoudre les problèmes liés aux AWS DataSync emplacements. Certains de ces problèmes peuvent inclure : + Permissions et erreurs de montage avec les emplacements NFS + Problèmes liés à la propriété des fichiers + Problèmes d'accès aux sites SMB utilisant l'authentification Kerberos + Problèmes d'autorisation et d'accès liés au stockage d'objets, tels que les emplacements Amazon S3 et Microsoft Azure Blob ## Ma tâche a échoué avec un message d'erreur indiquant que les autorisations NFS ont été refusées Un message d'erreur « autorisations refusées » peut s'afficher si vous configurez votre serveur de fichiers NFS avec `root_squash` ou `all_squash` si vos fichiers ne disposent pas tous d'un accès en lecture. **Action à exécuter** Pour résoudre ce problème, configurez votre exportation NFS avec `no_root_squash` ou assurez-vous que les autorisations associées à tous les fichiers que vous souhaitez transférer autorisent un accès en lecture à tous les utilisateurs. Pour accéder DataSync aux répertoires, vous devez également activer l'accès à toutes les exécutions. Pour vous assurer que le répertoire peut être monté, vconnectez-vous d'abord à n'importe quel ordinateur possédant la même configuration réseau que votre agent. Exécutez ensuite la commande CLI suivante : `mount -t nfs -o nfsvers= : ` Si le problème n'est toujours pas résolu, contactez le [AWS Support centre](https://console.aws.amazon.com/support/home#/) de contact. ## Ma tâche a échoué en raison d'une erreur de montage NFS L'erreur suivante peut s'afficher lors de l'exécution d'une DataSync tâche impliquant un emplacement de serveur de fichiers NFS : La tâche n'a pas pu accéder à l'emplacement loc-1111222233334444a : x40016 : mount.nfs : le délai de connexion a expiré **Actions à exécuter** Procédez comme suit jusqu'à ce que l'erreur soit résolue. 1. Assurez-vous que le serveur de fichiers NFS et l'exportation que vous spécifiez dans votre DataSync emplacement sont valides. Si ce n'est pas le cas, supprimez votre emplacement et votre tâche, puis créez un nouvel emplacement et une nouvelle tâche utilisant un serveur de fichiers NFS valide et exportez-les. Pour de plus amples informations, veuillez consulter [Utilisation de la DataSync console](create-nfs-location.md#create-nfs-location-console). 1. Vérifiez la configuration de votre pare-feu entre votre agent et le serveur de fichiers NFS. Pour de plus amples informations, veuillez consulter [Exigences réseau pour le stockage sur site, autogéré et autre stockage dans le cloud](datasync-network.md#on-premises-network-requirements). 1. Assurez-vous que votre agent peut accéder au serveur de fichiers NFS et monter l'exportation. Pour de plus amples informations, veuillez consulter [Fournir un DataSync accès aux serveurs de fichiers NFS](create-nfs-location.md#accessing-nfs). 1. Si le message d'erreur persiste, ouvrez un canal d'assistance avec Support. Pour de plus amples informations, veuillez consulter [Je ne sais pas ce qui se passe avec mon agent. Quelqu'un peut-il m'aider ?](troubleshooting-datasync-agents.md#enable-support-access). ## Ma tâche a échoué en raison d'une erreur de montage Amazon EFS L'erreur suivante peut s'afficher lors de l'exécution d'une DataSync tâche impliquant un emplacement Amazon EFS : La tâche n'a pas pu accéder à l'emplacement loc-1111222233334444a : x40016 : Impossible de se connecter à la cible de montage EFS dont l'adresse IP est : 10.10.1.0. Cela peut se produire si le chemin de montage du système de fichiers Amazon EFS que vous configurez avec votre position est mis à jour ou supprimé. DataSync n'est pas au courant de ces modifications dans le système de fichiers. **Action à exécuter** Supprimez votre emplacement et votre tâche et [créez un nouvel emplacement Amazon EFS](create-efs-location.md#create-efs-location-how-to) avec le nouveau chemin de montage. ## La propriété des fichiers n'est pas maintenue avec le transfert NFS Après votre transfert, vous remarquerez peut-être que les fichiers de votre emplacement de DataSync destination ont un utilisateur IDs (UIDs) ou un groupe IDs (GIDs) différent de celui des fichiers de votre emplacement source. Par exemple, les fichiers de votre destination peuvent avoir un UID de `65534``99`, ou`nobody`. Cela peut se produire si un système de fichiers impliqué dans votre transfert utilise le mappage d'identifiants NFS version 4, une fonctionnalité qui DataSync n'est pas prise en charge. **Action à exécuter** Plusieurs options s'offrent à vous pour contourner ce problème : + Créez un nouvel emplacement pour le système de fichiers qui utilise la version 3 de NFS au lieu de la version 4. + Désactivez le mappage des identifiants NFS version 4 sur le système de fichiers. Réessayez le transfert. L'une ou l'autre option devrait résoudre le problème. ## Ma tâche ne peut pas accéder à un emplacement SMB qui utilise Kerberos DataSync les erreurs liées aux sites SMB qui utilisent l'[authentification Kerberos](create-smb-location.md#configuring-smb-kerberos-authentication) sont généralement liées à des incohérences entre votre emplacement et les configurations Kerberos. Il se peut également qu'il y ait un problème de réseau. **Impossible d'accéder à l'emplacement** L'erreur suivante indique qu'il existe peut-être des problèmes de configuration liés à votre emplacement SMB ou à la configuration de Kerberos : ``` Task failed to access location ``` **Vérifiez les points suivants** : + Le serveur de fichiers SMB que vous spécifiez pour votre emplacement est un nom de domaine. Pour Kerberos, vous ne pouvez pas spécifier l'adresse IP du serveur de fichiers. + Le principal Kerberos que vous spécifiez pour votre emplacement correspond au principal que vous utilisez pour créer le fichier de table des clés Kerberos (keytab). Les noms principaux distinguent les majuscules et minuscules. + Le mot de passe utilisateur mappé du principal Kerberos n'a pas changé depuis que vous avez créé le fichier keytab. Si le mot de passe change (en raison de la rotation du mot de passe ou pour toute autre raison), l'exécution de votre tâche risque d'échouer avec l'erreur suivante : La tâche n'a pas pu accéder à l'emplacement loc-1111222233334444a : x40015 : kinit : échec de la préauthentification lors de l'obtention des informations d'identification initiales **Impossible de contacter le royaume KDC** L'erreur suivante indique un problème réseau : ``` kinit: Cannot contact any KDC for realm 'MYDOMAIN.ORG' while getting initial credentials" ``` **Vérifiez les points suivants** : + Le fichier de configuration Kerberos (`krb5.conf`) que vous avez fourni DataSync contient les informations correctes sur votre domaine Kerberos. Pour un exemple de `krb5.conf` fichier, consultez la section Conditions requises pour l'[authentification Kerberos](create-smb-location.md#configuring-smb-kerberos-prerequisites). + Le port du serveur Kerberos Key Distribution Center (KDC) est ouvert. Le port KDC est généralement le port TCP 88. + La configuration DNS de votre réseau. ## Ma tâche a échoué en raison d'une input/output erreur Un message d' input/output erreur peut s'afficher si votre système de stockage ne répond pas I/O aux demandes de l' DataSync agent. Cela est souvent dû à une panne de disque du serveur, à une modification de la configuration de votre pare-feu ou à une défaillance du routeur réseau. Si l'erreur concerne un serveur de fichiers NFS ou un cluster Hadoop Distributed File System (HDFS), suivez les étapes ci-dessous pour résoudre l'erreur. **Actions à entreprendre (NFS)** Vérifiez d'abord les journaux et les indicateurs de votre serveur de fichiers NFS pour déterminer si le problème a commencé sur le serveur NFS. Si c'est le cas, résolvez ce problème. Ensuite, vérifiez que votre configuration réseau n'a pas changé. Pour vérifier si le serveur de fichiers NFS est correctement configuré et qu'il DataSync peut y accéder, procédez comme suit : 1. Configurez un autre client NFS sur le même sous-réseau réseau que l'agent . 1. Montez votre partage sur ce client. 1. Veillez à ce que le client puisse lire et écrire dans le partage avec succès. **Actions à entreprendre (HDFS)** Procédez comme suit jusqu'à ce que l'erreur soit résolue : 1. Assurez-vous que votre cluster HDFS autorise votre DataSync agent à communiquer avec le cluster NameNode et les DataNode ports. Dans la plupart des clusters, vous pouvez trouver les numéros de port utilisés par le cluster dans les fichiers de configuration suivants : + Pour trouver le NameNode port, consultez le `core-site.xml` fichier sous la `fs.default.name` propriété `fs.default` or (en fonction de la distribution Hadoop). + Pour trouver le DataNode port, consultez le `hdfs-site.xml` fichier situé sous la `dfs.datanode.address` propriété. 1. Dans votre `hdfs-site.xml` dossier, vérifiez que votre `dfs.data.transfer.protection` propriété n'a qu'une seule valeur. Par exemple : ``` dfs.data.transfer.protection privacy ``` ## Erreur: `FsS3UnableToConnectToEndpoint` DataSync Impossible de se connecter à votre [site Amazon S3](create-s3-location.md). Cela peut signifier que le compartiment S3 de l'emplacement n'est pas accessible ou que l'emplacement n'est pas configuré correctement. Procédez comme suit jusqu'à ce que le problème soit résolu : + Vérifiez si vous DataSync pouvez [accéder à votre compartiment S3](create-s3-location.md#create-s3-location-access). + Assurez-vous que l'emplacement est correctement configuré à l'aide de la DataSync console ou de l'opération [DescribeLocationS3](https://docs.aws.amazon.com/datasync/latest/userguide/API_DescribeLocationS3.html). ## Erreur: `FsS3HeadBucketFailed` DataSync ne peut pas accéder au compartiment S3 vers lequel vous effectuez le transfert ou à partir duquel vous effectuez le transfert. Vérifiez DataSync s'il est autorisé à accéder au compartiment à l'aide de l'[HeadBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_HeadBucket.html)opération Amazon S3. Si vous devez modifier vos autorisations, consultez[Fournir DataSync un accès aux compartiments S3](create-s3-location.md#create-s3-location-access). ## Échec de la tâche avec une `Unable to list Azure Blobs on the volume root` erreur Si votre tâche de DataSync transfert échoue en raison d'une `Unable to list Azure Blobs on the volume root` erreur, il se peut qu'il s'agisse d'un problème lié à votre jeton de signature d'accès partagé (SAS) ou au réseau de votre compte de Azure stockage. **Actions à exécuter** Essayez ce qui suit et réexécutez la tâche jusqu'à ce que le problème soit résolu : + Assurez-vous que votre [jeton SAS](creating-azure-blob-location.md#azure-blob-sas-tokens) dispose des autorisations appropriées pour accéder à votreMicrosoft Azure Blob Storage. + Si vous utilisez votre DataSync agentAzure, configurez votre compte de stockage pour autoriser l'accès depuis le réseau virtuel sur lequel réside votre agent. + Si vous exécutez votre agent sur Amazon EC2, configurez votre pare-feu de Azure stockage pour autoriser l'accès depuis l'adresse IP publique de l'agent. Pour plus d'informations sur la configuration du réseau Azure de votre compte de stockage, consultez la [Azure Blob Storagedocumentation](https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security). ## Erreur: `FsAzureBlobVolRootListBlobsFailed` Le jeton de signature d'accès partagé (SAS) DataSync utilisé pour accéder à votre compte Microsoft Azure Blob Storage ne dispose pas de l'autorisation de liste. Pour résoudre le problème, [mettez à jour votre position](creating-azure-blob-location.md#azure-blob-update-location) à l'aide d'un jeton doté de l'autorisation de liste et réessayez d'exécuter votre tâche. ## Erreur: `SrcLocHitAccess` DataSync Impossible d'accéder à votre emplacement source. Vérifiez qu'il DataSync est autorisé à accéder à l'emplacement et réessayez d'exécuter votre tâche. ## Erreur: `SyncTaskErrorLocationNotAdded` DataSync Impossible d'accéder à votre position. Vérifiez qu'il DataSync est autorisé à accéder à l'emplacement et réessayez d'exécuter votre tâche. ## Erreur: `S3 location creation failed with (InvalidRequestException) when calling the CreateLocationS3 operation` Cette erreur peut être liée aux autorisations IAM, aux politiques relatives aux compartiments Amazon S3, aux AWS KMS autorisations ou à d'autres problèmes d'autorisation. Si cette erreur s'affiche, utilisez les informations suivantes pour résoudre le problème : + [Résolvez les erreurs d'accès refusé (403 Interdit) dans Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html) dans le guide de l'*utilisateur d'Amazon Simple Storage Service* + [Comment résoudre les erreurs 403 Access Denied depuis Amazon S3 ?](https://repost.aws/knowledge-center/s3-troubleshoot-403) sur AWS re:Post ## La tâche avec l'emplacement source S3 échoue avec `HeadObject` ou sans `GetObjectTagging` erreur **Erreurs liées à `HeadObject` ou `GetObjectTagging`** Si vous transférez des objets dotés d'une version spécifique IDs depuis un compartiment S3, il se peut qu'une erreur liée à `HeadObject` ou s'affiche`GetObjectTagging`. Par exemple, voici une erreur liée à `GetObjectTagging` : ``` [WARN] Failed to read metadata for file /picture1.png (versionId: 111111): S3 Get Object Tagging Failed [ERROR] S3 Exception: op=GetObjectTagging photos/picture1.png, code=403, type=15, exception=AccessDenied, msg=Access Denied req-hdrs: content-type=application/xml, x-amz-api-version=2006-03-01 rsp-hdrs: content-type=application/xml, date=Wed, 07 Feb 2024 20:16:14 GMT, server=AmazonS3, transfer-encoding=chunked, x-amz-id-2=IOWQ4fDEXAMPLEQM+ey7N9WgVhSnQ6JEXAMPLEZb7hSQDASK+Jd1vEXAMPLEa3Km, x-amz-request-id=79104EXAMPLEB723 ``` Si l'une de ces erreurs s'affiche, vérifiez que le rôle IAM DataSync utilisé pour accéder à votre emplacement source S3 dispose des autorisations suivantes : + `s3:GetObjectVersion` + `s3:GetObjectVersionTagging` Si vous devez mettre à jour votre rôle avec ces autorisations, consultez[Création d'un rôle IAM pour accéder DataSync à votre position Amazon S3](create-s3-location.md#create-role-manually). # Résolution des problèmes liés aux DataSync tâches Utilisez les informations suivantes pour résoudre les problèmes liés aux AWS DataSync tâches et à leur exécution. Ces problèmes peuvent inclure des problèmes de configuration des tâches, des exécutions de tâches bloquées et des données qui ne sont pas transférées comme prévu. ## Erreur : SyncOption valeur non valide. Option : TransferModePreserveDeletedFiles, Valeur : TOUT, SUPPRIMER. Cette erreur se produit lorsque vous créez ou modifiez votre DataSync tâche et que vous sélectionnez l'option **Transférer toutes les données** et que vous désélectionnez l'option **Conserver les fichiers supprimés.** Lorsque vous transférez toutes les données, DataSync il ne scanne pas votre position de destination et ne sait pas quoi supprimer. ## L'exécution de la tâche échoue avec une EniNotFounderreur Cette erreur se produit si vous supprimez l'une des interfaces réseau de votre tâche dans votre cloud privé virtuel (VPC). Si votre tâche est planifiée ou mise en file d'attente, elle échouera s'il manque une [interface réseau requise pour transférer vos données](required-network-interfaces.md). **Actions à exécuter** Pour contourner ce problème, vous disposez des options suivantes : + Redémarrez la tâche manuellement. Lorsque vous effectuez cette opération, il DataSync créera toutes les interfaces réseau manquantes dont il a besoin pour exécuter la tâche. + Si vous devez nettoyer les ressources de votre VPC, veillez à ne pas supprimer les interfaces réseau associées à une DataSync tâche que vous utilisez toujours. Pour voir les interfaces réseau allouées à votre tâche, effectuez l'une des opérations suivantes : + Utilisez l'[DescribeTask](https://docs.aws.amazon.com//datasync/latest/userguide/API_DescribeTask.html)opération. Vous pouvez afficher les interfaces réseau dans les éléments de `DestinationNetworkInterfaceArns` réponse `SourceNetworkInterfaceArns` et. + Dans la console Amazon EC2, recherchez votre identifiant de tâche (tel que`task-f012345678abcdef0`) pour trouver ses interfaces réseau. + Envisagez de ne pas exécuter vos tâches automatiquement. Cela peut inclure la désactivation de la mise en file d'attente ou de la planification des tâches (par le biais d'une automatisation personnalisée ou par le biais d' DataSync une automatisation personnalisée). ## L'exécution de la tâche échoue avec une erreur « Impossible d'allouer de la mémoire » Lorsque votre DataSync tâche échoue en raison d'une erreur « Impossible d'allouer de la mémoire », cela peut avoir différentes conséquences. **Action à exécuter** Essayez ce qui suit jusqu'à ce que le problème ne s'affiche plus : + Si votre transfert implique un agent, assurez-vous que celui-ci répond aux exigences de la [machine virtuelle (VM)](agent-requirements.md#hardware) ou de l'[instance Amazon EC2](agent-requirements.md#ec2-instance-types). + Divisez votre transfert en plusieurs tâches à l'aide de [filtres](filtering.md). Il est possible que vous essayiez de transférer un nombre de fichiers ou d'objets supérieur à ce que [peut gérer une seule DataSync tâche](datasync-limits.md#task-hard-limits). + Si le problème persiste, [contactez Support](https://aws.amazon.com/contact-us/). ## La tâche échoue avec `Input/Output error` for for FSx pour le système de fichiers ONTAP Lorsque votre DataSync tâche échoue ou que `Input/Output error` vous transférez des données avec un système de fichiers FSx for ONTAP, cela peut être dû à un ou plusieurs des problèmes suivants. **Le volume FSx for ONTAP a atteint sa capacité de fichier maximale** Cette erreur se produit lorsque le nombre d'inodes ou de pointeurs de fichiers disponibles sur un volume est épuisé. **Mesures à prendre** Tout d'abord, visualisez la [capacité de fichier maximale du](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/view-volume-file-capacity.html) volume. Augmentez ensuite la capacité de fichier du volume en augmentant le nombre d'inodes ou en augmentant la capacité de stockage. Pour plus d'informations, consultez la section [Augmenter la capacité maximale de fichiers d'un volume](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#max-file-capacity) dans le *guide de l'utilisateur FSx pour ONTAP*. **Le volume FSx for ONTAP n'a plus de capacité de stockage disponible** Cette erreur se produit lorsque le volume n'a pas de capacité de stockage disponible. **Mesures à prendre** Déterminez d'abord la [capacité de stockage disponible](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitor-volume-storage-console.html) du volume. Augmentez ensuite la capacité de stockage du volume. Pour plus d'informations, consultez la section [Augmenter la capacité de stockage d'un volume](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#increase-volume-capacity) dans le *guide de l'utilisateur FSx pour ONTAP*. **Note** Pour augmenter automatiquement la capacité de stockage du volume en cas de besoin, consultez la section [Utilisation du dimensionnement automatique du volume](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#volume-autosizing) dans le guide de l'utilisateur *FSx pour ONTAP*. **Le répertoire FSx for ONTAP a atteint le nombre maximum de fichiers pouvant être stockés dans chaque répertoire** Cette erreur se produit lorsque vous avez atteint le nombre maximum de fichiers pouvant être stockés dans chaque répertoire. **Action à exécuter** Augmentez la taille maximale des répertoires pour prendre en charge les répertoires plus volumineux. Pour plus d'informations, consultez la section [Meilleures pratiques d'utilisation de la taille de répertoire maximale FSx pour ONTAP](https://docs.aws.amazon.com/prescriptive-guidance/latest/fsx-ontap-enterprise-deployment/best-practices.html#bp-max-directory-size) dans le guide *AWS prescriptif*. **L'exécution de la DataSync tâche a généré trop de simultanéité en lecture/écriture, consommant un pourcentage élevé de la capacité de débit du système de fichiers.** Cette erreur se produit lorsque l'exécution de la DataSync tâche consomme une trop grande partie de la capacité de débit disponible de votre système de fichiers. **Mesures à prendre** Tout d'abord, déterminez si l'exécution de la tâche consommait une trop grande partie de la capacité de débit du système de fichiers à l'aide des méthodes suivantes : + Surveillez les performances du système de fichiers à l'aide CloudWatch des métriques disponibles. Pour plus d'informations, consultez la section [Surveillance des métriques du système de fichiers](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitor-throughput-cloudwatch.html#fsxn-howtomonitor-fs) dans le *guide FSx de l'utilisateur d'ONTAP*. + Surveillez le système de fichiers pour détecter les avertissements relatifs aux performances du serveur de fichiers dans la FSx console Amazon. Pour plus d'informations, consultez la section [Avertissements et recommandations en matière de performances](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/performance-insights-FSxN.html#resolve-warnings) dans le *guide FSx de l'utilisateur d'ONTAP*. Assurez-vous ensuite que la tâche n'utilise pas toute la capacité de débit disponible du système de fichiers en effectuant l'une des opérations suivantes : + Définissez la limite de bande passante pour l'exécution des tâches sur une quantité inférieure à la capacité FSx de débit allouée au système de fichiers ONTAP. Pour de plus amples informations, veuillez consulter [Définition des limites de bande passante pour votre AWS DataSync tâche](configure-bandwidth.md). + Augmentez la capacité de débit allouée au système de fichiers. Pour plus d'informations, consultez la section [Mise à jour de la capacité de débit](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/increase-throughput-capacity.html) dans le guide de l'*utilisateur FSx pour ONTAP*. ## Échec de la tâche `Connection Reset by peer` ou `Host is down` message correspondant au FSx système de fichiers ONTAP Si votre DataSync tâche échoue avec un `Host is down` message `Connection Reset by peer` ou lors du transfert de données avec un système de fichiers FSx for ONTAP, cela peut être dû à un ou plusieurs des problèmes suivants : + Le serveur SMB du système de fichiers a été redémarré ou déconnecté pendant l'exécution de la tâche. + Le système de fichiers est passé du serveur principal au serveur secondaire (et à l'adresse IP) pendant l'exécution de la tâche. DataSync ne prend pas en charge le basculement vers une adresse IP secondaire lors de l'exécution d'une tâche. FSx pour le basculement des systèmes de fichiers ONTAP vers un serveur secondaire et une adresse IP lors des événements suivants : + Le serveur principal devient indisponible. + La zone de disponibilité du serveur principal devient indisponible (pour les systèmes de fichiers multi-AZ). + Lors d'une modification de capacité de débit initiée par l'utilisateur. + Pendant la période de maintenance régulière du système de fichiers. Pour plus d'informations, reportez-vous au [processus FSx de basculement ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/high-availability-AZ.html#Failover) dans le guide de l'utilisateur FSx d'ONTAP. **Action à exécuter** Redémarrez la tâche. ## L'exécution de la tâche a un statut de lancement mais rien ne semble se passer Votre DataSync tâche peut rester bloquée avec un statut de **lancement**, généralement parce que l'agent est hors tension ou a perdu la connectivité réseau. **Actions à exécuter** Assurez-vous que le statut de votre agent est **EN LIGNE**. Si l'agent est **HORS LIGNE**, assurez-vous qu'il est allumé. Si l'agent est allumé et que la tâche est toujours **en cours de lancement**, il y a probablement un problème de connexion réseau entre votre agent et AWS. Pour obtenir des informations sur le test de la connectivité réseau, consultez [Vérification de la connexion de votre agent au DataSync service](test-agent-connections.md#test-network). Si le problème persiste, consultez[Je ne sais pas ce qui se passe avec mon agent. Quelqu'un peut-il m'aider ?](troubleshooting-datasync-agents.md#enable-support-access). ## L'exécution de la tâche semble bloquée dans l'état de préparation La durée pendant laquelle votre tâche de DataSync transfert affiche le statut **Préparation** dépend de la quantité de données présentes dans la source et la destination du transfert, ainsi que des performances de ces systèmes de stockage. Lorsqu'une tâche démarre, DataSync effectue une liste de répertoires récursive pour découvrir tous les fichiers, objets, répertoires et métadonnées de votre source et de votre destination. DataSync utilise ces listes pour identifier les différences entre les systèmes de stockage et déterminer les éléments à copier. Ce processus peut prendre quelques minutes, voire quelques heures. **Action à exécuter** Tu ne devrais pas avoir à faire quoi que ce soit. Continuez à attendre que le statut de la tâche passe à **Transfert**. Si le statut ne change toujours pas, contactez le [AWS Support centre](https://console.aws.amazon.com/support/home#/). ## L'exécution de la tâche s'arrête avant la fin du transfert Si l'exécution de votre DataSync tâche s'arrête prématurément, la configuration de votre tâche peut inclure un Région AWS élément désactivé dans votre Compte AWS. **Actions à exécuter** Procédez comme suit pour exécuter à nouveau votre tâche : 1. Vérifiez le [statut d'inscription](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) des régions de votre tâche et assurez-vous qu'elles sont activées. 1. [Redémarrez la tâche](run-task.md). ## L'exécution de la tâche échoue lors du transfert depuis un bucket Google Cloud Storage Comme il DataSync communique avec Google Cloud Storage à l'aide de l'API Amazon S3, il existe une limite qui peut entraîner l'échec de votre DataSync transfert si vous essayez de copier des balises d'objets. Le message suivant concernant le problème apparaît dans vos CloudWatch journaux : [WARN] Impossible de lire les métadonnées du fichier/*your-bucket*/*your-object*: S3 Get Object Tagging Echec : poursuite sans balisage Pour éviter cela, désélectionnez l'option **Copier les balises d'objets** lors de la configuration des paramètres de vos tâches de transfert. ## Il existe des incohérences entre les horodatages de l'exécution des tâches Lorsque vous consultez la DataSync console ou les CloudWatch journaux Amazon, vous remarquerez peut-être que les heures de début et de fin de l'exécution de vos DataSync tâches ne correspondent pas aux horodatages que vous voyez dans d'autres outils de surveillance. Cela est dû au fait que la console et CloudWatch les journaux prennent en compte le temps passé par l'exécution d'une tâche dans les [états](run-task.md#understand-task-execution-statuses) de lancement ou de mise en file d'attente, alors que d'autres outils ne le font pas. Vous remarquerez peut-être cette différence lorsque vous comparez les horodatages d'exécution entre la DataSync console ou les CloudWatch journaux et les emplacements suivants : + Journaux du système de fichiers impliqué dans votre transfert + Date de dernière modification sur un objet Amazon S3 qui DataSync a écrit à + Trafic réseau provenant de l' DataSync agent + EventBridge Événements Amazon ## L'exécution de la tâche échoue avec une `NoMem` erreur L'ensemble de données que vous essayez de transférer est peut-être trop important pour DataSync. Si cette erreur s'affiche, contactez le [AWS Support Centre](https://console.aws.amazon.com/support/home#/). ## L'exécution de la tâche échoue avec une `FsNfsIdMappingEnabled` erreur DataSync ne prend pas en charge le mappage des NFSv4 identifiants. Pour contourner ce problème, [configurez votre emplacement NFS à utiliser NFSv3](create-nfs-location.md#configure-network-nfs-location). ## L'objet ne parvient pas à être transféré en raison Azure Blob Storage d'une `user metadata key` erreur Lors du transfert d'un compartiment S3 versAzure Blob Storage, le message d'erreur suivant peut s'afficher : ``` [ERROR] Failed to transfer file /user-metadata/file1: Azure Blob user metadata key must be a CSharp identifier ``` Cela signifie que cela `/user-metadata/file1` inclut les métadonnées utilisateur qui n'utilisent pas d'identifiant C\$1 valide. Pour plus d'informations, consultez la [documentation Microsoft](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names). ## Il y a un `/.aws-datasync` dossier dans l'emplacement de destination DataSync crée un dossier appelé `/.aws-datasync` dans votre emplacement de destination pour faciliter le transfert de données. Bien que ce dossier soit DataSync généralement supprimé après votre transfert, il se peut que cela ne se produise pas dans certains cas. **Action à exécuter** Supprimez ce dossier à tout moment tant que vous n'avez pas de copie de tâche en cours d'exécution vers cet emplacement. ## Impossible de transférer des liens symboliques entre des sites à l'aide du protocole SMB Lorsque l'exécution de la tâche est terminée, le message d'erreur suivant s'affiche : ``` Transfer and verification completed. Selected files transferred except for files skipped due to errors. If no skipped files are listed in Cloud Watch Logs, please contact AWS Support for further assistance. ``` Lors du transfert entre des systèmes de stockage SMB (tels qu'un serveur de fichiers SMB et un système de fichiers Amazon FSx pour Windows File Server), les avertissements et erreurs suivants peuvent s'afficher dans vos CloudWatch journaux : ``` [WARN] Failed to read metadata for file /appraiser/symlink: No data available [ERROR] Failed to read metadata for directory /appraiser/symlink: No data available ``` **Action à exécuter** DataSync ne prend pas en charge le transfert de liens symboliques (ou liens physiques) lors du transfert entre ces types de localisation. Pour de plus amples informations, veuillez consulter [Liens et répertoires copiés par AWS DataSync](special-files-copied.md). ## Erreurs dans les rapports de tâches Vous pouvez rencontrer l'une des erreurs suivantes lorsque vous essayez de surveiller votre DataSync transfert à l'aide d'un rapport de tâches. | Message d’erreur | Solution | | --- | --- | | Le chemin du fichier dépasse la longueur maximale de 4 096 caractères. Impossible d'écrire dans le rapport des tâches | Aucune. DataSync Impossible de transférer un fichier dont le chemin dépasse 4 096 octets. Pour de plus amples informations, veuillez consulter [Limites relatives au système de stockage, aux fichiers et aux objets](datasync-limits.md#file-system-limits). | | Impossible de télécharger le ou les rapports de tâches vers S3 en raison d'un compartiment ou d'un rôle IAM non valide | Vérifiez que le [rôle DataSync IAM](creating-task-report.md#task-report-access) dispose des autorisations appropriées pour télécharger un rapport de tâches dans votre compartiment S3. | | Une erreur d'exécution s'est produite avant la génération de rapports de tâches | Consultez vos [CloudWatch journaux](monitor-datasync.md) pour déterminer pourquoi l'exécution de votre tâche a échoué. | # Résolution des problèmes de vérification des données AWS DataSync [Vérifie par défaut l'intégrité](how-datasync-transfer-works.md#how-verifying-works) de vos données à la fin d'un transfert. Utilisez les informations suivantes pour vous aider à diagnostiquer les erreurs de vérification et les avertissements courants, tels que la modification ou la suppression de fichiers avant la fin de DataSync la vérification de vos données. En cas de problèmes de vérification, il est souvent utile de consulter vos [CloudWatch journaux](configure-logging.md) (ou [rapports de tâches](task-reports.md)) en plus de l'erreur d'exécution des tâches que vous constatez. DataSyncfournit des journaux structurés en JSON pour les tâches en mode amélioré, tandis que les tâches en mode de base ont des journaux non structurés. ## Il existe des incohérences entre le contenu d'un fichier Lorsque l'exécution de la tâche est terminée, le message d'erreur suivant s'affiche : ``` Transfer and verification completed. Verification detected mismatches. Files with mismatches are listed in Cloud Watch Logs ``` Dans vos CloudWatch journaux, vous remarquerez peut-être des échecs de vérification pour des contenus qui diffèrent entre les emplacements source et de destination. Cela peut se produire si des fichiers sont modifiés lors de votre transfert. Par exemple, les journaux suivants indiquent `file1.txt` que `mtime` les `srcHash` `dstHash` valeurs et sont différentes : **Exemple de journal en mode de base** ``` [NOTICE] Verification failed <> /directory1/directory2/file1.txt [NOTICE] /directory1/directory2/file1.txt srcMeta: type=R mode=0755 uid=65534 gid=65534 size=534528 atime=1633100003/684349800 mtime=1602647222/222919600 extAttrsHash=0 [NOTICE] srcHash: 0c506c26bd1e43bd3ac346734f1a9c16c4ad100d1b43c2903772ca894fd24e44 [NOTICE] /directory1/directory2/file1.txt dstMeta: type=R mode=0755 uid=65534 gid=65534 size=511001 atime=1633100003/684349800 mtime=1633106855/859227500 extAttrsHash=0 [NOTICE] dstHash: dbd798929f11a7c0201e97f7a61191a83b4e010a449dfc79fbb8233801067c46 ``` In DataSync, `mtime` représente la dernière fois qu'un fichier a été écrit avant sa [préparation](how-datasync-transfer-works.md#how-datasync-prepares). Lors de la vérification des transferts, DataSync compare `mtime` les valeurs entre les emplacements source et de destination. Un tel échec de vérification se produit si le nom `mtime` d'un fichier n'est pas le même pour les deux emplacements. Les différences entre `srcHash` et `dstHash` indiquent que le contenu du fichier ne correspond pas aux deux emplacements. **Actions à exécuter** Procédez comme suit : 1. Utilisez un convertisseur de temps d'époque pour déterminer si le fichier ou l'objet source ou de destination a été modifié plus récemment. Cela peut aider à identifier la version actuelle. 1. Pour éviter que cette erreur ne se reproduise, [planifiez l'exécution de votre tâche](task-scheduling.md) pendant une fenêtre de maintenance lorsqu'aucune activité n'est enregistrée à la source et à la destination. ## Il existe une incompatibilité entre les métadonnées SMB d'un fichier Lorsque l'exécution de la tâche est terminée, le message d'erreur suivant s'affiche : ``` Transfer and verification completed. Verification detected mismatches. Files with mismatches are listed in Cloud Watch Logs ``` Lors du transfert entre des systèmes de stockage prenant en charge le protocole SMB (Server Message Block), cette erreur peut s'afficher lorsque les attributs SMB étendus d'un fichier ne correspondent pas entre la source et la destination. Par exemple, les journaux suivants indiquent que `file1.txt` la `extAttrsHash` valeur varie d'un emplacement à l'autre, indiquant que le contenu du fichier est identique mais que les attributs étendus n'ont pas été définis à la destination : **Exemple de journal en mode de base** ``` [NOTICE] Verification failed <> /directory1/directory2/file1.txt [NOTICE] /directory1/directory2/file1.txt srcMeta: type=R mode=0755 uid=65534 gid=65534 size=1469752 atime=1631354985/174924200 mtime=1536995541/986211400 extAttrsHash=2272191894 [NOTICE] srcHash: 38571d42b646ac8f4034b7518636b37dd0899c6fc03cdaa8369be6e81a1a2bb5 [NOTICE] /directory1/directory2/file1.txt dstMeta: type=R mode=0755 uid=65534 gid=65534 size=1469752 atime=1631354985/174924200 mtime=1536995541/986211400 extAttrsHash=3051150340 [NOTICE] dstHash: 38571d42b646ac8f4034b7518636b37dd0899c6fc03cdaa8369be6e81a1a2bb5 ``` Un message d'erreur associé à propos des attributs étendus peut également s'afficher : ``` [ERROR] Deferred error: WriteFileExtAttr2 failed to setextattrlist(filename="/directory1/directory2/file1.txt"): Input/output error ``` **Action à exécuter** Cette erreur se produit généralement lorsque les autorisations sont insuffisantes pour copier les listes de contrôle d'accès (ACLs) vers la destination. Pour résoudre ce problème, consultez les guides de configuration suivants en fonction de votre type de destination : + [Autorisations requises](create-fsx-location.md#create-fsx-windows-location-permissions) FSx pour les systèmes de fichiers Windows File Server + [Autorisations requises](create-ontap-location.md#create-ontap-location-smb) FSx pour les systèmes de fichiers ONTAP qui utilisent SMB ## Les fichiers à transférer ne se trouvent plus à l'emplacement source Lorsque l'exécution de la tâche est terminée, le message d'erreur suivant s'affiche : ``` Transfer and verification completed. Selected files transferred except for files skipped due to errors. If no skipped files are listed in Cloud Watch Logs, please contact AWS Support for further assistance. ``` Dans vos journaux, vous pouvez voir des erreurs indiquant que les fichiers ne se trouvent pas à l'emplacement source. Cela peut se produire si des fichiers (tels que `file1.dll` et`file2.dll`) sont supprimés après leur [préparation](how-datasync-transfer-works.md#how-datasync-prepares) mais avant leur DataSync transfert : **Exemple de journal en mode de base** ``` [ERROR] Failed to open source file /file1.dll: No such file or directory [ERROR] Failed to open source file /file2.dll: No such file or directory ``` **Action à exécuter** Pour éviter ces situations, [planifiez l'exécution de votre tâche](task-scheduling.md) lorsqu'il n'y a aucune activité à l'emplacement source. Par exemple, vous pouvez exécuter votre tâche pendant une fenêtre de maintenance lorsque les utilisateurs et les applications ne travaillent pas activement avec cet emplacement. Dans certains cas, il est possible que les journaux associés à cette erreur ne s'affichent pas. Dans ce cas, contactez le [AWS Support centre](https://console.aws.amazon.com/support/home#/). ## DataSync Impossible de vérifier les données de destination Lorsque l'exécution de la tâche est terminée, le message d'erreur suivant s'affiche : ``` Transfer and verification completed. Verification detected mismatches. Files with mismatches are listed in Cloud Watch Logs ``` Dans vos journaux, vous remarquerez peut-être qu'il n'est pas DataSync possible de vérifier certains dossiers ou fichiers dans l'emplacement de destination. Ces erreurs peuvent ressembler à ceci : **Exemple de journal en mode de base** ``` [ERROR] Failed to read metadata for destination file /directory1/directory2/file1.txt: No such file or directory ``` Pour les fichiers, vous pouvez rencontrer des échecs de vérification comme celui-ci : **Exemple de journal en mode de base** ``` [NOTICE] Verification failed <> /directory1/directory2/file1.txt [NOTICE] /directory1/directory2/file1.txt srcMeta: type=R mode=0755 uid=65534 gid=65534 size=61533 atime=1633099987/747713800 mtime=1536995631/894267700 extAttrsHash=232104771 [NOTICE] srcHash: 1426fe40f669a7d36cca1b5329983df31a9aeff8eb9fe3ac885f26de2f8fff6b [NOTICE] /directory1/directory2/file1.txt dstMeta: type=R mode=0755 uid=65534 gid=65534 size=0 atime=0/0 mtime=0/0 extAttrsHash=0 [NOTICE] dstHash: 0000000000000000000000000000000000000000000000000000000000000000 ``` **Action à exécuter** Ces journaux indiquent que les données de destination ont été supprimées après le transfert mais avant la vérification. (Les journaux se ressemblent lorsque les données sont téléchargées vers un emplacement source au cours de la même période.) Pour éviter ces situations, [planifiez l'exécution de votre tâche](task-scheduling.md) lorsqu'il n'y a aucune activité sur le lieu de destination. Par exemple, vous pouvez exécuter votre tâche pendant une fenêtre de maintenance lorsque les utilisateurs et les applications ne travaillent pas activement avec cet emplacement. ## DataSync Impossible de lire les métadonnées des objets Lorsque l'exécution de la tâche est terminée, le message d'erreur suivant s'affiche : ``` Transfer and verification completed. Selected files transferred except for files skipped due to errors. If no skipped files are listed in Cloud Watch Logs, please contact AWS Support for further assistance. ``` Dans vos journaux, vous remarquerez peut-être que cela ne DataSync peut pas être lu en `file1.png` raison de l'échec d'une `HeadObject` demande Amazon S3. [DataSync effectue `HeadObject` des demandes](create-s3-location.md#create-s3-location-s3-requests-made) auprès des emplacements S3 lors de la préparation et de la vérification des tâches. **Exemple de journal en mode de base** ``` [WARN] Failed to read metadata for file /file1.png: S3 Head Object Failed ``` **Actions à exécuter** Pour résoudre ce problème, vérifiez si vous DataSync disposez du niveau d'autorisations approprié pour travailler avec votre compartiment S3 : + Assurez-vous que le rôle IAM DataSync utilisé pour accéder à vos sites Amazon S3 autorise l'`s3:GetObject`autorisation. Pour de plus amples informations, veuillez consulter [Autorisations requises](create-s3-location.md#create-s3-location-required-permissions). + Si votre compartiment S3 utilise le chiffrement côté serveur, assurez-vous qu'il DataSync est autorisé à accéder aux objets de ce compartiment. Pour de plus amples informations, veuillez consulter [Accès aux compartiments S3 à l'aide du chiffrement côté serveur](create-s3-location.md#create-s3-location-encryption). ## Les métadonnées définies par le système d'un objet ne correspondent pas Lorsque l'exécution de vos tâches en mode amélioré entre les compartiments S3 est terminée, le message d'erreur suivant s'affiche : ``` Verification failed due to a difference in metadata ``` Il se peut que vous remarquiez dans vos journaux une incohérence dans les métadonnées définies par le [système](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingMetadata.html#SysMetadata) Amazon S3 d'un objet. Dans cet exemple particulier, l'objet source ne possède pas de `Content-Type` métadonnées, mais l'objet de destination en possède. Cela s'est produit parce que le compartiment S3 de destination appliquait automatiquement `"ContentType": "application/octet-stream"` des métadonnées à l'objet lorsqu'il y était DataSync transféré. **Exemple de journal en mode amélioré** ``` { "Action": "VERIFY", "Source": { "LocationId": "loc-0b3017fc4ba4a2d8d", "RelativePath": "encoding/content-null", "Metadata": { "Type": "Object", "ContentSize": 24, "LastModified": "2024-12-23T15:48:15Z", "S3": { "SystemMetadata": { "ETag": "\"68b9c323bb846841ee491481f576ed4a\"" }, "UserMetadata": {}, "Tags": {} } } }, "Destination": { "LocationId": "loc-abcdef01234567890", "RelativePath": "encoding/content-null", "Metadata": { "Type": "Object", "ContentSize": 24, "LastModified": "2024-12-23T16:00:03Z", "S3": { "SystemMetadata": { "ContentType": "application/octet-stream", "ETag": "\"68b9c323bb846841ee491481f576ed4a\"" }, "UserMetadata": { "file-mtime": "1734968895000" }, "Tags": {} } } }, "TransferType": "CONTENT_AND_METADATA", "ErrorCode": "MetadataDiffers", "ErrorDetail": "Verification failed due to a difference in metadata" } ``` **Action à exécuter** Pour éviter cette erreur, mettez à jour vos objets de localisation source afin d'inclure la propriété `Content-Type` des métadonnées. ## Comprendre la durée de vérification des données DataSync la vérification inclut une SHA256 somme de contrôle sur le contenu des fichiers et une comparaison exacte des métadonnées des fichiers entre les emplacements. La durée de la vérification dépend de plusieurs facteurs, notamment le nombre de fichiers ou d'objets concernés, la taille des données dans les systèmes de stockage et les performances de ces systèmes. **Action à exécuter** Compte tenu des facteurs qui peuvent affecter le délai de vérification, vous ne devriez rien avoir à faire. Toutefois, si l'exécution de votre tâche semble bloquée avec un statut de [vérification](run-task.md#understand-task-execution-statuses), contactez le [AWS Support Centre](https://console.aws.amazon.com/support/home#/). # Résolution des problèmes liés aux coûts de stockage S3 plus élevés que prévu avec DataSync Si les coûts de stockage de votre Amazon S3 sont supérieurs à ce que vous pensiez à la suite d'un AWS DataSync transfert, cela peut être dû à une ou plusieurs des raisons suivantes : + Lors du transfert vers ou depuis des compartiments S3, vous encourez des coûts liés aux demandes d'API S3 effectuées par. DataSync + DataSync utilise la fonctionnalité de téléchargement partitionné d'Amazon S3 pour charger des objets dans des compartiments S3. Cette approche peut entraîner des frais de stockage inattendus pour les téléchargements qui ne se terminent pas correctement. + DataSync copie les balises d'objet des objets source et de destination lorsque l'option **Copier les balises d'objet** est activée sur la console ou `ObjectTags` est définie sur`PRESERVE`. La copie de ces balises d'objet peut entraîner des coûts liés aux demandes d'API S3. + La gestion des versions d'objet peut être activée sur votre compartiment S3. Le versionnement des objets permet à Amazon S3 de stocker plusieurs copies d'objets portant le même nom. **Actions à exécuter** Dans ces cas, vous pouvez procéder comme suit : + Assurez-vous de bien comprendre comment DataSync les requêtes S3 sont utilisées et comment elles peuvent affecter vos coûts de stockage. Pour de plus amples informations, veuillez consulter [Évaluation des coûts des requêtes S3 lors de l'utilisation DataSync](create-s3-location.md#create-s3-location-s3-requests). + Si le problème est lié aux téléchargements partitionnés, configurez une politique de téléchargement partitionné pour votre compartiment S3 afin de nettoyer les téléchargements partitionnés incomplets afin de réduire les coûts de stockage. Pour plus d'informations, consultez le billet de AWS blog [S3 Lifecycle Management Update - Support pour les téléchargements partitionnés et les marqueurs de suppression](https://aws.amazon.com/blogs/aws/s3-lifecycle-management-update-support-for-multipart-uploads-and-delete-markers/). + Si le problème est lié à la copie de balises d'objet et que vous n'avez pas besoin de balises d'objet, décochez la case **Copier les balises d'objet** dans la DataSync console ou `ObjectTags` définissez-la `None` lors de la création, du démarrage ou de la mise à jour d'une tâche. + Si le problème est lié à la gestion des versions d'objets, désactivez la gestion des versions d'objets dans votre compartiment S3. Si vous avez besoin d'une aide supplémentaire, contactez le [AWS Support centre](https://console.aws.amazon.com/support/home#/).