規劃 Azure 檔案同步部署

Azure 檔案同步服務可讓您快取內部部署 Windows Server 或雲端 VM 上的個 Azure 檔案共用。

本文將向您介紹 Azure 檔案同步概念和功能。 一旦您熟悉 Azure 檔案同步，就請考慮遵循 Azure 檔案同步部署指南來試用這項服務。

這些檔案將儲存在雲端的 Azure 檔案共用中。 Azure 檔案共用的使用方式有兩種：直接裝載這些無伺服器 Azure 檔案共用 (SMB)，或使用 Azure 檔案同步快取內部部署的 Azure 檔案共用。您所選擇的部署選項會變更規劃部署時所需考慮的層面。

• 直接掛接 Azure 檔案共用：由於 Azure 檔案儲存體會提供 SMB 存取，因此您可以使用 Windows、macOS 和 Linux 中提供的標準 SMB 用戶端，在內部部署或雲端中裝載 Azure 檔案共用。 由於 Azure 檔案共用是無伺服器的，因此針對生產案例進行部署並不需要管理檔案伺服器或 NAS 裝置。 這表示您不需要套用軟體修補程式或交換實體磁碟。

• 使用 Azure 檔案同步快取內部部署的 Azure 檔案共用：Azure 檔案同步可讓您將組織的檔案共用集中在 Azure 檔案儲存體中，同時保有內部部署檔案伺服器的靈活度、效能及相容性。 Azure 檔案同步會將內部部署 (或雲端) Windows Server 轉換成 Azure 檔案共用的快速快取。

管理概念

Azure 檔案同步部署有三個基礎管理物件：

• Azure 檔案共用：Azure 檔案共用是無伺服器的雲端檔案共用，可提供 Azure 檔案同步同步關係的雲端端點。 雖然 Azure 檔案共用中的檔案可以直接使用 SMB 或 FileREST 通訊協定進行存取，但是建議您在搭配 Azure 檔案同步使用 Azure 檔案共用時，主要透過 Windows Server 快取存取檔案。這是因為 Azure 檔案儲存體現今缺少有效率的變更偵測機制 (如 Windows Server 所具有的)，因此直接對 Azure 檔案共用進行變更將需要一段時間才能傳播回伺服器端點。
• 伺服器端點：Windows Server上正在同步至 Azure 檔案共用的路徑。 這可以是磁碟區上的特定資料夾或磁碟區的根目錄。 如果伺服器端點的命名空間沒有重疊，則相同磁碟區中可以存在多個伺服器端點。
• 同步群組：此為物件，可定義雲端端點或 Azure 檔案共用與伺服器端點之間的同步關係。 位於同步群組內的端點會彼此保持同步。 例如，如果您有兩組不同的檔案需要透過 Azure 檔案同步管理，您會建立兩個同步群組，並將不同的端點個別新增至這兩個同步群組。

Azure 檔案共用管理概念

Azure 檔案共用已部署到儲存體帳戶，這是代表共用儲存體集區的最上層物件。 此儲存體集區可用來部署多個檔案共用，以及其他儲存體資源 (例如 Blob 容器、佇列或資料表)。 部署到儲存體帳戶的所有儲存體資源，都共用適用於該儲存體帳戶的限制。 如需目前的儲存體帳戶限制，請參閱 Azure 檔案儲存體的可擴縮性和效能目標。

要用於 Azure 檔案儲存體部署的儲存體帳戶有兩種主要類型：

• 一般用途第 2 版 (GPv2) 儲存體帳戶：GPv2 儲存體帳戶可讓您在標準/硬碟型 (HDD 型) 硬體上部署 Azure 檔案共用。 除了儲存 Azure 檔案共用之外，GPv2 儲存體帳戶還可以儲存其他儲存體資源，例如 Blob 容器、佇列或資料表。
• FileStorage 儲存體帳戶：FileStorage 儲存體帳戶可讓您在進階/固態磁碟型 (SSD 型) 硬體上部署 Azure 檔案共用。 FileStorage 帳戶只能用來儲存 Azure 檔案共用；無法將其他儲存體資源 (Blob 容器、佇列、資料表等) 部署在 FileStorage 帳戶中。 只有 FileStorage 帳戶可以部署 SMB 和 NFS 檔案共用。

在 Azure 入口網站、PowerShell 或 CLI 中，可能會遇到數個其他儲存體帳戶類型。 BlockBlobStorage 和 BlobStorage 這兩個儲存體帳戶類型，不能包含 Azure 檔案共用。 您可能會看到其他兩個儲存體帳戶類型為一般用途第 1 版 (GPv1) 和傳統儲存體帳戶，這兩者都可以包含 Azure 檔案共用。 雖然 GPv1 和傳統儲存體帳戶可能包含 Azure 檔案共用，但 Azure 檔案儲存體的大部分新功能僅適用於 GPv2 和 FileStorage 儲存體帳戶。 因此，我們建議僅將 GPv2 和 FileStorage 儲存體帳戶用於新的部署，若環境中已存在 GPv1 和傳統儲存體帳戶時，則建議對其進行升級。

Azure 檔案同步管理概念

同步群組會部署到儲存體同步服務，這些服務是最上層物件，用來註冊與 Azure 檔案同步搭配使用的伺服器，並包含同步群組關聯性。 儲存體同步服務資源是儲存體帳戶資源的對等，同樣可以部署到 Azure 資源群組中。 儲存體同步服務可以建立同步群組，跨多個儲存體帳戶和多個已註冊 Windows Server 包含 Azure 檔案共用。

您必須先向儲存體同步服務註冊 Windows Server，才能在儲存體同步服務中建立同步群組。 這會建立已註冊的伺服器物件，代表您的伺服器或叢集與儲存體同步服務之間的信任關係。 若要註冊儲存體同步服務，您必須先在伺服器上安裝 Azure 檔案同步代理程式。 一次只能向單一儲存體同步服務註冊個別伺服器或叢集。

同步群組包含一個雲端端點或 Azure 檔案共用，以及至少一個伺服器端點。 伺服器端點物件所包含的設定，可設定雲端階層處理功能，以提供 Azure 檔案同步的快取功能。為了與 Azure 檔案共用同步，包含 Azure 檔案共用的儲存體帳戶必須與儲存體同步服務位於相同的 Azure 區域中。

考量所需的儲存體同步服務計數

上一節我們討論設定 Azure 檔案同步的核心資源：儲存體同步服務。 一個 Windows Server 只能註冊至一個儲存體同步服務。 因此，通常最好只部署單一儲存體同步服務，並在其中註冊所有伺服器。

只有在您有下列情況時，才需要建立多個儲存體同步服務：

• 永遠不能彼此交換資料的相異伺服器集合。 在此情況下，您可以將系統設計為排除特定的伺服器集合，使其在不同儲存體同步服務的同步群組中，與作為雲端端點使用的 Azure 檔案共用進行同步。 此情況的另一個觀點是，向不同儲存體同步服務註冊的 Windows 伺服器無法與相同的 Azure 檔案共用進行同步。
• 需要超過單一儲存體同步服務可支援的已註冊伺服器或同步群組數量。 如需詳細資訊，請參閱 Azure 檔案同步調整目標。

規劃平衡的同步拓撲

在您部署任何資源之前，請務必先規劃要在本機伺服器上同步的內容，以及與哪一個 Azure 檔案共用同步。 進行規劃可協助您判斷您需要多少儲存體帳戶、Azure 檔案共用和同步資源。 即使您的資料目前不在 Windows Server 或您想要長期使用的伺服器上，這些考量仍關係重大。 移轉區段有助於判斷您情況適用的移轉路徑。

在此步驟中，您將決定您需要多少 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 檔案共用中 (同步之外) 所做的變更。

部署對應的結構化方法

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

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

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

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

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

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

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

最佳做法是讓每個同步範圍的項目數保持在少量。 這是您將資料夾對應至 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 檔案作為範本，以利建立您的對應。

下載命名空間對應範本。

Windows 檔案伺服器考量

若要在 Windows Server 上啟用同步功能，您必須安裝 Azure 檔案同步的可下載代理程式。 Azure 檔案同步代理程式提供兩個主要元件：FileSyncSvc.exe，這是負責監視伺服器端點上變更並起始同步工作階段的背景 Windows 服務，以及 StorageSync.sys，這是可啟用雲端階層處理和快速災害復原的檔案系統篩選器。

作業系統需求

支援 Azure 檔案同步搭配下列 Windows Server 版本：

版本	支援的 SKU	支援的部署選項
Windows Server 2025	Azure、Datacenter、Essentials、Standard 和 IoT	Full 和 Core
Windows Server 2022	Azure、Datacenter、Essentials、Standard 和 IoT	Full 和 Core
Windows Server 2019	Datacenter、Essentials、Standard 和 IoT	Full 和 Core
Windows Server 2016	Datacenter、Essentials、Standard 和 Storage Server	Full 和 Core
Windows Server 2012 R2*	Datacenter、Essentials、Standard 和 Storage Server	Full 和 Core

*需要下載並安裝 Windows Management Framework (WMF) 5.1。 可為 Windows Server 2012 R2 下載和安裝的適當套件為 Win8.1AndW2K12R2-KB*******-x64.msu。

Windows Server 的未來版本將會於發佈時加入支援清單。

最低系統資源

Azure 檔案同步需要至少一個 CPU 的伺服器、至少一個 CPU、至少 2 GiB 的記憶體，以及使用 NTFS 檔案系統格式化的本機連結磁碟區。

對於大部分的生產工作負載，不建議您設定僅具有最低需求的「Azure 檔案同步」同步伺服器。 如需詳細資訊，請參閱建議的系統資源。

建議的系統需求

就像任何伺服器功能或應用程式一樣，Azure 檔案同步的系統資源需求取決於部署的規模；伺服器上較大型的部署需要更多的系統資源。 對於 Azure 檔案同步，規模取決於伺服器端點間的物件數目和資料集上的變換。 單一伺服器可在多個同步群組中具有伺服器端點，而在下表中列出的物件數目則說明伺服器所附加的完整命名空間。

例如，具有 1 千萬個物件的伺服器端點 A + 具有 1 千萬個物件的伺服器端點 B = 2 千萬個物件。 對於該範例部署，我們會建議 8 個 CPU、16 GiB 的記憶體以提供穩定的狀態，以及 (如果可能) 48 GiB 的記憶體以進行初始遷移。

基於效能考量，命名空間資料會儲存在記憶體中。 因此，較大的命名空間需要更多記憶體來維持良好的效能，而更多變換則需要更多的 CPU 才能處理。

在下表中，我們提供了命名空間的大小，以及典型一般用途檔案共用的容量轉換，其中平均檔案大小為 512 KiB。 如果您的檔案大小較小，請考慮為相同容量新增額外的記憶體。 將您的記憶體組態以命名空間的大小為基礎。

命名空間大小 - 檔案與目錄 (數百萬)	一般總容量 (TiB)	CPU 核心	建議的記憶體 (GiB)
3	1.4	2	8 (初始同步)/2 (一般變換)
5	2.3	2	16 (初始同步)/4 (一般變換)
10	4.7	4	32 (初始同步)/8 (一般變換)
30	14.0	8	48 (初始同步)/16 (一般變換)
50	23.3	16	64 (初始同步)/32 (一般變換)
100*	46.6	32	128 (初始同步)/32 (一般變換)

*不建議同步處理超過 1 億個檔案和目錄。 這是以測試閾值為基礎的軟性限制。 如需詳細資訊，請參閱 Azure 檔案同步擴展目標 (機器翻譯)。

評估 Cmdlet

在部署 Azure 檔案同步之前，您應該使用 Azure 檔案同步評估 Cmdlet 來評估其是否與您的系統相容。 此 Cmdlet 會檢查檔案系統和資料集的潛在問題，例如不支援的字元或作業系統版本。 這些檢查也包含下列提到的大部分功能 (但不是全部)；我們建議您仔細閱讀本節的其餘部分，以確保您的部署可順利進行。

您可以藉由安裝 Az PowerShell 模組來安裝評估 Cmdlet，此模組可依照此處的指示進行安裝：安裝和設定 Azure PowerShell。

使用方式

您可以使用幾個不同的方式來叫用評估工具：您可以執行系統檢查、資料集檢查，或兩者都執行。 若要執行系統和資料集的檢查：

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

若要只要測試資料集：

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

若只要測試系統需求：

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

若要以 CSV 格式顯示結果：

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

檔案系統相容性

只在直接連接的 NTFS 磁碟區上支援 Azure 檔案同步。 Windows Server 上直接連接的儲存體或 DAS 表示 Windows Server 作業系統擁有檔案系統。 您可以透過將磁碟實際連接到檔案伺服器、將虛擬磁碟連接至檔案伺服器 VM (例如 Hyper-v 所裝載的 VM)，或甚至透過 iSCSI 來提供 DAS。

只支援 NTFS 磁碟區；不支援 ReFS、FAT、FAT32 及其他檔案系統。

下表顯示 NTFS 檔案系統功能的 Interop 狀態：

功能	支援狀態	備註
存取控制清單 (ACL)	完全支援	Azure 檔案同步會保留 Windows 樣式 Discretionary 存取控制清單，並由伺服器端點上的 Windows Server 強制執行。 當直接裝載 Azure 檔案共用時，也可以強制執行 ACL，不過這需要額外的設定。 如需詳細資訊，請參閱身分識別一節。
永久連結	已跳過
符號連結	已跳過
掛接點	部分支援	掛接點可能是伺服器端點的根目錄，但如果伺服器端點的命名空間中包含它們，系統會予以略過。
接合	已跳過	例如，分散式檔案系統 DfrsrPrivate 和 DFSRoots 資料夾。
重新剖析點	已跳過
NTFS 壓縮	部分支援	Azure 檔案同步不支援位於已壓縮系統磁碟區資訊 (SVI) 目錄之磁碟區上的伺服器端點。
疏鬆檔案	完全支援	疏鬆檔案會同步 (不會封鎖)，但它們會以完整檔案的形式同步至雲端。 如果檔案內容在雲端中 (或另一部伺服器上) 有所變更，該檔案在變更下載之後就不再是疏鬆檔案。
替代資料流 (ADS)	已保留，但未同步	例如，不會同步「檔案分類基礎結構」所建立的分類標籤。 每個伺服器端點上檔案的現有分類標籤會原封不動。

Azure 檔案同步也會略過特定的暫存檔案和系統資料夾：

檔案/資料夾	注意
pagefile.sys	系統專用檔案
Desktop.ini	系統專用檔案
thumbs.db	縮圖的暫存檔案
ehthumbs.db	媒體暫存檔案的縮圖
~$*.*	Office 暫存檔
*.tmp	暫存檔案
*.laccdb	Access DB 鎖定檔案
635D02A9D91C401B97884B82B3BCDAEA.*	內部同步檔案
\System Volume Information	特定磁碟區的資料夾
$RECYCLE.BIN	Folder
\SyncShareState	同步處理的資料夾
.SystemShareInformation	Azure 檔案共用中用於同步的資料夾

考量本機磁碟上需要多少可用空間

規劃使用 Azure 檔案同步時，請考量您計劃包含伺服器端點的本機磁碟上，需要多少可用空間。

使用 Azure 檔案同步時，您必須考量下列各項在本機磁碟上佔用的空間：

• 如果啟用雲端階層處理：

  • 分層式檔案的重新分析點
  • Azure 檔案同步中繼資料資料庫
  • Azure 檔案同步熱存放區
  • 您熱快取中完整下載的檔案 (如果有的話)
  • 磁碟區可用空間原則需求

• 如果已停用雲端階層處理：

  • 完整下載的檔案
  • Azure 檔案同步熱存放區
  • Azure 檔案同步中繼資料資料庫

我們將使用範例來說明如何預估本機磁碟上所需的可用空間量。 假設您已在 Azure Windows VM 上安裝 Azure 檔案同步代理程式，並規劃在磁碟 F 上建立伺服器端點。您有 100 萬個檔案，而且想要將所有這些檔案分層 (10 萬個目錄且磁碟叢集大小為 4 KiB)。 磁碟大小為 1000 GiB。 您想要啟用雲端階層處理，並將磁碟區可用空間原則設定為 20%。

1. NTFS 會為每個分層檔案配置叢集大小。 100 萬個檔案 * 4 KiB 叢集大小 = 4,000,000 KiB (4 GiB)

   注意

   若要完全受益於雲端階層處理，建議使用較小的 NTFS 叢集大小 (小於64KiB)，因為每個分層檔案都會佔用叢集。 此外，分層檔案所佔用的空間會由 NTFS 所配置。 因此，它不會顯示在任何 UI 中。

2. 同步中繼資料會根據每個項目佔用叢集大小。 (100 萬個檔案 + 100,000 個目錄) * 4 KiB 叢集大小 = 4,400,000 KiB (4.4 GiB)
3. Azure 檔案同步熱存放區每個檔案會佔用 1.1 KiB。 100 萬個檔案 * 1.1 KiB = 1,100,000 KiB (1.1 GiB)
4. 磁碟區可用空間原則為 20%。 1000 GiB * 0.2 = 200 GiB

在此情況下，針對此命名空間，Azure 檔案同步將需要大約 209,500,000 KiB (209.5 GiB) 的空間。 將此數量與其他任何所需的額外可用空間相加，即可找出此磁碟所需的可用空間。

容錯移轉叢集

1. Azure 檔案同步的 [一般用途的檔案伺服器] 部署選項支援 Windows Server 容錯移轉叢集。 如需如何在容錯移轉叢集上設定檔案伺服器一般用途角色的詳細資訊，請參閱部署雙節點叢集檔案伺服器。
2. Azure 檔案同步唯一支援的案例是使用叢集磁碟的 Windows Server 容錯移轉叢集
3. 「適用於應用程式資料的向外延展檔案伺服器」(SOFS)、叢集共用磁碟區 (CSV) 或本機磁碟上不支援容錯移轉叢集。

重複資料刪除

Windows Server 2025、Windows Server 2022、Windows Server 2019 和 Windows Server 2016
不論在 Windows Server 2016、Windows Server 2019、Windows Server 2022 和 Windows Server 2025 的磁碟區上啟用或停用雲端階層處理，都支援重複數據刪除。 在已啟用雲端階層處理的磁碟區上啟用重複資料刪除，可讓您在內部部署中快取更多檔案，而不需佈建更多儲存空間。

在啟用雲端階層處理的磁碟區上啟用重復資料刪除時，伺服器端點位置內的重復資料刪除最佳化檔案將會根據雲端階層處理原則設定進行階層處理，與一般檔案類似。 當重復資料刪除最佳化檔案已進行階層處理，重復資料刪除垃圾收集工作將會自動執行，藉由移除磁碟區上其他檔案不再需要參考的區塊來回收磁碟空間。

請注意，磁碟區節省空間僅適用於伺服器；您在 Azure 檔案共用中的資料將不會進行重復資料刪除。

Windows Server 2012 R2
Azure 檔案同步不支援在 Windows Server 2012 R2 的相同磁碟區上進行重復資料刪除和雲端階層處理。 如果已在磁碟區上啟用重復資料刪除，則必須停用雲端階層處理。

注意事項

• 如果在安裝 Azure 檔案同步代理程式之前安裝重復資料刪除，則需要重新啟動，才能支援在相同磁碟區上進行重復資料刪除和雲端階層處理。

• 在啟用雲端階層處理之後，如果在磁碟區上啟用重復資料刪除，則初始重復資料刪除最佳化工作將會最佳化磁碟區上尚未進行階層處理的檔案，而且會對雲端階層處理產生下列影響：

  • 可用空間原則會根據磁碟區上的可用空間，使用熱度圖繼續對檔案進行階層處理。
  • 日期原則會略過檔案的階層處理，而這些檔案可能由於存取檔案的重復資料刪除最佳化作業而有資格進行階層處理。

• 針對進行中的重復資料刪除最佳化作業，如果檔案尚未進行階層處理，則重復資料刪除 MinimumFileAgeDays 設定會延遲以日期原則進行雲端階層處理。

  • 範例：如果 MinimumFileAgeDays 設定為 7 天，而雲端階層處理日期原則為 30 天，則日期原則會在 37 天後對檔案進行階層處理。
  • 注意：一旦 Azure 檔案同步對檔案進行階層處理，重復資料刪除最佳化工作就會略過該檔案。

• 如果安裝 Azure 檔案同步 代理程式的 Windows Server 2012 R2 伺服器升級至 Windows Server 2016、Windows Server 2019、Windows Server 2022 或 Windows Server 2025，則必須執行下列步驟以支援相同磁碟區上的重複數據刪除和雲端階層處理：

  • 解除安裝適用於 Windows Server 2012 R2 的 Azure 檔案同步代理程式，然後重新啟動伺服器。
  • 下載新伺服器操作系統版本的 Azure 檔案同步 代理程式（Windows Server 2016、Windows Server 2019、Windows Server 2022 或 Windows Server 2025）。
  • 安裝 Azure 檔案同步代理程式，並重新啟動伺服器。

  注意：解除安裝並重新安裝代理程式時，會保留伺服器上的 Azure 檔案同步組態設定。

分散式檔案系統 (DFS)

Azure 檔案同步支援與 DFS 命名空間 (DFS-N) 和 DFS 複寫 (DFS-R) 互通。

DFS 命名空間 (DFS-N)：DFS-N 實作完全支援 Azure 檔案同步。 您可以將 Azure 檔案同步代理程式安裝在一或多個檔案伺服器上，同步伺服器端點與雲端端點之間的資料，然後使用 DFS-N 提供命名空間服務。 如需詳細資訊，請參閱 DFS 命名空間概觀和使用 Azure 檔案儲存體的 DFS 命名空間。

DFS 複寫 (DFS-R)：因為 DFS-R 與 Azure 檔案同步都是複寫解決方案，建議您在大部分情況下，以 Azure 檔案同步取代 DFS-R。不過有幾個案例，您會想要一起使用 DFS-R 和 Azure 檔案同步：

• 您正要從 DFS-R 部署移轉至 Azure 檔案同步部署。 如需詳細資訊，請參閱將 DFS 複寫 (DFS-R) 部署移轉至 Azure 檔案同步。
• 並非需要檔案資料複本的每部內部部署伺服器都能直接連線到網際網路。
• 分支伺服器將資料合併到您要使用 Azure 檔案同步的單一中樞伺服器。

Azure 檔案同步和 DFS-R 如需並存使用：

1. 務必在具有 DFS-R 複寫資料夾的磁碟區上停用 Azure 檔案同步雲端階層。
2. 不應在 DFS-R 唯讀複寫資料夾上設定伺服器端點。
3. 只有單一伺服器端點可以與 DFS-R 位置重疊。 多個伺服器端點與其他作用中的 DFS-R 位置重疊可能會導致衝突。

如需詳細資訊，請參閱 DFS 複寫概觀。

Sysprep

不支援在已安裝 Azure 檔案同步代理程式的伺服器上使用 sysprep，而且此舉可能會導致非預期的結果。 請在部署伺服器映像和完成 sysprep 迷你設定之後，再進行代理程式安裝與伺服器註冊。

Windows 搜尋

如果在伺服器端點上啟用雲端階層處理，則系統會略過分層檔案，且 Windows 搜尋不會將這些檔案編製索引。 非階層式檔案則會正確編製索引。

其他階層式存放裝置管理 (HSM) 解決方案

不應該搭配 Azure 檔案同步使用其他 HSM 解決方案。

效能和延展性

由於 Azure 檔案同步代理程式會在連線至 Azure 檔案共用的 Windows Server 機器上執行，因此有效的同步效能將取決於基礎結構中的許多因素：Windows Server 和基礎磁碟組態、伺服器與 Azure 儲存體之間的網路頻寬、檔案大小、資料集大小總計，以及資料集的活動。 由於 Azure 檔案同步會在檔案層級上運作，因此 Azure 檔案同步解決方案的效能特性應以每秒處理的物件 (檔案和目錄) 數來測量，以獲得較精準的結果。

不會立即偵測及複寫使用 Azure 入口網站或 SMB 對 Azure 檔案共用所做的變更，和伺服器端點的變更不一樣。 Azure 檔案儲存體還沒有變更通知或日誌功能，因此無法在檔案變更時自動啟動同步工作階段。 在 Windows Server 上，Azure 檔案同步會使用 Windows USN 日誌，在檔案變更時自動啟動同步工作階段。

若要偵測 Azure 檔案共用的變更，Azure 檔案同步有個已排程的作業，稱為「變更偵測作業」。 變更偵測作業會列舉檔案共用的每個檔案，然後比較該檔案的同步版本。 當變更偵測作業判斷檔案已有變更時，Azure 檔案同步就會起始同步工作階段。 變更偵測作業會每隔 24 小時起始。 由於變更偵測作業的運作方式是列舉 Azure 檔案共用的每個檔案，大命名空間會比小命名空間耗費更長的時間。 大命名空間判斷哪些檔案已變更所耗費的時間，可能會超過 24 小時 (每隔 24 小時執行一次偵測作業)。

如需詳細資訊，請參閱 Azure 檔案同步效能計量和 Azure 檔案同步擴展目標

身分識別

Azure 檔案同步會使用您的標準 AD 型身分識別，不需要設定同步以外的任何特殊設定。當您使用 Azure 檔案同步時，一般預期是大部分的存取都會透過 Azure 檔案同步快取伺服器進行，而不是透過 Azure 檔案共用進行。 由於伺服器端點位於 Windows Server 上，而且 Windows Server 已有很長時間支援 AD 和 Windows 樣式 ACL，因此除了確保向儲存體同步服務註冊的 Windows 檔案伺服器已加入網域之外，不需要採取任何動作。 Azure 檔案同步會將 ACL 儲存在 Azure 檔案共用中的檔案，並將其複寫至所有伺服器端點。

即使直接對 Azure 檔案共用所做的變更需要更長時間才能同步至同步群組中的伺服器端點，您可能仍想要確保您也可以在雲端直接對您的檔案共用強制執行 AD 權限。 若要這樣做，您必須使用網域將儲存體帳戶加入至您的內部部署 AD，就像 Windows 檔案伺服器加入網域的方式一樣。 若要深入了解如何使用網域將您的儲存體帳戶加入至客戶所擁有的 Active Directory，請參閱 Azure 檔案儲存體 Active Directory 概觀。

網路

Azure 檔案同步代理程式會使用 Azure 檔案同步 REST 通訊協定和 FileREST 通訊協定，與您的儲存體同步服務和 Azure 檔案共用進行通訊，而這兩個通訊協定一律使用經由連接埠 443 的 HTTPS。 SMB 永遠不會用來在您的 Windows Server 與 Azure 檔案共用之間上傳或下載資料。 由於大部分的組織允許經由連接埠 443 的 HTTPS 流量，因此若要造訪大部分的網站，通常不需要特殊的網路組態，就能部署 Azure 檔案同步。

根據組織的原則或獨特的法規需求，您與 Azure 的通訊可能需要受到更多約束，因此 Azure 檔案共用提供了數種機制，供您設定網路功能。 根據您的需求，您可以：

• 透過 ExpressRoute 或 Azure VPN 進行通道同步和檔案上傳/下載流量。
• 利用 Azure 檔案儲存體和 Azure 網路功能，例如服務端點和私人端點。
• 設定 Azure 檔案同步，以在您的環境中支援您的 Proxy。
• 節流來自 Azure 檔案同步的網路活動。

若要深入了解 Azure 檔案同步和網路功能，請參閱 Azure 檔案同步網路功能考量。

加密

使用 Azure 檔案同步時，需要考慮三個不同層級的加密：在 Windows Server 的待用儲存體加密、在 Azure 檔案同步代理程式與 Azure 之間的傳輸中加密，以及在 Azure 檔案共用中資料的待用加密。

Windows Server 待用加密

有兩種策略通常會使用 Azure 檔案同步，在 Windows Server 上加密資料：檔案系統底下的加密，讓檔案系統及寫入其中的所有資料都會進行加密，以及檔案格式本身內的加密。 這些方法並不互斥；如有需要，您可以將它們搭配使用，因為加密的目的不同。

為了在檔案系統底下提供加密，Windows Server 提供 BitLocker 收件匣。 BitLocker 對於 Azure 檔案同步而言完全透明。使用 BitLocker 這類加密機制的主要原因，是為了防止有人竊取磁碟，實際洩漏內部部署資料中心的資料，以及防止側載未授權的作業系統來執行未授權的讀取/寫入。 若要深入了解 BitLocker，請參閱 BitLocker 概觀。

與 BitLocker 作用類似的第三方產品，由於位於 NTFS 磁碟區下方，應該也能以完全透明的方式使用 Azure 檔案同步。

另一個用於加密資料的主要方法，就是在應用程式儲存檔案時，加密檔案的資料流。 某些應用程式可能會以原生方式執行此動作，但通常不會發生這種情況。 加密檔案資料流的方法範例是 Azure 資訊保護 (AIP)/Azure Rights Management Services (Azure RMS)/Active Directory RMS。 使用加密機制 (例如 AIP/RMS) 的主要原因，是要防止有人將資料從檔案共用複製到其他位置 (例如快閃磁碟機)，或透過電子郵件傳送給未授權人員，而將資料洩漏出去。 當檔案的資料流已加密為檔案格式的一部分時，此檔案會繼續在 Azure 檔案共用上加密。

Azure 檔案同步無法與 NTFS 加密檔案系統 (NTFS EFS) 或位於檔案系統上但在檔案資料流下的第三方加密解決方案交互操作。

傳輸中加密

Azure 檔案同步代理程式會使用 Azure 檔案同步 REST 通訊協定和 FileREST 通訊協定，與您的儲存體同步服務和 Azure 檔案共用進行通訊，而這兩個通訊協定一律使用經由連接埠 443 的 HTTPS。 Azure 檔案同步不會透過 HTTP 傳送未加密的要求。

Azure 儲存體帳戶包含一個需要傳輸中加密 (預設為啟用) 的切換。 即使已停用儲存體帳戶層級的切換，這表示有可能以未加密的方式連線至 Azure 檔案共用，但 Azure 檔案同步仍然只會使用加密通道來存取您的檔案共用。

停用儲存體帳戶傳輸中加密的主要原因，是為了支援必須在舊版作業系統上執行的繼承應用程式，例如 Windows Server 2008 R2 或舊版 Linux 散發套件，直接與 Azure 檔案共用交談。 如果繼承應用程式與檔案共用的 Windows Server 快取交談，切換此設定將不會有任何作用。

我們強烈建議您確保傳輸中資料加密已啟用。

如需傳輸中加密的詳細資訊，請參閱在 Azure 儲存體中需要安全傳輸。

Azure 檔案共用的待用加密

使用 Azure 儲存體服務加密 (SSE) 將儲存在 Azure 檔案儲存體中的所有資料進行待用加密。 儲存體服務加密的運作方式與 Windows 上的 BitLocker 相似：資料會在檔案系統層級下加密。 由於資料是在 Azure 檔案共用的檔案系統下加密，因此當其編碼為磁碟時，不需要存取用戶端上的基礎金鑰，即可讀取或寫入 Azure 檔案共用。 待用加密同時適用於 SMB 和 NFS 通訊協定。

根據預設，儲存於 Azure 檔案儲存體中的資料是以使用 Microsoft 管理的金鑰加密。 使用 Microsoft 管理的金鑰時，Microsoft 會保存金鑰來加密/解密資料，並負責定期輪替。 您也可以選擇管理自己的金鑰，這可讓您控制輪替的程序。 如果您選擇使用客戶管理的金鑰來對檔案共用進行加密，則 Azure 檔案儲存體會獲授權存取您的金鑰，以滿足用戶端的讀取和寫入要求。 使用客戶管理的金鑰時，可以隨時撤銷此授權，但這表示您的 Azure 檔案共用將無法再透過 SMB 或 FileREST API 來進行存取。

Azure 檔案儲存體使用與其他 Azure 儲存體服務 (例如 Azure Blob 儲存體) 相同的加密配置。 如需深入了解 Azure 儲存體服務加密 (SSE) 的詳細資訊，請參閱待用資料的 Azure 儲存體加密。

儲存層

Azure 檔案儲存體 提供兩種不同的媒體層記憶體 SSD 和 HDD，可讓您根據案例的效能和價格需求量身打造共用：

• SSD （進階版）：固態硬碟使用進階檔案共用，併為大部分 IO 作業提供一致的高效能和低延遲，對於 IO 密集工作負載，在單位數毫秒內。 進階檔案共用適合各種不同的工作負載，例如資料庫、網站託管以及開發環境等等。 進階檔案共用可以同時與伺服器訊息 (SMB) 和網路檔案系統 (NFS) 通訊協定搭配使用。 進階檔案共用以 FileStorage 儲存體帳戶類型進行部署，而且僅適用於已佈建的計費模型。 如需進階檔案共用佈建計費模型的詳細資訊，請參閱了解如何佈建進階檔案共用。 進階檔案共用提供比標準檔案共用更高的可用性 SLA（請參閱。

• HDD （標準）：標準檔案共用使用硬碟（HDD），併為一般用途的檔案共用提供符合成本效益的儲存選項。 標準檔案共用會部署在 一般用途第 2 版 （GPv2） 記憶體帳戶 種類中。 如需 SLA 的相關信息，請參閱 Azure 服務等級協定頁面 （請參閱。 標準檔案共用會使用提供使用量型定價的隨用隨付模型。 檔案 共用的存取層 可讓您根據 IOPS 成本調整記憶體成本，以優化總帳單：

  • 交易優化 檔案共用針對不需要進階檔案共用所提供的低延遲的交易繁重工作負載，提供最低的成本交易價格。 將數據遷移至 Azure 檔案儲存體 時建議。
  • 經常性 檔案共享會針對同時具有良好測量值的工作負載，提供平衡的記憶體和交易定價。
  • 非經常 性存取檔案共享為記憶體密集型工作負載提供最符合成本效益的記憶體定價。

選取工作負載的媒體層時，請考慮您的效能和使用需求。 如果您的工作負載需要單一位數的延遲，或您使用 SSD 記憶體媒體內部部署，則進階層可能最適合。 如果低延遲不是最重要的考慮 (例如，從 Azure 裝載了內部部署的小組共用，或使用 Azure 檔案同步在內部部署環境中進行快取)，則以成本的觀點來看，標準儲存體可能更適合。

在記憶體帳戶中建立檔案共享之後，就無法將它移至不同記憶體帳戶類型專屬的階層。 例如，若要將交易最佳化的檔案共用移至進階層，則必須在 FileStorage 儲存體帳戶中建立新的檔案共用，並將資料從原始共用複製到 FileStorage 帳戶中的新檔案共用。 我們建議使用 AzCopy 在 Azure 檔案共用之間複製資料，但是也可以使用 Windows 上的 robocopy 或 macOS 和 Linux 的 rsync 等工具進行複製。

如需詳細資訊，請參閱了解 Azure 檔案儲存體計費。

Azure 檔案同步 區域可用性

如需區域可用性的詳細資訊，請參閱依區域提供的產品。

下列區域需要您先要求 Azure 儲存體的存取權，才能在其中使用 Azure 檔案同步：

• 法國南部
• 南非西部
• 阿拉伯聯合大公國中部

若要要求這些區域的存取權，請依照本文件中的程序操作。

備援

為了保護 Azure 檔案共用中的資料，避免資料遺失或損毀，Azure 檔案儲存體會在寫入時儲存每個檔案的多個複本。 根據您的需求，您可以選取不同程度的備援。 Azure 檔案儲存體目前支援下列資料備援選項：

• 本地備援儲存體 (LRS)：使用 LRS 時，每個檔案會在 Azure 儲存體叢集內儲存三次。 這可防止因為硬體錯誤 (例如磁碟機損壞) 而遺失資料。 不過，如果在資料中心內發生火災或洪水之類的災害，則所有使用 LRS 的儲存體帳戶複本可能都會失去或無法復原。
• 區域備援儲存體 (ZRS)：使用 ZRS 時，每個檔案會儲存三個複本。 不過，這些複本會實際隔離在不同 Azure 可用性區域中的三個不同儲存體叢集。 可用性區域是 Azure 地區內獨特的實體位置。 每個區域皆由一或多個配備獨立電源、冷卻系統及網路的資料中心組成。 直到寫入所有三個可用性區域中的儲存體叢集後，才會接受對儲存體的寫入。
• 異地複寫儲存體 (GRS)：使用 GRS 時，您會有兩個區域，一個主要區域和一個次要區域。 檔案會在主要區域的 Azure 儲存體叢集中儲存三次。 寫入會以非同步方式複寫到 Microsoft 定義的次要區域。 GRS 提供六個資料複本，分散在兩個 Azure 區域之間。 在嚴重損壞的情況下 (例如因為自然災害或其他類似事件而永久遺失 Azure 區域)，Microsoft 將會執行容錯移轉。 在此情況下，讓次要區域會成為主要區域，為所有作業提供服務。 由於主要與次要區域之間的複寫是非同步的，在嚴重損壞的情況下，尚未複寫到次要區域的資料將會遺失。 您也可以執行異地備援儲存體帳戶的手動容錯移轉。
• 異地區域備援儲存體 (GZRS)：您可以將 GZRS 想成是 ZRS，但使用異地備援。 使用 GZRS 時，檔案會在主要區域中的三個不同儲存體叢集之間儲存三次。 接著，所有寫入都會以非同步方式複寫到 Microsoft 定義的次要區域。 GZRS 的容錯移轉運作方式與 GRS 相同。

最多 5 TiB 的標準 Azure 檔案共用可支援四個備援類型。 大於 5 TiB 的標準檔案共用僅支援 LRS 和 ZRS。 進階版 Azure 檔案共用僅支援 LRS 和 ZRS。

一般用途版本 2 (GPv2) 儲存體帳戶提供 Azure 檔案儲存體不支援的兩個其他備援選項：可讀取的異地備援儲存體 (RA-GRS)，以及可讀取的異地區域備援儲存體 (RA-GZRS)。 您可以在已設定這些選項的儲存體帳戶中佈建 Azure 檔案共用，不過 Azure 檔案儲存體不支援從次要區域讀取。 部署至 RA-GRS 或 RA-GZRS 儲存體帳戶的 Azure 檔案共用會分別以 GRS 或 GZRS 來計費。

遷移

如果您有現有的 Windows 檔案伺服器 2012R2 或更新版本，Azure 檔案同步可以直接安裝，而不需要將資料移至新的伺服器。 如果您打算在採用 Azure 檔案同步的過程中遷移至新的 Windows 檔案伺服器，或您的資料目前位於網路連接儲存裝置 (NAS)，有幾種可能的移轉方法可對此此資料使用 Azure 檔案同步。 您應該選擇哪一個移轉方法，取決於您資料目前所在的位置。

如需詳細指導，請參閱 Azure 檔案同步和 Azure 檔案共用移轉概觀文章。

防毒

因為防毒程式的運作方式是掃描檔案中的已知惡意程式碼，所以防毒產品可能會導致階層式檔案的重新叫用，進而產生高輸出費用。 分層檔案已設定安全的 Windows 屬性 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS，建議您洽詢您的軟體廠商，以了解如何設定其解決方案來略過讀取已設定此屬性的檔案 (很多軟體會自動這麼做)。

作為 Microsoft 內部防毒解決方案的 Windows Defender 和 System Center Endpoint Protection (SCEP)，皆會自動略過讀取已設定此屬性的檔案。 我們已經測試這兩個解決方案並找到一個小問題：當您將伺服器新增至現有同步群組時，會在新的伺服器上重新叫用 (下載) 小於 800 個位元組的檔案。 這些檔案會保留在新的伺服器上，而且不會分層，因為這些檔案不符合階層處理大小需求 (> 64kb)。

Backup

如果已啟用雲端階層處理，則不應使用直接備份伺服器端點的解決方案或伺服器端點所在的 VM。 雲端階層處理只會在伺服器端點上儲存您的資料子集，並將完整資料集放在您的 Azure 檔案共用中。 視所使用的備份解決方案而定，分層檔案可能會略過並且不會備份 (因為已設定 FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS 屬性)，或是可能會將其重新叫用到磁碟，因而產生高輸出費用。 我們建議使用雲端備份解決方案來直接備份 Azure 檔案共用。 如需詳細資訊，請參閱關於 Azure 檔案共用備份，或連絡您的備份提供者，查看是否支援備份 Azure 檔案共用。

如果您偏好使用內部部署備份解決方案，則應該在已停用雲端階層處理的同步群組中，對其中的某個伺服器執行備份，並確定沒有任何分層檔案。 執行還原時，請使用磁碟區層級或檔案層級的還原選項。 使用檔案層級還原選項進行還原的檔案會同步至同步群組中的所有端點，並使用從備份還原過來的版本取代現有檔案。 磁碟區層級還原將不會取代 Azure 檔案共用或其他伺服器端點中的較新檔案版本。

資料分類

如果您已安裝資料分類軟體，啟用雲端階層處理可能會因為下列兩個原因而導致成本增加：

1. 在啟用雲端階層處理的情況下，您最常使用的檔案會在本機快取，而最不常使用的檔案則會分層到雲端中的 Azure 檔案共用。 如果您的資料分類會定期掃描檔案共用中的所有檔案，則必須在每次掃描時重新叫用分層到雲端的檔案。

2. 如果資料分類軟體使用檔案資料流程的中繼資料，則必須完全重新叫用檔案，軟體才能看到分類。

這會增加重新叫用次數，而重新叫用的資料量可能會提高成本。

Azure 檔案同步代理程式更新原則

Azure 檔案同步代理程式會定期更新，以新增功能和解決問題。 建議您更新 Azure 檔案同步代理程式，因為已有新版本可用。

主要與次要代理程式版本

• 主要代理程式版本通常會包含新功能，且會使用遞增的數字作為版本號碼的第一個部分。 例如：17.0.0.0
• 次要代理程式版本也稱為「修補」，且會比主要版本更常發行。 它們通常包含錯誤修正和小幅改善，但是沒有任何新功能。 例如：17.2.0.0

升級路徑

有五個經核准及測試的方式，可用來安裝 Azure 檔案同步代理程式更新。

1. 使用 Azure 檔案同步代理程式的自動升級功能安裝代理程式更新。 Azure 檔案同步代理程式會自動升級。 您可以選擇安裝已推出的最新版本的代理程式，或在目前安裝的代理程式即將到期時，再行更新。 若要深入瞭解，請參閱自動代理程式生命週期管理。
2. 設定 Microsoft Update 自動下載並安裝代理程式更新。 建議安裝所有 Azure 檔案同步更新，以確保您可存取伺服器代理程式的最新修正程式。 Microsoft Update 會為您自動下載和安裝更新，讓這個程序順暢進行。
3. 使用 AfsUpdater.exe 下載並安裝代理程式更新。 AfsUpdater.exe 位於代理程式安裝目錄中。 按兩下可執行檔，即可下載並安裝代理程式的更新。 視發行版本而定，您可能需要重新啟動伺服器。
4. 使用 Microsoft Update 修補檔或 .msp 可執行檔修補現有的 Azure 檔案同步代理程式。 您可以從 Microsoft Update 目錄下載最新的 Azure 檔案同步更新套件。 執行 .msp 可執行檔會使用與 Microsoft Update 自動使用的相同方法升級 Azure 檔案同步安裝。 套用 Microsoft Update 修補程式將會執行 Azure 檔案同步安裝的就地升級。
5. 從 Microsoft 下載中心下載最新的 Azure 檔案同步代理程式安裝程式。 若要升級現有的 Azure 檔案同步代理程式安裝，請將舊版解除安裝，然後從所下載的安裝程式安裝最新版本。 Azure 檔案同步安裝程式會維護伺服器註冊、同步群組和任何其他設定。

自動代理程式生命週期管理

Azure 檔案同步代理程式會自動升級。 您可以選取兩種模式的其中一種，並指定要在伺服器上嘗試升級的維護時段。 這項功能的設計目的是為了協助您進行代理程式生命週期管理，也就是提供保護措施，讓您的代理程式不致於過期或輕鬆保持最新的設定。

1. 預設設定會嘗試防止代理程式過期。 在代理程式張貼到期日的 21 天內，代理程式將會嘗試自我升級。 代理程式會在到期前的 21 天內，以及在選取的維護時段開始嘗試一週升級一次。 此選項不會消除定期使用 Microsoft Update 修補檔的需求。
2. 您可以選擇性地選取在新的代理程式版本成為可用時 (目前不適用於叢集伺服器)，代理程式將會自動升級。 這項更新會在選取的維護時段發生，並可讓您的伺服器在新功能正式發行後立即受益於這些新功能和增強功能。 這是建議的輕鬆設定，可提供主要的代理程式版本，以及伺服器的定期更新修補檔。 每個發行的代理程式都是 GA 品質。 如果您選取此選項，Microsoft 會將最新代理程式版本的發行小眾測試版提供給您。 已排除叢集伺服器。 正式發行前小眾測試完成後，代理程式也將可在 Microsoft Update 和 Microsoft 下載中心上取得。

變更自動升級設定

下列指示說明如何在您完成安裝程式之後變更設定 (如果您需要進行變更)。

開啟 PowerShell 主控台並瀏覽至您安裝同步代理程式的目錄，然後匯入伺服器 Cmdlet。 依預設，這會看起來像這樣：

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

您可以執行 Get-StorageSyncAgentAutoUpdatePolicy 以檢查目前的原則設定，並判斷是否要予以變更。

若要將目前的原則設定變更為延遲更新追蹤，您可以使用：

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

若要將目前的原則設定變更為立即更新追蹤，您可以使用：

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

代理程式生命週期和變更管理保證

Azure 檔案同步是一項雲端服務，持續推出新功能和增強功能。 這表示特定的 Azure 檔案同步代理程式版本只會支援一段有限的時間。 為了簡化您的部署，下列規則保證您有足夠的時間和通知，可容納變更管理程序中的代理程式更新/升級：

• 主要代理程式版本從初始發行日期算起會獲得至少六個月的支援。
• 我們保證主要代理程式版本之間的支援至少有三個月的重疊。
• 系統會在到期至少三個月之前，使用即將到期代理程式向已註冊的伺服器發出警告。 您可以在儲存體同步服務的已註冊伺服器區段之下，檢查已註冊的伺服器是否使用舊版的代理程式。
• 次要代理程式版本的存留期會繫結至相關聯的主要版本。 例如，當代理程式 17.0.0.0 版設定為過期時，代理程式 17.*.*.* 版全都會設定為同時過期。

下一步

• 考量防火牆和 Proxy 設定
• 部署 Azure 檔案服務
• 部署 Azure 檔案同步
• 監視 Azure 檔案同步