共用方式為

使用 RoboCopy 遷移至 Azure 檔案共用

  • 發行項

此移轉文章說明如何使用 RoboCopy 將檔案移動或遷移至 SMB Azure 檔案共用。 RoboCopy 是受信任的知名檔案複製公用程式，其功能集使其非常適合用於移轉。 它採用 SMB 通訊協定，因此可廣泛運用於支援 SMB 的任何來源和目標組合。

  • 資料來源：任何支援 SMB 通訊協定的來源，例如網路連接儲存裝置 (NAS)、Windows 或 Linux 伺服器、另一個 Azure 檔案共用等
  • 移轉路由：從來源儲存體 ⇒ 具有 RoboCopy 的 Windows 機器 ⇒ Azure 檔案共用
  • 內部部署沒有快取檔案：因為最終目標是直接在雲端中使用 Azure 檔案共用，因此沒有計畫使用 Azure 檔案同步。

不同的來源和部署組合有許多不同的移轉路由。 請參閱移轉指南表格，找出最符合個人需求的移轉。

適用於

檔案共用類型 SMB NFS
標準檔案共用 (GPv2)、LRS/ZRS 是 否
標準檔案共用 (GPv2)、GRS/GZRS 是 否
進階檔案共用 (FileStorage)、LRS/ZRS 是 No

AzCopy 與 RoboCopy

AzCopy 和 RoboCopy 是本質上有所不同的兩種檔案複製工具。 RoboCopy 可使用任何版本的 SMB 通訊協定。 AzCopy 是「應雲端而生」的工具，可用來移動資料 (只要目標位於 Azure 儲存體中)。 AzCopy 需使用 REST 通訊協定。

RoboCopy 是受信任的 Windows 複製工具，在以完整精確度複製檔案方面位居領先地位。 RoboCopy 具有豐富的功能集，且能夠以完整精確度複製檔案和資料夾，因此支援許多移轉案例。 請參閱移轉概觀文章中的檔案精確度小節，以深入了解盡可能精確複製檔案的重要性。

相對地，AzCopy 近期才擴充為支援精確度有限的檔案複製，並新增了被視為移轉工具所需的第一項功能。 但兩者仍有一些差異，且在比較 AzCopy 旗標與 RoboCopy 旗標時，很容易對功能產生誤解。

範例：RoboCopy /MIR 會將來源鏡像至目標，也就是會考量已新增、變更和刪除的檔案。 使用 AzCopy -sync 的一項重要差異在於，來源上已刪除的檔案不會在目標上移除。 這會導致不完整的差異複製功能集。 AzCopy 將會繼續演進。 目前，不建議將 AzCopy 用於將 Azure 檔案共用作為目標的移轉情節。

移轉目標

目標是將資料從現有的檔案共用位置移至 Azure。 在 Azure 中，您會將資料儲存在可用的原生 Azure 檔案共用中，而不需要 Windows Server。 進行此移轉時，需要在移轉期間保證實際執行資料的完整性和可用性。 後者需要盡可能縮短停機時間，使其符合一般維護期間，或僅略為超過。

移轉概觀

移轉流程由幾個階段組成。 首先，您必須部署 Azure 儲存體帳戶和檔案共用。 接下來，您將設定網路功能、考慮部署 DFS 命名空間 (DFS-N)，或更新現有的命名空間。 到了實際要進行資料複製時，您必須考慮採用重複的差異 RoboCopy 執行以盡可能縮短停機時間，且最終將您的使用者完全移轉至新建立的 Azure 檔案共用。 下列各節將詳細說明移轉程序的各個階段。

階段 1：部署 Azure 儲存體資源

在此階段中，您將佈建 Azure 儲存體帳戶和其中 SMB Azure 檔案共用。

請記住，Azure 檔案共用會部署在 Azure 儲存體帳戶的雲端中。 對於標準檔案共用，這種安排可讓儲存體帳戶成為效能數值的調整目標，例如 IOPS 和輸送量。 如果您將多個檔案共用放置在單一儲存體帳戶中，則會為這些共用建立 IOPS 和輸送量的共用集區。

一般情況下，如果您有封存共用，或預期會有較低的日常活動，便可以將多個 Azure 檔案共用集中放在相同的儲存體帳戶中。 不過，如果您有高度作用中的共用 (許多使用者和/或應用程式所使用的共用)，您會想要各共用部署一個檔案共用儲存體帳戶。 這些限制不適用於 FileStorage (進階) 儲存體帳戶，其中會明確佈建並保證每個共用的效能。

注意

每個 Azure 區域中每一訂用帳戶的限制是 250 個儲存體帳戶。 增加配額后，每個區域最多可以建立 500 個儲存體帳戶。 如需詳細資訊，請參閱增加 Azure 儲存體帳戶配額。

當您部署儲存體帳戶時，另一個考慮是備援。 請參閱 Azure 檔案儲存體備援。

如果您已建立共用清單，則應將每個共用對應至將建立的儲存體帳戶。

您的資源名稱也很重要。 例如，如果您將 HR 部門的多個共用分組到一個 Azure 儲存體帳戶，則應該適當地命名儲存體帳戶。 同樣地，當您為 Azure 檔案共用命名時，應使用其內部部署對應項目所使用的類似名稱。

現在，請遵循建立 SMB 檔案共用中的指示，部署適當數量的 Azure 儲存體帳戶，其中包含適當數量的 Azure 檔案共用。 在大部分情況下，您會想要確定每個儲存體帳戶的區域都相同。

階段 2：準備使用 Azure 檔案共用

透過此階段中的資訊，您將能夠決定如何啟用 Azure 中和 Azure 以外的伺服器與使用者，以利用您的 Azure 檔案共用。 最重要的決策如下：

  • 網路：讓您的網路可路由 SMB 流量。
  • 認證：設定 Azure 儲存體帳戶以進行 Kerberos 驗證。 使用身分識別型驗證和加入儲存體帳戶的網域，可讓您的應用程式和使用者使用其 AD 身分識別進行驗證。
  • 授權： 每個 Azure 檔案共用的共享層級 ACL 將允許 AD 使用者和群組存取指定的共用。 在 Azure 檔案共享內，原生 NTFS ACL 將會接管。 接著，以檔案和資料夾 ACL 為基礎的授權，就會像對內部部署 SMB 共用一般運作。
  • 商務持續性：將 Azure 檔案共用整合至現有的環境中，通常需要保留現有的共用位址。 如果您尚未使用 DFS 命名空間，請考慮在您的環境中建立。 您將能夠讓使用者和指令碼使用的共用位址保持不變。 DFS-N 提供 SMB 的命名空間路由服務，方法是將用戶端重新導向至 Azure 檔案共用。

這段影片示範如何以五個簡單的步驟，安全地直接將 Azure 檔案共用公開給資訊工作者和應用程式。
影片會參考下列主題的專用文件。 請注意，Azure Active Directory 現為 Microsoft Entra ID。 如需詳細資訊，請參閱 Azure AD 的新名稱。

掛接 Azure 檔案共用

您必須先讓 Azure 檔案共用可透過 SMB 來存取，才可使用 RoboCopy。 最簡單的方式，是在您打算用於 RoboCopy 的 Windows Server 上，將共用掛接為本機網路磁碟機。

重要

請務必使用儲存體帳戶存取金鑰來掛接 Azure 檔案共用。 請勿使用網域身分識別。 您必須先完成 第 2 階段：準備使用 Azure 檔案共用，才能成功將 Azure 檔案共用掛接至本機 Windows Server。

準備好之後，請檢閱搭配 Windows 使用 Azure 檔案共用。 然後，掛接要啟動 RoboCopy 的 Azure 檔案共用。

階段 3：RoboCopy

下列 Robocopy 命令只會從您的來源儲存體將差異部分 (更新的檔案和資料夾) 複製到 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 影響您的生產環境、報告大量錯誤，或進展不如預期，請參閱疑難排解一節。

階段 4：使用者完全移轉

當您第一次執行 RoboCopy 命令時，使用者和應用程式仍會存取移轉來源上的檔案，且可能會變更這些檔案。 這可能是因為在 RoboCopy 處理了某個目錄並移至下個目錄後，來源位置上的使用者新增、變更或刪除了現在不會在這個目前的 RoboCopy 執行中處理的檔案。 此行為是預期的。

第一次執行是關於將大量的流失資料移至 Azure 檔案共用。 第一次複製可能需要一些時間。 請參閱疑難排解一節，以深入了解可能會影響 RoboCopy 速度的因素。

在初始執行完成後，再次執行命令。

當您第二次對相同的共用執行 RoboCopy 時，將會更快完成，因為僅需傳輸上次執行之後發生的變更。 您可以對相同的共用執行重複的作業。

考慮可接受的停機時間之後，您必須移除使用者對來源共用的存取。 為此，您可以執行任何會防止使用者變更檔案和資料夾結構和內容的步驟。 例如，將您的 DFS 命名空間指向非現有的位置，或變更每個共用上的 ACL。

執行最後一次 RoboCopy 命令。 這次會取用任何可能遺漏的變更。 最後一個步驟所需的時間，取決於 RoboCopy 掃描的速度。 您可以測量上次執行的時間長度，來估計這次的時間 (等於停機時間)。

在階段 2 中，您已將使用者設定為使用其身分識別存取共用，且應已建立策略，讓您的使用者使用已建立的路徑存取新的 Azure 檔案共用 (DFS-N)。

您可以嘗試以平行方式，在不同的來源與目標共用之間執行一些這類複製。 執行此作業時請留意網路輸送量和核心與執行緒計數的比率，切勿超出系統負荷。

疑難排解和最佳化

指定 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 到 DataBox 或伺服器到 Azure 檔案共用，並使用 /MIR 參數執行一或多個額外執行，以攔截和重試未複製的檔案。

您應準備好對指定的命名空間範圍執行多次 RoboCopy 作業。 連續執行的完成速度會比較快，因為複製的內容較少，但會因為處理命名空間的速度而受到更多限制。 當您多次執行時，可以藉由不讓 RoboCopy 嘗試在指定執行中勉強複製所有內容，從而加速每次執行。 這些 RoboCopy 參數可產生顯著的差異：

  • /R:n n = 重試複製失敗檔案的頻率，以及
  • /W:n n = 重試之間的等待秒數

/R:5 /W:5 是合理的設定，您可以視需要進行調整。 在此範例中，失敗的檔案會重試 5 次，且在重試之間有 5 秒的等待時間。 如果檔案仍無法複製，下一個 RoboCopy 作業將會重試。 因在使用中或因逾時問題而失敗的檔案，最終往往會在使用此方法後複製成功。

估計儲存體交易費用

當您開始移轉至 Azure 檔案儲存體時，RoboCopy 會將檔案和資料夾複製到 Azure。 根據您的 Azure 檔案儲存體的計費模型，可能會套用交易費用。 請參閱瞭解帳單。

如果對標準 Azure 檔案共用使用隨用隨付計費模型，則可能很難估計移轉將產生的交易數量。

  • 您無法根據來源已使用的儲存容量來估計交易數目。 交易數目隨著命名空間項目數 (檔案和資料夾) 及移轉的屬性 (不是大小) 而增減。 例如，移轉 1 GiB 的小檔案比 1 GiB 的大檔案需要更多交易。
  • 若要將停機時間降到最低，您可能需要從來源到目標執行數次複製作業。 每個複製作業期間會處理所有來源和目標項目，但後續執行會較快完成。 初始作業之後，只有複製執行之間引起的差異會透過網路傳輸。 請務必瞭解，雖然傳輸的資料較少，但所需的交易數目可能仍然相同。
  • 相同的檔案複製兩次不一定會出現相同的交易數目。 處理先前複製執行中移轉的項目可能只會產生少數讀取交易。 相反地，在複製執行之間變更中繼資料或內容可能需要大量交易來更新目標。 命名空間中的每個檔案可能各有獨特的需求，因而產生不同的交易數目。

建議您對自己的資料執行一些初始測試，以進一步瞭解產生多少筆交易。 這可讓您更清楚檔案移轉可能產生的交易總數。

下一步

下列文章將協助您瞭解進階選項和最佳做法。