本文檔介紹解決方案的體系結構和設計注意事項，該解決方案提供優(yōu)化方法來備份和還原 Azure Stack 集線器上托管的基于 VM 的用戶工作負荷的文件和應用程序。
下載此體系結構的 Visio 文件。
備份和還原是任何全面的業(yè)務連續(xù)性和災難恢復策略的基本組成部分。 在混合環(huán)境中設計和實現(xiàn)一致且可靠的備份方法很有挑戰(zhàn)性，但可以通過與 Microsoft Azure 提供的服務進行集成來大大簡化。 這不僅適用于在傳統(tǒng)的本地基礎結構上運行的工作負荷，還適用于由第三方公有和私有云提供商托管的工作負荷。 但是，當混合環(huán)境結合 Azure Stack 組合產(chǎn)品（包括 Azure Stack 中心）時，與 Azure 云服務集成的好處特別明顯。
盡管 Azure Stack 集線器的主要優(yōu)點之一是它支持平臺即服務 (PaaS) 模型，但它還可幫助客戶將現(xiàn)有的基礎結構即服務 (IaaS) 工作負荷。 此類工作負荷可能包括文件共享、Microsoft SQL Server 數(shù)據(jù)庫、Microsoft SharePoint 場和 Microsoft Exchange Server 群集。 將這些虛擬機遷移到超聚合上運行的高復原群集上運行的 Vm，具有與 Microsoft Azure 一致的管理和編程模型，從而最大程度地減少管理和維護開銷。
為了實現(xiàn) Azure 集線器 Stack Vm 上運行的文件和應用程序的備份，Microsoft 建議使用一種混合方法，該方法依賴于云和本地組件的組合來提供可縮放、高性能、彈性、安全、直接管理和經(jīng)濟高效的備份解決方案。 此解決方案的核心組件是 Microsoft Azure 備份 Server (MABS) v3，這是 Azure 備份產(chǎn)品的一部分。 MABS 依賴于用于計算、網(wǎng)絡和短期存儲資源的 Azure Stack 集線器基礎結構，同時利用基于 Azure 的存儲作為長期備份存儲。 這可以最大程度地減少或消除維護物理備份介質（如磁帶）的需要。
備注
MABS 基于 (DPM) Microsoft System Center Data Protection Manager，并提供類似的功能，只需幾個差異。 但是，不支持將 DPM 與 Azure Stack 中心一起使用。
云組件包括以下服務：
托管此解決方案中包含的所有云資源的 Azure 訂閱。
與 Azure 訂閱關聯(lián)的 Azure Active Directory (Azure AD) 租戶，它提供 Azure AD 安全主體的身份驗證，以授權對 Azure 資源的訪問權限。
Azure 區(qū)域中的 Azure 恢復服務保管庫，最靠近將托管 Azure Stack 中心部署的本地數(shù)據(jù)中心。
根據(jù)本文檔中所述的條件，云組件還可能包括以下服務：
本地數(shù)據(jù)中心與托管 Azure 恢復服務保管庫的 Azure 區(qū)域之間的 Azure ExpressRoute 線路，配置了 Microsoft 對等互連以容納更大的備份大小。
Azure 導入/導出服務，用于啟用 MABS 脫機備份到 Azure。
備注
到08/20，MABS 使用 Azure Data Box 脫機備份到 Azure 是預覽版。
根據(jù)使用 Azure 導入/導出服務將 MABS 脫機備份到 Azure，解決方案可能還會在與恢復服務保管庫相同的 Azure 區(qū)域中創(chuàng)建一個 Azure 存儲帳戶。
本地組件包括以下服務：
連接的部署模型中的 Azure Stack 集線器–集成系統(tǒng)，運行當前更新 (2002 到8月 2020) ，位于客戶的本地數(shù)據(jù)中心內。
Windows Server 2016 或 Windows Server 2019 VM 由 Azure Stack 集線器–集成系統(tǒng)并運行 MABS v3 更新版本 (UR) 1。
Azure Stack 集線器 Vm，其中包含 MABS 保護代理，該代理管理 MABS Azure Stack 中心 VM 的備份和還原。 MABS 保護代理跟蹤受保護工作負荷的更改，并將更改傳輸?shù)?MABS 數(shù)據(jù)存儲。 保護代理還標識其本地計算機上可受保護的數(shù)據(jù)，并在恢復過程中扮演角色。
在運行 MABS 的服務器上安裝 Microsoft Azure 恢復服務 (MARS) 代理，提供 MABS 和 Azure 恢復服務保管庫之間的集成。
備注
MARS 代理也稱為 Azure 備份代理。
建議的解決方案支持以下功能：運行 Windows Server 2019、2016、2012 R2、2012、2008 R2 SP1 (64 Azure Stack 集線器 Vm、Windows Management Framework 4.0) 、2008 SP2 (64 Windows Management Framework 4.0) 和 Windows 10 (64) ：
備份和還原新的技術文件系統(tǒng) (NTFS) 和復原文件系統(tǒng) (ReFS) 卷、共享、文件夾、文件和系統(tǒng)狀態(tài)。
備份和還原 SQL Server 2019、2017、2016 (與所需的 service pack [SPs] ) 和 2014 (以及所需的 Sp) 實例及其數(shù)據(jù)庫。
備份和還原 Exchange Server 2019 和 Exchange Server 2016 服務器和數(shù)據(jù)庫，包括數(shù)據(jù)庫可用性組中的獨立服務器和數(shù)據(jù)庫 (DAG) 。
在 DAG 中還原單個郵箱和郵箱數(shù)據(jù)庫。
通過最新的 Sp) 場和前端 web 服務器內容，備份和還原 SharePoint 2019 和 SharePoint 2016 (。
還原 SharePoint 2019 和 SharePoint 2016 數(shù)據(jù)庫、web 應用程序、文件、列表項和搜索組件。
備注
若要在 Azure Stack Hub 上部署 Windows 10 客戶端操作系統(tǒng)，則必須具有 Windows 每用戶許可，或已通過合格的多租戶宿主 (QMTH) 購買了該操作系統(tǒng)。
MABS 實現(xiàn)了磁盤到磁盤到云 (D2D2C) 備份方案，主備份本地存儲在承載 MABS 安裝的服務器上。 然后，本地備份將復制到 Azure Site Recovery 保管庫中。 本地磁盤的作用是短期存儲，而保管庫則提供長期存儲。
備注
與 DPM 不同，MABS 不支持磁帶備份。
在高級別中，備份過程包含以下四個階段：
在要保護的計算機上安裝 MABS 保護代理，并將其添加到保護組。
為計算機或其應用設置保護，包括備份到 MABS 本地磁盤以進行短期存儲，并設置為適用于長期存儲的 Azure。 作為設置的一部分，你可以為這兩種類型的備份指定備份計劃。
受保護的工作負荷根據(jù)指定的計劃備份到本地 MABS 磁盤。
MABS 磁盤上存儲的本地備份通過 MABS 服務器上運行的 MARS 代理備份到 Azure 恢復服務保管庫。
實現(xiàn)推薦的解決方案是為了滿足以下先決條件：
訪問 Azure 訂閱，其權限足以在 Azure 區(qū)域中預配 Azure 恢復服務保管庫，該存儲庫離托管 Azure Stack 中心部署的本地數(shù)據(jù)中心。
可從將托管 MABS 實例的 Azure Stack 中心 VM 訪問 AD DS) 域 (的 Active Directory 域服務。
一個 Azure Stack 中心承載的 VM，它將運行 MABS 實例，滿足在 Azure Stack 上安裝 Azure 備份服務器 中列出的先決條件，以及與 DPM/MABS 網(wǎng)絡支持中列出的 url 的出站連接。
備注
本文檔稍后將更詳細地介紹了 MABS 的額外磁盤空間和性能注意事項。
備注
若要驗證托管 MABS 的 VM 是否已連接到 Azure 備份服務，可以使用 Azure 備份服務器 PowerShell 模塊) 中包含的 DPMCloudConnection (cmdlet。
備注
MABS 還需要 SQL Server 的本地實例。 有關 SQL Server 要求的詳細信息，請參閱 安裝和升級 Azure 備份服務器。
Azure Stack 中心通過其基礎結構的固有復原能力，有助于提高工作負荷的可用性。 你可以通過設計和實現(xiàn)解決方案來進一步提高此可用性的程度，目的是擴展工作負荷保護的范圍。 這是 MABS 提供的附加值。 在 Azure Stack Hub 上運行的 MABS 的上下文中，需要更詳細地探討可用性的兩個方面：
MABS 及其數(shù)據(jù)存儲的可用性
MABS 保護的工作負荷的時間點還原功能的可用性
開發(fā)備份策略時，需要考慮兩個這兩個方案 (Rpo) 和恢復時間目標 (Rto) 。 RTO 和 RPO 代表組織內的各個業(yè)務功能規(guī)定的連續(xù)性需求。 RPO 指定一個時間段，該時間段表示受該數(shù)據(jù)的可用性影響的事件后可接受的最大數(shù)據(jù)丟失量。 RTO 指定可接受的最長持續(xù)時間，以便在影響這些功能可用性的事件后恢復業(yè)務職能。
備注
通常，若要解決 Azure Stack 集線器工作負載的 RTO 要求，應考慮到 Azure Stack 基礎結構、用戶 Vm、應用程序和用戶數(shù)據(jù)的恢復。 在此參考體系結構文檔的上下文中，我們只對這兩個組件中的最后兩個應用程序和用戶數(shù)據(jù)感興趣-盡管我們還提供了有關新式備份存儲 (MB) 功能的可用性的注意事項。
MABS 及其數(shù)據(jù)存儲可用性依賴于托管 MABS 安裝的 VM 的可用性及其本地和基于云的存儲。 Azure Stack 中心 Vm 在設計上是高度可用的。 如果 MABS 發(fā)生故障，你可以從任何其他 Azure Stack 中心 VM 托管 MABS 恢復 Azure 備份保護的項。 但請注意，對于托管 MABS 的服務器，若要恢復通過在另一臺服務器上運行的 MABS 執(zhí)行的備份，則必須使用相同的 Azure Site Recovery 保管庫注冊這兩臺服務器。
備注
通常，你可以部署 MABS 的另一個實例并將其配置為備份主要 MABS 部署，這類似于使用 DPM 時可用的主對輔助保護、鏈接和循環(huán)保護配置。 但是，MABS 不支持此方法，在此參考體系結構文檔中所述的方案中，它不會產(chǎn)生有意義的可用性優(yōu)勢。
MABS 保護的工作負荷的時間點還原功能取決于數(shù)據(jù)類型、備份和保護策略的大范圍。 若要了解這些依賴關系，必須更詳細地了解這些概念。
從 MABS 的角度來看，需要考慮兩種數(shù)據(jù)類型：
文件數(shù)據(jù) 是通常駐留在文件服務器上的數(shù)據(jù) (如 Microsoft Office 文件、文本文件或媒體文件) ，需要將這些數(shù)據(jù)作為平面文件進行保護。
應用程序數(shù)據(jù) 是應用程序服務器 (的數(shù)據(jù)，例如 Exchange 存儲組、SQL Server 數(shù)據(jù)庫或 SharePoint 場) ，這需要 MABS 知道相應的應用程序要求。
備注
作為使用 MABS 進行文件數(shù)據(jù)備份的替代方法，可以直接在 Azure Stack 中心 Vm 上安裝 MABS 代理，并將其本地文件系統(tǒng)直接備份到 Azure 恢復服務保管庫。 但是，與 MABS 不同，此方法不提供集中管理，并且始終依賴基于云的存儲進行備份和還原。
無論是保護文件數(shù)據(jù)還是應用程序數(shù)據(jù)，保護都首先在 MABS 實例的本地存儲中創(chuàng)建數(shù)據(jù)源的副本。 副本將按照你配置的設置定期同步或更新。 MABS 用于同步副本的方法取決于受保護的數(shù)據(jù)的類型。 如果將某個副本標識為不一致，則 MABS 將執(zhí)行一致性檢查，這是針對數(shù)據(jù)源的副本逐塊驗證。
對于服務器上的文件卷或共享，在初始完整備份之后，MABS protection 代理使用卷篩選器并更改日志來確定哪些文件已更改。 然后，它對這些文件執(zhí)行校驗和過程，以僅同步已更改的塊。 在同步過程中，這些更改將傳輸?shù)?MABS，然后應用于副本，從而將副本與數(shù)據(jù)源同步。
如果副本變得與其數(shù)據(jù)源不一致，MABS 會生成一個警報，該警報指定哪一臺計算機和哪些數(shù)據(jù)源受到影響。 若要解決此問題，可以通過對副本啟動一致性同步檢查來修復副本。 在一致性檢查過程中，MABS 執(zhí)行逐塊驗證，并修復副本以使其與數(shù)據(jù)源保持一致。 你可以為保護組計劃每日一次的一致性檢查，也可以手動發(fā)起一致性檢查。
MABS 會定期為受保護的數(shù)據(jù)源創(chuàng)建恢復點。 恢復點 是可以恢復的數(shù)據(jù)的版本。
對于應用程序數(shù)據(jù)，在 MABS 創(chuàng)建副本之后，卷篩選器會跟蹤對屬于應用程序文件的卷塊所做的更改。 將更改傳輸?shù)?MABS 服務器的方式取決于應用程序和同步的類型。 在 MABS 管理員控制臺中標記為 " 同步 " 的操作類似于增量備份，并且在與副本結合使用時，它將創(chuàng)建應用程序數(shù)據(jù)的事務一致、準確的反射。
在 MABS 管理員控制臺中標記為 " 快速完整備份 " 的同步類型時，會創(chuàng)建完整的卷影復制服務 (VSS) 快照，但僅將更改的塊傳輸?shù)?MABS 服務器。
每次快速完整備份都會為應用程序數(shù)據(jù)創(chuàng)建一個恢復點。 如果應用程序支持增量備份，則每次同步也將創(chuàng)建一個恢復點。 同步過程依賴于應用程序：
對于 Exchange 數(shù)據(jù)，同步將使用 Exchange VSS 編寫器傳輸增量 VSS 快照。 為每個同步和每個快速完整備份創(chuàng)建恢復點。
對于日志傳送、處于只讀模式或者使用簡單恢復模式 SQL Server 數(shù)據(jù)庫，不支持增量備份。 僅在每次快速完整備份時創(chuàng)建恢復點。 對于所有其他 SQL Server 數(shù)據(jù)庫，同步將傳輸事務日志備份，并在每次增量同步和快速完整備份時創(chuàng)建恢復點。 事務日志是指從上次備份事務日志以來對數(shù)據(jù)庫執(zhí)行的所有事務的連續(xù)記錄。
SharePoint 服務器不支持增量備份。 僅在每次快速完整備份時創(chuàng)建恢復點。
增量同步所需的時間比快速完整備份少。 但是，隨著同步次數(shù)的增加，恢復數(shù)據(jù)所需的時間也在增加。 這是因為，MABS 必須還原上次完整備份，然后還原并應用所有增量同步，直至所選的恢復時間點為止。
若要實現(xiàn)更快的恢復時間，MABS 會定期執(zhí)行快速完整備份，這將更新副本以包括已更改的塊。 在快速完整備份期間，MABS 會先拍攝副本的快照，然后再使用更改的塊更新副本。 為了實現(xiàn)更頻繁的 Rpo 并減少數(shù)據(jù)丟失時段，MABS 還會在兩次快速完整備份之間執(zhí)行增量同步。
與文件數(shù)據(jù)保護一樣，如果副本變得與其數(shù)據(jù)源不一致，MABS 會生成一個警報，該警報指定哪些服務器和哪些數(shù)據(jù)源受到影響。 若要解決不一致問題，可以通過對副本啟動一致性同步檢查來修復副本。 在一致性檢查過程中，MABS 將對副本執(zhí)行逐塊驗證，并修復該副本以使其重新與數(shù)據(jù)源保持一致。 你可以為保護組計劃每日一次的一致性檢查，也可以手動發(fā)起一致性檢查。
在計算機上安裝 MABS 保護代理軟件并將其數(shù)據(jù)添加到保護組時，計算機或其工作負荷將受到保護。 保護組用于配置和管理對計算機上的數(shù)據(jù)源的保護。 “保護組”是一組共享相同保護配置的數(shù)據(jù)源。 保護配置 是保護組共有的設置集合，例如保護組名稱、保護策略、存儲分配和副本創(chuàng)建方法。
MABS 在存儲池中存儲每個保護組成員的單獨副本。 保護組成員可以包含以下數(shù)據(jù)源：
文件服務器或服務器群集上的卷、共享或文件夾。
Exchange 服務器或服務器群集的存儲組。
SQL Server 或服務器群集的實例的數(shù)據(jù)庫。
根據(jù)為該保護組設置的恢復目標，為每個保護組配置保護策略。 恢復目標 代表與組織的 Rto 和 rpo 相對應的數(shù)據(jù)保護要求。 在 MABS 中，它們是根據(jù)以下參數(shù)的組合定義的：
短期保留范圍。 這會確定要在本地 MABS 存儲上保留備份數(shù)據(jù)的時間。
同步和恢復點頻率。 這與數(shù)據(jù)丟失容錯直接對應，后者又反映了組織的 Rpo。 它還通過收集數(shù)據(jù)更改來確定 MABS 應將其本地副本與受保護的數(shù)據(jù)源同步的頻率。 可以將同步頻率設置為介于15分鐘到24小時之間的任意時間間隔。 你還可以選擇在創(chuàng)建恢復點之前進行同步，而不是按指定的時間計劃進行同步。
短期恢復點計劃。 這會確定應該在本地存儲中為保護組創(chuàng)建多少恢復點。 對于文件保護，可選擇希望創(chuàng)建恢復點的日期和時間。 對于支持增量備份的應用程序數(shù)據(jù)保護，同步頻率決定了恢復點計劃。
快速完整備份計劃。 對于不支持增量備份的應用程序的數(shù)據(jù)保護，以及是否支持快速完整備份，這將決定恢復點計劃。
聯(lián)機備份計劃。 這會確定在與本地 MABS 實例關聯(lián)的 Azure 恢復服務保管庫中創(chuàng)建本地備份副本的頻率。 您可以按每天、每周、每月或每年的頻率來計劃計劃，每日最多允許執(zhí)行兩次備份的頻率。 MABS 會自動使用最近的本地副本創(chuàng)建用于聯(lián)機備份的恢復點，而不會傳輸受保護數(shù)據(jù)源的新數(shù)據(jù)。
備注
恢復服務保管庫支持最多9999個恢復點。
在線保留策略。 這會指定時間段，在此期間，每日、每周、每月和每年備份將保留在與本地 MABS 實例關聯(lián)的 Azure Site Recovery 保管庫中。
備注
若要聯(lián)機保護數(shù)據(jù)源的最新內容，請在創(chuàng)建在線恢復點之前在本地磁盤上創(chuàng)建新的恢復點。
備注
默認情況下，Azure 恢復服務保管庫是 異地冗余 的，這意味著復制到其存儲的任何備份都將自動復制到屬于預定義區(qū)域對的 Azure 區(qū)域。 如果復制設置足以滿足復原需求，并且需要將存儲成本降至最低，則可以選擇將這些設置更改為 "本地冗余"。 但是，您應考慮保留默認設置。 此外，請記住，如果保管庫包含任何受保護的項，則不能更改此選項。
備注
有關 Azure 區(qū)域對的列表，請參閱 業(yè)務連續(xù)性和災難恢復 (BCDR) ： Azure 配對區(qū)域。
計劃在 Azure Stack 集線器上部署 MABS 時，需要考慮分配給 VM (的處理、存儲和網(wǎng)絡資源量，以及托管部署的 Vm) 。 Microsoft 建議分配 2.33 ghz (GHz) 四核 CPU，以滿足 MABS 處理需求，大約 10 GB 磁盤空間可容納安裝二進制文件。 其他存儲要求可以分為以下幾類：
備份所用的磁盤空間。 備份磁盤空間的一般建議是分配一個與要備份的所有數(shù)據(jù)的大小約1.5 倍的存儲池磁盤空間。 將磁盤附加到 VM 后，MABS 會管理卷和磁盤空間管理。 可附加到 VM 的磁盤的數(shù)目取決于其大小。
備注
不應將備份存儲在本地，超過五天。 早于5天的備份應卸載到 Azure Site Recovery 保管庫中。
MARS 代理緩存位置的磁盤空間。 請考慮在托管 MABS 安裝的 VM 上使用驅動器 C 。
還原期間本地臨時區(qū)域的磁盤空間。 請考慮使用托管 MABS 安裝的 VM 上的臨時驅動器 D 。
若要為托管 MABS 安裝的 VM 設置存儲，請使用具有高級性能層的托管磁盤。 預期性能特征為每秒2300個 i/o 操作數(shù) (IOPS) 145，每個磁盤 (MB) 數(shù)。 (請注意，與 Azure 不同，不保證 Azure Stack 中心的性能。 )
若要獲取更準確的存儲空間，以適應 Azure Stack 基于集線器的工作負載備份，請考慮使用 Microsoft 下載中提供的 MABS 的 VM 大小計算器 Azure Stack。 計算器以 Microsoft Excel 工作簿的形式實現(xiàn)，該工作簿使用宏根據(jù)您提供的多個參數(shù)派生最佳 Azure Stack 中心大小調整信息。 這些參數(shù)包括：
包含要保護的 Vm 列表的源詳細信息，包括：
受保護數(shù)據(jù)的大小
工作負荷類型 (Windows Server、SharePoint 或 SQL Server)
數(shù)據(jù)保持期（天）
默認情況下，每個工作負荷類型都與預定義的每日更改率 (或變動) 相關聯(lián)。 如果這些值不反映環(huán)境中的實際使用模式，則可以選擇調整這些值。
MABS 的 Azure Stack VM 大小計算器將使用你指定的信息來提供：
用于托管 MABS 安裝的 Azure Stack 中心 VM 的估計大小。
承載備份數(shù)據(jù)所需的估計 MABS 磁盤空間量。
每個 (TB) 1 tb 的磁盤總數(shù)。
可供 MABS 使用的 IOPS。
根據(jù)受保護的數(shù)據(jù)的總大小和 MABS 使用情況) 的可用 IOPS 估計完成初始 (備份的估計時間。
每日備份完成的估計時間 (基于每日變動的總大小和可供 MABS 使用的 IOPS) 。
備注
2018年4月發(fā)布了適用于 MABS 的 Azure Stack VM 大小計算器，這意味著它不會考慮到 MABS v3 中合并的優(yōu)化 (包含 UR1) 中包含的優(yōu)化。 不過，它包括特定于 MB 的增強功能，該功能是在2017年6月發(fā)布的 MABS v2 中引入的。
如果你使用 MABS 圖形界面創(chuàng)建保護組，則每當你將數(shù)據(jù)源添加到保護組時，MABS 也會根據(jù)你指定的短期恢復目標自動計算本地磁盤空間分配。 此時，你可以選擇在存儲池中為你為組中的成員身份選擇的每個數(shù)據(jù)源的副本和恢復點分配多少空間。 此外，還需要確保更改日志的受保護服務器的本地磁盤上有足夠的空間。 MABS 為保護組的成員提供默認的空間分配。 有關不同 MABS 組件的默認空間分配的詳細信息，請參閱 部署保護組文檔。
請考慮使用默認的空間分配，除非您確定它們不能滿足您的需求。 覆蓋默認的分配可能會導致分配的空間過少或過多。 為恢復點分配的空間太少會阻止 MABS 存儲足夠多的恢復點來滿足保持期目標。 分配過多的空間會浪費磁盤容量。 創(chuàng)建保護組后，如果為數(shù)據(jù)源分配了過少的空間，則可以增加每個數(shù)據(jù)源的副本卷和恢復點卷的分配量。 如果為保護組分配了過多的空間，則可以從保護組中刪除數(shù)據(jù)源，并刪除副本。 然后，將數(shù)據(jù)源添加到具有較小分配的保護組。
如果需要調整 Azure Stack 中心 VM 托管 MABS 后期部署的估計大小，以適應處理或存儲要求的變化，你有三個基本選項可供選擇：
實現(xiàn)垂直縮放。 這涉及到修改托管 MABS 的 Azure Stack 中心 Vm 的處理器、內存和磁盤資源的數(shù)量和類型。
實現(xiàn)水平縮放。 這涉及到預配或取消設置安裝了 MABS 的 Azure Stack 集線器 Vm，以滿足受保護工作負荷的處理需求。
修改保護策略。 這涉及更改保護策略的參數(shù)，包括保持期、恢復點計劃和快速完整備份計劃。
備注
務必要記住的是，MABS 受恢復點數(shù)量、快速完整備份和增量備份的限制。 有關這些限制的詳細信息，請參閱 恢復過程。
如果選擇自動增大卷，則在生產(chǎn)數(shù)據(jù)增長時，MABS 的備份卷的帳戶將會增加。 否則，MABS 會將備份存儲限制為保護組中的數(shù)據(jù)源大小。
從網(wǎng)絡角度來看，有兩個主要選項可用于調整可用帶寬：
增加 VM 大小。 對于 Azure Stack 集線器 Vm，其大小確定最大網(wǎng)絡帶寬。 但是，請務必注意，沒有帶寬保證;而是允許 Vm 利用可用帶寬，直到達到其大小所確定的限制。
增加上行交換機的吞吐量。 Azure Stack 集線器系統(tǒng)支持一系列硬件交換機，這些交換機提供多種上行速度選擇。 每個 Azure Stack 中心群集節(jié)點都具有兩個到機箱頂部交換機的上行鏈路，以實現(xiàn)容錯。 系統(tǒng)為關鍵基礎結構分配了一半的上行容量，余數(shù)是 Azure Stack 服務和所有用戶流量的共享容量。 以更快的速度部署的系統(tǒng)具有更多的可用帶寬來備份流量。
通常，可以通過將第二個網(wǎng)絡適配器附加到服務器來隔離網(wǎng)絡流量，在 Azure Stack 集線器 Vm 的情況下，與 internet 的所有 VM 流量共享同一上行。 第二個虛擬網(wǎng)絡適配器將不會在物理傳輸級別隔離流量。
若要適應更大的備份大小，可以考慮利用適用于 Microsoft 對等互連的 Azure ExpressRoute 連接 Azure Stack 中心虛擬網(wǎng)絡與 Azure 恢復服務保管庫之間的連接。 Azure ExpressRoute 通過連接提供商提供的專用連接將本地網(wǎng)絡擴展到 Microsoft 云。 可以購買各種帶寬的 ExpressRoute 線路，每秒50兆位 () Mbps， (Gbps) 每秒10千兆字節(jié)。
備注
有關在 Azure Stack Hub 方案中實現(xiàn) Azure ExpressRoute 的詳細信息，請參閱 使用 Azure ExpressRoute 將 Azure Stack 中心連接到 azure。
備注
MABS v3 利用內置于 MB 的增強功能，并通過在一致性檢查期間僅傳輸已更改的數(shù)據(jù)來優(yōu)化網(wǎng)絡和存儲的使用。
從可管理性角度來看，影響備份和還原策略的主要注意事項之一是保護組的配置，以及用于確定哪些受保護的工作負荷應屬于相同受保護組的標準。 如本文檔前面所述， 保護組 是數(shù)據(jù)源（例如卷、共享或應用程序數(shù)據(jù)存儲）的集合，這些數(shù)據(jù)源具有常見的備份和還原設置。 定義保護組時，需要指定：
要保護的數(shù)據(jù)源，如服務器和工作負載。
備份存儲，包括短期和長期保護設置。
恢復點，這是可從中恢復備份數(shù)據(jù)的時間點。
分配的磁盤空間，它是為存儲池的備份分配的磁盤空間量。
初始復制（初始復制）是數(shù)據(jù)源的初始備份的方法，它可以通過網(wǎng)絡) 或脫機 (如通過 Azure 導入/導出服務) 等方式在線傳輸 (。
一致性檢查，這是驗證已備份數(shù)據(jù)的完整性的方法。
確定哪些受保護的工作負荷應屬于相同的受保護組時，一些最常見的方法包括：
按計算機。 這會將計算機的所有數(shù)據(jù)源組合到同一個保護組中。
按工作負荷。 這會將文件和每個應用程序數(shù)據(jù)類型分隔到不同的保護組中。 但是，若要恢復托管多個工作負荷的服務器，可能需要從不同的保護組中進行多次還原。
通過 RPO 和 RTO。 此方法將具有相似 Rpo 的數(shù)據(jù)源組合在一起。 可以通過設置保護組的同步頻率來控制 RPO，該頻率決定了在意外中斷期間 (度量時間) 的潛在數(shù)據(jù)丟失量。 在此參考體系結構文檔中所述的方案中，可以通過在短期存儲中設置保留期來控制 RTO。 這是因為，這會確定可以從本地短期存儲（而不是基于云的長期存儲）還原備份的時間段。 從本地短期存儲備份會導致更快的還原。
按數(shù)據(jù)特性。 此方法將對數(shù)據(jù)更改頻率、數(shù)據(jù)增長速率或其存儲要求進行分組，作為分組條件。
命名保護組時，請使用唯一的有意義的名稱。 名稱可包含字母數(shù)字字符的任意組合并且可以包含空格，但長度不能超過64個字符。
此外，在創(chuàng)建保護組時，必須選擇用于創(chuàng)建初始副本的方法。 初始復制會將選定要保護的所有數(shù)據(jù)復制到托管 MABS 的服務器，然后將其復制到 Azure Site Recovery 保管庫中。 (每個階段還會執(zhí)行一致性檢查。 ) MABS 可以通過網(wǎng)絡自動創(chuàng)建副本，但你可以選擇通過脫機備份、傳輸和還原數(shù)據(jù)來手動創(chuàng)建副本。
選擇副本創(chuàng)建方法時，請參閱 通過網(wǎng)絡進行初始復制時可用的信息，其中包括一個表，該表格提供了在給定不同的受保護數(shù)據(jù)大小和網(wǎng)絡速度的情況下，通過網(wǎng)絡自動創(chuàng)建副本所需的 MABS 時間。
脫機播種過程支持 Azure 導入/導出服務。 Azure 導入/導出服務提供了使用 SATA 磁盤將數(shù)據(jù)傳輸?shù)?Azure 存儲帳戶的功能。 此功能適用于以下方案：客戶有 tb 的初始備份數(shù)據(jù)和與 Azure 的低帶寬網(wǎng)絡連接。
脫機種子設定工作流涉及以下高級步驟：
客戶使用 AzureOfflineBackupDiskPrep 工具將初始備份數(shù)據(jù)復制到一個或多個 SATA 磁盤。
此工具會在托管目標 Azure 存儲帳戶和 Azure 恢復服務保管庫的訂閱中自動生成 Azure 導入作業(yè)和 Azure AD 應用。 此應用的目的是為 Azure 備份提供對 Azure 導入服務的安全且具有范圍的訪問權限，這是脫機播種過程所必需的。
客戶將 SATA 驅動器寄給托管目標 Azure 存儲帳戶的 Azure 數(shù)據(jù)中心。
Azure 數(shù)據(jù)中心人員將數(shù)據(jù)從 SATA 磁盤復制到 Azure 存儲帳戶。
工作流觸發(fā)從 Azure 存儲帳戶到 Azure 恢復服務保管庫的復制。
除了采用最佳設計和實施的備份策略外，為每種類型的受保護工作負荷定義、記錄和測試正確的還原過程也同樣重要。 盡管 MABS 提供了自動驗證已備份數(shù)據(jù)的完整性的內置一致性檢查，但還原的測試應該是日常操作過程的一部分，這會根據(jù)還原工作負荷的狀態(tài)來驗證該完整性。 此類驗證的結果應對工作負荷所有者提供。
通常情況下，測試還原往往非常困難，因為它需要與托管受保護工作負荷的環(huán)境非常相似。 Azure Stack 中心，其內置 DevOps 和基礎結構即代碼功能可大大簡化應對這一挑戰(zhàn)。
規(guī)劃和實現(xiàn)基于 Azure Stack 集線器的工作負荷的備份和還原通常涉及多個利益干系人之間的交互：
Azure Stack 中心操作員。 Azure Stack 中心操作員管理 Azure Stack 中心基礎結構，確保有足夠的計算、存儲和網(wǎng)絡資源實現(xiàn)全面的備份和還原解決方案，并使這些資源可供租戶使用。 它們還與應用程序和數(shù)據(jù)所有者協(xié)作，幫助確定將其工作負荷部署到 Azure Stack 集線器的最佳方法。
Azure 管理員。 Azure 管理員管理實現(xiàn)混合備份解決方案所需的 Azure 資源。
Azure AD 管理員。 Azure AD 管理員管理 Azure AD 資源，包括用于設置、配置和管理 Azure 資源的用戶和組對象。
Azure Stack 中心租戶 IT 人員。 這些利益干系人設計、實施和管理 MABS，包括其備份和還原。
Azure Stack 中心用戶。 這些用戶提供了 RPO 和 RTO 要求，并提交了備份和還原數(shù)據(jù)和應用程序的請求。
在混合方案中管理用戶數(shù)據(jù)和應用程序，以保證其他安全注意事項。 這些注意事項可以分為以下幾類：
備份加密
Azure 恢復服務保管庫保護
MABS 和 Azure 備份強制對靜態(tài)備份和傳輸中的備份進行加密：
靜態(tài)加密。 MABS 安裝過程中的一個步驟涉及到提供一個通行短語，此密碼隨后用于在將所有備份上傳到 Azure 恢復服務保管庫之前對其進行加密。 僅當從該保管庫下載備份后，才會進行解密。 通行短語僅適用于創(chuàng)建通行短語和本地安裝的 MARS 代理的用戶。 務必確保通行短語存儲在安全的位置，因為當在 MABS 服務器上執(zhí)行基于云的還原時，該密碼在不同于其中發(fā)生備份的服務器上執(zhí)行。
傳輸中加密。 MABS v3 依賴于) 協(xié)議版本 1.2 (的傳輸層安全性來保護與 Azure 的連接。
Azure 恢復服務保管庫提供了許多用于進一步保護聯(lián)機備份的機制，包括：
Azure RBAC) (azure 基于角色的訪問控制。 Azure RBAC 允許根據(jù)最低權限原則委托和隔離責任。 有三個與 Azure 備份相關的內置角色，可限制對備份管理操作的訪問：
備份參與者。 提供了創(chuàng)建和管理備份的權限，但刪除了恢復服務保管庫并將訪問權限委派給其他人除外。
Backup 運算符。 提供與備份參與者相同的訪問權限，但刪除備份和管理備份策略除外。
備份讀取器。 提供監(jiān)視備份管理操作的訪問權限。
Azure 資源鎖。 你可以選擇創(chuàng)建和分配對 Azure Site Recovery 保管庫的只讀和刪除鎖定，以減輕意外或惡意更改或刪除保管庫的風險。
軟刪除。 軟刪除有助于保護保管庫和備份數(shù)據(jù)免遭意外或惡意刪除。 使用軟刪除時，如果用戶刪除備份項，則相應的數(shù)據(jù)將保留14天，允許在該時間段內不丟失數(shù)據(jù)的情況下進行恢復。 "軟刪除" 狀態(tài)中的備份數(shù)據(jù)的額外14天的保留期不會產(chǎn)生任何費用。 默認情況下啟用軟刪除。
保護安全敏感的操作。 每當嘗試安全敏感操作（如更改密碼）時，Azure 恢復服務保管庫都會自動實現(xiàn)一層額外的身份驗證。 這一額外驗證可幫助確保只有經(jīng)過授權的用戶才執(zhí)行這些操作。
可疑的活動監(jiān)視和警報。 Azure 備份提供了對與 Azure 備份操作相關的安全敏感事件的內置監(jiān)視和警報。 備份報表有助于實現(xiàn)使用跟蹤、審核備份和還原，以及確定關鍵備份趨勢。
盡管備份和還原被視為 IT 操作的一部分，但有一些特定于 DevOps 的注意事項需要合并到一個綜合性的備份策略中。 Azure Stack 中心有助于自動部署各種工作負荷，包括基于 VM 的應用程序和服務。 你可以利用此功能來簡化 MABS 部署 Azure Stack 中心 Vm，從而簡化了多租戶方案中的初始設置。 通過結合使用 Azure 資源管理器模板、VM 擴展和 DPM PowerShell 模塊，可以自動執(zhí)行 MABS 的配置，包括設置其保護組、保留設置和備份計劃。 在 DevOps 的最佳實踐精神中，將模板和腳本存儲在源代碼管理中，并通過管道配置它們的部署。 在需要重新創(chuàng)建還原文件和應用程序數(shù)據(jù)所需的基礎結構的情況下，這些設置還有助于最大程度地減少恢復時間。
考慮此參考體系結構文檔中所述的備份解決方案的成本時，請記住同時考慮本地組件和基于云的組件。 本地組件的定價取決于 Azure Stack 集線器定價模型。 與 Azure 一樣，Azure Stack 中心提供通過企業(yè)協(xié)議和云解決方案提供商計劃提供的即用即付的方式。 這種安排包括每個 Windows Server VM 的每月價格。 如果可以選擇利用現(xiàn)有的 Windows Server 許可證，則可以顯著降低基礎 VM 定價的成本。 盡管 MABS 依賴 SQL Server 作為其數(shù)據(jù)存儲，但在運行該實例時，不會有任何與 SQL Server 實例相關聯(lián)的許可費用，因為該實例專門用于 MABS。
與 Azure 相關的費用與使用以下資源關聯(lián)：
Azure 備份。 Azure 備份的定價主要取決于受保護的工作負荷的數(shù)量，以及每個 (的壓縮和加密) 之前已備份的數(shù)據(jù)的大小。 在復制 Azure 恢復服務保管庫內容時，此成本還受本地冗余存儲 (LRS) 和異地冗余存儲 (GRS) 的選擇影響。 有關詳細信息，請參閱 Azure 備份定價。
Azure ExpressRoute。 Azure ExpressRoute 定價基于以下兩種模型之一：
無限制數(shù)據(jù)。 這是每月費用，其中包含所有入站和出站數(shù)據(jù)傳輸。
計量數(shù)據(jù)。 這是每月收費，每 gb 的所有入站數(shù)據(jù)傳輸都是免費的，并按 gb 收費。
Azure 導入/導出。 Azure 導入/導出成本包括設備處理的每個設備的一項固定費用。
Azure 存儲。 使用 Azure 導入/導出時，將應用標準的 Azure 存儲費率和交易費用。
如果不使用 ExpressRoute，則在備份和還原期間，你可能需要考慮到 Internet 連接的帶寬利用率增加。 成本會因多種因素而異，其中包括地理區(qū)域、當前帶寬使用情況以及 Internet 服務提供商的選擇。
本參考體系結構文檔中所述的推薦解決方案理解不是為在 Azure Stack Hub 上運行的用戶工作負荷提供備份和還原功能的唯一方法。 客戶具有其他選項，其中包括：
使用 Windows Server 操作系統(tǒng)中包含的 Windows Server 備份 功能進行本地備份和還原。 然后，用戶可以將本地備份復制到長期存儲。 此方法通過依賴于 Windows VSS 提供程序來支持應用程序一致的備份，但會增加本地磁盤空間使用和備份維護開銷。
使用 Azure 備份和本地安裝的 MARS 代理進行備份和還原。 此方法最大程度地減少了本地磁盤空間的使用，并自動執(zhí)行了將備份上載到基于云的存儲的過程。 但是，它不支持應用程序一致的備份。
備份和還原使用安裝在同一數(shù)據(jù)中心但 Azure Stack 中心以外的備份解決方案進行備份和還原。 此方法可促進涉及到 Azure Stack 集線器斷開連接部署模型的方案。
Azure Stack 集線器–通過使用磁盤快照來備份和還原。 此方法要求已停止要備份的 VM，這通常不是關鍵業(yè)務工作負荷的可行選項，但在某些情況下可能是可接受的。
總之，Azure Stack 中心是一種獨特的產(chǎn)品，在許多方面與其他虛擬化平臺不同。 因此，它對其 Vm 上運行的工作負荷的業(yè)務連續(xù)性策略有特殊的注意事項。 利用 Azure 服務有助于簡化設計和實現(xiàn)策略。 此體系結構參考文檔介紹了如何使用 MABS 備份已連接部署模型中 Azure Stack 中心 Vm 上的文件和應用程序數(shù)據(jù)。 此方法可讓客戶從 Azure Stack 集線器的復原能力和可管理性中獲益，并從 Azure 云中的超大規(guī)模和全球存在中獲益。
請務必注意，此處所述的備份解決方案僅重點介紹 Azure Stack 中心 Vm 上的文件和應用程序數(shù)據(jù)。 這只是總體業(yè)務連續(xù)性策略的一部分，應考慮影響工作負荷可用性的各種其他方案。 這些問題包括本地化的硬件和軟件故障、系統(tǒng)中斷、災難性事件和大規(guī)模災難。
閩公網(wǎng)安備 35010202001226號
