共用方式為

將 StorSimple 8100 和 8600 移轉至 Azure 檔案同步

  • 發行項

StorSimple 8000 系列包含 8100 或 8600 實體、內部部署設備及其雲端服務元件。 本移轉指南也涵蓋 StorSimple 8010 和 8020 虛擬裝置。 您可以使用選用的 Azure 檔案同步，將資料從其中一個設備移轉至 Azure 檔案共用。Azure 檔案同步是取代 StorSimple 內部部署功能的預設和策略性長期 Azure 服務。 本文提供成功移轉至 Azure 檔案同步所需的背景知識和移轉步驟。

注意

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

移轉概觀 - 按一下即可播放！

這段影片提供下列概觀：

  • Azure 檔案
  • Azure 檔案同步
  • StorSimple 和 Azure 檔案儲存體的比較
  • StorSimple 資料管理員移轉工具和程式概觀

第 1 階段：為移轉做準備

本節包含從 StorSimple 磁碟區移轉至 Azure 檔案共用時，您應採取的步驟。

準備移轉 - 按一下即可播放！

這段影片涵蓋：

  • 選取儲存層
  • 選取儲存體備援選項
  • 選取 direct-share-access 與Azure 檔案同步
  • StorSimple 服務資料加密金鑰和序號
  • StorSimple 磁碟區備份移轉
  • 將 StorSimple 磁碟區和共用對應至 Azure 檔案共用
  • 將 Azure 檔案共用內的共用分組
  • 對應考量事項
  • 移轉規劃工作表
  • 命名空間對應試算表

存貨

當您開始規劃移轉時，請先找出需要移轉的所有 StorSimple 設備和磁碟區。 之後，您可以決定最佳移轉路徑。

  • StorSimple 實體設備 (8000 系列) 使用此移轉指南。
  • StorSimple 虛擬設備 (1200 系列) 使用不同的移轉指南。

移轉成本摘要

在 StorSimple 資料管理員資源中，透過移轉作業從 StorSimple 磁碟區移轉至 Azure 檔案共用無須費用。 在移轉期間和之後可能會產生其他成本：

  • 網路輸出：您的 StorSimple 檔案會存放在特定 Azure 區域內的儲存體帳戶中。 如果您佈建 Azure 檔案共用，並將其移轉至相同 Azure 區域中的儲存體帳戶，則不會產生輸出成本。 不過，如果您在此移轉的過程中將檔案移至不同區域中的儲存體帳戶，則會產生輸出成本。
  • Azure 檔案共用交易：將檔案複製到 Azure 檔案共用之外時 (在移轉中或其他情況下)，將會因寫入檔案和中繼資料而產生交易成本。 最佳做法是在移轉期間，於交易最佳化層上啟動 Azure 檔案共用。 完成移轉後，再切換到您想要的分層。 本文所述的階段會在適當的時機加以說明。
  • 變更 Azure 檔案共用層：變更 Azure 檔案共用成本交易的分層。 在大部分的情況下，遵循上一點的建議會更符合成本效益。
  • 儲存體成本：當此移轉開始將檔案複製到 Azure 檔案共用時，將會耗用儲存體並計費。 移轉後的備份會成為 Azure 檔案共用快照集。 檔案共用快照集耗用的儲存體容量僅限於其中包含的差異。
  • StorSimple：在您取消佈建 StorSimple 裝置和儲存體帳戶之前，將會繼續產生儲存體、備份和設備的 StorSimple 成本。

Direct-share-access 與Azure 檔案同步

Azure 檔案共用可開拓將檔案服務部署結構化的新商機。 Azure 檔案共用是雲端中的 SMB 共用，經設定可讓使用者使用熟悉的 Kerberos 驗證和以原生方式運作的現有 NTFS 權限 (檔案和資料夾 ACL)，直接透過 SMB 通訊協定進行存取。 深入了解 Azure 檔案共用的身分識別型存取。

直接存取的替代方法是 Azure 檔案同步。Azure 檔案同步是 StorSimple 快取內部部署常用檔案的直接類比能力。

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

  • 檔案同步處理和雲端階層處理，可在任何 Windows 伺服器上建立效能存取快取。
  • 檔案共用作為 Azure 中的原生儲存體，可透過多種通訊協定來存取，例如 SMB 和檔案 REST。

Azure 檔案共用會保留重要的檔案精確度層面，例如屬性、權限和時間戳記。 有了 Azure 檔案共用，應用程式或服務就不再需要解譯儲存在雲端中的檔案和資料夾。 您可以透過熟悉的通訊協定和用戶端直接存取這些資料。 Azure 檔案共用可讓您將一般用途的檔案伺服器資料和應用程式資料儲存在雲端中。

本文著重於移轉步驟。 如果您想要在移轉之前深入了解 Azure 檔案同步，請參閱下列文章：

StorSimple 服務資料加密金鑰

當您第一次設定 StorSimple 設備時，設備產生了服務資料加密金鑰，並指示您安全地儲存金鑰。 此金鑰會用來加密相關 Azure 儲存體帳戶中的所有資料，StorSimple 設備會將您的檔案儲存於此。

服務資料加密金鑰是成功移轉的要件。 請從您的記錄中擷取此金鑰，詳細目錄中的每個設備都各有一個。

如果您在記錄中找不到金鑰，可以從設備產生新的金鑰。 每個設備都有唯一的加密金鑰。

變更服務資料加密金鑰

服務資料加密金鑰用來加密從 StorSimple Manager 服務傳送至 StorSimple 裝置的機密客戶資料，例如儲存體帳戶認證。 如果您的 IT 組織在存放裝置上有金鑰輪替原則，則您必須定期變更這些金鑰。 根據 StorSimple Manager 服務是管理單一裝置或多個裝置而定，金鑰變更程序可能稍有不同。 如需詳細資訊，請移至 StorSimple 安全性和資料保護。

變更服務資料加密金鑰分成 3 個步驟：

  1. 使用 Azure Resource Manager 的 Windows PowerShell 指令碼，授權裝置以變更服務資料加密金鑰。
  2. 使用 Windows PowerShell for StorSimple，起始服務資料加密金鑰變更。
  3. 如果您有一個以上的 StorSimple 裝置，請在其他裝置上更新服務資料加密金鑰。

步驟 1：使用 Windows PowerShell 指令碼，授權裝置以變更服務資料加密金鑰

一般而言，裝置系統管理員將會要求服務管理員授權裝置，以變更服務資料加密金鑰。 然後服務管理員就會授權裝置來變更金鑰。

使用以 Azure Resource Manager 為基礎的指令碼來執行此步驟。 服務管理員可以選擇具備授權資格的裝置。 然後裝置就會獲得授權，以啟動服務資料加密金鑰變更程序。

如需有關使用指令碼的詳細資訊，請移至 Authorize-ServiceEncryptionRollover.ps1

哪些裝置可獲得授權以變更服務資料加密金鑰？

裝置必須符合下列準則，才能獲得授權以起始服務資料加密金鑰變更：

  • 裝置必須在線上，才能獲得授權以變更服務資料加密金鑰。
  • 如果尚未起始金鑰變更，您可以在 30 分鐘後再次授權同一個裝置。
  • 如果先前獲得授權的裝置尚未起始金鑰變更，則您可以授權另一個裝置。 新裝置已獲授權之後，舊裝置就無法起始變更。
  • 正在變換服務資料加密金鑰時，無法授權裝置。
  • 如果有些已向服務註冊的裝置已變換加密，而某些裝置還沒有，則您可以授權裝置。

步驟 2：使用 Windows PowerShell for StorSimple 起始服務資料加密金鑰變更

這個步驟是在 Windows PowerShell for StorSimple 介面中，對已獲授權的 StorSimple 裝置執行。

注意

除非金鑰變換完成，否則無法在 Azure 入口網站對 StorSimple Manager 服務執行任何作業。

如果您使用裝置序列主控台連接到 Windows PowerShell 介面，請執行下列步驟。

起始服務資料加密金鑰變更

  1. 選取選項 1 以使用完整存取權登入。

  2. 在命令提示字元中，輸入：

    Invoke-HcsmServiceDataEncryptionKeyChange

  3. Cmdlet 順利完成之後，您就會得到新的服務資料加密金鑰。 複製並儲存此金鑰，以供此程序的步驟 3 使用。 此金鑰將用來更新已向 StorSimple Manager 服務註冊的其餘所有裝置。

    注意

    此程序必須在授權 StorSimple 裝置後的四個小時內起始。

    然後，新金鑰就會傳送至服務並推播至所有已向服務註冊的裝置。 之後，服務儀表板上將出現警示。 此服務會停用已註冊的裝置上的所有作業，然後裝置管理員就必須在其他裝置上更新服務資料加密金鑰。 不過，不會中斷 I/O (將資料傳送至雲端的主機)。

    如果只有一個裝置向您的服務註冊，則變換程序現在已完成，您可以略過下一個步驟。 如果有多個裝置向您的服務註冊，請繼續步驟 3。

步驟 3：在其他 StorSimple 裝置上更新服務資料加密金鑰

如果有多個裝置向您的 StorSimple Manager 服務註冊，您就必須在 StorSimple 裝置的 Windows PowerShell 介面中執行這些步驟。 您在步驟 2 取得的金鑰必須用於更新所有註冊 StorSimple Manager 服務的其他 StorSimple 裝置。

請執行下列步驟，在您的裝置上更新服務資料加密。

若要在實體裝置上更新服務資料加密金鑰

  1. 使用 Windows PowerShell for StorSimple 連線到主控台。 選取選項 1 以使用完整存取權登入。
  2. 在命令提示字元中，輸入：Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey
  3. 提供您在 步驟 2：使用 Windows PowerShell for StorSimple 起始服務資料加密金鑰變更中取得的服務資料加密金鑰。

若要更新所有 8010/8020 雲端設備上的服務資料加密金鑰

  1. 下載並安裝 Update-CloudApplianceServiceEncryptionKey.ps1 PowerShell 指令碼。
  2. 開啟 PowerShell，並在命令提示字元中，輸入：Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

此指令碼將確保服務資料加密金鑰已在裝置管理員下的所有 8010/8020 雲端設備上設定。

警告

在決定如何連線到 StorSimple 設備時，請考慮下列事項：

  • 透過 HTTPS 工作階段連線是最安全的建議選項。
  • 直接連線至裝置序列主控台是安全的，但透過網路交換器連線至序列主控台則否。
  • HTTP 工作階段連線是選項之一，但未經加密。 除非是已關閉、受信任的網路中，否則不建議使用此類連線。

已知的限制

在開始移轉之前，請先了解 StorSimple 資料管理員和 Azure 檔案共用的一些限制，因為移轉可能因此受到阻礙：

  • 僅支援來自 StorSimple 設備的 NTFS 磁碟區。 不支援 ReFS 磁碟區。
  • 不支援放置於 Windows Server 動態磁碟上的任何磁碟區。
  • 服務無法使用 BitLocker 加密或已啟用重復資料刪除的磁碟區。
  • 無法移轉損毀的 StorSimple 備份。
  • 特殊的網路功能選項 (例如防火牆或私人端點專用通訊) 無法在儲存 StorSimple 備份的來源儲存體帳戶上啟用，也無法在您保存 Azure 檔案共用的目標儲存體帳戶上啟用。

檔案精確度

如果沒有已知限制中的限制會阻礙移轉，Azure 檔案共用中可儲存的項目仍有所限制。

檔案精確度指的是組成檔案的許多屬性、時間戳記和資料。 在移轉中，檔案精確度是一種量值，代表來源 (StorSimple 磁碟區) 的資訊可轉譯 (移轉) 至目標 Azure 檔案共用的程度。

Azure 檔案儲存體支援NTFS 檔案屬性的子集。 Windows ACL、通用中繼資料和某些時間戳記將會移轉。

下列項目不會阻止移轉，但會在移轉期間造成個別項目的問題：

  • 時間戳記：不會設定檔案變更時間。 目前這是透過 REST 通訊協定的唯讀項目。 檔案的上次存取時間戳記不會移動，因為這在儲存於 Azure 檔案共用中的檔案上不受支援。
  • 替代的資料流程無法儲存在 Azure 檔案共用中。 將會複製含有替代資料流的檔案，但在過程中會從檔案中去除替代資料流。
  • 在移轉期間會略過符號連結、永久連結、接合和重新分析點。 移轉複製記錄會列出每個略過的項目和原因。
  • EFS 加密的檔案無法複製。 複製記錄會顯示「拒絕存取」，表示項目複製失敗。
  • 損毀的檔案會略過。 針對 StorSimple 磁碟上損毀的每個項目，複製記錄可能列出不同的錯誤：「要求失敗，因為發生嚴重的裝置硬體錯誤」、「檔案或目錄損毀或無法讀取」或「存取控制清單 (ACL) 結構無效」。
  • 略過超過 4 TiB 的個別檔案。
  • 檔案路徑長度必須等於或少於 2048 個字元。 路徑較長的檔案和資料夾會被略過。
  • 略過重新剖析點。 任何來自 Microsoft 或第三方的重複資料刪除/SIS 重新剖析點皆無法由移轉引擎解析，且會使受影響的檔案和資料夾無法移轉。

本文結尾的疑難排解一節具有項目層級和移轉作業層級錯誤碼的詳細資料，以及其因應措施的可能選項。

StorSimple 磁碟區備份

StorSimple 會在磁碟區層級上提供差異備份。 Azure 檔案共用也有這種功能，稱為共用快照集。

您的移轉作業只能移動備份，而非來自即時磁碟區的資料。 因此，最新的備份最接近即時資料，因此應該一律包含在移轉的移動備份清單中。

決定您是否需要在移轉期間移動任何較舊的備份。 最佳做法是盡可能縮減這份清單，讓您的移轉作業更快完成。

若要識別必須移轉的重要備份，請建立備份原則的檢查清單。 例如：

  • 最近的備份。
  • 12 個月每月備份一次。
  • 3 年每年備份一次。

在建立移轉作業時，您可以使用此清單來識別必須移轉的確切 StorSimple 磁碟區備份，以滿足您的需求。

最好先暫停所有 StorSimple 備份保留原則，再選取要移轉的備份。 移轉備份可能需要數天或數週的時間。 StorSimple 提供了刪除備份的備份保留原則。 您為此移轉選取的備份可能在有機會移轉之前即遭到刪除。

警告

不支援選取超過 50 個 StorSimple 磁碟區備份。

將您現有的 StorSimple 磁碟區對應至 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 圖示。 下載命名空間對應範本。

儲存體帳戶數目

部署多個儲存體帳戶可能有益於移轉，因為每個帳戶存放的 Azure 檔案共用數量較少。

如果檔案共用的使用率很高 (有許多使用者或應用程式使用)，則兩個 Azure 檔案共用可能會達到儲存體帳戶的效能限制。 因此，一般最好是移轉至多個儲存體帳戶，每個帳戶都有各自獨立的檔案共用，而且每個儲存體帳戶通常不超過二或三個共用。 最佳做法是部署各有一個檔案共用的儲存體帳戶。 如果您在儲存體帳戶中有封存共用，則可以將多個 Azure 檔案共用集中放在相同的儲存體帳戶中。

這些考量事項適用於直接雲端存取 (透過 Azure VM 或服務)，而不是 Azure 檔案同步。如果您打算在這些共用上專門使用 Azure 檔案同步，則可以將數個分組成單一 Azure 儲存體帳戶。 未來，您可能會想要將應用程式隨即轉移至雲端，以便直接存取檔案共用，因為在此情況下，有較高的 IOPS 和輸送量會更有利。 或者，您也可以開始使用 Azure 中的服務，更高的 IOPS 和輸送量也有益於此服務。

建立共用清單後，請將每個共用對應至其所在的儲存體帳戶。 決定 Azure 區域，並確定每個儲存體帳戶和 Azure 檔案同步資源都符合您所選取的區域。

重要

請勿立即設定儲存體帳戶的網路和防火牆設定。 此時進行這些設定會導致無法進行移轉。 完成移轉之後，請設定這些 Azure 儲存體設定。

儲存體帳戶設定

您可以在儲存體帳戶上進行許多設定。 請使用下列檢查清單來確認您的儲存體帳戶設定。 您可以在移轉完成後變更網路設定。

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

第 1 階段摘要

在第 1 階段結束時：

  • 您會擁有 StorSimple 裝置和磁碟區的良好概觀。
  • 資料管理員服務已準備好存取雲端中的 StorSimple 磁碟區，因為您已為每個 StorSimple 裝置擷取了服務資料加密金鑰。
  • 您已規劃好需要移轉的磁碟區和備份 (若有超過最近的備份)。
  • 您知道如何將磁碟區對應至適當數目的 Azure 檔案共用和儲存體帳戶。

第 2 階段：部署 Azure 儲存體和移轉資源

本節討論有關部署 Azure 中所需的不同資源類型考量事項。 有些資源會在移轉後保存您的資料，有些則只用於移轉。 在您完成部署計劃之前，請勿開始部署資源。 特定 Azure 資源在部署之後，可能會難以甚至無法變更其特定層面。

部署必要的資源 - 按一下即可播放！

這段影片涵蓋下列項目的部署：

  • 儲存體帳戶
  • 訂用帳戶和資源群組
  • 儲存體帳戶
  • 類型與名稱
  • 效能和共用大小
  • 位置和復寫類型
  • Azure 檔案共用
  • StorSimple 資料管理員服務

部署儲存體帳戶

您可能需要部署數個 Azure 儲存體帳戶。 根據您的部署計劃，每個帳戶將存放數量較少的 Azure 檔案共用。 移至 Azure 入口網站以部署您規劃的儲存體帳戶。 針對任何新的儲存體帳戶，請考慮遵循下列基本設定。

重要

在移轉之前或執行期間，請勿為您的儲存體帳戶設定網路和防火牆設定。 此時進行這些設定會導致無法進行移轉。 公用端點必須可供來源和目標儲存體帳戶存取。 不支援限制於特定 IP 範圍或虛擬網路。 您可以在移轉完成後變更儲存體帳戶網路設定。

訂用帳戶

您可以使用 StorSimple 部署所使用的相同訂用帳戶，也可以使用不同的訂用帳戶。 唯一的限制是您的訂用帳戶必須與 StorSimple 訂用帳戶位於相同的 Microsoft Entra 租用戶中。 開始進行移轉之前，請考慮將 StorSimple 訂用帳戶移至適當的租用戶。 您只能移動整個訂用帳戶，因為個別的 StorSimple 資源無法移至不同的租用戶或訂用帳戶。

資源群組

Azure 中的資源群組有助於組織資源和管理員管理權限。 深入了解。

儲存體帳戶名稱

您的儲存體帳戶名稱將會成為用來存取檔案共用之 URL 的一部分，並具有某些字元限制。 在您的命名慣例中，請考慮為儲存體帳戶指定在世界上獨一無二的名稱，只允許小寫字母和數字，且必須介於 3 到 24 個字元之間，不允許使用連字號或底線等特殊字元。 請參閱 Azure 儲存體資源命名規則。

Location

儲存體帳戶的 Azure 區域是很重要的。 如果您使用 Azure 檔案同步，則所有的儲存體帳戶都必須位於與儲存體同步服務資源相同的區域中。 您挑選的 Azure 區域應接近或集中於您的本機伺服器和使用者。 您部署資源後，就無法變更其區域。

您可以挑選與 StorSimple 資料 (儲存體帳戶) 目前所在之處不同的區域，但若您這麼做，在移轉期間就會產生輸出費用。 資料會離開 StorSimple 區域，並輸入新的儲存體帳戶區域。 如果您將資料留在相同的 Azure 區域中，則不會收取任何頻寬費用。

效能

您可以為 Azure 檔案共用或標準儲存體選擇進階儲存體 (SSD)。 標準儲存體包含數個適用於檔案共用的層級。 對從 StorSimple 移轉的大部分客戶而言，標準儲存體是最適合的選擇。

  • 如果您需要進階 Azure 檔案共用的效能，請選擇進階儲存體。
  • 針對一般用途的檔案伺服器工作負載 (包括經常性存取資料和封存資料)，請選擇標準儲存體。 如果雲端中共用上的唯一工作負載只有 Azure 檔案同步，也請選擇標準儲存體。
  • 針對進階檔案共用，請在建立儲存體帳戶精靈中選擇 [檔案共用]。

複寫

複寫設定有數個選項。 請從下列兩個選項擇一：

  • 本地備援儲存體 (LRS)。
  • 區域備援儲存體 (ZRS)，無法在所有 Azure 區域中使用。

注意

不支援異地備援儲存體 (GRS) 和異地區域備援儲存體。

Azure 檔案共用

建立儲存體帳戶後，請移至儲存體帳戶的 [檔案共用] 區段，並根據您在第 1 階段的移轉計劃，部署適當數量的 Azure 檔案共用。 針對 Azure 中的新檔案共用，請考慮遵循下列基本設定。

顯示新的檔案共用 UI 的 Azure 入口網站螢幕擷取畫面。


名稱
支援小寫字母、數字及連字號。

配額
此處的配額相當於 Windows Server 執行個體上的 SMB 固定配額。 最佳做法是不要在此設定配額，因為達到配額上限時，您的移轉和其他服務將會失敗。

層級
為您的新檔案共用選取 [交易最佳化]。 在移轉期間將會發生許多交易， 待移轉完成後再變更為最適合您工作負載的層級，將會更符合成本效益。

StorSimple 資料管理員

保存移轉作業的 Azure 資源稱為 StorSimple 資料管理員。 選取 [新增資源]，並搜尋此名稱。 然後選取建立。

此暫存資源會用於協調流程。 您會在移轉完成後將其取消佈建。 請務必將其部署在與 StorSimple 儲存體帳戶相同的訂用帳戶、資源群組和區域中。

Azure 檔案同步

透過 Azure 檔案同步，您可以新增最常存取檔案的內部部署快取。 與 StorSimple 的快取功能類似，Azure 檔案同步雲端階層處理功能提供本機存取延遲，同時改善對 Windows Server 執行個體上可用快取容量和多站台同步的控制能力。如果內部部署快取是您的目標，請在區域網路中準備 Windows Server VM (也支援實體伺服器和容錯移轉叢集)，並具有足夠的直接連結儲存體容量。

重要

先不要設定 Azure 檔案同步。 在移轉的第 4 階段之前，不應開始部署 Azure 檔案同步。

第 2 階段摘要

在第 2 階段結束時，您已部署儲存體帳戶和所有 Azure 檔案共用。 您還會擁有 StorSimple 資料管理員資源。 在設定移轉作業時，您將會在第 3 階段使用此資源。

第 3 階段：建立和執行移轉作業

本節說明如何設定移轉作業，並對應 StorSimple 磁碟區上的目錄，該磁碟區應複製到您選取的目標 Azure 檔案共用。

建立並執行移轉作業 - 按一下即可播放！

這段影片涵蓋：

  • 建立移轉作業
  • 摘要
  • 來源
  • 選取要移轉的磁碟區備份
  • Target
  • 目錄對應
  • 語意規則
  • 執行移轉作業
  • 執行作業定義
  • 檢視作業的狀態
  • 平行執行作業
  • 解譯記錄檔

第一步，請移至您的 StorSimple 資料管理員，尋找功能表上的 [工作定義]，然後選取 [+ 作業定義]。 正確的目標儲存體類型是預設值：Azure 檔案共用。

StorSimple 8000 系列移轉作業類型。

此螢幕擷取畫面顯示移轉作業新的作業建立表單。

作業定義名稱
這個名稱應該指出您要移動的檔案集合。 建議您為其指定類似於 Azure 檔案共用的名稱。

作業執行位置
選取區域時，您必須選取與 StorSimple 儲存體帳戶相同的區域，如果該區域無法使用，則應選擇相近的區域。

來源

來源訂用帳戶
選取要用來儲存 StorSimple 裝置管理員資源的訂用帳戶。

StorSimple 資源
選取註冊您設備的 StorSimple 裝置管理員。

服務資料加密金鑰
如果您在記錄中找不到金鑰，請參閱本文中的先前章節。

裝置
選取保存您要移轉磁碟區的 StorSimple 裝置。

磁碟區
選取來源磁碟區。 稍後，您將決定要將整個磁碟區或子目錄移轉至目標 Azure 檔案共用。

磁碟區備份
您可以選取 [選取磁碟區備份]，選擇您要在此作業中移動的特定備份。 本文後續會有專門章節詳細說明此程序。

Target

選取訂用帳戶、儲存體帳戶和 Azure 檔案共用作為此移轉作業的目標。

目錄對應

本文中的專用章節，討論所有相關的詳細資料。

選取要移轉的磁碟區備份

選擇需要移轉的備份有很重要的層面：

  • 您的移轉作業只能移動備份，而不是即時磁碟區的資料。 因此最新的備份最接近即時資料，而且應一律包含在移轉時的移動備份清單中。 當您開啟備份選取對話方塊時，依預設會選取此項目。
  • 請確定最新的備份為最新版本，以盡可能減少與即時共用之間的差異。 在建立移轉作業之前，可考慮手動觸發並完成另一次磁碟區備份。 即時共用的微小差異可改善您的移轉體驗。 如果此差異為零，表示您在清單中建立最新的備份之後，StorSimple 磁碟區就沒有有任何變更，使用者的完全移轉將可大幅簡化並加速完成。
  • 備份必須以從最舊到最新的順序移動至 Azure 檔案共用。 執行移轉作業之後，就無法在 Azure 檔案共用上將較舊的備份「排序至」備份清單中。 因此，在建立作業之前，您必須確定備份清單已完成。
  • 作業建立後，就無法修改此作業中的備份清單，即使作業未曾執行過也一樣。
  • 若要選取備份，您想要移轉的 StorSimple 磁碟區必須在線上。

新作業建立表單的螢幕擷取畫面，其中詳述選取了 StorSimple 備份以進行移轉的部分。

若要為您的移轉作業選取 StorSimple 磁碟區的備份，請選取作業建立表單上的 [選取磁碟區備份]。

此影像顯示選取備份的刀鋒視窗上半部列出了所有可用的備份。已選取的備份在此清單中會呈現灰色，並新增至刀鋒視窗下半部的第二個清單。您也可以在該處再次將其刪除。

備份選取刀鋒視窗開啟時，會分成兩個清單。 在第一個清單中會顯示所有可用的備份。 您可以篩選特定時間範圍，藉以擴大和縮小結果集。 (請參閱下一節)

已選取的備份會顯示為灰色，並新增至刀鋒視窗下半部的第二個清單。 第二個清單會顯示已選取要移轉的所有備份。 錯誤選取的備份也可以再次移除。

警告

您必須選取需要移轉的所有備份。 後續您將無法新增舊的備份。 一旦建立作業之後，您就無法修改作業以變更選取項目。

此螢幕擷取畫面顯示備份選取刀鋒視窗的時間範圍選取情形。

根據預設，清單會經過篩選，以顯示過去七天內的 StorSimple 磁碟區備份。 預設會選取最新的備份，即使過去七天內未發生備份也一樣。 針對較舊的備份，請使用刀鋒視窗頂端的時間範圍篩選器。 您可以根據現有的篩選選取，或設定自訂的時間範圍，僅篩選在這段期間所進行的備份。

警告

不支援選取超過 50 個 StorSimple 磁碟區備份。 具有大量備份的工作可能會失敗。 在有機會移轉選取的備份之前，請確定您的備份保留原則不會刪除選取的備份！

目錄對應

目錄對應不是移轉作業的必要項目。 如果您將區段保留空白，StorSimple 磁碟區根目錄上的所有檔案和資料夾，都會移至目標 Azure 檔案共用的根目錄。 在大多數情況下，將整個磁碟區的內容儲存在 Azure 檔案共用中並不是最佳的方法。 通常建議將磁碟區的內容分割成 Azure 中的多個檔案共用。 如果您尚未建立方案，請先參閱 將您的 StorSimple 磁碟區對應至 Azure 檔案共用。

在您的移轉計畫中，您可能已決定 StorSimple 磁碟區上的資料夾必須分割至多個 Azure 檔案共用。 如果是這種情況，您可以透過下列方式來完成分割：

  1. 定義多個作業，以移轉一個磁碟區上的資料夾。 每個作業都有相同的 StorSimple 磁碟區來源，但以不同的 Azure 檔案共用作為目標。
  2. 使用工作建立表單的 [目錄對應] 區段，並遵循特定的對應語意，精確地指定要將 StorSimple 磁碟區中的哪些資料夾移轉到指定的檔案共用。

重要

提交表單時，無法驗證此表單中的路徑和對應運算式。 如果指定的對應不正確，則工作可能會完全失敗，或產生非預期的結果。 在這種情況下，通常最好是刪除 Azure 檔案共用、重新建立，然後修正共用新移轉作業中的對應陳述式。 使用固定的對應陳述式來執行新作業，可以修正省略的資料夾，並將帶入現有的共用中。 不過，只有因為路徑拼寫錯誤而省略的資料夾可以透過這種方式定址。

語意元素

對應是由左至右表示：[\來源路徑] > [\目標路徑]。

語意字元 意義
\ 根層級指標。
> [Source] 和 [target-mapping] 運算子。
| 或 RETURN (新行) 兩個資料夾對應指令的分隔符號。
或者，您可以省略此字元並選取 [輸入]，以在其本身的行上取得下一個對應運算式。

範例

將資料夾 User data 的內容移至目標檔案共用的根目錄：

\User data > \

將整個磁碟區內容移至目標檔案共用上的新路徑：

\ > \Apps\HR tracker

將來源資料夾內容移至目標檔案共用上的新路徑：

\HR resumes-Backup > \Backups\HR\resumes

將多個來源位置排序為新的目錄結構：

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

語意規則

  • 一律指定相對於根層級的資料夾路徑。
  • 使用根層級指標 "\" 作為每個資料夾路徑的開頭。
  • 請勿包含磁碟機代號。
  • 指定多個路徑時，來源或目標路徑不能重疊：
    無效來源路徑重疊範例：
    \folder\1 > \folder
    \folder\1\2 > \folder2
    無效目標路徑重疊範例：
    \folder > \
    \folder2 > \
  • 不存在的來源資料夾會被忽略。
  • 會建立不存在於目標上的資料夾結構。
  • 如同 Windows，資料夾名稱不區分大小寫，但仍會保留大小寫。

注意

移轉作業將不會複製 \System Volume Information 資料夾的內容和 StorSimple 磁碟區上的 $Recycle.Bin。

執行移轉作業

您的移轉作業會列在已部署至資源群組的「資料管理員」資源 [工作定義] 下。 從作業定義的清單中，選取您要執行的作業。

在開啟的 [作業] 刀鋒視窗中，您可以看到作業的目前狀態，以及所選取的備份清單。 備份清單會依最舊到最新排序，並依此順序移轉至 Azure 檔案共用。

移轉作業刀鋒視窗的螢幕擷取畫面，其中醒目提示了用來啟動作業的命令。此外也顯示為移轉排程的選定備份。

在一開始，移轉作業將會是 [從未執行] 狀態。
準備就緒後，即可開始移轉作業。 選取影像可查看解析度更高的版本。
備份成功移轉後，將會自動建立 Azure 檔案共用快照集。 StorSimple 備份的原始備份日期會放在 Azure 檔案共用快照集的 [註解] 區段中。 使用此欄位可讓您查看最初備份資料的時間，相較於拍攝檔案共用快照集的時間。

警告

備份的處理順序必須從最舊到最新。 建立移轉作業之後，您就無法變更所選 StorSimple 磁碟區備份的清單。 如果備份清單不正確或不完整，請勿啟動作業。 請刪除作業，並選取的正確備份來建立新的作業。 針對每個選取的備份，請檢查您的保留排程。 備份有可能在獲得移轉之前即遭到一或多個保留原則刪除！

個別項目錯誤

移轉作業在備份清單中有兩個資料行，列出複製期間可能發生的任何問題：

  • 複製錯誤
    此資料行列出應該複製，但未複製的檔案或資料夾。 這些錯誤通常可以復原。 當備份在此資料行中列出項目問題時，請檢查複製記錄。 如果您需要移轉這些檔案，請選取 [重試備份]。 備份完成處理後，這就會成為可用選項。 管理移轉作業章節會更詳細地說明您的選項。
  • 不支援的檔案
    此資料行會列出無法移轉的檔案或資料夾。 Azure 儲存體對於檔案名、路徑長度以及檔案類型有所限制，目前或邏輯上無法儲存在 Azure 檔案共用中。 移轉作業不會因這類錯誤而暫停。 重試備份的移轉不會變更結果。 當備份在此資料行中列出項目問題時，請檢查複製記錄並記下問題。 如果您是在最後一個備份發生這類問題，並且在複製記錄中發現失敗原因是檔案名稱、路徑長度或您造成影響的其他問題，您可以在即時 StorSImple 磁碟區中補救此問題、採用 StorSimple 磁碟區備份，然後僅使用該備份來建立新的移轉作業。 接著，您可以移轉這個已補救的命名空間，使其成為 Azure 檔案共用的最新/即時版本。 這是一項耗時的手動流程。 仔細檢查複製記錄，並評估是否值得進行這項流程。

這些複製記錄是 *.csv 檔案，其中列出了成功複製的命名空間項目，以及複製失敗的項目。 這些錯誤會進一步分割成先前討論過的類別。 從記錄檔位置中，您可以藉由搜尋 "failed" 來尋找失敗檔案的記錄。 結果應該是一組複製失敗的檔案記錄。 依大小排序這些記錄。 有可能會產生 17 個位元組大小的額外記錄。 這些記錄是空白的且可以忽略。 您可以使用排序，聚焦在具有內容的記錄。

相同的程序適用於記錄成功複製的記錄檔。

管理移轉作業

移轉作業具有下列狀態：

  • 從未執行
    已定義但從未執行過的新作業。
  • 等待中
    處於此狀態的作業正在等待資源佈建於移轉服務中。 當就緒時，工作就會自動切換成其他狀態。
  • 失敗
    失敗的作業遇到嚴重錯誤，因而無法處理更多備份。 預期作業不應進入此狀態。 最好的應對措施就是支援要求。
  • 取消 / 正在取消
    您可以取消和整個移轉作業或作業內的個別備份。 取消的備份將不會被處理，因為取消的移轉作業將會停止處理備份。 預期取消作業需要很長的時間。 這不會讓您無法建立新的作業。 最理想的做法是靜待作業完全進入 [已取消] 的狀態。 您可以略過失敗/已取消的作業，或稍後再將其刪除。 您不需要刪除作業，就可以在 StorSimple 移轉結束時刪除資料管理員資源。

移轉作業刀鋒視窗的螢幕擷取畫面，在頂端具有執行中狀態的大型狀態圖示。

執行中

執行中作業目前正在處理備份。 請參閱刀鋒視窗下半部的表格，以查看目前正在處理的備份以及可能已移轉的備份。
已移轉的備份會包含具有複製記錄連結的資料行。 如果備份報告了任何錯誤，您應檢閱其複製記錄檔。

移轉作業刀鋒視窗的螢幕擷取畫面，在頂端具有已暫停狀態的大型狀態圖示。

已暫停

需進行決策時，移轉作業將會暫停。 這種情況會啟用刀鋒視窗頂端的兩個命令按鈕：
當備份顯示檔案應移動但未移動時，請選擇 [重試備份] ([複製錯誤]資料行)。
當備份遺失時 (在您建立作業後遭到原則刪除) 或備份損毀時，請選擇 [跳過備份]。 當您按一下失敗的備份時，可在開啟的刀鋒視窗中找到詳細的錯誤資訊。

當您「跳過」或「重試」目前的備份時，移轉服務會在您的目標 Azure 檔案共用中建立新的快照集。 先前的版本可能不完整，您可以在稍後將其刪除。

顯示移轉作業刀鋒視窗的影像，在頂端具有完成狀態的大型狀態圖示。

完成和完成但出現警告

作業中的所有備份都成功處理時，移轉作業會列為 [完成]。
完成但出現警告狀態代表發生下列情況：

  • 備份遇到可復原的問題。 此備份會標示為「部分成功」或「失敗」。
  • 您已決定要繼續進行暫停的工作，略過具有所述問題的備份。 (您選擇 [略過備份]，而不是 [重試備份])
如果移轉作業完成但出現警告，您應該一律檢查相關備份的複製記錄。

同時執行作業

您可能會有多個 StorSimple 磁碟區，每個磁碟區都有本身的共用，必須移轉至 Azure 檔案共用。 請務必了解您可以同時處理的容量。 在使用者體驗中並沒有強制執行的限制，但如果同時執行工作，則會降低或禁止完整的移轉。

定義移轉作業沒有任何限制。 您可以在相同或不同的 StorSimple 設備上，定義相同的 StorSimple 來源磁碟區，也就是相同的 Azure 檔案共用。 不過，執行這些作業有一些限制：

  • 同時只能執行一個具有相同 StorSimple 來源磁碟區的移轉作業。
  • 具有相同目標 Azure 檔案共用的移轉作業可以同時執行。
  • 開始下一個作業之前，請確定先前的任何作業都處於 copy stage，並顯示移動檔案至少 30 分鐘的進度。
  • 只要遵守先前的規則，每個 StorSimple 裝置管理員最多可平行執行四個移轉作業。

當您嘗試啟動移轉工作時，系統會檢查先前的規則。 如果有執行中的作業，您可能無法啟動新的作業。 您將會收到一則警示，其中會列出目前執行中的作業名稱，必須等待這些作業完成，才能啟動新的作業。

提示

建議您在資料管理員資源的 [作業定義] 索引標籤中定期檢查您的移轉作業，確認是否有作業已暫停且需要您的介入才能完成。

第 3 階段摘要

在第 3 階段結束時，您將至少執行一個從 StorSimple 磁碟區到 Azure 檔案共用的移轉作業。 執行後，您會將指定的備份移轉至 Azure 檔案共用快照集。 在共用的移轉作業完成後，您現在可以專注於設定共用的 Azure 檔案同步，或將您的資訊工作者和應用程式直接共用存取權提供給 Azure 檔案共用。

第 4 階段：存取 Azure 檔案共用

有兩個主要策略可存取 Azure 檔案共用：

  • Azure 檔案同步：將 Azure 檔案同步部署到內部部署 Windows Server 執行個體。 Azure 檔案同步具有本機快取的所有優點，就像 StorSimple 一樣。
  • 直接共用存取：部署直接共用存取。 如果您所指定 Azure 檔案共用的存取案例無法受益於本機快取，或您無法再裝載內部部署 Windows Server 執行個體，請使用此策略。 採用此策略，您的使用者和應用程式將會繼續透過 SMB 通訊協定存取 SMB 共用。 這些共用已不再位於內部部署伺服器上，而是直接位在雲端中。

您應該已在本指南的第 1 階段決定哪一個選項最適合您。

本節的其餘部分將著重於部署指示。

Azure 檔案共用的存取選項 - 按一下即可播放！

這段影片涵蓋：

  • 存取 Azure 檔案共用的方法
  • Azure 檔案同步
  • Direct-share-access
  • 部署 Azure 檔案同步
  • 部署 Azure 檔案同步雲端資源
  • 部署內部部署 Windows Server 執行個體
  • 準備 Windows Server 執行個體以進行 Azure 檔案同步
  • 在 Windows Server 執行個體上設定 Azure 檔案同步
  • 監視初始同步
  • 測試 Azure 檔案同步
  • 建立 SMB 共用

部署 Azure 檔案同步

現在就可以部署一部分的 Azure 檔案同步。

  1. 建立 Azure 檔案同步雲端資源。
  2. 在您的內部部署伺服器上部署 Azure 檔案同步代理程式。
  3. 向雲端資源註冊伺服器。

請先不要建立任何同步處理群組。 您需要先完成 Azure 檔案共用的移轉作業，才能設定與 Azure 檔案共用的同步處理。 如果您在移轉完成前就開始使用 Azure 檔案同步，將會造成不必要的移轉困難，因為您會難以判斷起始完全移轉的時機。

部署 Azure 檔案同步雲端資源

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

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

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

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

提示

如果您想要在移轉完成後變更您資料所在的 Azure 區域，請在與目標儲存體帳戶相同的區域中部署儲存體同步處理服務，以進行此移轉。

部署內部部署 Windows Server 執行個體

  • 將 Windows Server 2019 (至少 2012R2) 建立為虛擬機器或實體伺服器。 此外也支援 Windows Server 容錯移轉叢集。 請勿重複使用伺服器做為 StorSimple 8100 或 8600 的前端。
  • 佈建或新增直接連結儲存體。 不支援網路連結儲存體。

最佳做法是針對新的 Windows 伺服器執行個體，提供等於或大於您 StorSimple 8100 或 8600 設備可在本機進行快取的儲存體數量。 您將使用與 StorSimple 設備相同的方式來使用 Windows Server 執行個體。 如果具有與設備相同的儲存體數量，即使有差異，應該也有類似的快取體驗。 您可以從 Windows 伺服器執行個體中新增或移除儲存體。 這項功能可讓您調整本機磁碟區大小，以及可供快取使用的本機儲存體數量。

準備 Windows Server 執行個體以進行檔案同步

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

在 Windows Server 執行個體上設定 Azure 檔案同步

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

重要

您的 StorSimple 必須先將檔案和資料夾移轉至 Azure 檔案共用，才能繼續進行。 請確定檔案共用未經過任何變更。

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

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

重要

請務必開啟雲端階層處理。 雲端階層處理是 Azure 檔案同步功能，可讓本機伺服器的儲存容量比雲端的儲存容量少，卻有完整的命名空間可使用。 本機上有用的資料也會在本機快取，以實現快速效能。 在此步驟開啟雲端階層處理的另一個原因是，我們不想要在此階段同步檔案內容。 此時應僅移動命名空間。

部署直接共用存取

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

第 4 階段摘要

在這個階段結束時，您已在 StorSimple 資料管理員中建立並執行多個移轉作業。 這些作業已將您的檔案和資料夾及其備份移轉至 Azure 檔案共用。 您也已部署 Azure 檔案同步，或讓您的網路和儲存體帳戶準備好直接共用存取。

第 5 階段：使用者完全移轉

在此階段中，您將完成移轉：

  • 規劃您的停機時間。
  • 追捕在第 3 階段中的移轉作業執行時，使用者和應用程式在 StorSimple 端所產生的任何變更。
  • 將您的使用者透過 Azure 檔案同步容錯移轉至新的 Windows Server 執行個體，或透過直接共用存取容錯移轉至 Azure 檔案共用。

將工作負載完全移轉至 Azure 檔案共用的步驟 - 按一下即可播放！

這段影片涵蓋：

  • 在工作負載完全移轉之前採取的步驟
  • 執行您的完全移轉
  • 完全移轉後步驟

規劃您的停機時間

這種移轉方法需要為您的使用者和應用程式規劃一些停機時間。 目標是要將停機時間盡可能縮短。 下列考量事項可提供幫助：

  • 執行您的移轉作業時，請讓您的 StorSimple 磁碟區維持可用狀態。
  • 當您完成執行共用的資料移轉作業之後，就可以從 StorSimple 磁碟區或共用移除使用者存取權 (至少寫入存取權)。 最終的 RoboCopy 將會追捕您的 Azure 檔案共用。 接著便可以剪下您的使用者。 RoboCopy 的執行位置，取決於您是選擇使用 Azure 檔案同步或直接共用存取。 後續章節將討論該主題。
  • 當您完成 RoboCopy 追捕之後，您就可以直接向使用者公開新的位置，方法包括使用 Azure 檔案共用，或是 Azure 檔案同步 Windows Server 執行個體上的 SMB 共用。DFS-N 部署通常可協助您快速且有效率地完成完全移轉。 此部署會將您現有的共用位址保持一致，並重新指向包含已移轉檔案和資料夾的新位置。

完全可行的資料封存方法是在 StorSimple 磁碟區 (或子資料夾) 上停機，再執行一次 StorSimple 磁碟區備份、移轉，然後開啟移轉目的地以供使用者和應用程式存取。 如此，您就不需要追捕 RoboCopy。 不過，這種方法的代價是會延長停機時間，根據您需要移轉的檔案和備份數目而定，可能會延長到數天或更長的時間。 這個選項可能僅適用於長時間沒有寫入存取權的封存工作負載。

判斷您的命名空間已完全同步至伺服器的時間

當您將 Azure 檔案同步用於 Azure 檔案共用時，在啟動任何本機 RoboCopy 之前，請務必確認您的整個命名空間已下載至伺服器。 下載您的命名空間所需的時間取決於 Azure 檔案共用中的項目數。 有兩種方法可以判斷您的命名空間是否已完全抵達伺服器。

Azure 入口網站

您可以使用 Azure 入口網站來查看您的命名空間完全到達時間。

  • 登入 Azure 入口網站，然後移至您的同步處理群組。 檢查同步處理群組和伺服器端點的同步狀態。
  • 需要注意的點是下載。 如果伺服器端點是新佈建，則會顯示 [初始同步處理]，表示命名空間仍處於關機狀態。 在該狀態變更為 [初始同步] 以外的狀態後，您的命名空間將會在伺服器上完整填入。

您現在可以繼續進行本機 RoboCopy。

Windows Server 事件檢視器

您也可以使用 Windows Server 執行個體上的事件檢視器，來判斷命名空間何時完全抵達。

  1. 開啟 [事件檢視器]，然後移至 [應用程式與服務]。
  2. 移至並開啟 Microsoft\FileSync\Agent\Telemetry。
  3. 尋找最新的 event 9102，此事件對應到已完成的同步工作階段。
  4. 選取 [詳細資料]，並確認您正在查看的事件其 SyncDirection 值為 Download。
  5. 當您的命名空間已完成下載至伺服器時，將會有單一事件，其 Scenario 值為 FullGhostedSync 且 HResult = 0。
  6. 如果您錯過該事件，也可以尋找其他 SyncDirection = Download 且 Scenario = "RegularSync" 的 9102 events。 尋找其中一個事件也表示命名空間已完成下載，並同步處理至一般同步工作階段，不論目前是否有任何要同步處理的作業。

最終的 RoboCopy

此時，您的內部部署 Windows Server 執行個體與 StorSimple 8100 或 8600 設備之間存在差異。

  1. 在進行移轉時，您需要追捕使用者或應用程式在 StorSimple 端產生的變更。
  2. 在使用 Azure 檔案同步的情況下：StorSimple 設備具有已填入的快取，而 Windows 伺服器執行個體只有命名空間，且此時沒有儲存在本機的檔案內容。 最終的 RoboCopy 可以協助您開始使用本機 Azure 檔案同步快取，方法是盡可能提取本機快取的檔案內容，並且可以容納在 Azure 文件同步服務器上。
  3. 某些檔案可能會因無效字元而遭到移轉作業忽略。 若是如此，請將這些檔案複製到已啟用 Azure 檔案同步的 Windows 伺服器執行個體。 稍後您可以進行調整，使其同步。如果您未針對特定的共用使用 Azure 檔案同步，建議您重新命名 StorSimple 磁碟區上具有無效字元的檔案。 然後直接對 Azure 檔案共用執行 RoboCopy。

警告

Windows Server 2019 中的 Robocopy 存在問題，在使用 /MIR 函式時，會導致目標伺服器上由 Azure 檔案同步分層的檔案從來源重新複製，並重新上傳至 Azure。 建議在 2019 以外的 Windows Server 上執行 Robocopy，例如 Windows Server 2016。

警告

在伺服器具有完整下載的 Azure 檔案共用的命名空間之前，您「不能」啟動 RoboCopy。 如需詳細資訊，請參閱判斷您的命名空間是否已完整下載到您的伺服器。

您只需要複製在上一次執行移轉作業之後變更的檔案，以及之前未透過這些作業移動的檔案。 在完成移轉之後，您可以在伺服器上解決這些檔案沒有移動的問題。 如需詳細資訊，請參閱 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 案例所需的重要修正。

在設定 RoboCopy 命令的來源和目標位置時，請務必檢查來源和目標的結構以確保兩者相符。 如果您使用的是移轉作業的目錄對應功能，您的根目錄結構可能與 StorSimple 磁碟區的結構不同。 如果是這種情況，您可能需要多個 RoboCopy 作業，每個子目錄各一個作業。 如果您不確定命令是否會如預期般執行，您可以使用 /L 參數，此參數會模擬命令，但不會實際進行任何變更。

這個 RoboCopy 命令會使用 /MIR，因此不會移動相同的檔案 (例如分層檔案)。 但是，如果來源路徑和目標路徑錯誤，/MIR 還會清除 Windows Server 執行個體或 Azure 檔案共用上不存在於 StorSimple 來源路徑中的目錄結構。 這些路徑必須完全準確，才能使 RoboCopy 作業達到其預定目標，也就是使用移轉進行時的最新變更來更新您的已移轉內容。

請參閱 RoboCopy 記錄檔，以查看是否有遺留的檔案。 如果有問題，請修正這些問題，然後重新執行 RoboCopy 命令。 在修正所需檔案或資料夾的未解決問題之前，請勿取消佈建任何 StorSimple 資源。

如果您未使用 Azure 檔案同步快取有問題的特定 Azure 檔案共用，而是改為選擇直接共用存取：

  1. 裝載 Azure 檔案共用以做為本機 Windows 機器的網路磁碟機。
  2. 在 StorSimple 和裝載的 Azure 檔案共用之間執行 RoboCopy。 如果檔案未複製，請在 StorSimple 端修正其名稱以移除無效字元。 然後重試 RoboCopy。 先前列出的 RoboCopy 命令可以多次執行，不會造成 StorSimple 的不必要重新叫用。

疑難排解和最佳化

指定 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) 已修正，但尚未公開提供修正程式。 請檢查此段落以取得修正程式可用性的更新和部署方式。

使用者完全移轉

如果您使用 Azure 檔案同步，您可能需要根據 StorSimple 磁碟區上的共用，在已啟用 Azure 檔案同步的 Windows 伺服器執行個體上建立對應的 SMB 共用。 您可以提前執行此步驟，以節省此處的所需時間。 但是您必須確定在此之前，沒有人可以存取並變更 Windows 伺服器執行個體。

如果您有 DFS-N 部署，可以將 DFN-Namespaces 指向新的伺服器資料夾位置。 如果您沒有 DFS-N 部署，而您在本機使用 Windows 伺服器執行個體將 8100 或 8600 設備作為前端，則可以從網域中取出該伺服器。 然後，將已啟用 Azure 檔案同步的新 Windows 伺服器執行個體加入網域。 在此流程中，請為伺服器提供與舊伺服器相同的伺服器名稱和共用名稱，使您的使用者、群組原則和指令碼可清楚掌握完全移轉。

深入了解 DFS-N。

第 6 階段：取消佈建

當您將資源取消佈建後，便無法存取該資源的設定及其資料。 解除佈建無法復原。 在確認下列事項之前，請勿繼續：

  • 您的移轉已完成。
  • 您即將取消佈建的 StorSimple 檔案、資料夾或磁碟區備份並沒有任何相依性。

開始之前，最好先在實際執行環境中觀察新的 Azure 檔案同步部署一陣子。 您可以在這段時間中修正可能遇到的任何問題。 在觀察 Azure 檔案同步部署至少幾天之後，您就可以開始依下列順序取消佈建資源：

  1. 透過 Azure 入口網站取消佈建您的 StorSimple 資料管理員資源。 此作業將會刪除您的所有 DTS 工作。 之後將無法輕鬆地擷取複製記錄。 如果這些工作對您的記錄而言很重要，請在取消佈建之前先進行擷取。
  2. 確定您的 StorSimple 實體設備已移轉，然後將其取消註冊。 如果您不確定設備是否已移轉，請不要繼續進行。 如果取消佈建仍需使用的資源，您將無法復原資料或其設定。
    您可以選擇先取消佈建 StorSimple 磁碟區資源，這會清除設備上的資料。 此程序可能需要數天的時間，而且不會徹底將設備上的資料清零。 如果在意這點，請將磁碟空間清空和資源的解除佈建分開處理，並遵循您的原則。
  3. 如果 StorSimple 裝置管理員中沒有任何已註冊的裝置，您可以繼續移除該裝置管理員資源本身。
  4. 現在您可以在 Azure 中刪除 StorSimple 儲存體帳戶。 同樣地，在您繼續之前，請暫停並確認您的移轉已完成，而且沒有任何與這項資料相依的項目。
  5. 從您的資料中心拔除 StorSimple 實體設備。
  6. 如果 StorSimple 設備屬於您，則可以自由進行電腦回收。 如果您的裝置是租用而來，請通知出租人並視情況返還裝置。

您的移轉已完成。

注意

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

疑難排解

使用 StorSimple 資料管理員移轉服務時，整個移轉作業或個別檔案可能會因為各種原因而失敗。 檔案精確度一節提供更多有關受支援/不支援案例的詳細資料。 下表列出錯誤碼、錯誤詳細資料，以及可能的因應措施選項。

工作階層錯誤

階段 錯誤 詳細資料和因應措施
Backup 找不到所指定參數的備份 在「估計」或「複製」時，找不到為作業執行選取的備份。 請確定備份仍存在於 StorSimple 備份目錄中。 有時候，自動備份保留原則會刪除選取期間的備份以進行移轉，並實際執行此備份的移轉作業。 開始移轉之前，請考慮先停用任何備份保留排程。
估計
設定計算		 加密金鑰的安裝失敗 您的服務資料加密金鑰不正確。 如需詳細資訊，並協助擷取正確的金鑰，請檢閱本文中的加密金鑰一節。
批次錯誤 啟動執行移轉所需的所有內部基礎結構可能會發生問題。 此流程涉及多個其他服務。 當您嘗試再次執行作業時，這些問題通常會自行解決。
StorSimple Manager 發生內部錯誤。 等候幾分鐘的時間，然後再次嘗試操作。 如果問題持續發生，請連絡 Microsoft 支援服務。 (錯誤碼: 1074161829) 此一般錯誤有多個原因，但有一個可能的原因是 StorSimple 裝置管理員達到 50 個設備的限制。 檢查裝置管理員中最近執行的作業是否突然開始失敗，並出現此錯誤，這表示這是問題。 此特定問題的因應措施是移除資料管理員服務所建立和使用的任何離線 StorSimple 8001 設備。 您可以在入口網站中提出支援票證或手動刪除票證。 請務必只刪除離線 8001 系列設備。
正在估計檔案 複製磁碟區工作失敗 此錯誤很可能表示您指定了以某種方式損毀的備份。 移轉服務無法裝載或讀取。 您可以手動試用備份，或開啟支援票證。
無法繼續，因為磁碟區為非 NTFS 格式 移轉服務只能使用未啟用 Dedupe 的 NTFS 磁碟區。 如果您有不同格式的磁碟區，例如 ReFS 或協力廠商格式，移轉服務將無法移轉此磁碟區。 請參閱已知限制一節。
請連絡支援人員。 磁碟上找不到適當的磁碟分割 應該指定移轉磁碟區的 StorSimple 磁碟幾乎沒有該磁碟區的磁碟分割。 這不尋常，而且可能表示損毀或管理不一致。 您可進一步調查此問題的唯一選項是提出支援票證。
逾時 估計階段因逾時而失敗通常是 StorSimple 設備或來源磁碟區備份速度緩慢，且有時甚至有損毀的問題。 如果重新執行備份無法運作，則提出支援票證是最佳做法。
找不到檔案 <路徑>
找不到路徑的一部分		 作業定義可讓您提供來源子路徑。 當該路徑不存在時，會顯示此錯誤。 例如：\Share1 > \Share\Share1
在此範例中，您已將 \Share1 指定為來源中的子路徑，對應至目標中的其他子路徑。 不過，來源路徑不存在 (拼字錯誤？)。 注意：Windows 會保留大小寫，但與大小寫無關。 這表示指定 \Share1 和 \share1 是相同的。 此外：系統會自動建立不存在的目標路徑。
呼叫者沒有權限執行此作業 當來源 StorSimple 儲存體帳戶或具有 Azure 檔案共用的目標儲存體帳戶已啟用防火牆設定時，就會顯示此錯誤。 您必須允許透過公用端點的流量，且不會使用進一步的防火牆規則加以限制。 否則，即使您已授權，資料轉換服務仍無法存取任一個儲存體帳戶。 停用任何防火牆規則並重新執行作業。
複製檔案 所存取的帳戶不支援 HTTP 停用目標儲存體帳戶上的網際網路路由，或使用 Microsoft 路由端點。
指定的共用已滿 如果目標是進階 Azure 檔案共用，請確定您已為共用佈建足夠的容量。 暫時過度佈建是常見的做法。

項目層級錯誤

在移轉作業執行的複製階段，個別命名空間項目 (檔案和資料夾) 可能會遇到錯誤。 下表列出最常見的錯誤，並盡可能建議因應措施選項。

階段 錯誤 風險降低
複製 -2146233088
伺服器忙碌中。		 如果失敗太多，請重新執行作業。 如果只有極少數錯誤，您可以再次嘗試執行作業，但通常手動複製失敗的項目可能會更快。 然後略過以處理下一個備份，以繼續移轉。
-2146233088
無法在允許的時間內完成作業。		 如果失敗太多，請重新執行作業。 如果只有極少數錯誤，您可以再次嘗試執行作業，但通常手動複製失敗的項目可能會更快。 然後略過以處理下一個備份，以繼續移轉。
上傳逾時或未啟動複製 如果失敗太多，請重新執行作業。 如果只有極少數錯誤，您可以再次嘗試執行作業，但通常手動複製失敗的項目可能會更快。 然後略過以處理下一個備份，以繼續移轉。
-2146233029
已取消作業。		 如果失敗太多，請重新執行作業。 如果只有極少數錯誤，您可以再次嘗試執行作業，但通常手動複製失敗的項目可能會更快。 然後略過以處理下一個備份，以繼續移轉。
1920
系統無法存取檔案。		 當移轉引擎遇到重新分析點、連結或連接點時，這是常見的錯誤。 不支援此使用方式。 無法複製這些類型的檔案。 請檢閱本文中的已知限制一節和檔案精確度一節。
-2147024891
拒絕存取		 這是以無法在磁碟上存取檔案的方式加密的檔案錯誤。 可從磁碟讀取檔案，但只包含加密內容的檔案不會受到影響，而且可以複製。 您唯一的選項是手動複製它們。 您可以裝載受影響的磁碟區並執行下列命令來尋找這類項目：get-childitem <path> [-Recurse] -Force -ErrorAction SilentlyContinue | Where-Object {$_.Attributes -ge "Encrypted"} | format-list fullname, attributes
不是有效的 Win32 FileTime。 參數名稱：fileTime 在此情況下，您可以存取檔案，但無法用於評估複本，因為移轉引擎相依的時間戳記已損毀或由應用程式以不正確的格式寫入。 您也束手無策，因為您無法變更備份中的時間戳記。 如果保留此檔案很重要，或許在此最新版本上 (包括此檔案的最近一次備份)，您可以手動複製檔案、修正時間戳記，然後將它移至目標 Azure 檔案共用。 此選項不會非常地妥善調整，但對於您想要在目標中保留至少一個版本的高價值檔案而言，仍是一個選項。
-2146232798
已關閉安全控制代碼		 通常是暫時性的錯誤。 如果失敗太多，請重新執行作業。 如果只有極少數錯誤，您可以再次嘗試執行作業，但通常手動複製失敗的項目可能會更快。 然後略過以處理下一個備份，以繼續移轉。
-2147024413
嚴重裝置硬體錯誤		 這是罕見的錯誤，實際上不會回報實體裝置，而是移轉服務所使用的 8001 系列虛擬化設備。 設備發生問題。 發生此錯誤的檔案不會阻止移轉繼續下一個備份。 這讓您難以執行手動複本，或重試包含此錯誤檔案的備份。 如果留下的檔案非常重要，或有大量的檔案，您可能需要再次開始移轉所有備份。 請開啟支援票證以進一步調查。
刪除
(鏡像清除)		 指定的目錄不是空的。 當移轉模式設定為鏡像，而從 Azure 檔案共用移除項目的流程遇到導致無法刪除項目的問題時，就會發生此錯誤。 刪除只會在即時共用中發生，而不是從先前的快照集進行。 刪除是必要的，因為受影響的檔案不在目前的備份中，因此必須在下一個快照集之前從即時共用中移除。 有兩個選項：選項 1：裝載目標 Azure 檔案共用，並手動刪除具有此錯誤的檔案。 選項 2：您可以忽略這些錯誤並繼續處理下一個備份，並預期目標與來源不同，而且有一些不在原始 StorSimple 備份中的額外項目。
不正確的要求 此錯誤表示來源檔案具有無法複製到 Azure 檔案共用的特定特性。 最值得注意的是，檔案名稱中可能會有不可見的控制字元，或者檔案名稱或檔案路徑中有 1 個位元組的雙位元組字元。 您可以使用複製記錄來取得路徑名稱、將檔案複製到暫存位置、重新命名路徑以移除不支援的字元，然後再次將 robocopy 複製到 Azure 檔案共用。 然後，您可以略過到處理的下一個備份，以繼續移轉。

下一步

  • 了解雲端分層原則的彈性。
  • 在 Azure 檔案共用上啟用 Azure 備份，以排程快照集，並定義備份保留排程。
  • 如果您在 Azure 入口網站中看到某些檔案永久不同步，請參閱 疑難排解指南以取得解決這些問題的步驟。