使用資料箱，可以運用 Azure 檔案同步將檔案從網路連接儲存裝置 (NAS) 移轉到混合式雲端部署
這篇移轉文章是適用於 NAS、Azure 檔案同步和 Azure 資料箱等關鍵字的其中一篇。 確認本文是否適用於您的案例：
- 資料來源：網路連接儲存裝置 (NAS)
- 移轉路由：AS ⇒ 資料箱 ⇒ Azure 檔案共用 ⇒ 與 Windows Server 同步
- 在內部部署快取檔案：是，最終目標是 Azure 檔案同步部署
如果您的案例不同，請查看移轉指南的表格。
Azure 檔案同步可在直接連結存放裝置 (DAS) 位置作用。 它不支援同步至網路連接儲存裝置 (NAS) 位置。 因此您必須移轉檔案。 本文會引導您逐步完成該移轉的規劃和實作。
適用於
| 檔案共用類型 | SMB | NFS |
|---|---|---|
| 標準檔案共用 (GPv2)、LRS/ZRS |  |
 |
| 標準檔案共用 (GPv2)、GRS/GZRS | |
|
| 進階檔案共用 (FileStorage)、LRS/ZRS | |
|
移轉目標
目標是將您在 NAS 設備上的共用移至 Windows Server。 然後，您可在混合式雲端部署中使用 Azure 檔案同步。 進行此移轉時，需要在移轉期間保證實際執行資料的完整性和可用性。 後者需要盡可能縮短停機時間，使其符合一般維護期間，或僅略為超過。
移轉概觀
移轉流程由幾個階段組成。 您需要：
- 部署 Azure 儲存體帳戶和檔案共用。
- 部署執行 Windows Server 的內部部署電腦。
- 設定 Azure 檔案同步。
- 使用 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 檔案作為範本，以利建立您的對應。
|
下載命名空間對應範本。 |
階段 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 會傳送給您一到五個 SSD 磁碟，每個磁碟的容量為 8 TiB，上限總計為 40 TiB。 因為加密和檔案系統的額外負荷，可用容量約在 20% 以下。 如需詳細資訊，請參閱資料箱磁碟文件。
- 資料箱。 此選項是最常見的選項。 Microsoft 會將作用類似 NAS 的耐用資料箱設備傳送給您， 其可用容量為 80 TiB。 如需詳細資訊，請參閱資料箱文件。
- Data Box Heavy。 此選項的主打的功能是作用類似 NAS 的移動式耐用資料箱設備。 其容量為 1 PiB。 因為加密和檔案系統的額外負荷，可用容量約在 20% 以下。 如需詳細資訊，請參閱 Data Box Heavy 文件。
第 4 階段：在內部部署環境中佈建適合的 Windows Server 執行個體
在您等候 Azure 資料箱裝置抵達時，您可以開始查看要搭配 Azure 檔案同步使用的一或多個 Windows Server 執行個體的需求。
- 建立 Windows Server 2022 實例（至少為 Windows Server 2012 R2）作為虛擬機或實體伺服器。 也支援 Windows Server 容錯移轉叢集。
- 佈建或新增直接連結存放裝置。 不支援 NAS。
您部署的 Windows Server 執行個體資源設定 (計算和 RAM)，主要取決於您要同步的檔案和資料夾數目。 如果您有任何疑慮，建議您採用較高的效能設定。
了解如何依據您需要同步的項目數，調整 Windows Server 執行個體大小。
注意
先前連結的文章含有一個資料表，其中列出伺服器記憶體 (RAM) 的範圍。 伺服器可以使用此範圍中較小的數字，但預期初始同步處理的時間會變得很長。
第 5 階段：將檔案複製到您的資料箱
資料箱送達時，您必須進行設定，以對 NAS 設備進行暢通無阻的網路連線。 針對您所訂購的資料箱類型，遵循安裝文件：
視資料箱的類型而定，可能會有資料箱複製工具可用。 此時，我們不建議使用這些工具將檔案移轉至 Azure 檔案共用，因為它們無法將檔案完全精確地複製到資料箱。 請改用 Robocopy。
當您的資料箱抵達時，您在訂購時所指定的每一個儲存體帳戶都會有預先佈建的 SMB 共用可供使用。
- 如果您的檔案進入進階 Azure 檔案共用，每個進階「檔案儲存體」的儲存體帳戶將會有一個 SMB 共用。
- 如果您的檔案進入標準儲存體帳戶，每個標準 (GPv1 和 GPv2) 儲存體帳戶將會有三個 SMB 共用。 只有結尾為
_AzFiles的檔案共用與您的移轉相關。 請忽略任何區塊和分頁 Blob 共用。
依照 Azure 資料箱文件中的步驟進行：
- 連線至資料箱。
- 將資料複製到資料箱。 您可以使用 Robocopy (依照下列指示) 或新的資料箱資料複製服務。
- 準備資料箱以上傳至 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 案例所需的重要修正。
第 6 階段：部署 Azure 檔案同步雲端資源
繼續進行本指南之前，請先等候所有檔案都已抵達正確的 Azure 檔案共用。 傳送和擷取資料箱資料的程序需要一些時間才能完成。
若要完成此步驟，您需要 Azure 訂用帳戶認證。
要為 Azure 檔案同步設定的核心資源，稱為儲存體同步服務。 我們建議您只針對目前或未來要同步處理相同檔案集的所有伺服器，部署一個服務即可。 當您確知有幾組絕不可交換資料的伺服器時，才需要建立多個儲存體同步服務。 例如，您可能會有某些伺服器絕不會同步處理相同的 Azure 檔案共用。 否則，使用單一儲存體同步服務將是最佳做法。
為您的儲存體同步服務選擇靠近您所在位置的 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 執行個體上設定 Azure 檔案同步
已註冊的內部部署 Windows Server 執行個體必須準備就緒，並已連線至網際網路，才能進行此程序。
此步驟會將您在先前步驟中於 Windows Server 執行個體上設定的所有資源和資料夾結合在一起。
- 登入 Azure 入口網站。
- 找出您的儲存體同步服務資源。
- 針對每個 Azure 檔案共用，在儲存體同步服務資源中建立新的同步群組。 在 Azure 檔案同步的術語中，當您說明建立同步群組的同步拓撲時，Azure 檔案共用就成為雲端端點。 建立同步群組時，請為其提供一個熟悉的名稱，以便您辨識在該處同步的是哪一組檔案。 請務必參考具有相符名稱的 Azure 檔案共用。
- 建立同步群組之後，其資料列將會出現在同步群組清單中。 選取名稱 (連結)，以顯示同步群組的內容。 您將會在 [雲端端點] 下方看到您的 Azure 檔案共用。
- 找到 [新增伺服器端點] 按鈕。 您在本機伺服器上佈建的資料夾將會成為這個伺服器端點的路徑。
開啟雲端階層處理功能，並只在 [初始下載] 區段中選取 [僅命名空間]。
重要
雲端階層處理是 Azure 檔案同步功能，可讓本機伺服器的儲存容量比雲端的儲存容量少，卻可使用完整的命名空間。 本機上受關注的資料也會在本機快取，以實現快速存取效能。 雲端階層處理是選用功能。 您可以針對每個 Azure 檔案同步伺服器端點個別設定此功能。 如果您的 Windows Server 執行個體沒有足夠的本機磁碟容量來保存所有雲端資料，而您想要避免從雲端下載所有資料，則需要使用此功能。
針對您需要設定同步處理的所有 Azure 檔案共用/伺服器位置，重複上述步驟以建立同步群組，並將相符的伺服器資料夾新增為伺服器端點。 等待命名空間的同步處理完成。 下一節將說明如何確定同步完成。
注意
建立伺服器端點後，同步處理即會作用。 但是，同步處理需要列舉 (探索) 您透過資料箱移至 Azure 檔案共用的檔案和資料夾。 根據命名空間大小，此程序可能需要很長的時間，雲端的命名空間才會出現在伺服器上。
第 9 階段：等待命名空間完全顯示在伺服器上
繼續進行移轉的後續步驟之前，請先等待伺服器從雲端共用完整下載命名空間。 如果您太早開始將檔案移至伺服器，則須面臨不必要的上傳，甚至是檔案同步衝突的風險。
若要判斷您的伺服器是否已完成初始下載同步，請在同步處理的 Windows Server 執行個體上開啟 [事件檢視器]，然後使用 Azure 檔案同步遙測事件記錄檔。 遙測事件記錄檔位於 Applications and Services\Microsoft\FileSync\Agent 下的 Event Viewer 中。
搜尋最新的 9102 事件。
同步工作階段完成後，會記錄事件識別碼 9102。 在事件文字中，有一個記錄下載同步方向的欄位。 (HResult 必須為零，且必須下載檔案。)
您要看到連續兩個這種類型的事件，且顯示此內容，才能確定伺服器已完成命名空間下載。 如果在這兩個 9102 事件中有其他事件，並沒有問題。
第 10 階段：從 NAS 執行 Robocopy
當伺服器完成雲端共用中整個命名空間的初始同步後，您就可以繼續執行此步驟。 在您繼續執行此步驟之前，必須先完成初始同步處理。 如需詳細資料，請參閱上一節。
在此步驟中，您將執行 Robocopy 作業，讓雲端共用與您將共用分支至資料箱後 NAS 上發生的最新變更同步。 視您的 NAS 共用上發生的流失量而定，這個 Robocopy 作業執行可能會快速完成或需要一些時間。
警告
由於 Windows Server 2019 中有迴歸的 Robocopy 行為，因此 Robocopy /MIR 切換與階層式目標目錄不相容。 在移轉的這個階段中，您無法使用 Windows Server 2019 或 Windows 10 用戶端。 請在中繼 Windows Server 2016 執行個體上使用 Robocopy。
以下是基本的移轉方法：
- 從 NAS 設備執行 Robocopy，以同步處理您的 Windows Server 執行個體。
- 使用 Azure 檔案同步從 Windows Server 同步處理 Azure 檔案共用。
執行 Windows Server 目標資料夾的第一個本機副本：
- 識別 NAS 設備上的第一個位置。
- 識別 Windows Server 執行個體上已設定 Azure 檔案同步的相符資料夾。
- 使用 Robocopy 開始複製。
下列 Robocopy 命令只會從您的 NAS 儲存體將差異部分 (更新的檔案和資料夾) 複製到 Windows Server 目標資料夾。 然後，Windows Server 執行個體會將這些檔案和資料夾同步到 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>
| 交換器 | 意義 |
|---|---|
/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 案例所需的重要修正。
如果您在 Windows Server 執行個體上佈建的儲存體少於 NAS 設備上檔案使用的容量，即表示您已設定雲端階層處理。 由於本機 Windows Server 磁碟區已滿，因此雲端階層處理將會啟動，並將已成功同步處理的檔案分層。 雲端階層處理會產生足夠的空間，讓您可以繼續從 NAS 設備複製。 雲端階層處理會每小時檢查，確認已執行同步並釋出磁碟空間，以達到 99% 的磁碟區可用空間。
Robocopy 可能需要移動更多檔案，這些檔案數會超過您可以儲存在本機 Windows Server 執行個體上的檔案數量。 您可以預期相較於 Azure 檔案同步上傳檔案並解除本機磁碟區的分層，Robocopy 移動檔案的速度必須更快。 在此情況下，Robocopy 將會失敗。 建議您循序完成共用，避免發生此情況。 例如，只移動 Windows Server 執行個體上可用空間所能容納的共用。 或避免所有共用同時開始執行 Robocopy 作業。 好消息是 /MIR 切換將確保只移動差異部分。 移動差異之後，重新啟動的作業就不需要再次移動檔案。
執行轉換
當您第一次執行 Robocopy 命令時，使用者和應用程式仍會存取 NAS 上的檔案，且可能會進行變更。 Robocopy 將會依序處理目錄。 然後，NAS 上的使用者可能會新增、變更或刪除在目前 Robocopy 執行期間未處理的第一個目錄中的檔案。 此行為是預期的。
第一次執行是將大量流失的資料移至您的 Windows Server 執行個體，並透過 Azure 檔案同步進入雲端。第一次複製作業可能需要很長的時間，視下列情況而定:
- 上傳頻寬。
- 區域網路速度，以及配合此速度的最佳 Robocopy 執行緒數目。
- 需要由 Robocopy 和 Azure 檔案同步處理的項目 (檔案和資料夾) 數目。
初始執行完成後，請再次執行命令。
第二次為了共用而執行 Robocopy 時，命令的完成速度會更快。 因為只需要傳輸前次執行後的變更部分。 您可以在相同的共用中執行重複作業。
若要考慮可接受的停機時間，您必須移除 NAS 型共用的使用者存取權。 您可以採取任何方式來達成此目的，以防止使用者變更檔案和資料夾結構與內容。 例如，您可以將您的 DFS 命名空間指向不存在的位置，或變更共用上的根 ACL。
最後再執行一次 Robocopy。 這次會挑出任何錯過的變更。 最後一個步驟所需的時間，取決於 Robocopy 掃描的速度。 您可以藉由測量上次執行的時間長度來估計時間 (等於停機時間)。
在 Windows Server 資料夾上建立共用，且可能會調整您的 DFS-N 部署以指向該共用。 請務必設定與您 NAS SMB 共用上相同的共用層級權限。 如果您有已加入網域的企業級 NAS，則會自動比對使用者 SID，因為使用者是在 Active Directory 中，且 Robocopy 會複製完全正確的檔案和中繼資料。 如果您在 NAS 上使用本機使用者，您必須：
- 將這些使用者重新建立為 Windows Server 本機使用者。
- 將 Robocopy 移至 Windows Server 執行個體的現有 SID 對應到新 Windows Server 本機使用者的 SID。
您已完成將共用或共用群組移轉至一般的根目錄或磁碟區 (視您在第 1 階段的對應而定)。
您可以嘗試平行執行一些副本。 建議您一次處理一個 Azure 檔案共用範圍。
過時的選項：「離線資料傳輸」
發行 Azure 檔案同步代理程式第 13 版之前，必須透過稱為「離線資料傳輸」的程序來完成資料箱整合。 此程式已被取代，您無法再以「離線數據傳輸」模式建立伺服器端點。 在代理程式第 13 版中，該程序已取代為本文所說明的步驟，速度更快且更簡單。
疑難排解
最常見的問題是 Robocopy 命令在 Windows Server 端因「磁碟區已滿」而失敗。 雲端階層處理會每小時執行一次，從本機 Windows Server 磁碟撤除已同步的內容。 其目標是在磁碟區上提供 99% 可用空間。
請讓同步進度和雲端階層處理釋出磁碟空間。 您可以在 Windows Server 執行個體的檔案總管中觀察可用空間量。
當您的 Windows Server 執行個體有足夠的可用容量時，請再次執行命令以解決問題。 在此情況下，命令執行將不會中斷。 您可以放心繼續執行程序。 唯一造成的不便是必須重新執行命令。
若要針對 Azure 檔案同步問題進行疑難排解，請參閱下一節中所列的文章。
下一步
下列文章將協助您瞭解 Azure 檔案儲存體 和 Azure 檔案同步 的進階選項和最佳做法。
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應