本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 疑难解答 AWS DataSync 问题
使用以下信息对 AWS DataSync 问题和错误进行故障排除。
**Topics**
+ [对 DataSync 代理问题进行故障排除](troubleshooting-datasync-agents.md)
+ [对 DataSync 位置问题进行故障排除](troubleshooting-storage-issues.md)
+ [对 DataSync 任务问题进行故障排除](troubleshooting-tasks.md)
+ [解决数据验证的问题](troubleshooting-task-verification.md)
+ [使用 S3 存储成本高于预期进行故障排除 DataSync](multipart-upload-policy.md)
# 对 DataSync 代理问题进行故障排除
使用以下信息来帮助您解决与 AWS DataSync 代理有关的问题。其中一些问题可能包括：
+ 连接到 Amazon EC2 代理的本地控制台时出错
+ 未能检索代理的激活密钥
+ 使用 VPC 服务端点激活代理时出现问题
+ 发现代理处于离线状态
## 如何连接到 Amazon EC2 代理的本地控制台？
要连接到 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 地址。
## 无法检索代理激活密钥错误是什么意思？
激活 DataSync 代理时，代理会连接到您指定的服务端点以请求激活密钥。此错误可能意味着您的网络安全设置阻止了连接。
**要采取的操作**
如果您正在使用虚拟私有云（VPC）服务端点，请验证您的安全组设置是否允许代理连接到 VPC 端点。有关所需端口的信息，请参阅[VPC 或 FIPS VPC 服务端点的网络要求](datasync-network.md#using-vpc-endpoint)。
如果您使用的是公共或联邦信息处理标准（FIPS）端点，请检查您的防火墙和路由器设置，以允许您的代理连接到该端点。有关信息，请参阅[公共或 FIPS 服务端点的网络要求](datasync-network.md#using-public-endpoints)。
## 我仍然无法使用 VPC 服务端点激活代理
如果您在使用 VPC 服务终端节点激活 DataSync 代理时仍然遇到问题，请参阅 [我不知道我的代理出了什么问题。有人能帮我吗？](#enable-support-access)
## 如果我的代理处于离线状态，我该怎么办？
您的 DataSync 代理可能出于多种原因而处于离线状态，但您也许可以将其恢复在线。在删除代理并创建新代理之前，请仔细阅读以下清单，以帮助您了解可能发生的情况。
+ **联系您的备份团队** — 如果您的代理由于其虚拟机 (VM) 已从快照或备份中恢复而处于离线状态，则可能需要[更换代理](replacing-agent.md)。
+ **检查代理的虚拟机或 Amazon EC2 实例是否已关闭** — 根据您使用的代理类型，如果虚拟机或 EC2 实例已关闭，请尝试将其重新打开。再次开启后，[测试您的代理与的网络连接](test-agent-connections.md#test-network) AWS。
+ **验证您的代理是否满足最低硬件要求** — 您的代理可能处于离线状态，因为自代理激活以来，其虚拟机或 EC2 实例配置被意外更改。例如，如果您的虚拟机不再具有所需的最低内存或空间，则代理可能会显示为离线。有关更多信息，请参阅 [对 AWS DataSync 代理人的要求](agent-requirements.md)。
+ **等待代理相关的软件更新完成** — 您的代理可能会在[AWS提供的软件更新](managing-agent.md#managing-agent-updates)后短暂脱机。如果您认为这是代理离线的原因，请稍等片刻，然后检查代理是否恢复联机。
+ **检查您的 VPC 服务终端节点设置** — 如果您的离线代理使用公共服务终端节点，并且也在您为其创建 VPC 服务终端节点的同一 VPC 中 DataSync，则可能需要禁用该 VPC 终端节点的[私有 DNS 支持](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)。
如果这些似乎都不是代理离线的原因，则可能需要[更换代理](replacing-agent.md)。
## 我不知道我的代理出了什么问题。有人能帮我吗？
您可以允许 AWS 支持 访问您的 DataSync 代理并帮助解决与代理相关的问题。您必须通过代理的本地控制台启用此访问权限。
**向您的代理提供 支持 访问权限**
1. [登录到代理的本地控制台](local-console-vm.md#local-console-login)。
1. 在提示符处，输入**5**以打开命令提示符（fo VMware VMs r，使用**6**）。
1. 输入 **h** 以打开 **AVAILABLE COMMANDS** 窗口。
1. 在 **AVAILABLE COMMANDS（可用命令）**窗口中，输入以下内容连接 支持：
`open-support-channel`
如果您使用带有 VPC 端点的代理，则必须为支持通道提供 VPC 端点 IP 地址，如下所示：
`open-support-channel vpc-ip-address`
您的防火墙必须允许入站 TCP 端口 22 以启动针对 AWS的支持通道。当您连接到时 支持，会为您 DataSync 分配一个支持号码。请记下您的支持编号。
**注意**
信道号不是 TCP/UDP 端口号。相反，它建立到服务器的 SSH (TCP 22) 连接，并为该连接提供支持通道。
1. 建立支持渠道后，请向提供您的支持服务号码， 支持 以便他们可以提供故障排除帮助。
1. 在支持会话完成后，按下 **Enter** 以结束。
1. 输入**exit**以注销 DataSync 本地控制台。
1. 按照提示操作退出本地控制台。
# 对 DataSync 位置问题进行故障排除
使用以下信息来帮助您解决 AWS DataSync 营业地点问题。其中一些问题可能包括：
+ NFS 位置的权限和挂载错误
+ 文件所有权问题
+ 访问使用 Kerberos 身份验证的 SMB 位置时出现问题
+ 对象存储的权限与访问问题，例如 Amazon S3 和 Microsoft Azure Blob 位置
## 我的任务失败，出现 NFS 权限被拒绝错误
如果用 `root_squash` 或 `all_squash` 配置 NFS 服务器，并且您的文件没有所有读取访问权限，则可能会显示“权限被拒绝”错误消息。
**要采取的操作**
要修复此问题，请用 `no_root_squash` 配置 NFS 导出，或者确保要传输的所有文件的权限允许所有用户进行读取访问。
DataSync 要访问目录，还必须启用所有执行访问权限。要确保可以挂载目录，首先连接到与代理具有相同网络配置的任何计算机。然后运行以下 CLI 命令：
`mount -t nfs -o nfsvers= : `
如果问题仍未解决，请联系[AWS 支持 中心](https://console.aws.amazon.com/support/home#/)。
## 我的任务失败，出现 NFS 挂载错误
在运行涉及 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 挂载错误
在运行涉及 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 传输未保留文件所有权
传输完成后，您可能会注意到 DataSync 目标位置的文件具有不同的用户 IDs (UIDs) 或组 IDs (GIDs)，而不是源位置的相同文件。例如，目标位置中文件的 UID 可能是 `65534`、`99` 或 `nobody`。
如果传输中涉及的文件系统使用 NFS 版本 4 ID 映射（该功能 DataSync 不支持），则可能会发生这种情况。
**要采取的操作**
您有几种方法可以解决此问题：
+ 为使用 NFS 版本 3（而不是版本 4）的文件系统创建一个新位置。
+ 在文件系统上禁用 NFS 版本 4 ID 映射。
重试传输。无论哪种方法都应解决问题。
## 我的任务无法访问使用 Kerberos 的 SMB 位置
DataSync 使用 [Kerberos 身份验证的 SMB 位置出现错误通常与您的位置与 Kerber](create-smb-location.md#configuring-smb-kerberos-authentication) os 配置不匹配有关。也可能存在网络问题。
**无法访问位置**
以下错误表示 SMB 位置或 Kerberos 设置可能存在配置问题：
```
Task failed to access location
```
**验证以下各项**：
+ 您为所在位置指定的 SMB 文件服务器是一个域名。对于 Kerberos，无法指定文件服务器的 IP 地址。
+ 您为所在位置指定的 Kerberos 主体与用于创建 Kerberos 密钥表（keytab）文件的主体相匹配。主体名称区分大小写。
+ 自创建 keytab 文件以来，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"
```
**验证以下各项**：
+ 您提供的 Kerberos 配置文件 (`krb5.conf`) 包含有关您的 K DataSync erberos 领域的正确信息。有关示例 `krb5.conf` 文件，请参阅 [Kerberos 身份验证的先决条件](create-smb-location.md#configuring-smb-kerberos-prerequisites)。
+ Kerberos 密钥分配中心（KDC）的服务器端口已打开。KDC 端口通常为 TCP 端口 88。
+ 网络上的 DNS 配置。
## 我的任务因 input/output 错误而失败
如果您的存储系统未能通过 DataSync 代理 I/O 请求，则会收到一条 input/output 错误消息。常见原因包括服务器磁盘故障、防火墙配置更改或网络路由器故障。
如果错误涉及 NFS 文件服务器或 Hadoop Distributed File System（HDFS）集群，请跟随以下步骤来解决错误。
**采取的操作（NFS）**
首先检查 NFS 文件服务器的日志和指标，以确定问题是否始于 NFS 服务器。如果是，请解决该问题。
接下来，检查网络配置是否尚未更改。要检查 NFS 文件服务器的配置是否正确以及是否 DataSync 可以访问它，请执行以下操作：
1. 在与代理相同的网络子网上设置另一个 NFS 客户端。
1. 在客户端上装载您的共享。
1. 验证客户端可以成功地读取和写入共享。
**采取的操作（HDFS）**
在解决错误之前，请执行以下操作：
1. 确保您的 HDFS 集群允许您的 DataSync 代理与集群 NameNode 和 DataNode 端口通信。
在大多数集群中，您可以在以下配置文件中找到集群使用的端口号：
+ 要找到 NameNode 端口，请在`fs.default`或`fs.default.name`属性下的`core-site.xml`文件中查找（取决于 Hadoop 发行版）。
+ 要找到端 DataNode 口，请在`dfs.datanode.address`属性下的`hdfs-site.xml`文件中查找。
1. 在您的 `hdfs-site.xml` 文件中，验证您的 `dfs.data.transfer.protection` 属性是否只有一个值。例如：
```
dfs.data.transfer.protection
privacy
```
## 错误：`FsS3UnableToConnectToEndpoint`
DataSync 无法连接到你的 [Amazon S3 地点](create-s3-location.md)。这可能意味着无法访问该位置的 S3 存储桶，或者该位置的配置不正确。
在解决问题之前，请执行以下操作：
+ 检查是否 DataSync 可以[访问您的 S3 存储桶](create-s3-location.md#create-s3-location-access)。
+ 使用 DataSync 控制台或 [DescribeLocationS3](https://docs.aws.amazon.com/datasync/latest/userguide/API_DescribeLocationS3.html) 操作确保位置配置正确。
## 错误：`FsS3HeadBucketFailed`
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` 错误而失败
如果您的 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 的相应权限。
+ 如果您在中运行 DataSync 代理Azure，请将您的存储帐户配置为允许从代理所在的虚拟网络进行访问。
+ 如果您在 Amazon EC2 上运行代理，请将 Azure 存储防火墙配置为允许从代理的公有 IP 地址进行访问。
有关如何配置 Azure 存储账户网络的信息，请参阅[Azure Blob Storage 文档](https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security)。
## 错误：`FsAzureBlobVolRootListBlobsFailed`
DataSync 用于访问您的共享访问签名 (SAS) 令牌Microsoft Azure Blob Storage没有 “列表” 权限。
要解决问题，请使用具有列表权限的令牌[更新您的位置](creating-azure-blob-location.md#azure-blob-update-location)，然后尝试重新运行任务。
## 错误：`SrcLocHitAccess`
DataSync 无法访问您的来源位置。检查是否 DataSync 有权访问该地点，然后尝试再次运行您的任务。
## 错误：`SyncTaskErrorLocationNotAdded`
DataSync 无法访问您的位置。检查是否 DataSync 有权访问该地点，然后尝试再次运行您的任务。
## 错误：`S3 location creation failed with (InvalidRequestException) when calling the CreateLocationS3 operation`
此错误可能与 IAM 权限、Amazon S3 存储桶策略、 AWS KMS 权限或其他权限问题有关。如果遇到此错误，请使用以下信息进行故障排除：
+ 《Amazon Simple Storage Service 用户指南》**中的[排查 Amazon S3 中的拒绝访问（403 禁止）错误](https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html)。
+ [如何解决来自 Amazon S3 的 403 访问被拒绝错误？](https://repost.aws/knowledge-center/s3-troubleshoot-403) on AWS re:Post
## S3 源位置的任务失败并显示 `HeadObject` 或 `GetObjectTagging` 错误
**与 `HeadObject` 或 `GetObjectTagging` 相关的错误**
如果您要 IDs 从 S3 存储桶传输具有特定版本的对象，则可能会看到与`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`
如果您需要更新角色，使其具有这些权限，请参阅 [为创建 IAM 角色 DataSync 以访问您的 Amazon S3 位置](create-s3-location.md#create-role-manually)。
# 对 DataSync 任务问题进行故障排除
使用以下信息来帮助您解决与 AWS DataSync 任务和任务执行有关的问题。这些问题可能包括任务设置问题、任务执行卡滞以及数据无法按预期传输。
## 错误：SyncOption 值无效。选项： TransferMode，PreserveDeletedFiles，值：全部，移除。
当您创建或编辑 DataSync 任务并选择 “**传输所有数据**” 选项并取消选择 “**保留已删除文件**” 选项时，就会发生此错误。
当您传输所有数据时， DataSync 不会扫描您的目标位置，也不知道要删除什么。
## 任务执行失败并EniNotFound出现错误
如果您删除虚拟私有云（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 或自定义自动化）。
## 任务执行失败，出现无法分配内存错误
当您的 DataSync 任务因无法分配内存错误而失败时，这可能意味着一些不同的含义。
**要采取的操作**
请尝试以下操作，直到问题不再出现为止：
+ 如果传输涉及代理，请确保代理符合[虚拟机（VM）](agent-requirements.md#hardware)或 [Amazon EC2 实例](agent-requirements.md#ec2-instance-types)的要求。
+ 使用[筛选器](filtering.md)将传输分成多个任务。您尝试传输的文件或对象可能超出了[一项 DataSync 任务所能处理的范围](datasync-limits.md#task-hard-limits)。
+ 如果问题依然存在，[请联系 支持](https://aws.amazon.com/contact-us/)。
## `Input/Output error`对于 ONTAP 文件 FSx 系统，任务失败
当您的 DataSync 任务在使用 for ONTAP 文件系统传输数据`Input/Output error`时失败时，可能是由于以下一个或多个问题所致。 FSx
**FSx 适用于 ONTAP 的卷已达到其最大文件容量**
卷上可用的索引节点或文件指针数量用尽时，就会出现此错误。
**要采取的行动**
首先，查看该卷的[最大文件容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/view-volume-file-capacity.html)。然后，通过增加索引节点数量或增大存储容量来增加卷的文件容量。有关更多信息，请参阅《f [or *ONTAP 用户指南*》FSx 中的增加卷的最大文件容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#max-file-capacity)。
**FSx 适用于 ONTAP 的卷已用完可用存储容量**
如果卷上没有可用存储容量，就会出现此错误。
**要采取的行动**
首先，确定卷的[可用存储容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitor-volume-storage-console.html)？ 然后增加卷的存储容量 有关更多信息，请参阅《f [or *ONTAP 用户指南》中的增加卷FSx 的*存储容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#increase-volume-capacity)。
**注意**
要在需要时自动增加卷的存储容量，请参阅《*FSx 适用于 ONTAP 的用户*指南》中的 “[使用卷自动调整](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#volume-autosizing)大小”。
**f FSx or ONTAP 目录已达到每个目录中可以存储的最大文件数**
当达到每个目录中可存储的最大文件数时，就会出现此错误。
**要采取的操作**
增加最大目录大小以支持更大的目录。有关更多信息，请参阅*AWS 规范性*指南[中的 FSx 使用 ONTAP 最大目录大小的最佳实践](https://docs.aws.amazon.com/prescriptive-guidance/latest/fsx-ontap-enterprise-deployment/best-practices.html#bp-max-directory-size)。
**DataSync 任务执行产生了过多的读写并发性，占用了文件系统吞吐容量的很大一部分**
当 DataSync 任务执行消耗了文件系统的可用吞吐量过多时，就会发生此错误。
**要采取的行动**
首先，使用以下方法确定任务执行是否消耗了过多的文件系统吞吐能力：
+ 使用可用 CloudWatch 指标监控文件系统的性能。有关更多信息，请参阅《适用于 *ONTAP 的用户指南*》FSx 中的[监控文件系统指标](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitor-throughput-cloudwatch.html#fsxn-howtomonitor-fs)。
+ 在 Amazon FSx 控制台中监控文件系统是否存在文件服务器性能警告。有关更多信息，请参阅《适用于 *ONTAP 的用户指南*》FSx 中的[性能警告和建议](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/performance-insights-FSxN.html#resolve-warnings)。
然后，通过执行以下操作之一，确保任务未用尽文件系统的所有可用吞吐能力：
+ 将任务执行的带宽限制设置 FSx 为小于 ONTAP 文件系统的预配置吞吐量容量。有关更多信息，请参阅 [为 AWS DataSync 任务设置带宽限制](configure-bandwidth.md)。
+ 提高文件系统的预置吞吐能力。有关更多信息，请参阅 *ONTAP 用户指南*中的[FSx 更新吞吐量容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/increase-throughput-capacity.html)。
## 任务失`Connection Reset by peer`败并显示 ONTAP 文件系统的`Host is down`消息 FSx
如果您的 DataSync 任务在使用 for ONTAP 文件系统传输数据时失败并`Host is down`显示`Connection Reset by peer`或消息，则可能是由于以下一个或多个问题所致： FSx
+ 在任务执行期间，文件系统的 SMB 服务器重启或以其他方式断开连接。
+ 任务执行期间，文件系统从主服务器（和 IP 地址）故障转移到辅助服务器。 DataSync 不支持在任务执行期间故障转移到辅助 IP 地址。
FSx 对于 ONTAP 文件系统在以下事件期间故障切换到辅助服务器和 IP 地址：
+ 主服务器不可用。
+ 主服务器的可用区变为不可用（对于多可用区文件系统而言）。
+ 在用户启动的吞吐能力更改期间。
+ 在文件系统的定期维护时段内。
有关更多信息，请参阅《[FSx 适用于 ONTAP 的用户指南》 FSx 中的 ONTAP 故障转移流程](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/high-availability-AZ.html#Failover)。
**要采取的操作**
重新启动任务。
## 任务执行处于启动状态，但似乎什么也没发生
您的 DataSync 任务可能会停留在 “**启动**” 状态，这通常是因为代理已关闭电源或已断开网络连接。
**要采取的操作**
确保您的代理的状态为**在线**。如果代理处于**离线状态**，请确保其已开机。
如果代理已打开电源并且任务仍停滞在**正在启动**状态，则很可能是您的代理和 AWS之间出现网络连接问题。有关如何测试网络连接的信息，请参阅[验证您的代理与 DataSync 服务的连接](test-agent-connections.md#test-network)。
如果您仍遇到此问题，请参阅 [我不知道我的代理出了什么问题。有人能帮我吗？](troubleshooting-datasync-agents.md#enable-support-access)。
## 任务执行似乎卡在准备状态
DataSync 传输任务处于 “**准备**中” 状态的时间取决于传输源和目标中的数据量以及这些存储系统的性能。
任务启动时， DataSync 执行递归目录列表以发现源和目标中的所有文件、对象、目录和元数据。 DataSync 使用这些列表来识别存储系统之间的差异并确定要复制的内容。此过程可能耗时数分钟甚至数小时。
**要采取的操作**
您无需做任何事情。只需继续等待直至任务状态变为**正在传输**。如果状态仍未变更，请联系 [AWS 支持 中心](https://console.aws.amazon.com/support/home#/)。
## 任务执行在传输完成之前停止
如果您的 DataSync 任务执行提前停止，则您的任务配置中可能包含已禁用的 AWS 账户。 AWS 区域
**要采取的操作**
执行以下操作以重新运行任务：
1. 检查任务区域的[选择加入状态](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)，并确保它们已启用。
1. 再次[启动任务](run-task.md)。
## 从 Google 云存储桶传输时，任务执行失败
由于使用 Amazon S3 API DataSync 与 Google 云存储进行通信，因此如果您尝试复制对象标签，则存在一个限制，可能会导致 DataSync 传输失败。您的 CloudWatch 日志中会显示以下与该问题相关的消息：
[警告] 无法读取文件的元数据/*your-bucket*/*your-object*: S3 获取对象标记失败：继续不加标记
为防止出现这种情况，请在配置传输任务设置时取消选择**复制对象标签**选项。
## 任务执行的时间戳不匹配
在查看 DataSync 控制台或 Amazon CloudWatch 日志时，您可能会注意到 DataSync 任务执行的开始和结束时间与您在其他监控工具中看到的时间戳不匹配。这是因为控制台和 CloudWatch 日志会考虑任务执行在启动或排队[状态](run-task.md#understand-task-execution-statuses)下所花费的时间，而其他一些工具则没有。
在比较 DataSync 控制台或 CloudWatch 日志与以下位置之间的执行时间戳时，您可能会注意到这种差异：
+ 传输中涉及的文件系统的日志
+ DataSync 写入到 Amazon S3 对象的最后修改日期
+ 来自 DataSync 代理的网络流量
+ 亚马逊 EventBridge 活动
## 任务执行失败并出现 `NoMem` 错误
您要传输的数据集可能太大 DataSync。如果您看到此错误，请联系 [AWS 支持 中心](https://console.aws.amazon.com/support/home#/)。
## 任务执行失败并出现 `FsNfsIdMappingEnabled` 错误
DataSync 不支持 NFSv4 ID 映射。要解决此问题，[请配置要使用 NFSv3的 NFS 位置](create-nfs-location.md#configure-network-nfs-location)。
## 对象无法传输到 Azure Blob Storage，并出现 `user metadata key` 错误
从 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` 文件夹
DataSync `/.aws-datasync`在目标位置创建一个名为的文件夹，以帮助简化数据传输。
虽然 DataSync 通常会在传输后删除此文件夹，但在某些情况下可能不会发生这种情况。
**要采取的操作**
只要没有正在执行的任务将数据复制到该位置，您就可以随时删除此文件夹。
## 无法使用 SMB 在两个位置之间传输符号链接
当任务执行完毕后，您会看到以下错误：
```
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 文件服务器和 Ama FSx zon for Windows 文件服务器文件系统）之间传输时，您可能会在日志中看到以下警告和错误： 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)。
## 任务报告错误
在尝试使用任务报告监控您的 DataSync传输时，您可能会遇到以下错误之一。
| 错误消息 | 解决办法 |
| --- | --- |
| 文件路径超过了 4096 个字符的最大长度。无法写入任务报告 | 无。 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)，确定任务执行失败的原因。 |
# 解决数据验证的问题
默认情况下，[会在传输结束时 AWS DataSync 验证数据的完整性](how-datasync-transfer-works.md#how-verifying-works)。使用以下信息来帮助您诊断常见的验证错误和警告，例如在 DataSync 完成数据验证之前文件被修改或删除。
对于验证问题，很多时候，除了看到的[任务执行错误之外，查看[CloudWatch 日志](configure-logging.md)（或任务报告](task-reports.md)）也会有所帮助。 DataSync为增强模式任务提供 JSON 结构化日志，而基本模式任务具有非结构化日志。
## 文件内容不匹配
当任务执行完毕后，您会看到以下错误：
```
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. 使用 epoch 时间转换器，确定源文件或目标文件或对象最近是否遭到修改。这有助于确定最新版本。
1. 为避免再次出现此错误，请[将任务安排](task-scheduling.md)在维护时段内运行，此时源和目标处于不活动状态。
## 文件的 SMB 元数据不匹配
当任务执行完毕后，您会看到以下错误：
```
Transfer and verification completed. Verification detected mismatches. Files with mismatches are listed in Cloud Watch Logs
```
在支持服务器消息块（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
```
**要采取的操作**
当没有足够的权限将访问控制列表 (ACLs) 复制到目标时，通常会发生此错误。要解决此问题，请根据目标类型查看以下配置指南：
+ Windows 文件服务器文件系统@@ [所需的权限](create-fsx-location.md#create-fsx-windows-location-permissions) FSx
+ 使用 SMB FSx 的 ONTAP 文件系统@@ [所需的权限](create-ontap-location.md#create-ontap-location-smb)
## 要传输的文件已不在源位置
当任务执行完毕后，您会看到以下错误：
```
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.
```
在日志中，您可能会看到表明文件不在源位置的错误消息。如果文件（例如`file1.dll`和`file2.dll`）在[准备](how-datasync-transfer-works.md#how-datasync-prepares)之后但在 DataSync 传输之前被删除，则会发生这种情况：
**基本模式的日志示例**
```
[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 无法验证目标数据
当任务执行完毕后，您会看到以下错误：
```
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 无法读取对象元数据
当任务执行完毕后，您会看到以下错误：
```
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 可能会注意到由`file1.png`于 Amazon S3 `HeadObject` 请求失败而无法读取。 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)。
## 对象的系统定义元数据不匹配
在 S3 存储桶之间的增强模式任务执行完毕后，您会看到以下错误：
```
Verification failed due to a difference in metadata
```
您可能会在日志中注意到，对象的 Amazon S3 [系统定义元数据](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingMetadata.html#SysMetadata)不匹配。在这一特定示例中，源对象没有 `Content-Type` 元数据，但目标对象有。之所以发生这种情况，是因为目标 S3 存储桶在将`"ContentType": "application/octet-stream"`元数据 DataSync 传输到那里时会自动将元数据应用于该对象。
**增强模式的日志示例**
```
{
"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` 元数据属性。
## 了解数据验证时间
DataSync 验证包括文件内容的 SHA256 校验和以及不同位置之间文件元数据的精确比较。验证所需的时间取决于多种因素，包括所涉及的文件或对象数量、存储系统中的数据大小以及存储系统性能。
**要采取的操作**
考虑到可能影响验证时间的因素，您无需执行任何操作。但是，如果任务执行看起来卡在了[验证](run-task.md#understand-task-execution-statuses)状态，请联系 [AWS 支持 中心](https://console.aws.amazon.com/support/home#/)。
# 使用 S3 存储成本高于预期进行故障排除 DataSync
如果您的 Amazon S3 存储成本高于您在 AWS DataSync 转移后的预期，则可能是由于以下一个或多个原因造成的：
+ 向 S3 存储桶传入或传出 S3 存储桶时，会产生与发出的 S3 API 请求相关的费用。 DataSync
+ DataSync 使用 Amazon S3 分段上传功能将对象上传到 S3 存储桶。这种方法可能会导致对未成功完成的上传收取意外的存储费用。
+ DataSync 在控制台上启用 “**复制对象标签**” 或`ObjectTags`设置为 “复制” 时，会从源对象和目标对象复制对象标签`PRESERVE`。复制这些对象标签可能会产生 S3 API 请求费用。
+ 可能对您的 S3 存储桶启用了对象版本控制。对象版本控制导致 Amazon S3 存储同名对象的多个副本。
**要采取的操作**
在这些情况下，您可以执行以下步骤：
+ 请务必了解 S3 请求是如何 DataSync 使用的，以及它们可能如何影响您的存储成本。有关更多信息，请参阅 [使用时评估 S3 请求成本 DataSync](create-s3-location.md#create-s3-location-s3-requests)。
+ 如果问题与分段上传有关，请配置 S3 存储桶分段上传策略以清除未完成的分段上传来降低存储成本。有关更多信息，请参阅 AWS 博客文章 [S3 生命周期管理更新-支持分段上传和删除](https://aws.amazon.com/blogs/aws/s3-lifecycle-management-update-support-for-multipart-uploads-and-delete-markers/)标记。
+ 如果问题与复制对象标签有关，并且您不需要对象标签，请在创建、启动或更新任务`None`时清除 DataSync 控制台中的 “**复制对象标签**” 复选框或`ObjectTags`将其设置为。
+ 如果问题与对象版本控制有关，请在 S3 存储桶上禁用对象版本控制。
如果需要其他帮助，请联系 [AWS 支持 中心](https://console.aws.amazon.com/support/home#/)。