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é 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 (ou rapports de tâches) 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/222919600extAttrsHash=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/859227500extAttrsHash=0 [NOTICE] dstHash:dbd798929f11a7c0201e97f7a61191a83b4e010a449dfc79fbb8233801067c46
In DataSync, mtime représente la dernière fois qu'un fichier a été écrit avant sa préparation. 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 :
-
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.
-
Pour éviter que cette erreur ne se reproduise, planifiez l'exécution de votre tâche 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 FSx pour les systèmes de fichiers Windows File Server
-
Autorisations requises 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 etfile2.dll) sont supprimés après leur préparation 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 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
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 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 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:GetObjectautorisation. Pour de plus amples informations, veuillez consulter Autorisations requises. -
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.
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 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, contactez le AWS Support Centre
