共用方式為

使用 Azure 檔案同步從網路連接儲存裝置 (NAS) 遷移至混合式雲端部署

  • 發行項

這篇移轉文章是提到關鍵字 NAS 和 Azure 檔案同步的其中一篇文章。確認本文是否適用於您的案例：

  • 資料來源：網路連接儲存裝置 (NAS)
  • 移轉路由：NAS ⇒ Windows Server ⇒ 上傳並與 Azure 檔案共用同步
  • 在內部部署快取檔案：是，最終目標是 Azure 檔案同步部署。

如果您的案例不同，請查看移轉指南的表格。

Azure 檔案同步適用於直接連結存放裝置 (DAS) 位置，而不支援同步至網路連接儲存裝置 (NAS) 位置。 因此，您必須移轉檔案，而本文會引導您完成這類移轉的規劃和執行。

適用於

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

移轉目標

目標是將 NAS 裝置上的 SMB 檔案共用移至 Windows Server，然後利用 Azure 檔案同步進行混合式雲端部署。 一般情況下，移轉的方法必須保證生產資料在移轉期間的完整性和可用性。 後者需要盡可能縮短停機時間，使其符合一般維護期間，或僅略為超過。

移轉概觀

如移轉至 SMB Azure 檔案共用一文所述，使用正確的複製工具和方法很重要。 NAS 設備會直接在您的區域網路上公開 SMB 共用。 您可以使用 Azure Storage Mover 或 RoboCopy 移動檔案。

階段 1：識別您需要多少 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 圖示。 下載命名空間對應範本。

階段 2：在內部部署環境中佈建適合的 Windows Server

  • 建立 Windows Server 2022 或 Windows Server 2019 虛擬機器，或部署實體伺服器。 此外也支援 Windows Server 容錯移轉叢集。

  • 佈建或新增直接連結存放裝置 (即 DAS，相較於不受支援的 NAS)。

    您佈建的儲存體數量可能會小於您目前在 NAS 設備上使用的數量。 選擇使用此設定時，您也需要使用 Azure 檔案同步的雲端階層處理功能。 不過，當您在後續階段將檔案從較大的 NAS 空間複製到較小的 Windows Server 磁碟區時，您必須分批處理：

    1. 移動一組可容納於磁碟的檔案
    2. 讓檔案同步和雲端階層處理交互運作
    3. 在磁碟區上建立更多可用空間後，繼續處理下一批檔案。 或者，在本文的 RoboCopy 區段中檢閱 RoboCopy 命令，以使用新的 /LFSM 參數。 使用 /LFSM 可大幅簡化 RoboCopy 作業，但這與您可能需使用的其他 RoboCopy 參數不相容。 只有在移轉目的地是本機儲存體時，才使用 /LFSM 參數。 目的地是遠端 SMB 共用時不支援。

    您可以在 Windows Server 上佈建您的檔案在 NAS 設備上佔用的相等空間，而避免使用此批次方法。 請考慮在 NAS/Windows 上啟用重複資料刪除。 如果您不想要將這麼大量的儲存體永久認可至 Windows Server，您可以在移轉之後、調整雲端階層處理原則之前降低磁碟區大小。 這會為 Azure 檔案共用建立較小的內部部署快取。

您部署的 Windows Server 資源設定 (計算和 RAM)，主要取決於您要同步的項目 (檔案和資料夾) 數。 如有任何疑慮，建議您採用效能較高的設定。

了解如何依據您需要同步的項目 (檔案和資料夾) 數，調整 Windows Server 大小。

注意

先前連結的文章提供了一個資料表，其中列出伺服器記憶體 (RAM) 的範圍。 您可以為伺服器設定較少量的記憶體，但預期初始同步可能會耗費較多時間。

階段 3：部署 Azure 檔案同步雲端資源

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

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

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

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

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

在這個階段中，請參閱第 1 階段的對應表，然後用來佈建正確數目的 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 檔案共用命名時，應使用其內部部署對應項目所使用的類似名稱。

階段 5：部署 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 入口網站中的儲存體同步服務資源。 在左側功能表中，移至 [已註冊的伺服器]。 您會看到其中列出了您的伺服器。

階段 6：在 Windows Server 上設定 Azure 檔案同步

已註冊的內部部署 Windows Server 必須準備就緒，並已連線至網際網路，才能進行此程序。

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

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

重要

雲端階層處理是 Azure 檔案同步功能，可讓本機伺服器的儲存容量比雲端的儲存容量少，卻有完整的命名空間可使用。 本機上受關注的 (經常性) 資料也會在本機快取，以提供本機快速存取效能。 雲端階層處理是每個 Azure 檔案同步「伺服器端點」的選用功能。

警告

如果您在 Windows Server 磁碟區上佈建的儲存體比您在 NAS 設備上使用的資料少，則必須進行雲端階層處理。 如果您未開啟雲端階層處理，伺服器不會釋出空間來儲存所有檔案。 針對移轉暫時將您的階層處理原則設定為 99% 的磁碟區可用空間。 在完成移轉之後，請務必恢復雲端階層處理設定，並將其設定為較適用於長期的層級。

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

建立所有伺服器端點後，同步就會開始運作。 您可以建立測試檔案，並確認檔案是否從您的伺服器位置同步至已連線的 Azure 檔案共用 (如同步群組中的雲端端點所述)。

若否，伺服器資料夾和 Azure 檔案共用這兩個位置都會是空的，且其中一處會等待資料傳入。 在下一個步驟中，您會開始將檔案複製到 Windows Server，讓 Azure 檔案同步將其移至雲端。 如果您已啟用雲端階層處理，當您用盡本機磁碟區上的容量時，伺服器就會開始將檔案分層。

階段 7：使用 Azure Storage Mover 或 RoboCopy 複製資料

現在您可以使用 Azure Storage Mover 或 RoboCopy，將資料從 NAS 設備複製到 Windows Server，然後使用 Azure 檔案同步，將資料移至 Azure 檔案共用。 本指南使用 RoboCopy 進行初始複製作業。 若要改用 Azure Storage Mover，請參閱使用 Azure Storage Mover 移轉至 SMB Azure 檔案共用。

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

  • 識別 NAS 設備上的第一個位置。
  • 識別 Windows Server 上已設定 Azure 檔案同步的相符資料夾。
  • 啟動複製作業。

下列 RoboCopy 命令會將檔案從 NAS 儲存體複製到您的 Windows Server 目標資料夾。 Windows Server 會將其同步至 Azure 檔案共用。

如果您在 Windows Server 上佈建的儲存體比您的檔案在 NAS 設備上使用的少，表示您已設定雲端階層處理。 本機 Windows Server 磁碟區已滿時，雲端階層處理將會啟動，且會將已成功同步的檔案分層。 雲端階層處理會產生足夠的空間，讓您可以繼續從 NAS 設備複製。 雲端階層處理會每小時檢查一次已同步的內容，並且釋出磁碟空間以達到 99% 的磁碟區可用空間。

RoboCopy 移動檔案的速度有可能比同步至雲端和本機分層還快，因而導致本機磁碟空間用盡。 在此情況下，RoboCopy 會失敗。 建議您循序完成共用，避免發生此情況。例如，請勿同時啟動所有共用的複製作業，或僅移動可容納於 Windows Server 上現行可用空間量的共用。

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 案例所需的重要修正。

階段 8：使用者完全移轉

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

第一次執行是將大量資料移至您的 Windows Server，並透過 Azure 檔案同步進入雲端。第一次複製作業可能需要很長的時間，視下列情況而定：

  • 您的下載頻寬
  • 上傳頻寬
  • 區域網路速度，以及與此速度最搭配的 RoboCopy 執行緒數目
  • 需要由 RoboCopy 和 Azure 檔案同步處理的項目 (檔案和資料夾) 數目

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

第二次會較快完成，因為只需要傳輸上次執行之後發生的變更。 在這第二次執行期間，仍可累積新的變更。

重複此程序，直到特定位置完成 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。

您已完成將共用/共用群組遷移至通用根目錄或磁碟區的作業。 (取決於階段 1 中的對應)

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

警告

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

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

疑難排解

您最有可能遇到的問題是，Windows Server 端的 RoboCopy 命令因「磁碟區已滿」而失敗。 雲端階層處理會每小時執行一次，從本機 Windows Server 磁碟撤除已同步的內容。 其目標是要達到磁碟區上 99% 的可用空間。

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

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

請查看下一節中的連結，了解如何對 Azure 檔案同步問題進行疑難排解。

下一步

下列文章會協助您了解部署選項、最佳做法和疑難排解步驟。