使用 Azure 資料箱將資料離線遷移至 Azure 檔案同步

  • 發行項

此移轉文章是與關鍵字 Azure 檔案同步和 Azure 資料箱相關的其中一篇文章。 確認本文是否適用於您的案例：

A display of three sequential steps described in this migration guide. The column next to the image describes them in detail.

  • 資料來源：Windows Server 2012 R2 或更新版本，Azure 檔案同步將會安裝在其中，並且指向原始的檔案集。
  • 移轉路徑：Windows Server 2012 R2 或更新版本 ⇒ 資料箱 ⇒ Azure 檔案共用⇒與 Windows Server 原始檔案位置同步
  • 在內部部署環境中快取檔案：是，最終目標是從檔案現在所在位置同步檔案的 Azure 檔案同步部署。

使用 Azure 資料箱是將大量資料從內部部署 Windows Server 移至個別 Azure 檔案共用的可行途徑，然後您可以選擇性地將 Azure 檔案同步新增至原始來源伺服器。

有許多不同的移轉路徑可供您使用，請務必遵循正確的路徑：

  • 您的資料位於 Windows Server 2012 R2 或更新版本，且您打算將 AFS 安裝到該伺服器，並同步原始位置。 在此情況下，您不想要上傳所有檔案，並改為使用資料箱，然後針對進行中的變更使用檔案同步。 如果這是您的情況，本文將說明您的移轉路徑。
  • 您的來源上有資料，您將不會或無法在其中安裝 AFS。 例如，NAS (網路連接儲存裝置) 或不同伺服器。 您將會建立新的空白伺服器，並在該伺服器上使用 Azure 檔案同步。 如果是您的情況，那麼這並不是適合您的移轉指南。 請參閱：透過資料箱從 NAS 遷移至 Azure 檔案同步，或在移轉概觀頁面上尋找適合您情況的指南。
  • 針對所有其他情況，請參閱 Azure 檔案共用移轉指南的資料表。 此概觀頁面提供適用於所有移轉案例的絕佳起點。

移轉概觀

移轉流程由幾個階段組成。 您需要：

  • 部署儲存體帳戶和檔案共用。
  • 部署一個或多個 Azure 資料箱裝置，用來從您的 Windows Server 2012 R2 或更新版本移動資料。
  • 對 Azure 檔案同步設定授權上傳。

下列各節將詳細說明移轉程序的各個階段。

提示

如果您要返回本文，請使用畫面右側的瀏覽來跳至您離開的移轉階段。

階段 1：判斷您需要多少 Azure 檔案共用

使用此移轉指南時，您必須繼續使用包含您檔案的內部部署直接連接儲存裝置 (DAS)。 資料箱將從該位置接收檔案，而 Azure 檔案同步也會在該位置上進行設定。 NAS (網路連接儲存裝置) 無法用於此遷移路徑。

您可以藉由設定 Azure 檔案同步的同步群組來決定同步的內容，每個群組都能決定一組檔案的同步位置。 每個同步群組都至少有一個伺服器位置，稱為「伺服器端點」，以及一個 Azure 檔案共用，稱為「雲端端點」。

您可以將一組檔案的子路徑同步至各自的 Azure 檔案共用。 這表示可設定數個同步群組來完全涵蓋一組檔案。 本節的其餘部分將描述您的選項。 如果您需要重建您的資料，您必須在第一個步驟中執行此作業，然後再繼續進行本指南之前，請先訂購資料箱或設定同步。

警告

在開始進行移轉之前，您的檔案和資料夾結構必須是您希望其長期維持的結構。 在移轉期間，請避免任何不必要的資料夾重建。 這會降低使用 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 中的指導，並同時考慮一次以一部檔案伺服器為目標。

建立對應表

Diagram that shows an example of a mapping table. Download the following file to experience and use the content of this image.

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

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


Excel icon that sets the context for the download. 下載命名空間對應範本。

階段 2：部署 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 檔案共用命名時，應使用其內部部署對應項目所使用的類似名稱。

階段 3：判斷您需要多少 Azure 資料箱設備

請先完成上一個階段之後，再開始執行此步驟。 您的 Azure 儲存體資源 (儲存體帳戶和檔案共用) 應該在此時建立。 當您訂購資料箱時，您必須指定資料箱移動資料的目的地儲存體帳戶。

在這個階段中，您需要將移轉計畫的結果從上一個階段對應至可用資料箱選項的限制。 這些考量將協助您規劃要選擇的資料箱選項，以及將 NAS 共用移至 Azure 檔案共用時所需的數目。

注意

不支援資料箱磁碟，因為其不會保留檔案的精確度。

若要判斷您需要多少裝置及其類型，請考慮下列重要限制：

  • 任何 Azure 資料箱設備都可以將資料移至最多 10 個儲存體帳戶。
  • 每個資料箱選項都有各自的可用容量。 請參閱資料箱選項。

若要了解您決定要建立的儲存體帳戶和每個帳戶中的共用數目，請參閱您的移轉計畫。 然後查看 NAS 上每個共用的大小。 結合這種資訊可讓您最佳化並決定哪個設備應該將資料傳送至哪些儲存體帳戶。 兩個資料箱裝置可將檔案移至相同的儲存體帳戶，但不會跨兩個資料箱分割單一檔案共用的內容。

資料箱選項

若為標準移轉，請選擇下列其中一個資料箱選項或選項組合：

  • 資料箱。 此選項是最常見的選項。 Microsoft 會將作用類似 NAS 的耐用資料箱設備傳送給您， 其可用容量為 80 TiB。 如需詳細資訊，請參閱資料箱文件。
  • Data Box Heavy。 此選項的主打的功能是作用類似 NAS 的移動式耐用資料箱設備。 其容量為 1 PiB。 因為加密和檔案系統的額外負荷，可用容量約在 20% 以下。 如需詳細資訊，請參閱 Data Box Heavy 文件。

注意

資料箱和 Data Box Heavy 僅支援透過 SMB 複製資料。 不支援透過資料複製服務來複製資料，因為其無法保留檔案的精確度。

階段 4：將檔案複製到您的資料箱

資料箱送達時，您必須進行設定，以對 NAS 設備進行暢通無阻的網路連線。 針對您所訂購的資料箱類型，遵循安裝文件：

視資料箱的類型而定，可能會有資料箱複製工具可用。 此時，我們不建議使用這些工具將檔案移轉至 Azure 檔案共用，因為它們無法將檔案完全精確地複製到資料箱。 請改用 Robocopy。

當您的資料箱抵達時，您在訂購時所指定的每一個儲存體帳戶都會有預先佈建的 SMB 共用可供使用。

  • 如果您的檔案進入進階 Azure 檔案共用，每個進階「檔案儲存體」的儲存體帳戶將會有一個 SMB 共用。
  • 如果您的檔案進入標準儲存體帳戶，每個標準 (GPv1 和 GPv2) 儲存體帳戶將會有三個 SMB 共用。 只有結尾為 _AzFiles 的檔案共用與您的移轉相關。 請忽略任何區塊和分頁 Blob 共用。

依照 Azure 資料箱文件中的步驟進行：

  1. 連線至資料箱。
  2. 將資料複製到資料箱。
  3. 準備資料箱以上傳至 Azure。

連結的資料箱文件會指定 Robocopy 命令。 該命令不適合用來保留完整檔案和資料夾的精確度。 請改為使用此命令：

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

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

繼續進行本指南之前，請先等候所有檔案都已抵達正確的 Azure 檔案共用。 傳送和擷取資料箱資料的程序需要一些時間才能完成。

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

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

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

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

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

階段 7：在 Windows Server 執行個體上設定 Azure 檔案同步

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

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

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

An Azure portal section of the create server endpoint wizard is shown. A checkbox is highlighted that corresponds to the scenario of seeding the Azure file share with data. Check this box if you connect AFS to the same on-prem location from where you copied onto Data Box before.

進入建立伺服器端點精靈後，請利用資料夾路徑底下提供的核取方塊。 只有當您所輸入路徑指向的檔案和資料夾結構與 Azure 檔案共用 (資料箱針對此命名空間移入檔案和資料夾的位置) 的結構相同時，才會使用此選項。

如果資料夾階層不相符，則會將本身呈現為無法自動解決的差異。 請避免出現不相符的情況，否則任何在資料箱程序中所做的投資皆無益於您。 所有資料都會在 Azure 檔案共用中刪除。 所有資料都必須從本機伺服器上傳。 目錄結構必須符合，才能充分利用 Azure 資料箱的大量移轉，並能夠以伺服器的最新變更無縫更新雲端共用。

注意

啟用此核取方塊會將 [初始同步] 模式設定為 [使用此伺服器路徑中的內容權威性地覆寫 Azure 檔案共用中的檔案和資料夾]。此選項僅適用於同步群組中的第一個伺服器端點。

設定此新伺服器端點的授權上傳之後，您可以選擇啟用雲端階層處理。

雲端階層處理是 Azure 檔案同步功能，可讓本機伺服器的儲存容量比雲端的儲存容量少，卻可使用完整的命名空間。 本機上受關注的資料也會在本機快取，以實現快速存取效能。 雲端階層處理是選用功能。 您可以針對每個 Azure 檔案同步伺服器端點個別設定此功能。 您可以使用這項功能來達成內部部署的固定儲存空間，但仍會提供使用者本機效能快取，並在雲端中儲存較少存取的資料。

若要深入了解，請查看雲端階層處理概觀，或仔細查看您可用來微調本機伺服器上快取/分層內容的不同雲端階層處理原則。

完成您的移轉

建立伺服器端點後，同步處理即會作用。 但是，同步處理需要列舉 (探索) 您透過 Azure 資料箱移至 Azure 檔案共用的檔案和資料夾。 根據命名空間的大小，可能需要很長的時間才能在雲端上同步最新的伺服器變更。 您的使用者不會受到影響，而且可以繼續使用伺服器上的資料。 此策略可實現零停機的雲端移轉。

針對您需要設定同步處理的所有 Azure 檔案共用/伺服器位置，重複上述步驟以建立同步群組，並將相符的伺服器資料夾新增為伺服器端點。 您已使用 Azure 資料箱將檔案移至多個 Azure 檔案共用。 當您建立可將內部部署資料連線到這些 Azure 檔案共用的所有伺服器端點之後，您的移轉便已完成。

下一步

還有更多關於 Azure 檔案共用和 Azure 檔案同步的資訊。下列文章將協助您了解進階選項和最佳做法。 還可協助您進行疑難排解。 這些文章會在適當時提供連至 Azure 檔案共用文件的連結。