使用 RoboCopy 移轉至 Azure 檔案共用

適用於： ✔️SMB 檔案共享

本文說明如何使用 RoboCopy 將檔案移動或移轉至 SMB Azure 檔案共用。 RoboCopy 是一個可靠且廣為人知的檔案複製公用程式，其功能集使其非常適合用於移轉。 它使用 SMB 通訊協定，因此可廣泛適用於任何支援 SMB 的來源與目標組合。

  • 資料來源：任何支援 SMB 通訊協定的來源，例如網路附加儲存體 (NAS)、Windows 或 Linux 伺服器、另一個 Azure 檔案共用等，還有更多。
  • 移轉路徑：從來源儲存體 ⇒ Windows 機器搭配 RoboCopy ⇒ Azure 檔案共用
  • 內部部署不快取檔案：因為最終目標是在雲端直接使用 Azure 檔案共用，因此不打算使用 Azure 檔案同步。

重要事項

針對不同的來源與部署組合，存在許多不同的移轉路徑。 完成本文中的步驟之前，請確定您已閱讀 移轉概觀、判斷 RoboCopy 是最適合您需求的工具，並部署了移轉所需的 Azure 記憶體資源。

AzCopy 與 RoboCopy

AzCopy 和 RoboCopy 本質上是不同的工具。 RoboCopy 使用 SMB 並完整複製檔案，非常適合進行遷移。 有關檔案忠實度的更多資訊，請參閱遷移基礎。 AzCopy 是一款雲端原生工具，使用 REST。

關鍵的行為差異是： RoboCopy /MIR 會將來源鏡像到目標。 它能處理新增、變更和刪除的檔案。 AzCopy 同步不會從目標端移除來源上刪除的檔案，導致遷移場景不完整。 因此，不要用 AzCopy 來進行以 Azure 檔案分享為目標的遷移情境。

掛接 Azure 檔案共享

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

重要事項

以系統管理層級存取掛接 Azure 檔案共用：可使用以身分為基礎且具備系統管理層級 Azure RBAC 角色的存取 (建議)，或使用儲存體帳戶金鑰 (較不安全)。

檢閱使用 Windows 搭配 Azure 檔案共用，然後掛接您想開始執行 RoboCopy 的 SMB Azure 檔案共用。

使用 RoboCopy 將檔案複製到 Azure 檔案共用

下列 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>
Switch 意義
/MT:n 允許 RoboCopy 以多執行緒方式執行。 n 的預設值是 8。 上限為 128 個執行緒。 雖然較高的執行緒數有助於用盡可用頻寬，但不代表執行緒越多移轉就一定更快。 Azure 檔案儲存體 的測試顯示，8 到 20 在初次複製執行中可呈現較均衡的效能。 後續的 /MIR 執行會逐漸受到可用計算與可用網路頻寬的影響。 針對後續的執行，讓您的執行緒計數值更貼近處理器核心計數和每個核心的執行緒計數。 請考量是否需要將核心保留給實際執行伺服器可能會有的其他工作。 Azure 檔案儲存體 的測試顯示，最多 64 個執行緒可產生良好效能，但前提是處理器可同時維持它們持續運作。
/R:n 首次嘗試複製失敗之檔案的最大重試次數。 RoboCopy 會在該檔案於此次執行中永久複製失敗前，嘗試複製 n 次。 您可最佳化執行效能：如果您認為過去的逾時問題造成失敗，請選擇 2 或 3。 這在 WAN 連結上更常見。 如果您認為檔案複製失敗是因為檔案正在使用中，請選擇不重試或選擇 1。 幾秒後再試一次，可能不足以讓檔案的使用中狀態改變。 將檔案保持開啟的使用者或應用程式，可能還需要多達數小時的時間。 在此情況下，接受檔案未複製，並在您規劃的後續 RoboCopy 執行中再補捉它，最終可能仍能成功複製該檔案。 這可讓目前的執行更快完成，不會因為大量重試而被拖長，而這些重試最後多數仍會因檔案在重試逾時前持續保持開啟而導致複製失敗。
/W:n 指定 Robocopy 要等待多長時間，再嘗試複製在上次嘗試期間未成功複製的檔案。 n是每次重試之間要等待的秒數。 /W:n常與 /R:n 一起使用。
/B 以備份應用程式所使用的相同模式執行 Robocopy。 此參數可讓 Robocopy 移動目前使用者沒有權限的檔案。 備份切換參數需要您在提高權限的系統管理命令列或 PowerShell 視窗中執行 RoboCopy 命令。 如果您將 RoboCopy 用於 Azure 檔案儲存體，請務必使用儲存體帳戶存取金鑰 (而非網域身分) 來掛接 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 謹慎使用
使用重新啟動模式。 如果存取遭拒，此選項會使用備份模式。 因為檢查點，此選項會大幅降低複製效能。

RoboCopy 可能會報告檔案被複製，即使不需要資料傳輸。 此行為是因為 robocopy 在產生輸出時會同時評估檔案資料與元資料變更。

要正確解讀結果，請檢視指令輸出中的檔案狀態：

  • 較新的：檔案資料會被複製到目的地。
  • 修改：僅更新元資料;檔案資料不會被重新複製。

在這兩種情況下，RoboCopy 可能會像資料傳輸一樣報告位元組數。 這種行為在驗證複製操作時會造成混淆。

重要事項

我們建議使用 Windows Server 2022 或更新版本。 使用 Windows Server 2019 時，請確保已更新到最新修補層級，或至少已安裝 OS 更新 KB5005103。 它包含針對某些 RoboCopy 案例的重要修正。

秘訣

如果 RoboCopy 影響您的生產環境、回報大量錯誤，或進度不如預期，請查看疑難排解區段。

完成遷移切換

當您第一次執行 RoboCopy 命令時，您的使用者與應用程式仍在存取移轉來源上的檔案，並可能持續變更它們。 RoboCopy 可能已處理某個目錄並移到下一個目錄，接著來源位置上的使用者新增、變更或刪除了一個檔案，而該檔案在這次 RoboCopy 執行中就不會再被處理。 這是預期的行為。

第一次執行的重點是將大量變動中的資料搬移到您的 Azure 檔案共用。 第一次複製可能需要一段時間。 如需更多可能影響 RoboCopy 速度的因素深入解析，請查看疑難排解區段。

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

第二次對同一個共用執行 RoboCopy 時，完成速度會更快，因為它只需要傳輸自上次執行後發生的變更。 您可以針對同一個共用重複執行工作。

在評估可接受的停機時間後，您需要移除使用者對來源共用的存取權。 您可以透過任何可防止使用者變更檔案與資料夾結構及內容的步驟來達成。 例如，將您的 DFS 命名空間指向不存在的位置，或變更每個共用上的 ACL。

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

您可以嘗試在不同的來源與目標共用之間平行執行其中幾個複製。 這麼做時，請留意您的網路輸送量與核心對執行緒數的比例，避免讓系統負載過高。

疑難排解和最佳化

某次 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 會遍歷你指定的命名空間，並在初始執行及後續追回時評估每個檔案和資料夾的複製情況。 這些重複執行可減少停機時間，並提升遷移檔案的整體成功率。

頻寬不一定是最大的限制因素。 對於擁有許多小檔案的大型命名空間，命名空間列舉速度對總複製時間的影響可能大於吞吐量。 複製 1 TiB 的小檔案所需時間遠比複製 1 TiB 較大檔案長得多。 這種差異是預期中的。

RoboCopy 透過選項 /MT:n 支援多執行緒複製， 其中 n 代表可使用的執行緒數量。 在為 RoboCopy 配置機器時，請考慮處理器核心數量（大多數 CPU 每核心提供兩個執行緒）以及你計劃平行執行多少 RoboCopy 工作。

更多執行緒能更快複製小檔案，但對大型檔案可能無法提供成比例的效益。 大型檔案的高執行緒數量會增加吞吐量或 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 工作會再嘗試一次。 因為檔案正在使用中或因逾時問題而失敗的檔案，常能用這種方式最終成功複製。

使用 Robocopy 將 Azure 檔案儲存體 快照的檔案複製到本地硬碟

你可以使用 Robocopy 將 SMB Azure 檔案分享的快照視圖中檔案和資料夾複製回本地硬碟。 欲了解更多資訊，請參閱 從共享快照將資料複製回本地磁碟。

估算儲存體交易費用

當您開始移轉到 Azure 檔案儲存體 時，RoboCopy 會將您的檔案與資料夾複製到 Azure。 依據您的 Azure 檔案儲存體 計費模型，可能會產生交易費用。 請參閱了解計費。

如果你的 HDD（標準）Azure 檔案共享採用隨用付費計費模式，可能很難估算遷移會產生多少交易。

  • 您無法依據來源使用的儲存體容量來估算交易數量。 交易數量會隨著移轉的命名空間項目 (檔案與資料夾) 數量及其屬性而擴增，而不是隨著大小。 例如，移轉 1 GiB 的小檔案比移轉 1 GiB 的大檔案需要更多交易。
  • 為了減少停機時間，你可能需要從來源到目標執行多次複製操作。 每次複製操作都會處理所有來源和目標項目，但後續執行會更快完成。 在初次作業之後，只有兩次複製之間引入的差異才會透過網路傳輸。 務必了解：即使傳輸的資料較少，所需的交易數量仍可能相同。
  • 同一個檔案複製兩次不一定會產生相同的交易數量。 處理先前複製執行中已移轉的項目，可能只需要少數讀取交易。 相較之下，兩次複製之間若中繼資料或內容發生變更，可能需要較多交易來更新目標。

先對自己的資料做一些初步測試，以更了解一次檔案遷移產生了多少交易。

後續步驟

下列文章可協助您了解進階選項與最佳做法。

  • 上次更新時間：