在之前的文章中，我們分享了設定說明 и 由 Veeam 提供支援。 今天我們想談談使用 Commvault 進行備份。 不會有任何說明，但我們會告訴您我們的客戶備份了什麼以及如何備份。
OST-2資料中心是基於Commvault的儲存系統備份系統。
它是如何工作的呢？
Commvault 是一個用於備份應用程式、資料庫、檔案系統、虛擬機器和實體伺服器的平台。 來源資料可以位於任何站點：在我們的客戶端、另一個商業資料中心或雲端。
用戶端在備份物件上安裝代理程式 – 數據代理 – 並依照所需的備份策略進行設定。 iData Agent 收集必要的數據，對其進行壓縮、重複資料刪除、加密並將其傳輸到 DataLine 備份系統。
代理伺服器 提供客戶端網路和我們的網路之間的連接，隔離資料傳輸的通道。
在DataLine端，接收來自iData Agent的數據 媒體代理伺服器 並將其發送到儲存系統、磁帶庫等進行儲存。這一切都是受管理的 通訊服務。 在我們的配置中，主控伺服器位於OST站點，備份伺服器位於NORD站點。
預設情況下，用戶端資料會儲存在一個網站上，但您可以同時將備份組織到兩個位置，或設定將備份傳輸到第二個網站的計畫。 此選項稱為“輔助副本”。 例如，月底的所有完整備份將自動複製或移動到第二個站點。
Commvault 備份系統的操作方案。
備份系統主要運行在VMware虛擬化：CommServe、Media Agent和Proxy伺服器部署在虛擬機器上。 如果客戶使用我們的設備，備份放在華為OceanStor 5500 V3儲存系統上。 為了備份客戶端儲存系統並將備份儲存在磁帶庫上，需要在實體伺服器上使用單獨的媒體代理程式。
對客戶來說什麼是重要的？
根據我們的經驗，選擇Commvault進行備份的客戶需要注意以下幾點。
安慰。 客戶希望自己管理備份。 所有基本操作都可以在 Commvault 控制台中進行：
- 新增和刪除備份伺服器；
- 設定iData代理；
- 建立和手動啟動任務；
- 備份的自我恢復；
- 設定有關備份任務狀態的通知；
- 根據角色和使用者群組限制對控制台的存取。
重複資料刪除。 重複資料刪除可讓您在備份過程中尋找並刪除重複的資料區塊。 因此，它有助於節省儲存系統的空間並減少傳輸的資料量，從而降低對通道速度的要求。 如果沒有重複資料刪除，備份將佔用原始資料量的兩到三倍。
對於 Commvault，可以在用戶端或媒體代理端配置重複資料刪除。 在第一種情況下，非唯一資料區塊甚至不會傳送到媒體代理伺服器。 在第二種情況下，重複區塊被丟棄並且不寫入儲存系統。
這種區塊去重是基於雜湊函數的。 每個區塊都分配有一個哈希值，該值儲存在哈希表中，哈希表是一種資料庫（Deduplication Database，DDB）。 當傳輸資料時，雜湊會透過該資料庫被「破壞」。 如果資料庫中已存在這樣的雜湊，則該區塊將被標記為非唯一，並且不會傳輸到媒體代理伺服器（在第一種情況下）或寫入資料儲存系統（在第二種情況下） 。
由於重複資料刪除，我們能夠節省高達 78% 的儲存系統空間。 目前，儲存系統上已儲存166,4 TB。 如果沒有重複資料刪除，我們將不得不儲存 744 TB。
區分權利的可能性。 Commvault 能夠設定不同層級的備份管理存取權限。 所謂的「角色」決定了將採取什麼行動 與備份對象相關的使用者。 例如，開發人員只能將具有資料庫的伺服器還原到特定位置，而管理員將能夠為同一台伺服器啟動特殊備份並新增使用者。
加密。 您可以透過以下方式透過 Commvault 在備份過程中加密資料：
- 在客戶端代理端：這種情況下的資料將以加密形式傳輸到備份系統；
- 在媒體代理商方面；
- 在鏈路層級：資料在客戶端代理端加密並在媒體代理伺服器上解密。
可用的加密演算法：Blowfish、GOST、Serpent、Twofish、3-DES、AES（建議commvault）。
一些統計數據
截至 27 月中旬，我們有 65 位客戶使用 Commvault 進行備份。 其中大多數是零售商和金融機構。 副本原始資料總容量為XNUMXTB。
每天約完成 4400 項任務。 以下是過去 16 天內已完成任務的統計資料。
透過 Commvault 最常用的備份是 Windows 檔案系統、SQL Server 和 Exchange 資料庫。
現在是承諾的案例。 雖然非個人化（NDA 打招呼:)），但它們讓我們了解了客戶為什麼以及如何使用基於 Commvault 的備份。 以下是使用單一備份系統的客戶案例，即通用軟體、媒體代理伺服器和儲存系統。
情況1
顧客。 俄羅斯糖果市場的貿易和生產公司，其分支機構網絡遍布俄羅斯各地。
一個任務。組織 Microsoft SQL 資料庫、檔案伺服器、應用程式伺服器、Exchange Online 信箱的備份。
來源資料位於俄羅斯各地的辦事處（10 多個城市）。 您需要備份到 DataLine 站點，然後在公司的任何辦公室還原資料。
同時，客戶希望透過存取控制實現完全獨立的控制。
儲存深度 – 一年。 對於 Exchange Online – 即時副本為 3 個月，存檔為一年。
解決方案。 為第二個網站上的資料庫配置了額外的副本：當月的最後一個完整備份傳輸到另一個網站並在那裡儲存一年。
客戶遠端辦公室的通道品質並不總是允許在最佳時間範圍內進行備份和還原。 為了減少傳輸流量，在客戶端配置了重複資料刪除。 多虧了它，考慮到辦公室的偏遠地區，完整的備份時間已經變得可以接受。 例如，來自聖彼得堡的 131 GB 資料庫的完整備份只需 16 分鐘即可完成。 從葉卡捷琳堡開始，340 GB 的資料庫備份時間為 1 小時 45 分鐘。
使用角色，用戶端為其開發人員配置不同的權限：僅備份或僅還原。
情況2
顧客。 俄羅斯兒童用品連鎖店。
一個任務。 組織備份：
基於4台實體伺服器的高負載MS SQL叢集；
具有網站、應用程式伺服器、1C、Exchange 和檔案伺服器的虛擬機器。
整個指定的客戶端基礎架構分佈在 OST 和 NORD 網站之間。
SQL 伺服器的 RPO 為 30 分鐘，其他伺服器為 1 天。
儲存深度 – 2 週到 30 天，視資料類型而定。
解決方案。 我們選擇了基於 Veeam 和 Commvault 的解決方案組合。 我們使用 Veeam 從雲端進行檔案備份。 資料庫伺服器、Active Directory、郵件和實體伺服器均透過 Commvault 進行備份。
為了實現較高的備份速度，客戶在使用MS SQL的實體伺服器上分配了一個單獨的網路介面卡來執行備份任務。 3,4 TB 資料庫的完整備份需要 2 小時 20 分鐘，完整恢復需要 5 小時 5 分鐘。
客戶擁有大量原始資料（近18 TB）。 如果像客戶之前那樣將資料放在磁帶庫上，則需要數十個盒帶。 這將使客戶整個備份系統的管理變得複雜。 因此，在最終的實施中，磁帶庫被替換為儲存系統。
情況3
顧客。 獨聯體國家的連鎖超市
一個任務。 客戶想要組織位於我們雲端的 SAP 系統的備份和復原。 對於 SAP HANA 資料庫，RPO=15 分鐘，對於具有應用程式伺服器的虛擬機，RPO=24 小時。 儲存深度 – 30 天。 如果發生事故，RTO=1 小時，根據請求恢復副本，RTO=4 小時。
解決方案。 對於HANA資料庫，依指定頻率配置DATA檔案和Log檔案的備份。 日誌檔案每 15 分鐘或達到一定大小時歸檔一次。
為了減少資料庫復原時間，我們配置了基於儲存系統和磁帶庫的二級儲存備份。 操作副本儲存在磁碟上，可以在一周內隨時恢復。 當備份超過 1 週時，它會移至存檔、磁帶庫，並在其中再儲存 30 天。
181 GB 資料庫之一的完整備份只需 1 小時 54 分鐘即可完成。
在設定備份時，我們使用了 SAP backint 接口，它允許我們將第三方備份系統與 SAP HANA Studio 整合。 因此，可以直接從 SAP 控制台管理備份。 這使得 SAP 管理員的生活變得更加輕鬆，無需習慣新介面。
客戶也可以透過標準 Commvault 用戶端控制台進行備份管理。
這就是今天的全部內容。 在評論中提問。
來源： www.habr.com