本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 故障診斷 AWS DataSync 問題
使用下列資訊來疑難排解 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 代理程式的問題進行故障診斷
使用下列資訊來協助您疑難排解 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)。
+ **檢查代理程式的 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)。
## 我不知道客服人員的情況。有人可以協助我嗎？
您可以允許 AWS 支援 存取 DataSync 代理程式，並協助疑難排解代理程式相關問題。您必須透過客服人員的本機主控台啟用此存取權。
**提供 代理程式的 支援 存取權**
1. [登入客服人員的本機主控台](local-console-vm.md#local-console-login)。
1. 在提示中，輸入 **5** 以開啟命令提示 （對於 VMware VMs，請使用 **6**)。
1. 輸入 **h** 以開啟**可用命令**視窗。
1. 在**可用命令**視窗中，輸入要連線至的下列項目 支援：
`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`或 設定 NFS 檔案伺服器，`all_squash`且您的檔案不具備讀取存取權，則可能會收到「許可遭拒」錯誤訊息。
**採取動作**
若要修正此問題，請使用 設定 NFS 匯出，`no_root_squash`或確定您要傳輸的所有檔案的許可允許所有使用者的讀取存取。
若要讓 DataSync 存取目錄，您還必須啟用所有執行檔存取。為了確保目錄可供掛載，請先連接至與代理程式具有相同網路組態的任何電腦，然後執行下列 CLI 命令：
`mount -t nfs -o nfsvers= : `
如果問題仍未解決，請聯絡 [AWS 支援 中心](https://console.aws.amazon.com/support/home#/)。
## 我的任務因 NFS 掛載錯誤而失敗
執行涉及 NFS 檔案伺服器位置的 DataSync 任務時，您可能會看到下列錯誤：
任務無法存取位置 loc-1111222233334444a：x40016： mount.nfs：連線逾時
**要採取的動作**
請執行下列動作，直到錯誤解決為止。
1. 請確定您在 DataSync 位置中指定的 NFS 檔案伺服器和匯出是有效的。如果不是，請刪除您的位置和任務，然後建立使用有效 NFS 檔案伺服器和匯出的新位置和任務。如需詳細資訊，請參閱[使用 DataSync 主控台](create-nfs-location.md#create-nfs-location-console)。
1. 檢查您的代理程式與 NFS 檔案伺服器之間的防火牆組態。如需詳細資訊，請參閱[內部部署、自我管理和其他雲端儲存的網路需求](datasync-network.md#on-premises-network-requirements)。
1. 請確定您的代理程式可以存取 NFS 檔案伺服器並掛載匯出。如需詳細資訊，請參閱[提供對 NFS 檔案伺服器的 DataSync 存取權](create-nfs-location.md#accessing-nfs)。
1. 如果您仍然看到錯誤，請使用 開啟支援管道 支援。如需詳細資訊，請參閱[我不知道客服人員的情況。有人可以協助我嗎？](troubleshooting-datasync-agents.md#enable-support-access)。
## 我的任務因 Amazon EFS 掛載錯誤而失敗
執行涉及 Amazon EFS 位置的 DataSync 任務時，您可能會看到下列錯誤：
任務無法存取位置 loc-1111222233334444a：x40016：無法使用 IP：10.10.1.0 連線至 EFS 掛載目標。
如果您使用位置設定的 Amazon EFS 檔案系統的掛載路徑已更新或刪除，就會發生這種情況。DataSync 不知道檔案系統中的這些變更。
**採取動作**
刪除您的位置和任務，並使用[新的掛載路徑建立新的 Amazon EFS 位置](create-efs-location.md#create-efs-location-how-to)。
## NFS 傳輸不會維護檔案擁有權
傳輸後，您可能會注意到 DataSync 目的地位置中的檔案具有與來源位置中相同檔案不同的使用者 IDs (UIDs) 或群組 IDs (GIDs)。例如，目的地中的檔案可能具有 `65534`、 `99`或 的 UID`nobody`。
如果傳輸中涉及的檔案系統使用 NFS 第 4 版 ID 映射，即 DataSync 不支援的功能，就會發生這種情況。
**採取動作**
您有幾個選項可以解決此問題：
+ 為使用 NFS 第 3 版而非第 4 版的檔案系統建立新的位置。
+ 在檔案系統上停用 NFS 第 4 版 ID 映射。
重試傳輸。任一選項都應解決問題。
## 我的任務無法存取使用 Kerberos 的 SMB 位置
使用 [Kerberos 身分驗證](create-smb-location.md#configuring-smb-kerberos-authentication)的 SMB 位置的 DataSync 錯誤通常與位置和 Kerberos 組態之間的不相符有關。也可能發生網路問題。
**無法存取位置**
下列錯誤表示您的 SMB 位置或 Kerberos 設定可能有組態問題：
```
Task failed to access location
```
**驗證下列項目**：
+ 您為位置指定的 SMB 檔案伺服器是網域名稱。對於 Kerberos，您無法指定檔案伺服器的 IP 地址。
+ 您為位置指定的 Kerberos 主體與您用來建立 Kerberos 金鑰資料表 (keytab) 檔案的主體相符。主體名稱區分大小寫。
+ 自您建立 keytab 檔案以來，Kerberos 主體的映射使用者密碼尚未變更。如果密碼變更 （因為密碼輪換或其他原因），您的任務執行可能會失敗，並顯示下列錯誤：
任務無法存取位置 loc-1111222233334444a：x40015：kinit：取得初始登入資料時預先驗證失敗
**無法聯絡 KDC 領域**
下列錯誤表示網路問題：
```
kinit: Cannot contact any KDC for realm 'MYDOMAIN.ORG' while getting initial credentials"
```
**驗證下列項目**：
+ 您提供 DataSync 的 Kerberos 組態檔案 (`krb5.conf`) 具有 Kerberos 領域的正確資訊。如需範例`krb5.conf`檔案，請參閱 [Kerberos 身分驗證先決條件](create-smb-location.md#configuring-smb-kerberos-prerequisites)。
+ Kerberos Key Distribution Center (KDC) 伺服器連接埠已開啟。KDC 連接埠通常是 TCP 連接埠 88。
+ 您網路上的 DNS 組態。
## 我的任務失敗，出現輸入/輸出錯誤
如果您的儲存系統失敗來自 DataSync 代理程式的 I/O 請求，您可以收到輸入/輸出錯誤訊息。常見的原因包括伺服器磁碟故障、防火牆組態的變更，或網路路由器故障。
如果錯誤涉及 NFS 檔案伺服器或 Hadoop 分散式檔案系統 (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 儲存貯體。檢查 DataSync 是否具有使用 Amazon S3 [HeadBucket](https://docs.aws.amazon.com/AmazonS3/latest/API/API_HeadBucket.html) 操作存取儲存貯體的許可。如果您需要調整許可，請參閱 [提供對 S3 儲存貯體的 DataSync 存取權](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) AWS re:Post
## 具有 S3 來源位置的任務失敗，並顯示 `HeadObject`或 `GetObjectTagging` 錯誤
**與 `HeadObject`或 相關的錯誤 `GetObjectTagging`**
如果您要從 S3 儲存貯體傳輸具有特定版本 IDs物件，您可能會看到與 `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 建立 IAM 角色以存取您的 Amazon S3 位置](create-s3-location.md#create-role-manually)。
# 針對 DataSync 任務的問題進行故障診斷
使用以下資訊來協助您疑難排解 AWS DataSync 任務和任務執行的問題。這些問題可能包括任務設定問題、任務執行停滯，以及資料未如預期般傳輸。
## 錯誤：無效的 SyncOption 值。選項：TransferMode、PreserveDeletedFiles、Value： ALL、REMOVE。
當您建立或編輯 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` FSx for ONTAP 檔案系統的任務失敗
當您的 DataSync 任務在使用 FSx for ONTAP 檔案系統傳輸資料`Input/Output error`時失敗，可能是下列一或多個問題所造成。
**FSx for ONTAP 磁碟區已達到其最大檔案容量**
當磁碟區上的可用索引或檔案指標數量用盡時，就會發生此錯誤。
**要採取的動作**
首先，檢視磁碟區[的最大檔案容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/view-volume-file-capacity.html)。然後，透過增加索引數量或增加儲存容量來增加磁碟區的檔案容量。如需詳細資訊，請參閱《*FSx for ONTAP 使用者指南*》中的[增加磁碟區的最大檔案容量](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)。然後，增加磁碟區的儲存容量。如需詳細資訊，請參閱《*FSx for ONTAP 使用者指南*》中的[增加磁碟區的儲存容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#increase-volume-capacity)。
**注意**
若要在需要時自動增加磁碟區的儲存容量，請參閱《*FSx for ONTAP 使用者指南*》中的[使用磁碟區自動調整大小](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/low-volume-capacity.html#volume-autosizing)。
**FSx for ONTAP 目錄已達到每個目錄中可存放的檔案數量上限**
當您已達到每個目錄中可存放的檔案數量上限時，就會發生此錯誤。
**採取動作**
增加目錄大小上限，以支援更大的目錄。如需詳細資訊，請參閱 *AWS 規範指引*中的[使用 FSx for ONTAP 目錄大小上限的最佳實務](https://docs.aws.amazon.com/prescriptive-guidance/latest/fsx-ontap-enterprise-deployment/best-practices.html#bp-max-directory-size)。
**DataSync 任務執行產生的讀取寫入並行過多，耗用檔案系統輸送量容量的高百分比**
當 DataSync 任務執行耗用過多檔案系統的可用輸送量容量時，就會發生此錯誤。
**要採取的動作**
首先，使用以下方法判斷任務執行是否耗用過多的檔案系統輸送量容量：
+ 使用可用的 CloudWatch 指標監控檔案系統的效能。如需詳細資訊，請參閱《*FSx for ONTAP 使用者指南*》中的[監控檔案系統指標](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/monitor-throughput-cloudwatch.html#fsxn-howtomonitor-fs)。
+ 在 Amazon FSx 主控台中監控檔案系統是否有檔案伺服器效能警告。如需詳細資訊，請參閱《*FSx for ONTAP 使用者指南*》中的[效能警告和建議](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/performance-insights-FSxN.html#resolve-warnings)。
然後，執行下列其中一項動作，確保任務不會使用所有檔案系統的可用輸送量容量：
+ 將任務執行的頻寬限制設定為小於 ONTAP 檔案系統佈建輸送量容量的 FSx 數量。如需詳細資訊，請參閱[設定 AWS DataSync 任務的頻寬限制](configure-bandwidth.md)。
+ 增加檔案系統的佈建輸送量容量。如需詳細資訊，請參閱《*FSx for ONTAP 使用者指南*》中的[更新輸送量容量](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/increase-throughput-capacity.html)。
## FSx for ONTAP 檔案系統的任務失敗，出現 `Connection Reset by peer`或 `Host is down` 訊息
如果您的 DataSync 任務在使用 FSx for ONTAP 檔案系統傳輸資料時，失敗並顯示 `Connection Reset by peer`或 `Host is down` 訊息，這可能是由於下列一或多個問題：
+ 檔案系統的 SMB 伺服器已在任務執行期間重新啟動或以其他方式中斷連線。
+ 檔案系統在任務執行期間從主要伺服器容錯移轉至次要伺服器 （和 IP 地址）。DataSync 不支援在任務執行期間容錯移轉至次要 IP 地址。
在下列事件期間，FSx for ONTAP 檔案系統會容錯移轉至次要伺服器和 IP 地址：
+ 主要伺服器無法使用。
+ 主要伺服器的可用區域無法使用 （適用於多可用區域檔案系統）。
+ 在使用者起始的輸送量容量變更期間。
+ 在檔案系統的定期排程維護時段期間。
如需詳細資訊，請參閱《[FSx for ONTAP 使用者指南》中的 FSx for ONTAP 容錯移轉程序](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/high-availability-AZ.html#Failover)。 FSx
**採取動作**
重新啟動任務。
## 任務執行有啟動狀態，但似乎沒有發生
您的 DataSync 任務可能會卡在**啟動**狀態，通常是因為代理程式已關閉電源或網路連線中斷。
**要採取的動作**
請確定客服人員的狀態為 **ONLINE**。如果代理程式為 **OFFLINE**，請確定已開啟電源。
如果代理程式已開啟，且任務仍在**啟動**中，則代理程式與 之間可能存在網路連線問題 AWS。如需如何測試網路連線的資訊，請參閱[驗證代理程式與 DataSync 服務的連線](test-agent-connections.md#test-network)。
如果您仍然遇到此問題，請參閱 [我不知道客服人員的情況。有人可以協助我嗎？](troubleshooting-datasync-agents.md#enable-support-access)。
## 任務執行似乎卡在準備狀態
DataSync 傳輸任務具有**準備**狀態的時間長度取決於傳輸來源和目的地中的資料量，以及這些儲存系統的效能。
當任務開始時，DataSync 會執行遞迴目錄清單，以探索來源和目的地中的所有檔案、物件、目錄和中繼資料。DataSync 使用這些清單來識別儲存系統之間的差異，並決定要複製的內容。此程序可能需要幾分鐘甚至幾個小時。
**採取動作**
您不應該執行任何操作。繼續等待任務狀態變更為 **Transferring**。如果狀態仍未變更，請聯絡 [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 Cloud Storage 儲存貯體傳輸時任務執行失敗
由於 DataSync 會使用 Amazon S3 API 與 Google Cloud Storage 通訊，因此如果您嘗試複製物件標籤，可能會有可能導致 DataSync 傳輸失敗的限制。下列與問題相關的訊息會顯示在您的 CloudWatch 日誌中：
【WARN】 無法讀取檔案 /*your-bucket*/*your-object* 的中繼資料：S3 取得物件標記失敗：在不標記的情況下繼續
若要避免這種情況，請在設定傳輸任務設定時取消選取**複製物件標籤**選項。
## 任務執行的時間戳記不相符
查看 DataSync 主控台或 Amazon CloudWatch logs時，您可能會注意到 DataSync 任務執行的開始和結束時間不符合您在其他監控工具中看到的時間戳記。這是因為主控台和 CloudWatch 日誌會將任務執行花費在啟動或佇列[狀態](run-task.md#understand-task-execution-statuses)的時間納入考量，而其他一些工具則不會。
比較 DataSync 主控台或 CloudWatch 日誌與下列位置之間的執行時間戳記時，您可能會注意到此差異：
+ 傳輸所涉及之檔案系統的日誌
+ DataSync 寫入的 Amazon S3 物件上上次修改日期
+ 來自 DataSync 代理程式的網路流量
+ Amazon EventBridge 事件
## 任務執行失敗並`NoMem`發生錯誤
您嘗試傳輸的資料集對於 DataSync 而言可能太大。如果看到此錯誤，請聯絡 [AWS 支援 中心](https://console.aws.amazon.com/support/home#/)。
## 任務執行失敗並`FsNfsIdMappingEnabled`發生錯誤
DataSync 不支援 NFSv4 ID 映射。若要解決此問題，[請將 NFS 位置設定為使用 NFSv3](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 檔案伺服器和 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)。
## 任務報告錯誤
嘗試使用任務報告監控 DataSync 傳輸時，您可能會遇到下列其中一個錯誤。
| 錯誤訊息 | 解決方法 |
| --- | --- |
| 檔案路徑超過 4，096 個字元的長度上限。無法寫入任務報告 | 無。DataSync 無法傳輸路徑超過 4，096 個位元組的檔案。 如需詳細資訊，請參閱[儲存系統、檔案和物件限制](datasync-limits.md#file-system-limits)。 |
| 由於儲存貯體或 IAM 角色無效，無法將任務報告上傳至 S3 (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) 複製到目的地時。若要解決此問題，請根據您的目的地類型檢閱下列組態指南：
+ FSx for Windows File Server 檔案系統[的必要許可](create-fsx-location.md#create-fsx-windows-location-permissions)
+ FSx for ONTAP 檔案系統使用 SMB [的必要許可](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.
```
在日誌中，您可能會看到錯誤，指出檔案不在來源位置。如果在[準備](how-datasync-transfer-works.md#how-datasync-prepares)後但在 DataSync 傳輸檔案之前刪除檔案 （例如 `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 無法驗證目的地資料
當您的任務執行完成時，您會看到下列錯誤：
```
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 因為 Amazon S3 `HeadObject`請求失敗`file1.png`而無法讀取。[DataSync 會在任務準備和驗證期間向 S3 位置提出`HeadObject`請求](create-s3-location.md#create-s3-location-s3-requests-made)。 S3
**基本模式日誌範例**
```
[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`中繼資料，但目的地物件有。這是因為當 DataSync 將目的地 S3 儲存貯體傳輸到物件時，目的地 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`中繼資料屬性。
## 了解資料驗證持續時間
DataSync 驗證包括檔案內容的 SHA256 檢查總和，以及位置間檔案中繼資料的確切比較。驗證需要多長時間取決於幾個因素，包括涉及的檔案或物件數量、儲存系統中的資料大小，以及這些系統的效能。
**採取動作**
考慮到可能影響驗證時間的因素，您不應該執行任何動作。不過，如果您的任務執行似乎卡在[驗證](run-task.md#understand-task-execution-statuses)狀態，請聯絡 [AWS 支援 中心](https://console.aws.amazon.com/support/home#/)。
# 使用 DataSync 對高於預期的 S3 儲存成本進行故障診斷
如果您的 Amazon S3 儲存成本高於您認為在 AWS DataSync 傳輸之後的儲存成本，可能是因為下列一或多個原因：
+ 往返 S3 儲存貯體時，您需要支付 DataSync 提出之 S3 API 請求的相關成本。
+ DataSync 使用 Amazon S3 分段上傳功能，將物件上傳至 S3 儲存貯體。對於未成功完成的上傳，此方法可能會導致非預期的儲存費用。
+ 在主控台上啟用複製物件標籤或`ObjectTags`設定為 時，DataSync 會從來源和目的地物件**複製物件標籤**`PRESERVE`。複製這些物件標籤可能會產生 S3 API 請求成本。
+ S3 儲存貯體可能啟用了物件版本控制。物件版本控制會導致 Amazon S3 儲存多個相同名稱的物件複本。
**要採取的動作**
在這些情況下，您可以執行下列步驟：
+ 請務必了解 DataSync 如何使用 S3 請求，以及它們如何影響您的儲存成本。如需詳細資訊，請參閱[使用 DataSync 時評估 S3 請求成本](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/)。
+ 如果問題與複製物件標籤有關，而且您不需要物件標籤，請清除 DataSync 主控台中的**複製物件標籤**核取方塊，或在建立、啟動或更新任務`None`時`ObjectTags`設定為 。
+ 如果問題與物件版本控制有關，請在 S3 儲存貯體上停用物件版本控制。
如果您需要其他協助，請聯絡 [AWS 支援 中心](https://console.aws.amazon.com/support/home#/)。