

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS DataSync の問題のトラブルシューティング
<a name="troubleshooting-datasync"></a>

次の情報を使用して、 AWS DataSync の問題とエラーをトラブルシューティングします。

**Topics**
+ [DataSync エージェントに関する問題のトラブルシューティング](troubleshooting-datasync-agents.md)
+ [DataSync ロケーションの問題のトラブルシューティング](troubleshooting-storage-issues.md)
+ [DataSync タスクの問題のトラブルシューティング](troubleshooting-tasks.md)
+ [データ検証に関する問題のトラブルシューティング](troubleshooting-task-verification.md)
+ [DataSync を使用すると S3 のストレージコストが予想よりも高くなる問題のトラブルシューティング](multipart-upload-policy.md)

# DataSync エージェントに関する問題のトラブルシューティング
<a name="troubleshooting-datasync-agents"></a>

次の情報は、 AWS DataSync エージェントの問題のトラブルシューティングに役立ちます。これらの問題には、次のようなものがあります。
+ Amazon EC2 エージェントのローカルコンソールに接続できない
+ エージェントのアクティベーションキーを取得できない
+ VPC サービスエンドポイントによるエージェントのアクティブ化に関する問題
+ エージェントがオフラインになっている

## Amazon EC2 エージェントのローカルコンソールに接続するにはどうすればいいですか?
<a name="local-console-ec2"></a>

Amazon EC2 エージェントのローカルコンソールに接続するには、SSH を使用する必要があります。EC2 インスタンスのセキュリティグループが SSH (TCP ポート 22) によるアクセスを許可していることを確認します。

ターミナルで次の `ssh` コマンドを実行して、インスタンスに接続します。

```
ssh -i /path/key-pair-name.pem instance-user-name@instance-public-ip-address
```
+ */path/key-pair-name* には、インスタンスへの接続に必要なプライベートキーのパスとファイル名 (`.pem`) を指定します。
+ *instance-user-name* には、`admin` を指定します。
+ *instance-public-ip-address* には、インスタンスのパブリック IP アドレスを指定します。

## 「エージェントのアクティベーションキーの取得に失敗しました」エラーはどういう意味ですか?
<a name="vpc-activation-error"></a>

DataSync エージェントをアクティブ化するとき、エージェントは指定したサービスエンドポイントに接続してアクティベーションキーをリクエストします。このエラーは、ネットワークのセキュリティ設定により接続がブロックされている可能性があることを意味します。

**実行するアクション**  
仮想プライベートクラウド (VPC) サービスエンドポイントを使用している場合は、セキュリティグループ設定でエージェントが VPC エンドポイントへの接続を許可していることを確認します。必要なポートの詳細については、「[VPC または FIPS VPC サービスエンドポイントのネットワーク要件](datasync-network.md#using-vpc-endpoint)」を参照してください。

パブリックエンドポイントまたは連邦情報処理標準 (FIPS) エンドポイントを使用している場合は、ファイアウォールとルーターの設定で、エージェントによるエンドポイントへの接続が許可されていることを確認してください。詳細については、「[パブリックまたは FIPS サービスエンドポイントのネットワーク要件](datasync-network.md#using-public-endpoints)」を参照してください。

## VPC サービスエンドポイントを使用してエージェントをアクティブ化できません
<a name="vpc-activation-failed"></a>

VPC サービスエンドポイントで DataSync エージェントをアクティブ化する際の問題が解決しない場合は、「[エージェントがどのような状況なのかがわかりません。サポートを受けることはできますか?](#enable-support-access)」を参照してください。

## エージェントがオフラインの場合の対処は?
<a name="troubleshoot-agent-offline"></a>

DataSync エージェントがオフラインになる理由はいくつかありますが、オンラインに戻すことができる場合もあります。エージェントを削除して新しいエージェントを作成する前に、以下のチェックリストを確認して、何が起きたのか理解するのに役立ててください。
+ **バックアップチームに問い合わせる** — 仮想マシン (VM) がスナップショットまたはバックアップから復元されたためにエージェントがオフラインになっている場合は、[エージェントの交換](replacing-agent.md)が必要な場合があります。
+ **エージェントの VM または Amazon EC2 インスタンスがオフになっていないか確認する** — 使用しているエージェントのタイプに応じて、VM または EC2 インスタンスがオフになっている場合はオンに戻してみてください。再度オンになったら、[エージェントのネットワーク接続をテストします](test-agent-connections.md#test-network) AWS。
+ **エージェントが最小ハードウェア要件を満たしていることを確認する** — エージェントがアクティブ化されたため、VM または EC2 インスタンスの構成が誤って変更されて、エージェントがオフラインになっている可能性があります。たとえば、VM に最低限必要なメモリやスペースがなくなった場合、エージェントはオフラインと表示されることがあります。詳細については、「[AWS DataSync エージェントの要件](agent-requirements.md)」を参照してください。
+ **エージェント関連のソフトウェア更新が完了するまで待つ** — [AWSによるソフトウェア更新](managing-agent.md#managing-agent-updates)の後に、エージェントが一時的にオフラインになることがあります。これがエージェントがオフラインになっている理由だと思われる場合は、しばらく待ってから、エージェントがオンラインに戻っているかどうか確認してください。
+ **VPC サービスエンドポイントの設定を確認する** — オフラインのエージェントがパブリックサービスエンドポイントを使用していて、DataSync 用の VPC サービスエンドポイントを作成したのと同じ VPC 内にある場合は、その VPC エンドポイントの[プライベート DNS サポート](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)を無効にする必要がある場合があります。

上記のいずれにもエージェントがオフラインになる理由ではないと思われる場合は、[エージェントの交換](replacing-agent.md)が必要である可能性があります。

## エージェントがどのような状況なのかがわかりません。サポートを受けることはできますか?
<a name="enable-support-access"></a>

 AWS サポート に DataSync エージェントへのアクセスを許可し、エージェント関連の問題のトラブルシューティングに役立てることができます。その際は必ず、エージェントのローカルコンソールを介して有効にしてください。

**エージェント サポート へのアクセスを許可するには**

1. [エージェントのローカルコンソールにログインします](local-console-vm.md#local-console-login)。

1. プロンプトで、コマンドプロンプトを開くには**5**を入力します(VMware VM の場合は、**6**を使用してください)。

1. 「**h**」と入力して **[AVAILABLE COMMANDS (利用可能なコマンド)]** ウィンドウを開きます。

1. **AVAILABLE COMMANDS (利用可能なコマンド)**ウィンドウで、次のように入力して サポートに接続します:

   `open-support-channel`

   VPC エンドポイントでエージェントを使用している場合は、次のように、サポートチャネルの VPC エンドポイント IP アドレスを指定してください: 

   `open-support-channel vpc-ip-address`

    AWSへのサポートチャネルを開始するには、ファイアウォールでインバウンド TCP ポート 22 を許可する必要があります。に接続すると サポート、DataSync によってサポート番号が割り当てられます。サポート番号を書き留めます。
**注記**  
チャネル番号は TCP/UDP ポート番号ではありません。代わりに、サーバーへの SSH (TCP 22) 接続を確立し、接続のサポートチャネルを提供します。

1. サポートチャネルが確立されたら、サポートサービス番号を に提供 サポート して、トラブルシューティングのサポートを提供できるようにします。

1. サポートセッションが完了した時点で、**Enter**を押してセッションを終了します。

1. **exit**を入力して DataSync ローカルコンソーからログアウトします。

1. プロンプトに従ってローカルコンソールを終了します。

# DataSync ロケーションの問題のトラブルシューティング
<a name="troubleshooting-storage-issues"></a>

以下の情報は、 AWS DataSync ロケーションに関する問題のトラブルシューティングに役立ちます。これらの問題には、次のようなものがあります。
+ NFS ロケーションでのアクセス許可とマウントエラー
+ ファイル所有権の問題
+ Kerberos 認証を使用する SMB ロケーションへのアクセスに関する問題
+ Amazon S3 や Microsoft Azure Blob のロケーションなど、オブジェクトストレージのアクセス許可とアクセスに関する問題

## タスクが失敗し、NFS のアクセス許可が拒否されたというエラーが表示された
<a name="task-permission-denied"></a>

`root_squash` または `all_squash` を使用して NFS ファイルサーバーを設定しており、ファイルにすべての読み込みアクセスがない場合、「アクセス許可拒否」のエラーメッセージが表示されます。

**実行するアクション**  
この問題を修正するには、`no_root_squash` で NFS エクスポートを設定するか、または、転送するすべてのファイルの権限が、すべてのユーザーに対して読み取りアクセスを許可していることを確認します。

DataSync がディレクトリにアクセスするには、すべて実行アクセスを有効にする必要もあります。ディレクトリをマウントできることを確認するには、まずエージェントと同じネットワーク構成がある任意のコンピュータに接続します。次に以下の CLI コマンドを実行します。

`mount -t nfs -o nfsvers=<your-nfs-server-version> <your-nfs-server-name>:<nfs-export-path-you-specified> <new-test-folder-on-your-computer>`

それでも問題が解決しない場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。

## タスクが失敗し NFS マウントエラーと表示された
<a name="onpremise-location-stuck-mounting"></a>

NFS ファイルサーバーのロケーションに関連する DataSync タスクを実行したとき、次のエラーが表示される場合があります。

Task failed to access location loc-1111222233334444a: x40016: mount.nfs: Connection timed out

**実行するアクション**  
エラーが解決するまで以下を行います。

1. DataSync ロケーションで指定した NFS ファイルサーバーとエクスポートが有効であることを確認します。有効になっていなければロケーションとタスクを削除し、有効な NFS ファイルサーバーとエクスポートを使用している新しいロケーションとタスクを作成します。詳細については、「[DataSync コンソールの使用](create-nfs-location.md#create-nfs-location-console)」を参照してください。

1. エージェントと NFS ファイルサーバー間のファイアウォール設定を確認します。詳細については、「[オンプレミス、セルフマネージド、その他のクラウドストレージのネットワーク要件](datasync-network.md#on-premises-network-requirements)」を参照してください。

1. エージェントが NFS ファイルサーバーにアクセスでき、エクスポートをマウントできることを確認します。詳細については、「[DataSync に NFS ファイルサーバーへのアクセスを許可する](create-nfs-location.md#accessing-nfs)」を参照してください。

1. それでもエラーが表示される場合は、 でサポートチャネルを開きます サポート。詳細については、「[エージェントがどのような状況なのかがわかりません。サポートを受けることはできますか?](troubleshooting-datasync-agents.md#enable-support-access)」を参照してください。

## タスクが失敗し Amazon EFS マウントエラーが表示された
<a name="troubleshoot-efs-mount-target"></a>

Amazon EFS のロケーションに関連する DataSync タスクを実行したとき、次のエラーが表示される場合があります。

Task failed to access location loc-1111222233334444a: x40016: Failed to connect to EFS mount target with IP: 10.10.1.0.

このエラーは、ロケーションで設定した Amazon EFS ファイルシステムのマウントパスが、更新または削除されると発生することがあります。DataSync は、ファイルシステムにおけるこのような変更を認識しません。

**実行するアクション**  
ロケーションとタスクを削除して、[新しいマウントパスを使用して新しい Amazon EFS のロケーションを作成します](create-efs-location.md#create-efs-location-how-to)。

## ファイルの所有権は NFS 転送では維持されません
<a name="nfs-id-mapping"></a>

転送後、DataSync の送信先のロケーションにあるファイルのユーザー ID (UID) またはグループ ID (GID) が、送信元のロケーションにある同じファイルの ID と異なっていることに気付くことがあります。例えば、送信先のファイルの UID が `65534`、`99`、`nobody` になっている場合です。

このエラーは、転送に関連するファイルシステムが、DataSync がサポートしていない NFS バージョン 4 の ID マッピングを使用しているときに発生することがあります。

**実行するアクション**  
この問題に対処するには、次の 2 つの方法があります。
+ ファイルシステムに NFS バージョン 4 ではなくバージョン 3 を使用して新しいロケーション作成します。
+ ファイルシステムの NFS バージョン 4 ID マッピングを無効にします。

転送を再試行します。いずれのオプションでも問題は解決します。

## タスクが Kerberos を使用する SMB ロケーションにアクセスできない
<a name="task-fails-smb-location-kerberos"></a>

[Kerberos 認証](create-smb-location.md#configuring-smb-kerberos-authentication)を使用する SMB ロケーションでの DataSync エラーは通常、ロケーションと Kerberos 設定の不一致に関連しています。また、ネットワークに問題がある可能性もあります。

**ロケーションにアクセスできない**  
次のエラーは、SMB ロケーションまたは Kerberos の設定に問題がある可能性があることを示しています。  

```
Task failed to access location
```
**以下を確認します**。  
+ ロケーションに指定した SMB ファイルサーバーがドメイン名になっていること。Kerberos では、ファイルサーバーの IP アドレスを指定することはできません。
+ ロケーションに指定した Kerberos プリンシパルが、Kerberos キーテーブル (キータブ) ファイルの作成に使用したプリンシパルと一致していること。プリンシパル名では大文字と小文字が区別されます。
+ Kerberos プリンシパルのマッピングされたユーザーパスワードが、キータブファイルの作成後に変更されていないこと。パスワードのローテーションやその他の理由によってパスワードが変更された場合、タスクの実行が失敗し、次のエラーが発生する可能性があります。

  Task failed to access location loc-1111222233334444a: x40015: kinit: Preauthentication failed while getting initial credentials

**KDC 領域に接続できない**  
次のエラーは、ネットワークの問題を示しています。  

```
kinit: Cannot contact any KDC for realm 'MYDOMAIN.ORG' while getting initial credentials"
```
**以下を確認します**。  
+ DataSync に提供した Kerberos 設定ファイル (`krb5.conf`) に、Kerberos 領域に関する正しい情報が含まれていること。`krb5.conf` ファイルの例については、「[Prerequisites](create-smb-location.md#configuring-smb-kerberos-prerequisites)」を参照してください。
+ Kerberos Key Distribution Center (KDC) サーバーポートが開いていること。通常、KDC ポートは TCP ポート 88 です。
+ ネットワーク上の DNS 設定。

## タスクが入力/出力エラーで失敗した
<a name="sync-io-error"></a>

ストレージシステムが DataSync エージェントからの I/O リクエストに失敗した場合に、入力/出力エラーメッセージが表示されることがあります。一般的な原因には、サーバーディスクの障害、ファイアウォール構成の変更、ネットワークルーターの障害などがあります。

エラーが NFS ファイルサーバーまたは Hadoop 分散ファイルシステム (HDFS) クラスターに関連している場合は、次のステップを実行してエラーを解決します。

**実行するアクション (NFS)**  
まず、NFS ファイルサーバーのログとメトリクスを確認して、NFS サーバーに起因する問題かどうかを判断します。「はい」の場合は、その問題を解決してください。

次に、ネットワーク設定が変更されていないことを確認します。NFS ファイルサーバーが正しく設定され、DataSync がアクセス可能であるかどうかを確認するには、次の操作を行います。

1.  エージェントと同じネットワークサブネットに別の NFS クライアントをセットアップします。

1. そのクライアントに共有をマウントします。

1. クライアントが共有に正常に読み書きできることを確認します。

**実行するアクション (HDFS)**  
以下の手順を、エラーが解決するまで実行します。

1. HDFS クラスターが、クラスターの NameNode ポートおよび DataNode ポートとの通信を DataSync エージェントに許可していることを確認します。

   ほとんどのクラスターでは、クラスターが使用するポート番号は以下の設定ファイルで確認できます。
   + NameNode ポートを見つけるには、`fs.default` または `fs.default.name` プロパティ (Hadoop ディストリビューションによって異なります) の下にある `core-site.xml` ファイルを調べます。
   + DataNode ポートを見つけるには、`dfs.datanode.address` プロパティの下にある `hdfs-site.xml` ファイルを調べます。

1. `hdfs-site.xml` ファイルで `dfs.data.transfer.protection` プロパティに 1 つの値しかないことを確認します。例えば、次のようになります。

   ```
   <property>
      <name>dfs.data.transfer.protection</name>
      <value>privacy</value>
   </property>
   ```

## エラー: `FsS3UnableToConnectToEndpoint`
<a name="troubleshoot-fss3unabletoconnecttoendpoint"></a>

DataSync が [Amazon S3 ロケーション](create-s3-location.md)に接続できません。これは、その場所の S3 バケットにアクセスできないか、場所が正しく設定されていない可能性があります。

この問題が解決されるまで、以下を行います。
+ DataSync が [S3 バケットにアクセス](create-s3-location.md#create-s3-location-access)できるかどうかを確認します。
+ DataSync コンソールまたは [DescriLocationS3](https://docs.aws.amazon.com/datasync/latest/userguide/API_DescribeLocationS3.html) オペレーションを使用して、場所が正しく設定されていることを確認します。

## エラー: `FsS3HeadBucketFailed`
<a name="troubleshoot-fss3headbucketfailed"></a>

DataSync が、転送先または転送元の S3 バケットにアクセスできません。Amazon S3 [HeadBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_HeadBucket.html) オペレーションを使用して、DataSync にバケットへのアクセス許可があるかどうかを確認します。アクセス許可を調整する必要がある場合は、「[DataSync に対する S3 バケットへのアクセス許可の付与](create-s3-location.md#create-s3-location-access)」を参照してください。

## タスクが `Unable to list Azure Blobs on the volume root` のエラーで失敗する
<a name="troubleshoot-azure-blob-storage-list-volume-root"></a>

DataSync 転送タスクが `Unable to list Azure Blobs on the volume root` のエラーで失敗した場合は、共有アクセス署名 (SAS) トークンまたは Azure ストレージアカウントのネットワークに問題がある可能性があります。

**実行するアクション**  
次のことを試して、問題が解決するまでタスクを再度実行してください。
+ [SAS トークン](creating-azure-blob-location.md#azure-blob-sas-tokens)に、Microsoft Azure Blob Storage へのアクセスに必要な適切な許可があることを確認してください。
+ Azure で DataSync エージェントを実行している場合は、エージェントが存在する仮想ネットワークからのアクセスを許可するようにストレージアカウントを設定します。
+ Amazon EC2 でエージェントを実行している場合は、エージェントのパブリック IP アドレスからのアクセスを許可するように Azure ストレージのファイアウォールを設定します。

Azure のストレージアカウントのネットワークを設定する方法については、「[Azure Blob Storage ドキュメント](https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security)」を参照してください。

## エラー: `FsAzureBlobVolRootListBlobsFailed`
<a name="troubleshoot-fsazureblobvolrootlistblobsfailed"></a>

DataSync が Microsoft Azure Blob Storage へのアクセスに使用する共有アクセス署名 (SAS) トークンに、一覧表示を行うアクセス許可ありません。

この問題を解決するには、一覧表示を行うアクセス許可を持つトークンを使用して[ロケーションを更新](creating-azure-blob-location.md#azure-blob-update-location)し、再度タスクを実行します。

## エラー: `SrcLocHitAccess`
<a name="troubleshoot-srclochitaccess"></a>

DataSync が送信元のロケーションにアクセスできない。DataSync にそのロケーションにアクセスするためのアクセス許可があるかを確認してから再度タスクを実行します。

## エラー: `SyncTaskErrorLocationNotAdded`
<a name="troubleshoot-synctaskerrorlocationnotadded"></a>

DataSync がロケーションにアクセスできません。DataSync にそのロケーションにアクセスするためのアクセス許可があるかを確認してから再度タスクを実行します。

## エラー: `S3 location creation failed with (InvalidRequestException) when calling the CreateLocationS3 operation`
<a name="troubleshoot-403-error"></a>

このエラーは、IAM アクセス許可、Amazon S3 バケットポリシー、 AWS KMS アクセス許可、またはその他のアクセス許可の問題に関連している可能性があります。このエラーが発生した場合は、次の情報を使用してトラブルシューティングを行います。
+ 「*Amazon Simple Storage Service ユーザーガイド*」の「[Amazon S3 でのアクセス拒否 (403 Forbidden) エラーのトラブルシューティング](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html)」
+ での[ Amazon S3 からの 403 アクセス拒否エラーのトラブルシューティング方法を教えてください。](https://repost.aws/knowledge-center/s3-troubleshoot-403) AWS re:Post

## S3 ソースロケーションにアクセスするタスクが `HeadObject` または `GetObjectTagging` エラーで失敗する
<a name="troubleshoot-getobjecttagging"></a>

**`HeadObject` または `GetObjectTagging` に関連するエラー**  
S3 バケットから特定のバージョン ID を持つオブジェクトを転送すると、`HeadObject` または `GetObjectTagging` に関連したエラーが表示されることがあります。例えば、以下は `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
```

これらのエラーのいずれかが表示された場合は、DataSync が S3 の送信元のロケーションにアクセスするために使用する IAM ロールに、次のアクセス許可があることを確認します。
+ `s3:GetObjectVersion`
+ `s3:GetObjectVersionTagging`

これらのアクセス許可でロールを更新する必要がある場合は、「[DataSync が Amazon S3 ロケーションにアクセスするために必要な IAM ロールの作成](create-s3-location.md#create-role-manually)」を参照してください。

# DataSync タスクの問題のトラブルシューティング
<a name="troubleshooting-tasks"></a>

以下の情報は、 AWS DataSync タスクとタスク実行に関する問題のトラブルシューティングに役立ちます。これには、タスクのセットアップの問題や、タスク実行がスタックする、データが正常に転送されないといった問題が含まれます。

## エラー: Invalid SyncOption value. Option: TransferMode,PreserveDeletedFiles, Value: ALL,REMOVE.
<a name="create-task-deleted-files-error"></a>

このエラーは、DataSync タスクを作成または編集しているときに、**[すべてのデータを転送する]** オプションを選択し、**[削除されたファイルを保持する]** オプションを選択解除したときに発生します。

すべてのデータを転送すると、DataSync は送信先の場所をスキャンしないため、何を削除すればよいかわかりません。

## タスク実行が EniNotFound というエラーで失敗する
<a name="network-interfaces-not-found"></a>

このエラーは、仮想プライベートクラウド (VPC) のタスクのネットワークインターフェイスのいずれかを削除した場合に発生します。タスクがスケジュールされているかキューに入っている場合、[データの転送に必要なネットワークインターフェイス](required-network-interfaces.md)がないと、タスクは失敗します。

**実行するアクション**  
この問題に対処するには、次のオプションがあります。
+ タスクを手動で再起動します。これを行うと、DataSync はタスクの実行に必要な、不足しているネットワークインターフェイスをすべて作成します。
+ VPC のリソースをクリーンアップする必要がある場合は、まだ使用している DataSync タスクに関連するネットワークインターフェイスを削除しないようにしてください。

  タスクに割り当てられたネットワークインターフェイスを表示するには、次のいずれかを実行します。
  + [DescribeTask](https://docs.aws.amazon.com//datasync/latest/userguide/API_DescribeTask.html) オペレーションを使用します。ネットワークインターフェイスは、`SourceNetworkInterfaceArns` および `DestinationNetworkInterfaceArns` レスポンス要素で表示できます。
  + Amazon EC2 コンソールで、タスク ID (`task-f012345678abcdef0` など) を検索してネットワークインターフェイスを見つけます。
+ タスクを自動実行しないことを検討してください。これには、タスクのキューイングまたはスケジューリング (DataSync またはカスタムオートメーションによる) の無効化が含まれる場合があります。

## タスク実行が Cannot allocate memory というエラーで失敗する
<a name="error-cannot-allocate-memory"></a>

DataSync タスクが Cannot allocate memory というエラーで失敗した場合、いくつかの原因が考えられます。

**実行するアクション**  
問題が解消されるまで、次のことを試してください。
+ 転送にエージェントが関連している場合は、そのエージェントが[仮想マシン (VM)](agent-requirements.md#hardware) または [Amazon EC2 インスタンス](agent-requirements.md#ec2-instance-types)の要件を満たしていることを確認します。
+ [フィルター](filtering.md)を使用して転送を複数のタスクに分割します。[1 つの DataSync タスクで処理できる](datasync-limits.md#task-hard-limits)数よりも多くのファイルまたはオブジェクトを転送しようとしている可能性があります。
+ それでも問題が解決しない場合は、[サポートにお問い合わせください](https://aws.amazon.com/contact-us/)。

## FSx for ONTAP ファイルシステムでタスクが `Input/Output error` で失敗する
<a name="task-fails-input-output-fsxn"></a>

FSx for ONTAP ファイルシステムでデータを転送するときに DataSync タスクが `Input/Output error` で失敗した場合、次の 1 つまたは複数の問題が原因である可能性があります。

**FSx for ONTAP ボリュームが最大ファイル容量に達した**  
このエラーは、ボリュームで使用可能な inode またはファイルポインタの数を使い果たした場合に発生します。

**実行するアクション**

まず、ボリュームの[最大ファイル容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/view-volume-file-capacity.html)を表示します。次に、inode の数を増やすか、ストレージ容量を増やすことで、ボリュームのファイル容量を増やします。詳細については、「*ONTAP User Guide*」の「[Increasing a volume's maximum file capacity](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#max-file-capacity)」を参照してください。

**FSx for ONTAP ボリュームの使用可能なストレージ容量が不足している**  
このエラーは、ボリュームに使用可能なストレージ容量がない場合に発生します。

**実行するアクション**

まず、ボリュームの[使用可能なストレージ容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitor-volume-storage-console.html)を決定します。次に、ボリュームのストレージ容量を増やします。詳細については、「*ONTAP User Guide*」の「[Increasing a volume's storage capacity](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#increase-volume-capacity)」を参照してください。

**注記**  
必要に応じてボリュームのストレージ容量を自動的に増やすには、「*ONTAP User Guide*」の「[Using volume autosizing](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#volume-autosizing)」を参照してください。

**FSx for ONTAP ディレクトリが、各ディレクトリに保存できるファイルの最大数に達した**  
このエラーは、各ディレクトリに保存できるファイルの最大数に達したときに発生します。

**実行するアクション**

最大ディレクトリサイズを増やして、より大きなディレクトリをサポートできるようにします。詳細については、「*AWS 規範ガイダンス*」の「[Best practices for using the NetApp ONTAP maximum directory size](https://docs.aws.amazon.com/prescriptive-guidance/latest/fsx-ontap-enterprise-deployment/best-practices.html#bp-max-directory-size)」を参照してください。

**DataSync タスク実行で読み取りと書き込みの同時実行が多すぎて、ファイルシステムのスループットキャパシティの大部分を消費する**  
このエラーは、DataSync タスク実行がファイルシステムの使用可能なスループットキャパシティを過度に消費している場合に発生します。

**実行するアクション**

まず、次の方法を使用して、タスク実行がファイルシステムのスループットキャパシティを過剰に消費していたかどうかを判断します。
+ 使用可能な CloudWatch メトリクスを使用して、ファイルシステムのパフォーマンスをモニタリングします。詳細については、「*ONTAP User Guide*」の「[Monitoring file system metrics in the Amazon FSx console](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitor-throughput-cloudwatch.html#fsxn-howtomonitor-fs)」を参照してください。
+ Amazon FSx コンソールでファイルシステムをモニタリングし、ファイルサーバーのパフォーマンスに関する警告がないか確認します。詳細については、「*ONTAP User Guide*」の「[Use performance warnings to improve file system performance](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/performance-insights-FSxN.html#resolve-warnings)」を参照してください。

次に、以下のいずれかを実行して、タスクがファイルシステムの使用可能なスループットキャパシティをすべて使用しないようにします。
+ タスク実行の帯域幅制限を、FSx for ONTAP ファイルシステムのプロビジョニングされたスループットキャパシティよりも小さい量に設定します。詳細については、「[AWS DataSync タスクの帯域幅制限の設定](configure-bandwidth.md)」を参照してください。
+ ファイルシステムのプロビジョニングされたスループットキャパシティを増やします。詳細については、「*ONTAP User Guide*」の「[Updating throughput capacity](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/increase-throughput-capacity.html)」を参照してください。

## FSx for ONTAP ファイルシステムの `Connection Reset by peer` または `Host is down` メッセージでタスクが失敗する
<a name="task-fails-connect-reset-fsxn"></a>

FSx for ONTAP ファイルシステムでデータを転送するときに DataSync タスクが `Connection Reset by peer` または `Host is down` メッセージで失敗した場合、次の 1 つまたは複数の問題が原因である可能性があります。
+ タスク実行中に、ファイルシステムの SMB サーバーが再起動または切断されました。
+ タスク実行中に、ファイルシステムがプライマリサーバーからセカンダリサーバー (および IP アドレス) にフェイルオーバーしました。DataSync は、タスク実行中のセカンダリ IP アドレスへのフェイルオーバーをサポートしていません。

  FSx for ONTAP ファイルシステムは、次のイベントの発生時にセカンダリサーバーおよび IP アドレスにフェイルオーバーします。
  + プライマリサーバーが使用できなくなったとき。
  + プライマリサーバーのアベイラビリティーゾーンが使用できなくなったとき (マルチ AZ ファイルシステムの場合)。
  + ユーザーが開始したスループットキャパシティの変更中。
  + ファイルシステムの定期メンテナンス期間中。

  詳細については、「ONTAP User Guide」の「[Failover process for FSx for ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/high-availability-AZ.html#Failover)」を参照してください。

**実行するアクション**  
タスクを再起動します。

## タスク実行のステータスが [起動中] になっているが、何も起きていないように見える
<a name="task-stuck-starting"></a>

DataSync タスクは **[起動中]** のステータスでスタックすることがあります。これは通常、エージェントの電源がオフになっているか、ネットワーク接続が切断されているためです。

**実行するアクション**  
エージェントのステータスが**オンライン**であることを確認します。エージェントが **オフライン** の場合は、エージェントの電源が入っていることを確認します。

エージェントの電源がオンでもタスクが引き続き **起動中**のステータスのままである場合は、エージェントと AWSの間でネットワーク接続の問題が発生している可能性が高いです。ネットワーク接続をテストする方法については、「[エージェントと DataSync サービスとの接続の検証](test-agent-connections.md#test-network)」を参照してください。

それでもこの問題が解決しない場合は、「[エージェントがどのような状況なのかがわかりません。サポートを受けることはできますか?](troubleshooting-datasync-agents.md#enable-support-access)」を参照してください。

## タスク実行が [準備中] ステータスのままスタックしているように見える
<a name="Preparing-status-too-long"></a>

DataSync 転送タスクが **[準備中]** のステータスである時間は、転送元と転送先のデータ量、およびそれらのストレージシステムのパフォーマンスによって異なります。

タスクを開始すると、DataSync は再帰的なディレクトリのリストアップを実行して、送信元と送信先あるすべてのファイル、オブジェクト、ディレクトリ、メタデータを検出します。DataSync はこれらのリストを使用してストレージシステム間の違いを識別し、何をコピーするかを決定します。このプロセスには数分または数時間かかることがあります。

**実行するアクション**  
必要な操作はありません。タスクのステータスが **[転送中]** に変わるまで待機してください。それでもステータスが変わらない場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。

## 転送が終了する前にタスク実行が停止した
<a name="troubleshoot-unfinished-task-execution"></a>

DataSync タスクの実行が早期に停止する場合は、タスクの設定に、 AWS アカウントで無効になっている AWS リージョン が含まれている可能性があります。

**実行するアクション**  
タスクを再度実行するには、次の手順を実行します。

1. タスクのリージョンの[オプトインステータス](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)をチェックし、有効になっていることを確認します。

1. 再度[タスクを開始します](run-task.md)。

## Google Cloud Storage バケットから転送するとタスク実行が失敗する
<a name="troubleshoot-object-tags-google-cloud-storage"></a>

DataSync は Amazon S3 API を使用して Google Cloud Storage と通信するため、オブジェクトタグをコピーしようとすると DataSync 転送が失敗する可能性がある制限があります。問題に関連する次のメッセージが CloudWatch ログに表示されます。

[WARN] Failed to read metadata for file /*your-bucket*/*your-object*: S3 Get Object Tagging Failed: proceeding without tagging

これを防ぐには、転送タスクの設定時に **[オブジェクトのタグをコピーする]** オプションの選択を解除します。

## タスク実行のタイムスタンプに不一致がある
<a name="troubleshoot-task-exec-times"></a>

DataSync コンソールまたは Amazon CloudWatch Logs を確認したときに、DataSync タスク実行の開始時刻と終了時刻が、他のモニタリングツールに表示されるタイムスタンプと一致していないことがあります。これは、他のツールとは異なり、コンソールと CloudWatch ログでは、タスク実行が起動中またはキューに登録中の[状態](run-task.md#understand-task-execution-statuses)にある時間が考慮されるためです。

DataSync コンソールまたは CloudWatch ログと以下の場所の実行タイムスタンプを比較すると、この不一致に気付くことがあります。
+ 転送に関係するファイルシステムのログ
+ DataSync が書き込みを行った Amazon S3 オブジェクトの最終更新日
+ DataSync エージェントからのネットワークトラフィック
+ Amazon EventBridge イベント

## タスク実行が `NoMem` エラーで失敗する
<a name="troubleshoot-nomem"></a>

転送しようとしているデータセットは、DataSync には大きすぎる可能性があります。このエラーが表示された場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。

## タスク実行が `FsNfsIdMappingEnabled` エラーで失敗する
<a name="troubleshoot-nfsv4-idmapping"></a>

DataSync は NFSv4 ID マッピングをサポートしていません。これを回避するには、[NFSv3 を使用するように NFS の場所を設定します](create-nfs-location.md#configure-network-nfs-location)。

## オブジェクトが Azure Blob Storage への転送に失敗し、`user metadata key` エラーが表示された
<a name="troubleshoot-azure-blob-user-metadata"></a>

S3 バケットから Azure Blob Storage に転送を行うと、次のエラーが表示される場合があります。

```
[ERROR] Failed to transfer file /user-metadata/file1: Azure Blob user metadata key must be a CSharp identifier
```

これは、`/user-metadata/file1` に、有効な C\$1 識別子を使用していないユーザーメタデータが含まれていることを示します。詳細については、[Microsoft のドキュメント](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/identifier-names)を参照してください。

## 送信先ロケーションに `/.aws-datasync` フォルダがある
<a name="troubleshoot-leftover-folder"></a>

DataSync は、データ転送を容易にするために、送信先のロケーションに `/.aws-datasync` というフォルダを作成します。

DataSync は通常、転送後にこのフォルダを削除しますが、削除されていない可能性もあります。

**実行するアクション**  
実行中のタスク実行がそのロケーションにコピーされていない限り、このフォルダをいつでも削除することができます。

## SMB を使用してロケーション間でシンボリックリンクを転送できない
<a name="troubleshooting-smb-symbolic-links"></a>

タスク実行が終了したときに、次のエラーが表示されます。

```
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.
```

SMB ストレージシステム (SMB ファイルサーバーや Amazon FSx for Windows File Server ファイルシステムなど) 間で転送する場合、CloudWatch ログに次の警告とエラーが表示される場合があります。

```
[WARN] Failed to read metadata for file /appraiser/symlink: No data available
[ERROR] Failed to read metadata for directory /appraiser/symlink: No data available
```

**実行するアクション**  
DataSync は、これらのロケーションタイプ間で転送する場合、シンボリックリンク (またはハードリンク) の転送をサポートしていません。詳細については、「[によってコピーされたリンクとディレクトリ AWS DataSync](special-files-copied.md)」を参照してください。

## タスクレポートエラー
<a name="troubleshoot-task-report"></a>

タスクレポートで DataSync 転送を監視しようとすると、次のいずれかのエラーが発生する可能性があります。


| エラーメッセージ | 回避方法 | 
| --- | --- | 
|  ファイルパスが最大長の 4,096 文字を超えています。タスクレポートには書き込みができません  |  なし。DataSync は 4,096 バイトを超えるパスが含まれるファイルを転送できません。 詳細については、「[ストレージシステム、ファイル、オブジェクトの制限事項](datasync-limits.md#file-system-limits)」を参照してください。  | 
|  バケットまたは IAMロールが無効であるため、タスクレポートを S3 にアップロードできませんでした  |  [DataSync IAM ロール](creating-task-report.md#task-report-access)に、S3 バケットにタスクレポートをアップロードするための適切な許可があることを確認します。  | 
|  タスクレポートの生成前に実行エラーが発生しました  | [CloudWatch のログ](monitor-datasync.md)をチェックして、タスク実行が失敗した理由を特定します。 | 

# データ検証に関する問題のトラブルシューティング
<a name="troubleshooting-task-verification"></a>

デフォルトでは、 は転送の終了時にデータの AWS DataSync [整合性を検証](how-datasync-transfer-works.md#how-verifying-works)します。DataSync がデータの検証を完了する前に変更または削除されるファイルなど、一般的な検証エラーや警告を診断するには、次の情報を使用します。

検証に関する問題では、表示されるタスク実行エラーに加えて、[CloudWatch ログ](configure-logging.md) (または[タスクレポート](task-reports.md)) を確認することが有益です。DataSync の拡張モードタスクでは JSON 構造化ログが提供されるのに対し、基本モードタスクでは非構造化ログが提供されます。

## ファイルの内容に不一致がある
<a name="troubleshooting-mismatch-file-contents"></a>

タスク実行が終了したときに、次のエラーが表示されます。

```
Transfer and verification completed. Verification detected mismatches. Files with mismatches are listed in Cloud Watch Logs
```

CloudWatch ログを確認すると、送信元と送信先のロケーションで内容が異なるために検証に失敗したログが見つかるはずです。これは、転送中にファイルが変更された場合に発生する可能性があります。

例えば、次のログは、`file1.txt` に異なる `mtime`、`srcHash`、および `dstHash` 値があることを示しています。

**基本モードのログの例**  

```
[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
```

DataSync では、`mtime` は[準備](how-datasync-transfer-works.md#how-datasync-prepares)前にファイルに最後に書き込みが行われた時刻を表します。転送を検証する場合、DataSync は送信元と送信先のロケーションの `mtime` の値を比較します。このような検証の失敗は、ファイルの `mtime` が両方のロケーションで同じでない場合に発生します。`srcHash` と `dstHash` の違いは、ファイルの内容が両方のロケーションで一致しないことを示しています。

**実行するアクション**  
以下の操作を実行します。

1. エポックタイムコンバーターを使用して、送信元または送信先のファイルまたはオブジェクトが最近変更されたかどうかを判断します。これにより、どのバージョンが最新かを特定できます。

1. このエラーが再発しないようにするには、メンテナンス期間中、送信元と送信先でアクティビティがないときに実行するように[タスクをスケジュール](task-scheduling.md)します。

## ファイルの SMB メタデータに不一致がある
<a name="troubleshooting-mismatch-smb-attributes"></a>

タスク実行が終了したときに、次のエラーが表示されます。

```
Transfer and verification completed. Verification detected mismatches. Files with mismatches are listed in Cloud Watch Logs
```

Server Message Block (SMB) プロトコルをサポートするストレージシステム間で転送する際、ファイルの拡張 SMB 属性が送信元と送信先の間で一致しない場合に、このエラーが表示されることがあります。

例えば、次のログは、`file1.txt` がロケーション間で異なる `extAttrsHash` 値を持つことを示しています。これは、ファイルの内容は一致するものの、送信先で拡張属性が設定されていないことを表します。

**基本モードのログの例**  

```
[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
```

拡張属性に関連するエラーメッセージが表示される場合もあります。

```
[ERROR] Deferred error: WriteFileExtAttr2 failed to setextattrlist(filename="/directory1/directory2/file1.txt"): Input/output error
```

**実行するアクション**  
このエラーは通常、アクセスコントロールリスト (ACL) を送信先にコピーするためのアクセス許可が不十分な場合に発生します。この問題を解決するには、送信先タイプに基づいて以下の設定ガイドを確認してください。
+ FSx for Windows File Server ファイルシステムで[必要なアクセス許可](create-fsx-location.md#create-fsx-windows-location-permissions)
+ SMB を使用する FSx for ONTAP ファイルシステムで[必要なアクセス許可](create-ontap-location.md#create-ontap-location-smb)

## 転送するファイルがソースロケーションにない
<a name="source-files-deleted-preparation"></a>

タスク実行が終了したときに、次のエラーが表示されます。

```
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.
```

ログには、ファイルがソースロケーションにないことを示すエラーが表示される場合があります。このエラーは、DataSync が[準備](how-datasync-transfer-works.md#how-datasync-prepares)を完了した後、ファイルを転送する前にファイル (`file1.dll` や `file2.dll` など) が削除された場合に発生する可能性があります。

**基本モードのログの例**  

```
[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
```

**実行するアクション**  
このような状況を回避するには、ソースロケーションにアクティビティがないときに実行するように[タスクをスケジュールします](task-scheduling.md)。

例えば、メンテナンス期間中、ユーザーとアプリケーションがそのロケーションでアクティブに作業していないときにタスクを実行できます。

場合によっては、このエラーに関連付けられたログが見つからないことがあります。その場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。

## DataSync が送信先のデータを検証できない
<a name="troubleshooting-cant-verify-destination"></a>

タスク実行が終了したときに、次のエラーが表示されます。

```
Transfer and verification completed. Verification detected mismatches. Files with mismatches are listed in Cloud Watch Logs
```

DataSync が送信先ロケーションにある特定のフォルダやファイルを検証できないことを示すログが見つかるはずです。このエラーは次のようになります。

**基本モードのログの例**  

```
[ERROR] Failed to read metadata for destination file /directory1/directory2/file1.txt: No such file or directory
```

ファイルの場合、次のような検証の失敗が見つかることがあります。

**基本モードのログの例**  

```
[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
```

**実行するアクション**  
これらのログは、転送後、検証前に送信先のデータが削除されたことを示します (ログは、同じ時間枠内にデータが送信元ロケーションにアップロードされた場合と同じようになります)。

このような状況を回避するには、送信先ロケーションにアクティビティがないときに実行するように[タスクをスケジュールします](task-scheduling.md)。

例えば、メンテナンス期間中、ユーザーとアプリケーションがそのロケーションでアクティブに作業していないときにタスクを実行できます。

## DataSync がオブジェクトのメタデータを読み取れない
<a name="troubleshooting-cant-read-object-metadata"></a>

タスク実行が終了したときに、次のエラーが表示されます。

```
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.
```

Amazon S3 `HeadObject` リクエストが失敗したために DataSync が `file1.png` を読み取れないことを示すログが見つかるはずです。DataSync は、タスクの準備中および検証中に S3 ロケーションで [`HeadObject` リクエストを行います](create-s3-location.md#create-s3-location-s3-requests-made)。

**基本モードのログの例**  

```
[WARN] Failed to read metadata for file /file1.png: S3 Head Object Failed
```

**実行するアクション**  
この問題を修正するには、DataSync に S3 バケットを操作するための適切なレベルのアクセス許可があるかどうかを確認します。
+ DataSync が Amazon S3 ロケーションにアクセスするために使用する IAM ロールで、`s3:GetObject` アクセス許可が付与されていることを確認します。詳細については、「[必要なアクセス許可](create-s3-location.md#create-s3-location-required-permissions)」を参照してください。
+ S3 バケットがサーバー側の暗号化を使用している場合は、DataSync がそのバケット内のオブジェクトにアクセスできることを確認してください。詳細については、「[サーバー側の暗号化を使用して S3 バケットにアクセスする](create-s3-location.md#create-s3-location-encryption)」を参照してください。

## オブジェクトのシステム定義メタデータに不一致がある
<a name="troubleshooting-verification-object-system-metadata"></a>

S3 バケット間の拡張モードタスクの実行が終了したときに、次のエラーが表示されます。

```
Verification failed due to a difference in metadata
```

オブジェクトの Amazon S3 [システム定義メタデータ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingMetadata.html#SysMetadata)の不一致を示すログが見つかるはずです。この例では、送信元のオブジェクトには `Content-Type` メタデータがありませんが、送信先のオブジェクトにはあります。このエラーは、DataSync がオブジェクトを転送したときに、送信先 S3 バケットがオブジェクトに `"ContentType": "application/octet-stream"` メタデータを自動的に適用したために発生しました。

**拡張モードのログの例**  

```
{
    "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"
}
```

**実行するアクション**  
このエラーを回避するには、送信元ロケーションのオブジェクトを更新して `Content-Type` メタデータプロパティを追加します。

## データの検証期間について
<a name="verifying-status-too-long"></a>

DataSync の検証には、ファイルの全内容に対する SHA256 チェックサムと、ロケーション間のファイルメタデータの正確な比較が含まれます。検証にかかる時間は、関連するファイルまたはオブジェクトの数、ストレージシステム内のデータのサイズ、これらのシステムのパフォーマンスなど、いくつかの要因によって決まります。

**実行するアクション**  
検証時間に影響を与える可能性のある要因を考慮すると、何もする必要はありません。ただし、タスクの実行が[検証中](run-task.md#understand-task-execution-statuses)ステータスでスタックしているように見える場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。

# DataSync を使用すると S3 のストレージコストが予想よりも高くなる問題のトラブルシューティング
<a name="multipart-upload-policy"></a>

 AWS DataSync 転送後の Amazon S3 ストレージのコストが予想以上に高い場合は、次の理由のうちのいずれか、または複数が原因である可能性があります。
+ S3 バケットとの間で転送する場合、DataSync により、S3 API リクエストに関連するコストが発生します。
+ DataSync は、Amazon S3 マルチパートアップロード機能を使用して S3 バケット にオブジェクトをアップロードします。このアプローチでは、正常に完了しなかったアップロードに対して、予期しないストレージ料金が発生することがあります。
+ コンソールで **[オブジェクトタグをコピー]** が有効になっているか、`ObjectTags` が `PRESERVE` に設定されている場合、DataSync は送信元オブジェクトと送信先オブジェクトからオブジェクトタグをコピーします。これらのオブジェクトタグをコピーすると、S3 API リクエストのコストが発生する可能性があります。
+ オブジェクトのバージョニングが S3 バケットで有効化されている可能性があります。オブジェクトのバージョニングは、Amazon S3 によって同じ名前を持つオブジェクトが複数のコピーに保存されるという結果になります。

**実行するアクション**  
このような場合は、以下の手順を実行できます。
+ DataSync が S3 リクエストをどのように使用するか、またそれらがストレージコストにどのように影響するかを必ず理解してください。詳細については、「[DataSync を使用する場合の S3 リクエストコストの評価](create-s3-location.md#create-s3-location-s3-requests)」を参照してください。
+ 問題がマルチパートアップロードに関連している場合は、S3 バケットのマルチパートアップロードのポリシーを設定して、不完全なマルチパートアップロードをクリーンアップしてストレージコストを削減します。詳細については、 AWS ブログ記事 [S3 Lifecycle Management Update - Support for Multipart Uploads and Delete Markers](https://aws.amazon.com/blogs/aws/s3-lifecycle-management-update-support-for-multipart-uploads-and-delete-markers/) を参照してください。
+ オブジェクトタグのコピーに関連する問題で、オブジェクトタグを必要としない場合は、DataSync コンソールで **[オブジェクトタグのコピー]** チェックボックスをオフにするか、タスクの作成、開始、または更新時に `ObjectTags` を `None` に設定します。
+ 問題がオブジェクトのバージョニングに関連している場合は、S3 バケットのオブジェクトのバージョニングを無効にしてください。

追加のヘルプが必要な場合は、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)にお問い合わせください。