共用方式為

將 StorSimple 1200 遷移至 Azure 檔案同步

  • 發行項

StorSimple 1200 系列是在內部部署資料中心執行的虛擬設備。 您可以將此設備的資料移轉至 Azure 檔案同步環境。 Azure 檔案同步是 StorSimple 設備可遷移到的預設和策略性長期 Azure 服務。 本文提供成功移轉至 Azure 檔案同步的背景知識和移轉步驟。

注意

StorSimple 服務 (包括 StorSimple 裝置管理員 8000 和 1200 系列和 StorSimple 資料管理員) 已終止支援。 StorSimple 的支援終止於 2019 年，在 Microsoft 生命週期原則和 Azure 通訊 頁面上發佈。 其他通知會透過電子郵件傳送，並張貼在 Azure 入口網站和 StorSimple 概觀中。 如需其他詳細資料，請連絡 Microsoft 支援服務。

適用於

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

Azure 檔案同步

Azure 檔案同步是一項 Microsoft 雲端服務，以兩個主要元件為基礎：

  • 檔案同步處理和雲端階層處理。
  • 檔案共用作為 Azure 中的原生儲存體，可透過多種通訊協定來存取，例如 SMB 和 FileREST。 Azure 檔案共用相當於 Windows Server 上的檔案共用，可以原生掛接為網路磁碟機。 它支援重要的檔案精確度層面，例如屬性、權限和時間戳記。 與 StorSimple 不同的是，不需要應用程式/服務來解譯儲存在雲端中的檔案和資料夾。 若要在雲端中儲存一般用途的檔案伺服器資料和某些應用程式資料，這是理想且最具彈性的方法。

本文著重於移轉步驟。 若您想要深入了解 Azure 檔案同步，建議您參閱下列文章：

移轉目標

目標是要確保生產資料的完整性，以及保證可用性。 後者需要盡可能縮短停機時間，使其符合一般維護期間，或僅略為超過。

StorSimple 1200 遷移至 Azure 檔案同步的路徑

需要本機 Windows Server 才能執行 Azure 檔案同步代理程式。 Windows Server 的最低需求為 2012R2 伺服器，但最好使用 Windows Server 2019。

替代移轉路徑有很多種，若要全數加以列載，並說明這些路徑與本文建議的最佳做法相較有哪些風險或缺點，文章可能會太過冗長。

本文中下方各步驟的移轉路由概觀。

上圖說明對應至本文各節的步驟。

步驟 1：佈建您的內部部署 Windows Server 和儲存體

  1. 以虛擬機器 (VM) 或實體伺服器建立 Windows Server 2019 (至少 2012R2)。 此外也支援 Windows Server 容錯移轉叢集。
  2. 佈建或新增直接連結存放裝置 (即 DAS，相較於不受支援的 NAS)。 Windows Server 儲存體的大小必須大於或等於虛擬 StorSimple 1200 設備的可用容量大小。

步驟 2：設定您的 Windows Server 儲存體

在此步驟中，您會將 StorSimple 儲存體結構 (磁碟區和共用) 對應至 Windows Server 儲存體結構。 如果您打算變更儲存體結構，也就是磁碟區數目、資料夾與磁碟區的關聯，或是目前 SMB/NFS 共用之上或之下的子資料夾結構，您現在即應考量這些變更。 在設定 Azure 檔案同步之後變更您的檔案和資料夾結構是很麻煩的，應該避免。 本文假設您進行 1:1 對應，因此當您依照本文的步驟操作時，必須將對應變更納入考量。

  • 所有的生產資料都不應出現在 Windows Server 系統磁碟區上。 系統磁碟區上不支援雲端階層處理。 不過，移轉以及 StorSimple 取代之類的連續作業都需要此功能。
  • 在您的 Windows Server 上佈建相同數量的磁碟區，就像您的 StorSimple 1200 虛擬設備一樣。
  • 設定您需要的任何 Windows Server 角色、功能和設定。 建議您選擇加入 Windows Server 更新，讓您的作業系統保持安全且最新的狀態。 同樣地，建議您選擇加入 Microsoft Update，讓 Microsoft 應用程式保持在最新狀態 (包括 Azure 檔案同步代理程式)。
  • 在閱讀下列步驟之前，請勿設定任何資料夾或共用。

步驟 3：部署第一個 Azure 檔案同步雲端資源

若要完成此步驟，您需要 Azure 訂用帳戶認證。

要為 Azure 檔案同步設定的核心資源，稱為儲存體同步服務。 我們建議您只針對目前或未來要同步處理相同檔案集的所有伺服器，部署一個服務即可。 當您確知有幾組絕不可交換資料的伺服器時，才需要建立多個儲存體同步服務。 例如，您可能會有某些伺服器絕不會同步處理相同的 Azure 檔案共用。 否則，使用單一儲存體同步服務將是最佳做法。

為您的儲存體同步服務選擇靠近您所在位置的 Azure 區域。 所有其他雲端資源都必須部署在相同的區域中。 若要簡化管理，請在訂用帳戶中建立新的資源群組，以存放同步和儲存體資源。

如需詳細資訊，請參閱部署 Azure 檔案同步相關文章中部署儲存體同步服務的這一節。請只遵循該篇文章的這一節。 後續步驟將提供文中其他小節的連結。

步驟 4：使您的本機磁碟區和資料夾結構符合 Azure 檔案同步和 Azure 檔案共用資源

在此步驟中，您將決定您需要多少 Azure 檔案共用。 單一 Windows Server 執行個體 (或叢集) 最多可同步 30 個 Azure 檔案共用。

您的磁碟區上可能會有更多您目前在本機共用的資料夾，以作為使用者和應用程式的 SMB 共用。 描述此案例最簡單的方式是想像 1:1 對應至 Azure 檔案共用的內部部署共用。 如果您的共用數目夠少 (一個 Windows Server 執行個體低於 30)，則我們建議使用 1:1 對應。

如果您有 30 個以上的共用，通常不需要將內部部署共用 1:1 對應至 Azure 檔案共用。 請考慮下列選項。

共用群組

例如，如果人力資源 (HR) 部門有 15 個共用，您可能會考慮將所有 HR 資料儲存在單一 Azure 檔案共用中。 將多個內部部署共用儲存在一個 Azure 檔案共用中，您仍可以在本機 Windows Server 執行個體上建立一般的 15 個 SMB 共用。 這只表示您會將這些 15 個共用的根資料夾組織成通用資料夾下的子資料夾。 然後，您會將此通用資料夾同步至 Azure 檔案共用。 如此一來，這個內部部署共用群組僅需要一個雲端中的 Azure 檔案共用。

磁碟區同步

Azure 檔案同步支援將磁碟區的根目錄同步至 Azure 檔案共用。 如果您同步磁碟區根目錄，則所有子資料夾和檔案都會移至相同的 Azure 檔案共用。

同步磁碟區的根目錄不一定是最佳選項。 同步多個位置有其好處。 例如，這麼做有助於讓每個同步範圍的項目數保持在較低的數量。 我們採用每個共用 1 億個項目 (檔案和資料夾) 的配置，來測試 Azure 檔案共用和 Azure 檔案同步。 但最佳做法是嘗試將單一共用中的數目保持在 2 千萬或 3 千萬個以下。 使用較少的項目數設定 Azure 檔案同步，不只有利於檔案同步處理。較少的項目數也有利於下列這些案例：

  • 雲端內容的初始掃描可更快完成，進而在針對 Azure 檔案同步啟用的伺服器上減少顯示命名空間的等待時間。
  • 從 Azure 檔案共用快照集進行雲端還原的速度將會更快。
  • 內部部署伺服器的災害復原速度可大幅提升。
  • 可以更快地偵測和同步直接在 Azure 檔案共用中 (同步之外) 所做的變更。

提示

如果您不知道有多少個檔案和資料夾，請參考 JAM Software GmbH 的 TreeSize 工具。

部署對應的結構化方法

在後續步驟中部署雲端儲存體之前，請務必在內部部署資料夾與 Azure 檔案共用之間建立對應。 此對應會通知您將佈建的 Azure 檔案同步「同步群組」資源的數量和種類。 同步群組會將您伺服器上的 Azure 檔案共用和資料夾繫結在一起，並建立同步連線。

若要決定您需要多少個 Azure 檔案共用，請參閱下列限制和最佳做法。 這麼做可協助您最佳化對應。

  • 用來安裝 Azure 檔案同步代理程式的伺服器可與最多 30 個 Azure 檔案共用進行同步。

  • Azure 檔案共用會部署在儲存體帳戶中。 這種安排可讓儲存體帳戶成為效能數值的調整目標，例如 IOPS 和輸送量。

    部署 Azure 檔案共用時，請注意儲存體帳戶的 IOPS 限制。 在理想的情況下，您應該讓檔案共用與儲存體帳戶 1:1 對應。 不過，由於貴組織和 Azure 有各種限制和侷限，這種情況不一定永遠可行。 當一個儲存體帳戶中不可能只部署一個檔案共用時，請考慮哪些共用高度活躍、哪些共用較不活躍，以確保最熱門的檔案共用不會一起放在同一個儲存體帳戶中。

    如果您打算將應用程式隨即轉移至 Azure，並以原生方式使用 Azure 檔案共用，您可能需要更高的 Azure 檔案共用效能。 如果這種使用方式是一種可能性，即使在未來，最好還是在本身的儲存體帳戶中建立單一標準 Azure 檔案共用。

  • 每個 Azure 區域中每一訂用帳戶的限制是 250 個儲存體帳戶。

提示

有了這項資訊，通常必須將磁碟區上的多個最上層資料夾分組為新的通用根目錄。 然後，您可以將這個新的根目錄和您分組的所有資料夾同步至單一 Azure 檔案共用。 這項技術可讓您保持在每部伺服器 30 個 Azure 檔案共用同步的限制內。

在通用根目錄下，這種分組不會影響對您資料的存取。 您的 ACL 保持不變。 您只需要在現在變更為通用根目錄的本機伺服器資料夾上，調整任何可能有的共用路徑 (例如 SMB 或 NFS 共用)。 沒有其他變更。

重要

Azure 檔案同步最重要的調整範圍是需要同步的項目數 (檔案和資料夾)。 如需詳細資訊，請參閱 Azure 檔案同步調整目標。

最佳做法是讓每個同步範圍的項目數保持在少量。 這是您將資料夾對應至 Azure 檔案共用時應考量的重要因素。 Azure 檔案同步會以每個共用 1 億個項目 (檔案和資料夾) 的配置進行測試。 但通常最好是將單一共用中的數目保持在 2 千萬或 3 千萬個以下。 如果開始超過這些數目，請將您的命名空間分割成多個共用。 如果大致上低於這些數目，則可以繼續將多個內部部署共用分組至相同的 Azure 檔案共用。 這種做法可提供您成長的空間。

在您的情況中，您可能會使用先前所述的新通用根資料夾方法，以邏輯方式將一組資料夾同步至相同的 Azure 檔案共用。 但是重新分組資料夾可能還是比較好，因為資料夾會同步至兩個 (而非一個) Azure 檔案共用。 您可以使用這種方法，在伺服器之間將每個檔案共用的檔案和資料夾數目保持平衡。 您也可以分割內部部署共用，並在更多內部部署伺服器之間進行同步，以增加每台額外伺服器與 30 個以上 Azure 檔案共用同步的功能。

常見的檔案同步案例和考量事項

# 同步案例 支援 考量事項 (或限制) 解決方案 (或因應措施)
1 具有多個磁碟/磁碟區和多個共用的檔案伺服器，同步至相同的目標 Azure 檔案共用 (合併) No 目標 Azure 檔案共用 (雲端端點) 僅支援與一個同步群組進行同步。

同步群組僅支援每個已註冊伺服器一個伺服器端點。		 1) 先將一個磁碟 (其根磁碟區) 同步至目標 Azure 檔案共用。 從最大的磁碟/磁碟區開始，有助於內部部署的儲存體需求。 將雲端階層處理設定為將所有資料分層至雲端，藉此釋放檔案伺服器磁碟上的空間。 將資料從其他磁碟區/共用移至正在同步的目前磁碟區。 請逐一繼續進行步驟，直到將所有資料分層至雲端/移轉為止。
2) 一次以一個根磁碟區 (磁碟) 為目標。 使用雲端階層處理將所有資料分層至目標 Azure 檔案共用。 從同步群組中移除伺服器端點、使用下一個根磁碟區/磁碟重新建立端點、同步處理，然後重複此流程。 注意：可能需要重新安裝代理程式。
3) 建議使用多個目標 Azure 檔案共用 (根據效能需求使用相同或不同的儲存體帳戶)
2 具有單一磁碟區和多個共用的檔案伺服器，同步至相同的目標 Azure 檔案共用 (合併) Yes 每個已註冊的伺服器無法有多個伺服器端點同步至相同的目標 Azure 檔案共用 (與上述相同) 同步存放多個共用或最上層資料夾的磁碟區根目錄。 如需詳細資訊，請參閱共用群組概念和磁碟區同步。
3 具有多個共用和/或磁碟區的檔案伺服器，同步至單一儲存體帳戶下的多個 Azure 檔案共用 (1:1 共用對應) Yes 單一 Windows Server 執行個體 (或叢集) 最多可同步 30 個 Azure 檔案共用。

儲存體帳戶是效能的調整目標。 IOPS 和輸送量會在檔案共用之間共用。

將每個同步群組的項目數目保持在每個共用 1 億個項目 (檔案和資料夾) 內。 在理想情況下，最好保持每個共用 2,000 或 3,000 萬個以下。		 1) 使用多個同步群組 (同步群組數目 = 要同步至的 Azure 檔案共用數目)。
2) 在此案例中一次只能同步 30 個共用。 如果您在該檔案伺服器上有超過 30 個共用，請使用共用群組概念和磁碟區同步，以減少來源的根資料夾或最上層資料夾數目。
3) 使用內部部署的其他檔案同步伺服器，並將資料分割/移動至這些伺服器，以解決來源 Windows 伺服器的限制。
4 具有多個共用和/或磁碟區的檔案伺服器，同步至不同儲存體帳戶下的多個 Azure 檔案共用 (1:1 共用對應) Yes 單一 Windows Server 執行個體 (或叢集) 最多可同步 30 個 Azure 檔案共用 (相同或不同的儲存體帳戶)。

將每個同步群組的項目數目保持在每個共用 1 億個項目 (檔案和資料夾) 內。 在理想情況下，最好保持每個共用 2,000 或 3,000 萬個以下。		 與上述方法相同
5 具有單一項目 (根磁碟區或共用) 的多個檔案伺服器，同步至相同的目標 Azure 檔案共用 (合併) No 同步群組無法使用已在另一個同步群組中設定的雲端端點 (Azure 檔案共用)。

儘管同步群組可以在不同的檔案伺服器上擁有伺服器端點，但檔案不能不同。		 請遵循上述案例 #1 中的指引，並同時考慮一次以一部檔案伺服器為目標。

建立對應表

顯示對應資料表範例的圖表。下載下列檔案以體驗和使用此影像的內容。

使用先前的資訊來判斷您需要多少 Azure 檔案共用，以及現有資料的哪些部分最後會在哪個 Azure 檔案共用中。

建立資料表以記錄您的想法，以便在需要時加以參考。 保持組織化相當重要，因為當您一次佈建許多 Azure 資源時，很可能會遺失對應計畫的詳細資料。 下載下列 Excel 檔案作為範本，以利建立您的對應。


可設定下載內容的 Excel 圖示。 下載命名空間對應範本。

步驟 5：佈建 Azure 檔案共用

Azure 檔案共用會儲存在雲端的 Azure 儲存體帳戶中。 在此需考量另一個層級的效能注意事項。

如果共用的使用率很頻繁 (有許多使用者和/或應用程式使用共用)，則兩個 Azure 檔案共用可能會達到儲存體帳戶的效能限制。

最佳做法是部署各有一個檔案共用的儲存體帳戶。 如果您有封存共用，或預期會有較低的日常活動，便可以將多個 Azure 檔案共用集中放在相同的儲存體帳戶中。

這些考量事項較適用於直接雲端存取 (透過 Azure VM)，而不是 Azure 檔案同步。如果您打算在這些共用上只使用 Azure 檔案同步，則可以將多個共用分組到單一 Azure 儲存體帳戶。

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

在上一個階段中，您已決定適當的共用數目。 在此步驟中，您會將儲存體帳戶對應至檔案共用。 現在，請部署適當數量的 Azure 儲存體帳戶，其中包含適當數目的 Azure 檔案共用。

請確定每個儲存體帳戶的區域都相同，且符合您已部署儲存體同步服務資源的區域。

警告

如果您建立具有 100 TiB 限制的 Azure 檔案共用，則該共用只能使用本地備援儲存體或區域備援儲存體的備援選項。 使用 100 TiB 檔案共用之前，請先考量您的儲存體備援需求。

依預設，Azure 檔案共用仍會以 5 TiB 的限制建立。 請遵循建立 Azure 檔案共用中的步驟來建立大型檔案共用。

當您部署儲存體帳戶時，另一個考量是 Azure 儲存體的備援。 請參閱 Azure 儲存體備援選項。

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

儲存體帳戶設定

您可以在儲存體帳戶上進行許多設定。 您應將下列檢查清單用於儲存體帳戶設定。 舉例來說，您可以在完成移轉後變更網路設定。

  • 防火牆和虛擬網路：已停用 - 不設定任何 IP 限制，或限制儲存體帳戶存取特定虛擬網路。 在移轉期間，會使用儲存體帳戶的公用端點。 必須允許來自 Azure VM 的所有 IP 位址。 在移轉後，最好在儲存體帳戶上設定防火牆規則。
  • 私人端點：支援 - 您可以啟用私人端點，但公用端點會用於移轉，必須保持可用狀態。

步驟 6：設定 Windows Server 目標資料夾

在先前的步驟中，您考量過將決定同步拓撲元件的各個層面。 現在請準備好伺服器來接收要上傳的檔案。

建立會將每個資料夾同步至其本身 Azure 檔案共用的所有資料夾。 請務必依循您先前記下的資料夾結構。 比方說，如果您決定將多個本機 SMB 共用一起同步至單一 Azure 檔案共用，則您必須將其放在磁碟區的通用根資料夾底下。 請立即在磁碟區上建立這個目標根資料夾。

您佈建的 Azure 檔案共用數目，應符合您在此步驟中建立的資料夾數目加上您將在根層級同步的磁碟區數目。

步驟 7：部署 Azure 檔案同步代理程式

在本節中，您將在 Windows Server 執行個體上安裝 Azure 檔案同步代理程式。

部署指南指出您必須關閉 Internet Explorer 增強式安全性設定。 此安全性措施不適用於 Azure 檔案同步。關閉此功能可讓您向 Azure 進行驗證，而不會有任何問題。

開啟 PowerShell。 使用下列命令來安裝必要的 PowerShell 模組。 顯示系統提示時，請務必安裝完整的模組和 NuGet 提供者。

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

如果您從伺服器連線到網際網路時發生任何問題，現在該來解決這些問題了。 Azure 檔案同步會使用任何可用的網路連線連接至網際網路。 也支援透過 Proxy 伺服器連線到網際網路。 您可以立即設定整個電腦的 proxy，或是在代理程式安裝期間指定只有 Azure 檔案同步才會使用的 Proxy。

如果設定 Proxy 表示需要為伺服器開啟防火牆，那麼您可能適用此方法。 在伺服器安裝結束時，當您完成伺服器註冊之後，網路連線報告會顯示在您選取的區域中，Azure 檔案同步需要與 Azure 中的哪些確切端點 URL 通訊。 報告也會指出需要通訊的原因。 您可以使用此報告，將伺服器周圍的防火牆鎖定於特定 URL。

您也可以採取較保守的方法，不要完全開放防火牆。 您可以改為限制伺服器與較高層級的 DNS 命名空間進行通訊。 如需詳細資訊，請參閱 Azure 檔案同步 Proxy 和防火牆設定。 請遵循您自己的網路最佳做法。

在伺服器安裝精靈結束時，將會開啟伺服器註冊精靈。 請向前述儲存體同步服務的 Azure 資源註冊伺服器。

部署指南提供這些步驟的詳細說明，包括您應該先安裝 PowerShell 模組：Azure 檔案同步代理程式安裝。

使用最新的代理程式。 您可以從 Microsoft 下載中心下載：Azure 檔案同步代理程式。

成功安裝和伺服器註冊之後，您可以確認已成功完成此步驟。 移至 Azure 入口網站中的儲存體同步服務資源。 在左側功能表中，移至 [已註冊的伺服器]。 您會看到其中列出了您的伺服器。

步驟 8：設定同步

此步驟會將您在先前步驟中於 Windows Server 執行個體上設定的所有資源和資料夾結合在一起。

  1. 登入 Azure 入口網站。
  2. 找出您的儲存體同步服務資源。
  3. 針對每個 Azure 檔案共用，在儲存體同步服務資源中建立新的同步群組。 在 Azure 檔案同步的術語中，當您說明建立同步群組的同步拓撲時，Azure 檔案共用就成為雲端端點。 建立同步群組時，請為其提供一個熟悉的名稱，以便您辨識在該處同步的是哪一組檔案。 請務必參考具有相符名稱的 Azure 檔案共用。
  4. 建立同步群組之後，其資料列將會出現在同步群組清單中。 選取名稱 (連結)，以顯示同步群組的內容。 您將會在 [雲端端點] 下方看到您的 Azure 檔案共用。
  5. 找到 [新增伺服器端點] 按鈕。 您在本機伺服器上佈建的資料夾將會成為這個伺服器端點的路徑。

警告

請務必開啟雲端階層處理！ 如果您的本機伺服器沒有足夠的空間可儲存 StorSimple 雲端儲存體中的資料大小總計，就必須執行此動作。 將您的階層處理原則暫時設定為 99% 的磁碟區可用空間，並在移轉完成後將其變更回更合理的層級。

針對所有必須同步設定的 Azure 檔案共用/伺服器位置，重複建立同步群組以及將相符的伺服器資料夾新增為伺服器端點的步驟。

步驟 9：複製您的檔案

基本移轉方法是透過 RoboCopy 從 StorSimple 虛擬設備移轉至 Windows Server，和透過 Azure 檔案同步移轉至 Azure 檔案共用。

執行 Windows Server 目標資料夾的第一個本機複本：

  • 識別虛擬 StorSimple 設備上的第一個位置。
  • 識別 Windows Server 上已設定 Azure 檔案同步的相符資料夾。
  • 使用 RoboCopy 啟動複製

下列 RoboCopy 命令會將您 StorSimple Azure 儲存體中的檔案召回至本機 StorSimple，然後將其移至 Windows Server 目標資料夾。 Windows Server 會將其同步至 Azure 檔案共用。 本機 Windows Server 磁碟區已滿時，雲端階層處理將會啟動，且會將已成功同步的檔案分層。 雲端階層處理會產生足夠的空間，讓您可以繼續從 StorSimple 虛擬設備複製。 雲端階層處理會每小時檢查一次已同步的內容，並且釋出磁碟空間以達到 99% 的磁碟區可用空間。

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)，才能正確記錄測試結果。
/LFSM 僅適用於具有階層式儲存體的目標。 若目的地是遠端 SMB 共用則不支援。
指定 Robocopy 在「低可用空間模式」中運作。此參數僅只對具有階層式儲存體且在 Robocopy 完成前用完本機容量的目標很有用。 這是特別為了與啟用 Azure 檔案同步雲端階層處理的目標搭配使用而新增的。 它可獨立於 Azure 檔案同步之外使用。在此模式中，每當檔案複製造成目的地磁碟區的可用空間低於「下限」值時，就會暫停 Robocopy。 此值可由旗標的 /LFSM:n 形式指定。 參數 n 是在基礎 2 中指定的：nKB、nMB 或 nGB。 如果指定 /LFSM 時沒有明確的下限值，則下限會設定為目的地磁碟區大小的 10%。 可用空間不足模式與 /MT、/EFSRAW 或 /ZB 不相容。 Windows Server 2022 已新增 /B 的支援。 如需詳細資訊 (包含相關錯誤 (bug) 和因應措施的詳細資料)，請參閱下方 Windows Server 2022 和 RoboCopy LFSM 區段。
/Z 謹慎使用
在重新啟動模式中複製檔案。 只有在不穩定的網路環境中，才建議使用此參數。 因為有額外的記錄，這會大幅降低複製效能。
/ZB 謹慎使用
使用重新啟動模式。 如果存取遭拒，此選項會使用備份模式。 因為檢查點，此選項會大幅降低複製效能。

重要

我們建議使用 Windows Server 2022。 使用 Windows Server 2019 時，請確定已安裝最新的修補程式層級或至少安裝 OS 更新 KB5005103。 其中包含特定 Robocopy 案例所需的重要修正。

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

第一次執行是要將大量的資料移回內部部署環境，透過 Azure 檔案同步移至 Windows Server 並備份至雲端。此作業可能需要很長的時間，視下列因素而定：

  • 您的下載頻寬
  • StorSimple 雲端服務的召回速度
  • 上傳頻寬
  • 必須由其中一項服務處理的項目 (檔案和資料夾) 數

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

第二次會較快完成，因為只需要傳輸上次執行之後發生的變更。 這些變更是最新的，因此可能是 StorSimple 的本機變更。 這會進一步縮短時間，因為從雲端召回的需求已減少。 在這第二次執行的期間，仍可能會累積新的變更。

重複此程序，直到完成的所需的時間是可接受的停機時間並且您對此感到滿意。

如果已考慮可接受的停機時間，並已準備好使 StorSimple 位置離線時，請立即執行此動作。 例如，移除 SMB 共用，讓使用者無法存取該資料夾，或採取任何其他適當的步驟來防止 StorSimple 上此資料夾中的內容發生變更。

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

在 Windows Server 資料夾上建立共用，並視情況調整您的 DFS-N 部署以指向該處。 請務必設定與您的 StorSimple SMB 共用相同的共用層級權限。

您現在已完成將共用或共用群組移轉至一般根目錄或磁碟區，視您先前對應的內容而定。

您可以嘗試平行執行一些複本。 建議您逐一處理每個 Azure 檔案共用的範圍。

警告

當您將所有資料從 StorSimple 移至 Windows Server，並完成您的移轉之後，請返回 Azure 入口網站中的所有同步群組，並將雲端階層處理磁碟區的可用空間百分比值調整為更適合快取使用率的值，例如 20%。

雲端階層處理磁碟區的可用空間原則會在磁碟區層級運作，且可能會有多個伺服器端點與其同步。 就算您只是忘了調整一個伺服器端點的可用空間，同步也將繼續套用最嚴格的規則，並嘗試保留 99% 的可用磁碟空間，且致使本機快取無法如預期執行。 除非您的目標是只用僅包含很少存取的封存資料的磁碟區命名空間，否則您需要在每個伺服器端點上調整可用空間原則。

疑難排解

您最有可能遇到的問題是，Windows Server 端的 RoboCopy 命令因「磁碟區已滿」而失敗。 如果發生這種情況，則您的下載速度可能會優於上傳速度。 雲端階層處理會每小時執行一次，從本機 Windows Server 磁碟撤除已同步的內容。

讓同步繼續進行，並且讓雲端階層處理釋出磁碟空間。 您可以在 Windows Server 的檔案總管中觀察可用空間量。

當您的 Windows Server 有足夠的可用容量時，重新執行命令即可解決問題。 遇到這種情況時作業並不會受阻，可以放心繼續操作。 重新執行命令有點煩，是唯一的影響。

您可能也會遇到其他 Azure 檔案同步問題。 如果發生這種情況，請參閱 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:n n = 重試複製失敗檔案的頻率，以及
  • /W:n n = 重試之間的等待秒數

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

Windows Server 2022 和 RoboCopy LFSM

RoboCopy 參數 /LFSM 可以用於避免 RoboCopy 作業失敗與磁碟區已滿錯誤。 每當檔案複製造成目的地磁碟區的可用空間低於「下限」值時，就會暫停 RoboCopy。

搭配使用 RoboCopy 與 Windows Server 2022。 僅此版本的 RoboCopy 包含重要的錯誤 (bug) 錯誤和功能，可使參數與大部分移轉所需的其他旗標相容。 例如，與 /B 旗標的相容性。

/B 以備份應用程式所使用的相同模式執行 RoboCopy。 此參數可讓 RoboCopy 移動目前使用者沒有權限的檔案。

一般而言，RoboCopy 可以在來源、目的地或第三方電腦上執行。

重要

若要使用 /LFSM，RoboCopy 必須在 Windows Server 2022 目標 Azure 檔案同步伺服器上執行。

另請注意，使用 /LFSM 時，您必須也使用目的地的本機路徑，而不是 UNC 路徑。 例如，您應使用的目的地路徑為 E:\Foldername，而不是 \\ServerName\FolderName 等 UNC 路徑。

警告

Windows Server 2022 上的 RoboCopy 目前可用版本有錯誤 (bug)，將導致暫停計算每個檔案錯誤的計數。 應用下列因應措施。

建議的 /R:2 /W:1 旗標增加檔案失敗的機率，原因是 /LFSM 會引起暫停。 在此範例中，因 /LFSM 導致暫停而未在 3 次暫停後複製的檔案，將導致 RoboCopy 不正確發生檔案失敗。 此情況的因應措施是使用 /R:n 和 /W:n 的較高值。 良好範例是 /R:10 /W:1800 (每隔 30 分鐘 10 次重試)。 這應提供 Azure 檔案同步階層處理演算法時間，在目的地磁碟區上建立空間。

此錯誤 (bug) 已修正，但尚未公開提供修正程式。 請檢查此段落以取得修正程式可用性的更新和部署方式。

注意

仍有疑問或遇到了任何問題嗎？
我們樂意提供協助：請直接寄送電子郵件：microsoft.com 上的 Azure 檔案移轉

移轉內容：

Azure 檔案同步內容：