使用資料箱從網路連接儲存裝置 (NAS) 移轉至 Azure 檔案共用
這篇移轉文章是提到關鍵字 NAS 和 Azure 資料箱的其中一篇文章。 確認本文是否適用於您的案例：
- 資料來源：網路連接儲存裝置 (NAS)
- 移轉路由：NAS ⇒ 資料箱 ⇒ Azure 檔案共用
- 內部部署沒有快取檔案：因為最終目標是直接在雲端中使用 Azure 檔案共用，因此沒有計畫使用 Azure 檔案同步。
如果您的案例不同，請查看移轉指南的表格。
本文會引導您完成規劃、部署和網路設定，以從您的 NAS 設備移轉至正常運作的 Azure 檔案共用。 本指南使用 Azure 資料箱進行大量資料傳輸 (離線資料傳輸)。
適用於
| 檔案共用類型 | SMB | NFS |
|---|---|---|
| 標準檔案共用 (GPv2)、LRS/ZRS |  |
 |
| 標準檔案共用 (GPv2)、GRS/GZRS | |
|
| 進階檔案共用 (FileStorage)、LRS/ZRS | |
|
移轉目標
目標是將您 NAS 設備上的共用移至 Azure，並使其成為原生的 Azure 檔案共用。 您可以使用原生 Azure 檔案共用，而不需要 Windows Server。 進行此移轉時，需要在移轉期間保證生產資料的完整性和可用性。 後者需要盡可能縮短停機時間，使其符合一般維護期間，或僅略為超過。
移轉概觀
移轉流程由幾個階段組成。 您必須部署 Azure 儲存體帳戶和檔案共用，並設定網路。 然後，您將使用 Azure 資料箱來移轉您的檔案，並使用 Robocopy 來跟上變更。 最後，您會將使用者和應用程式移轉至新建立的 Azure 檔案共用。 下列各節將詳細說明移轉程序的各個階段。
提示
如果您要返回本文，請使用右側的導覽區跳至您先前離開的移轉階段。
階段 1：識別您需要多少 Azure 檔案共用
在此步驟中，您將決定您需要多少 Azure 檔案共用。 您的磁碟區上可能會有更多您目前在本機共用的資料夾，以作為使用者和應用程式的 SMB 共用。 根據您想要移轉至雲端的檔案共享數目，您可以選擇使用 1:1 對應或共用群組。
使用 1:1 對應
如果您有足夠數量的共用，建議您進行 1:1 對應。 描述此案例最簡單的方式是想像 1:1 對應至 Azure 檔案共用的內部部署共用。
使用共用群組
如果您有大量檔案共用，請考慮共用群組。 例如，如果人力資源 (HR) 部門有 15 個共用，您可能會考慮將所有 HR 資料儲存在單一 Azure 檔案共用中。 如此一來，這個內部部署共用群組僅需要一個雲端中的 Azure 檔案共用。
階段 2：部署 Azure 儲存體資源
在此階段中，您將佈建 Azure 儲存體帳戶和其中檔案共用。
請記住，Azure 檔案共用會部署在 Azure 儲存體帳戶的雲端中。 對於標準檔案共用，這種安排可讓儲存體帳戶成為效能數值的調整目標，例如 IOPS 和輸送量。 如果您將多個檔案共用放置在單一儲存體帳戶中，則會為這些共用建立 IOPS 和輸送量的共用集區。
一般情況下，如果您有封存共用，或預期會有較低的日常活動，便可以將多個 Azure 檔案共用集中放在相同的儲存體帳戶中。 不過，如果您有高度作用中的共用 (許多使用者和/或應用程式所使用的共用)，您會想要各共用部署一個檔案共用儲存體帳戶。 這些限制不適用於 FileStorage (進階) 儲存體帳戶，其中會明確佈建並保證每個共用的效能。
注意
每個 Azure 區域中每一訂用帳戶的限制是 250 個儲存體帳戶。 增加配額后，每個區域最多可以建立 500 個儲存體帳戶。 如需詳細資訊，請參閱增加 Azure 儲存體帳戶配額。
當您部署儲存體帳戶時，另一個考慮是備援。 請參閱 Azure 檔案儲存體備援。
如果您已建立共用清單，則應將每個共用對應至將建立的儲存體帳戶。
您的資源名稱也很重要。 例如，如果您將 HR 部門的多個共用分組到一個 Azure 儲存體帳戶，則應該適當地命名儲存體帳戶。 同樣地，當您為 Azure 檔案共用命名時，應使用其內部部署對應項目所使用的類似名稱。
現在，請遵循建立 SMB 檔案共用中的指示，部署適當數量的 Azure 儲存體帳戶，其中包含適當數量的 Azure 檔案共用。 在大部分情況下，您會想要確定每個儲存體帳戶的區域都相同。
第 3 階段：判斷您需要多少 Azure 資料箱設備
只有在您完成上一個階段時，才會開始這個步驟。 您的 Azure 儲存體資源 (儲存體帳戶和檔案共用) 應該在此時建立。 在您的資料箱順序中，您必須指定資料箱要用來移動資料的儲存體帳戶。
在這個階段中，您需要將移轉計畫的結果從上一個階段對應至可用資料箱選項的限制。 這些考量將協助您規劃應選擇的資料箱選項，以及將 NAS 共用移至 Azure 檔案共用時所需的數目。
若要判斷您需要的裝置類型與數目，請考慮下列重要限制：
- 任何 Azure 資料箱都可以將資料移至最多 10 個儲存體帳戶。
- 每個資料箱選項都有本身的可用容量。 請參閱資料箱選項。
針對您決定要建立的儲存體帳戶和每個帳戶中的共用數目，請參閱您的移轉計畫。 然後查看 NAS 上每個共用的大小。 結合這種資訊可讓您最佳化並決定哪個設備應該將資料傳送至哪些儲存體帳戶。 您可以有兩個資料箱裝置將檔案移至相同的儲存體帳戶，但不會跨 2 個資料箱分割單一檔案共用的內容。
資料箱選項
若為標準移轉，則應該選擇下列兩個資料箱選項的其中一個或組合：
- Data Box 這是最常見的選項。 與 NAS 類似的加固資料箱設備將會寄送給您。 資料箱具有 80 TiB 的可用容量。 如需詳細資訊，請參閱 Data Box 文件。
- Data Box Heavy 此選項的特色是加固資料箱設備，其運作方式類似於 NAS，容量為 1 PiB。 由於加密和檔案系統的額外負荷，可用容量大約會減少 20%。 如需詳細資訊，請參閱 Data Box Heavy 文件。
警告
不建議將資料箱磁碟移轉至 Azure 檔案共用。 資料箱磁碟不會保留檔案中繼資料，例如存取權限 (ACL) 和其他屬性。
第 4 階段：佈建暫時性的 Windows 伺服器
當您等待 Azure 資料箱抵達時，您可以部署一或多個執行 Robocopy 作業所需的 Windows 伺服器。
- 這些伺服器第一次使用時，會將檔案複製到資料箱。
- 這兩部伺服器的第二種使用方式，就是在資料箱傳輸期間，跟上 NAS 設備上發生的變更。 這種方法可讓來源端保持最小的停機時間。
Robocopy 作業的運作速度主要取決於下列因素：
- 來源和目標儲存體上的 IOPS
- 兩者之間的可用網路頻寬
您可以在 [疑難排解] 區段中找到更多詳細資料：IOPS 與頻寬考量 - 在命名空間中快速處理檔案和資料夾的能力
您可以在 [疑難排解] 區段中找到更多詳細資料：處理速度 - Robocopy 執行之間的變更數目
您可以在 [疑難排解] 區段中找到更多詳細資料：避免非必要的工作
當您決定要提供給暫時性 Windows 伺服器的 RAM 和執行緒計數時，請務必記住參考的詳細資料。
第 5 階段：準備使用 Azure 檔案共用
為了節省時間，您應該在等待資料箱抵達時，繼續進行此階段。 透過此階段中的資訊，您將能夠決定如何啟用 Azure 中和 Azure 以外的伺服器與使用者，以利用您的 Azure 檔案共用。 最重要的決策如下：
- 網路：讓您的網路可路由 SMB 流量。
- 認證：設定 Azure 儲存體帳戶以進行 Kerberos 驗證。 將儲存體帳戶 AdConnect 和加入網域，可讓您的應用程式和使用者使用其 AD 身分識別進行驗證
- 授權：每個 Azure 檔案共用的共用層級 ACL 將允許 AD 使用者和群組存取指定的共用，而在 Azure 檔案共用內，將由原生 NTFS ACL 接管。 接著，以檔案和資料夾 ACL 為基礎的授權，就會像對內部部署 SMB 共用一般運作。
- 商務持續性：將 Azure 檔案共用整合至現有的環境中，通常需要保留現有的共用位址。 如果您尚未使用 DFS 命名空間，請考慮在您的環境中建立。 您可以讓使用者和指令碼使用的共用位址保持不變。 您將使用 DFS-N 作為 SMB 的命名空間路由服務，方法是在移轉後將 DFS-Namespace 目標重新導向至 Azure 檔案共用。
這段影片示範如何以五個簡單的步驟，安全地直接將 Azure 檔案共用公開給資訊工作者和應用程式。
影片會參考下列主題的專用文件。 請注意，Azure Active Directory 現為 Microsoft Entra ID。 如需詳細資訊，請參閱 Azure AD 的新名稱。
第 6 階段：將檔案複製到您的資料箱
當您的 DataBox 送達時，您必須使用對 NAS 設備的未受限制網路連線來設定 DataBox。 遵循您所訂購資料箱類型的安裝文件。
視資料箱類型而定，可能有資料箱複製工具可供您使用。 此時，不建議將資料箱移轉至 Azure 檔案共用，因為不會以完整不失真的方式將您的檔案複製到資料箱。 請改用 Robocopy。
當您的資料箱抵達時，將會針對您在訂購時所指定的每個儲存體帳戶，提供預先佈建的 SMB 共用。
- 如果您的檔案進入進階 Azure 檔案共用，每個進階「檔案儲存體」的儲存體帳戶將會有一個 SMB 共用。
- 如果您的檔案進入標準儲存體帳戶，每個標準 (GPv1 和 GPv2) 儲存體帳戶將會有三個 SMB 共用。 只有結尾為
_AzFiles的檔案共用與您的移轉相關。 請忽略任何區塊和分頁 Blob 共用。
依照 Azure 資料箱文件中的步驟進行：
- 連線至資料箱
- 將資料複製到資料箱
- 準備資料箱以移轉至 Azure
連結的資料箱文件會指定 Robocopy 命令。 不過，此命令不適合用來保留完整檔案和資料夾的正確性。 請改為使用此命令：
Robocopy /MT:32 /NP /NFL /NDL /B /MIR /IT /COPY:DATSO /DCOPY:DAT /UNILOG:<FilePathAndName> <SourcePath> <Dest.Path>
- 若要深入瞭解個別 Robocopy 旗標的詳細資料，請查看即將進行 Robocopy 一節中的資料表。
- 若要深入瞭解如何適當地調整執行緒計數
/MT:n的大小、最佳化 Robocopy 速度，以及在您的資料中心內妥善運用 Robocopy，請參閱 Robocopy 疑難排解一節。
提示
作為 Robocopy 的替代方案，資料箱已建立資料複製服務。 您可以使用這項服務將檔案載入至資料箱，並保有完整的精確度。 遵循此資料複製服務教學課程，確實設定正確的 Azure 檔案共用目標。
第 7 階段：從您的 NAS 跟上 Robocopy
當您的資料箱報告所有檔案和資料夾都已放入規劃的 Azure 檔案共用之後，您就可以繼續進行此階段。 僅於資料箱複製開始後 NAS 上的資料可能已變更時，才需要跟上 Robocopy。 在您基於封存用途使用共用的某些情況下，您可能可以停止變更 NAS 上的共用，直到完成移轉為止。 您也可以在移轉期間將 NAS 共用設為唯讀，以獲得供應商務需求的能力。
如果您需要在移轉期間讓共用處於讀寫狀態，且可以僅吸收短暫的停機時間範圍，則必須先完成這個跟上 Robocopy 的步驟，才能讓使用者容錯移轉以直接存取 Azure 檔案共用。
在此步驟中，您將執行 Robocopy 作業，以在您將共用分支至資料箱之後，在 NAS 上使用最新的變更來跟上您的雲端共用。 視您的 NAS 共用上發生的流失量而定，這個跟上 Robocopy 作業可能會快速完成或需要一些時間。
執行您 Windows Server 目標資料夾的第一個本機副本：
- 識別 NAS 設備上的第一個位置。
- 識別相符的 Azure 檔案共用。
- 將 Azure 檔案共用裝載為暫時性 Windows 伺服器上的區域網路磁碟機
- 使用 Robocopy 開始複製，如下所述
裝載 Azure 檔案共用
您必須先讓 Azure 檔案共用可透過 SMB 來存取，才可使用 RoboCopy。 最簡單的方式，是在您打算用於 RoboCopy 的 Windows Server 上，將共用掛接為本機網路磁碟機。
重要
您必須已完成階段：準備使用 Azure 檔案共用，才能成功將 Azure 檔案共用裝載至本機 Windows 伺服器：
當您準備好時，請檢閱使用 Azure 檔案共用搭配 Windows 操作說明文章，並裝載您想要開始 NAS 跟上 Robocopy 作業的 Azure 檔案共用。
Robocopy
下列 Robocopy 命令只會從您的 NAS 儲存體將差異部分 (更新檔案和資料夾) 複製到 Azure 檔案共用。
robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
| 交換器 | 意義 |
|---|---|
/MT:n |
允許 Robocopy 執行多執行緒。 n 的預設值為 8。 上限為 128 個執行緒。 雖然高執行緒計數有助於飽和可用的頻寬，但這並不表示您的移轉一定會使用更多執行緒更快速地進行。 Azure 檔案儲存體的測試指出 8 和 20 之間，顯示初始複製執行的平衡效能。 後續 /MIR 執行會逐漸受到可用計算與可用網路頻寬的影響。 針對後續的執行，讓您的執行緒計數值更貼近處理器核心計數和每個核心的執行緒計數。 請考量是否需要將核心保留給實際執行伺服器可能會有的其他工作。 Azure 檔案儲存體的測試顯示最多 64 個執行緒可產生良好的效能，前提是您的處理器可以讓其同時保持運作。 |
/R:n |
第一次嘗試複製檔案失敗時的最大重試計數。 Robocopy 會先嘗試 n 次，才會讓檔案在執行中永久無法複製。 您可以將執行的效能最佳化：如果您認為過去發生失敗是因為逾時問題，請選擇二或三的值。 這可能更常見於 WAN 連結。 如果您認為檔案無法複製是因為檔案正在使用中，請選擇不重試或一的值。 稍待幾秒鐘之後再試一次，對於讓使用中狀態的檔案變更狀態來說可能時間不夠。 開啟檔案的使用者或應用程式可能需要數小時以上的時間。 在此情況下，接受檔案未能複製並且在您規劃的其中一個後續 Robocopy 執行中捕捉，也許最終可以成功複製檔案。 這樣可協助目前的執行更快速完成，而不需經過長時間多次重試，最後會由於檔案仍然在重試逾時之後保持開啟，導致大部分複製失敗。 |
/W:n |
指定 Robocopy 要等待多長時間，再嘗試複製在上次嘗試期間未成功複製的檔案。 n 是重試之間要等待的秒數。 /W:n 通常與 /R:n 一起使用。 |
/B |
以備份應用程式所使用的相同模式執行 Robocopy。 此參數可讓 Robocopy 移動目前使用者沒有權限的檔案。 備份參數取決於在系統管理員提高權限的主控台或 PowerShell 視窗中執行 Robocopy 命令。 如果您針對 Azure 檔案儲存體使用 Robocopy，請務必使用儲存體帳戶存取金鑰和網域身分識別來掛接 Azure 檔案共用。 如果您沒有這麼做，錯誤訊息可能會讓您無法以直覺方式解決問題。 |
/MIR |
(將來源鏡像至目標。) 允許 Robocopy 只複製來源與目標之間的差異。 將會複製空白子目錄。 將會複製已變更或不存在於目標上的項目 (檔案或資料夾)。 將會從目標中清除 (刪除) 存在於目標上但不在來源上的項目。 使用此參數時，應使來源與目標資料夾結構完全相符。 比對表示從正確的來源和資料夾層級複製到目標上相符的資料夾層級。 唯有如此，「追捕」複製才能成功。 當來源和目標不相符時，使用 /MIR 會導致大規模刪除和重新複製。 |
/IT |
確定在特定鏡像案例中可保有精確度。 例如，若檔案在兩次 Robocopy 執行之間經歷了 ACL 變更和屬性更新，則會標示為隱藏。 如果沒有 /IT，則 Robocopy 可能會遺漏 ACL 變更，且不會傳輸至目標位置。 |
/COPY:[copyflags] |
檔案複製的精確度。 預設值：/COPY:DAT。 複製旗標：D = 資料、A = 屬性、T = 時間戳記、S = 安全性 = NTFS ACL、O = 擁有者資訊、U = 稽核資訊。 無法將稽核資訊儲存在 Azure 檔案共用中。 |
/DCOPY:[copyflags] |
目錄複製的精確度。 預設值：/DCOPY:DA。 複製旗標：D = 資料、A = 屬性、T = 時間戳記。 |
/NP |
指定將不會顯示每個檔案和資料夾的複製進度。 顯示進度會使複製效能大幅降低。 |
/NFL |
指定不記錄檔案名稱。 改善複製效能。 |
/NDL |
指定不記錄目錄名稱。 改善複製效能。 |
/XD |
指定要排除的目錄。 在磁碟區的根目錄上執行 Robocopy 時，請考慮排除隱藏的 System Volume Information 資料夾。 如果以設計方式使用，則其中的所有資訊都是此確切系統上確切磁碟區的特定資訊，並且隨需重建。 複製這項資訊在雲端中或是將資料複製回另一個 Windows 磁碟區時，並無太多助益。 留下此內容不應視為資料遺失。 |
/UNILOG:<file name> |
以 Unicode 的形式將狀態寫入記錄檔。 (覆寫現有的記錄。) |
/L |
僅適用於測試執行 僅列出檔案。 這些檔案不會被複製、刪除，也不會加上時間戳記。 通常搭配 /TEE 用於主控台輸出。 您可能必須移除範例指令碼中的旗標 (例如 /NP、/NFL 和 /NDL)，才能正確記錄測試結果。 |
/Z |
小心使用 在重新啟動模式中複製檔案。 只有在不穩定的網路環境中，才建議使用此參數。 因為有額外的記錄，這會大幅降低複製效能。 |
/ZB |
謹慎使用 使用重新啟動模式。 如果存取遭拒，此選項會使用備份模式。 因為檢查點，此選項會大幅降低複製效能。 |
重要
我們建議使用 Windows Server 2022。 使用 Windows Server 2019 時，請確定已安裝最新的修補程式層級或至少安裝 OS 更新 KB5005103。 其中包含特定 Robocopy 案例所需的重要修正。
提示
如果 RoboCopy 影響您的生產環境、報告大量錯誤，或進展不如預期，請參閱疑難排解一節。
使用者完全移轉
當您第一次執行 Robocopy 命令時，使用者和應用程式仍會存取 NAS 上的檔案，且可能會變更這些檔案。 這可能是因為在 RoboCopy 處理了某個目錄並移至下個目錄後，來源位置 (NAS) 上的使用者新增、變更或刪除了現在不會在這個目前的 RoboCopy 執行中處理的檔案。 此行為是預期的。
第一次執行是關於將大量的流失資料移至 Azure 檔案共用。 第一次複製可能需要一些時間。 請參閱疑難排解一節，以深入了解可能會影響 RoboCopy 速度的因素。
在初始執行完成後，再次執行命令。
當您第二次對相同的共用執行 RoboCopy 時，將會更快完成，因為僅需傳輸上次執行之後發生的變更。 您可以針對相同的共用執行重複的作業。
當您考慮到可接受的停機時間時，您必須移除 NAS 型共用的使用者存取權。 為此，您可以執行任何會防止使用者變更檔案和資料夾結構和內容的步驟。 例如，將您的 DFS 命名空間指向非現有的位置，或變更共用上的根 ACL。
執行最後一次 RoboCopy 命令。 這次會取用任何可能遺漏的變更。 最後一個步驟所需的時間取決於 RoboCopy 掃描的速度。 您可以測量上次執行的時間長度，來估計這次的時間 (等於停機時間)。
在 Windows Server 資料夾上建立共用，並視情況調整您的 DFS-N 部署以指向該處。 請務必設定與您的 NAS SMB 共用相同的共用層級權限。 如果您有已加入網域的企業級 NAS，當使用者存在於 Active Directory，且 RoboCopy 複製檔案和中繼資料時，將會自動比對使用者 SID。 如果您已使用 NAS 上的本機使用者，您需要將這些使用者重新建立為 Windows Server 本機使用者，並將移至 Windows Server 的現有 SID RoboCopy 對應至新 Windows Server 本機使用者的 SID。
您已完成將共用/共用群組遷移至通用根目錄或磁碟區的作業。
您可以嘗試平行執行一些複本。 建議您逐一處理每個 Azure 檔案共用的範圍。
疑難排解
指定 RoboCopy 執行的速度和成功率，將取決於數個因素：
- 來源和目標儲存體上的 IOPS
- 來源與目標之間的可用網路頻寬
- 在命名空間中快速處理檔案和資料夾的能力
- RoboCopy 執行之間的變更數目
- 您必須複製的檔案大小和數目
IOPS 與頻寬考量
在此類別中，您必須考量來源儲存體、目標儲存體，以及與其連線的網路。 可能的最大輸送量取決於這三個之中最慢的元件。 請確定您的網路基礎結構已設定為支援最佳的傳輸速率，以達到其最佳能力。
警告
儘管複製速度通常是愈快愈好，但仍請考慮使用區域網路和 NAS 設備來進行其他作業，通常是業務關鍵工作。
當移轉有可能會獨佔可用資源時，複製速度就可能不是愈快愈好。
- 請考量在您的環境中最適合執行移轉的時間：上班、下班時間或週末。
- 另外請考量 Windows Server 上的網路 QoS，以節流 RoboCopy 速度。
- 避免移轉工具的不必要工作。
RoboCopy 可藉由指定 /IPG:n 參數來插入封包間延遲，其中 n 是以毫秒為單位測量的 RoboCopy 封包間隔。 使用此參數有助於避免 IO 有限的裝置和擁擠的網路連結上發生資源獨佔。
/IPG:n 無法用於精確地將網路節流至特定的 Mbps。 請改用 Windows Server 網路 QoS。 RoboCopy 完全依賴 SMB 通訊協定來滿足所有網路需求。 使用 SMB 是 RoboCopy 無法影響網路輸送量本身的原因，但可能會降低其使用速度。
類似的考量適用於在 NAS 上觀察到的 IOPS。 NAS 磁碟區的叢集大小、封包大小，以及其他因素的陣列都會影響觀察到的 IOPS。 要控制 NAS 上的負載，導入封包間延遲通常是最簡單的方法。 測試多個值，例如，從 20 毫秒 (n=20) 左右到該數值的倍數。 一旦您導入延遲，便可以評估其他應用程式現在是否能如預期般運作。 此最佳化策略可讓您在環境中找出最佳的 RoboCopy 速度。
處理速度
RoboCopy 將會周遊其指向的命名空間，並評估每個要複製的檔案和資料夾。 在初始複製期間以及在追捕複製期間，每個檔案都會進行評估。 例如，對相同來源和目標儲存位置重複執行 RoboCopy /MIR。 這些重複執行有助於將使用者和應用程式的停機時間降到最低，並改善遷移檔案的整體成功率。
我們通常會在移轉時將頻寬視為最受限制的因素，實際上的確可能如此。 但對於檔案較小的較大命名空間，列舉命名空間的能力可能會對複製總時間有更大的影響。 假設所有其他變數都相同，鑒於複製 1 TiB 小型檔案所花費的時間，會遠超過複製 1 TiB 數量少的大型檔案。 因此，如果您要移轉大量的小型檔案，可能會遇到傳輸緩慢的問題。 這是預料中的行為。
這項差異的原因在於逐步執行命名空間所需的處理能力。 RoboCopy 會透過 /MT:n 參數支援多執行緒複製，其中 n 代表要使用的執行緒數目。 因此，特別針對 RoboCopy 佈建機器時，請考量處理器核心的數目，及其與所提供執行緒計數之間的關聯性。 最常見的配置是每個核心有兩個執行緒。 機器的核心和執行緒計數是決定您應如何指定多執行緒值 /MT:n 的重要資料點。 也請考量您打算在指定機器上平行執行的 RoboCopy 作業數目。
使用更多執行緒複製我們 1 TiB 的小型檔案範例時，速度會比較少的執行緒快得多。 同時，對於我們 1 TiB 較大檔案的額外資源投資可能不會產生等比例的好處。 高執行緒計數會嘗試同時在網路上複製更多大型檔案。 這個額外的網路活動會增加受到輸送量或儲存體 IOPS 限制的機率。
在第一個 RoboCopy 進入空白目標或具有大量已變更檔案的差異執行期間，您可能會受到網路輸送量的限制。 從初始執行的高執行緒計數開始。 高執行緒計數 (甚至超過機器上目前可用的執行緒) 會促使可用的頻寬趨於飽和。 後續的 /MIR 執行會逐漸受到處理項目的影響。 差異執行中的變更較少時，表示透過網路傳輸的資料較少。 您的速度現在更加相依於處理命名空間項目的能力，而非透過網路連結移動項目。 針對後續的執行，請讓您的執行緒計數值符合處理器核心計數和每個核心的執行緒計數。 請考量是否需要將核心保留給實際執行伺服器可能會有的其他工作。
提示
經驗法則：第一次 RoboCopy 執行時，將會移動較高延遲網路的大量資料，而受益於過度佈建執行緒計數 (/MT:n)。 後續執行會複製較少的差異，而很可能會從受限於網路輸送量轉變為受限於計算。 在這些情況下，通常建議使 RoboCopy 執行緒計數與機器上實際可用的執行緒相符。 在這種情況下，過度佈建可能會使處理器產生較多內容轉變，進而可能導致複製變慢。
避免不必要的作業
避免在您的命名空間中進行大規模變更。 例如，在目錄之間移動檔案、大規模變更屬性，或變更權限 (NTFS ACL)。 尤其是 ACL 變更可能會有很大的影響，因為通常會對資料夾階層較低的檔案產生串聯變更影響。 結果可能是：
- 因為需要更新 ACL 變更所影響的每個檔案和資料夾，而延長了 RoboCopy 作業執行時間
- 重複使用先前移動的資料，可能需要重新複製。 例如，若在先前複製檔案之後，資料夾結構有所變更，就需要複製更多資料。 RoboCopy 作業無法「倒帶」命名空間變更。 下一個作業必須清除先前傳輸至舊資料夾結構的檔案，並重新上傳新資料夾結構中的檔案。
另一個重要的層面是有效地使用 RoboCopy 工具。 使用建議的 RoboCopy 指令碼時，您將會建立並儲存錯誤的記錄檔。 可能會發生複製錯誤，這是正常情況。 這些錯誤通常會讓您必須執行多次複製工具 (例如 RoboCopy)。 一次初始執行，例如從 NAS 到資料箱，或從伺服器到 Azure 檔案共用。 另外一或多次使用/MIR 參數的額外執行，用來擷取和重試未複製的檔案。
您應準備好對指定的命名空間範圍執行多次 RoboCopy 作業。 連續執行的完成速度會比較快，因為複製的內容較少，但會因為處理命名空間的速度而受到更多限制。 當您多次執行時，可以藉由不讓 RoboCopy 嘗試在指定執行中勉強複製所有內容，從而加速每次執行。 這些 RoboCopy 參數可產生顯著的差異：
/R:nn = 重試複製失敗檔案的頻率，以及/W:nn = 重試之間的等待秒數
/R:5 /W:5 是合理的設定，您可以視需要進行調整。 在此範例中，失敗的檔案會重試 5 次，且在重試之間有 5 秒的等待時間。 如果檔案仍無法複製，下一個 RoboCopy 作業將會重試。 因在使用中或因逾時問題而失敗的檔案，最終往往會在使用此方法後複製成功。
下一步
深入探索 Azure 檔案共用。 下列文章可協助您了解進階選項、最佳做法，且同時包含疑難排解的協助。 這些文章會適當地連結至 Azure 檔案共用文件。