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. # 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#/).