Commvaultを使用したバックアップ：統計とケース

以前の投稿で、Veeamベースのバックアップとレプリケーションの セットアップ手順を共有しました。 今日は、Commvaultを使用したバックアップについてお話します。 指示はありませんが、お客様がすでにバックアップしているものとその方法をお知らせします。


OST-2データセンターのCommvaultに基づくストレージバックアップシステム。

どのように機能しますか？

Commvaultは、アプリケーション、データベース、ファイルシステム、仮想マシン、物理サーバーをバックアップするためのプラットフォームです。 この場合、ソースデータは任意のサイトに配置できます。クライアント側、別の商用データセンターまたはクラウドにあります。

クライアントは、エージェント— iDataエージェント —をバックアップオブジェクトにインストールし、必要なバックアップポリシーに従って構成します。 iData Agentは必要なデータを収集し、圧縮、重複排除、暗号化してDataLineバックアップシステムに転送します。

プロキシサーバーは、クライアントネットワークと当社のネットワークの接続、データが送信されるチャネルの分離を提供します。

DataLine側では、iData AgentからのデータがMedia Agent Serverによって受信され、ストレージシステム、テープライブラリなどへのストレージに送信されます 。CommServeはこれらすべてを管理します。 この構成では、メイン管理サーバーはOSTサイトにあり、バックアップサーバーはNORDサイトにあります。

デフォルトでは、クライアントデータは1つのサイトに追加されますが、バックアップを一度に2つの場所に整理したり、バックアップを2番目のサイトに転送するスケジュールを設定したりできます。 このオプションは、補助コピーと呼ばれます。 たとえば、月末のすべての完全バックアップは自動的に複製されるか、2番目のサイトに移動します。


Commvaultバックアップシステムのフローチャート。

バックアップシステムは主にVMware仮想化で動作します。CommServe、Media Agent、およびProxyサーバーは仮想マシンに展開されます。 クライアントが当社の機器を使用する場合、バックアップはHuawei OceanStor 5500 V3のストレージに配置されます。 クライアントストレージシステムをバックアップし、バックアップをテープライブラリに保存するには、物理​​サーバー上の別個のMedia Agentが使用されます。

顧客にとって何が重要ですか？

私たちの実践から、バックアップにCommvaultを選択したお客様は、次の点に注意を払っています。

コンソール お客様は、バックアップを自分で管理したいと考えています。 すべての基本操作は、Commvaultコンソールで利用できます。

• バックアップ用のサーバーの追加と削除。
• iData Agentのセットアップ。
• タスクの作成と手動起動。
• 自己復元バックアップ。
• バックアップタスクのステータスに関するアラートを設定します。
• 役割とユーザーグループに応じたコンソールへのアクセスの区別。

重複排除。 重複排除を使用すると、バックアッププロセス中に重複するデータブロックを見つけて削除できます。 したがって、ストレージスペースを節約し、送信されるデータの量を減らして、チャネル速度の要件を減らすことができます。 重複排除がなければ、バックアップは元のデータの2〜3倍のサイズを必要とします。

Commvaultの場合、重複排除はクライアント側またはMedia Agent側で構成できます。 前者の場合、一意でないデータブロックはMedia Agent Serverにも転送されません。 2番目では、繰り返しブロックは破棄され、ストレージシステムに書き込まれません。

このようなブロック重複排除は、ハッシュ関数に基づいています。 各ブロックにはハッシュが割り当てられ、ハッシュはデータベースの一種であるハッシュテーブル（重複排除データベース、DDB）に保存されます。 データを送信するとき、ハッシュはこのデータベースを「突破」します。 そのようなハッシュがすでにデータベースにある場合、ブロックは非一意としてマークされ、Media Agent Serverに送信されない（最初の場合）か、ストレージシステムに書き込まれません（2番目の場合）。

重複排除のおかげで、ストレージスペースの最大78％を節約できます。 これで、166.4 TBがストレージシステムに保存されます。 重複排除がなければ、744 TBを保存する必要があります。

権利を区別する機能。 Commvaultには、バックアップ管理へのさまざまなアクセスレベルを設定する機能があります。 いわゆる「ロール」は、バックアップオブジェクトに関してユーザーに許可されるアクションを決定します。 たとえば、開発者はデータベースを使用してサーバーを特定の場所にのみ復元でき、管理者は同じサーバーに対して異常なバックアップを開始し、新しいユーザーを追加できます。

暗号化 次の方法で、Commvaultを使用してバックアップ中にデータを暗号化できます。

• クライアントエージェント側：この場合、データは既に暗号化された形式でバックアップシステムに転送されます。
• Media Agentの側面;
• チャネルレベル：データはクライアントエージェント側で暗号化され、Media Agent Serverで復号化されます。

利用可能な暗号化アルゴリズム：Blowfish、GOST、Serpent、Twofish、3-DES、AES（Commvaultが推奨）。

いくつかの統計

12月中旬、Commvaultの支援により、27人の顧客がバックアップされました。 それらのほとんどは小売業者と金融機関です。 元のコピーデータの合計ボリュームは65 TBです。



1日あたり約4400のタスクが完了します。 以下は、過去16日間に完了したタスクの統計です。



何よりも、Commvaultを通じて、Windowsファイルシステム、SQL Server、およびExchangeデータベースがバックアップされます。



そして今、約束のケース。 それらは非人格ですが（NDAの挨拶:)）、しかし、顧客がCommvaultベースのバックアップを使用する理由と方法についてのアイデアを提供します。 以下は、単一のバックアップシステム、つまり一般的なソフトウェア、Media Agent Server、およびストレージシステムを使用するお客様のケースです。

事例1

お客様。 ロシアに支店の分散ネットワークを持つ菓子市場のロシアの貿易および製造会社。

チャレンジ。 Microsoft SQLデータベース、ファイルサーバー、アプリケーションサーバー、Exchange Onlineメールボックスのバックアップの構成。

ソースデータはロシア（10都市以上）のオフィスにあります。 DataLineサイトにバックアップしてから、会社のオフィスでデータを回復する必要があります。
同時に、クライアントは、アクセス制御を備えた完全な独立管理を望んでいました。
ストレージの深さ-1年。 Exchange Onlineの場合-オンラインコピーの場合は3か月、アーカイブの場合は1年。

解決策。 データベースの場合、2番目のサイトで追加のコピーが構成されました。その月の最後の完全バックアップが別のサイトに転送され、1年間そこに保存されます。

クライアントのリモートオフィスからのチャネルの品質により、最適なタイミングでのバックアップとリカバリが常に可能になるとは限りませんでした。 送信されるトラフィックの量を減らすために、クライアント側で重複排除が構成されています。 彼女のおかげで、オフィスの遠隔性を考えると、完全なバックアップ時間が許容されました。 たとえば、サンクトペテルブルクの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

お客様。 CISのスーパーマーケットチェーン
チャレンジ。 お客様は、クラウドにあるSAPシステムのバックアップとリカバリを整理したいと考えていました。 SAP HANAデータベースの場合、RPO = 15分、アプリケーションサーバーを持つ仮想マシンの場合RPO = 24時間。 ストレージの深さ-30日。 事故が発生した場合、RTO = 1時間、RTO = 4時間のリクエストでコピーを復元します。

解決策。 HANAデータベースの場合、設定された頻度でのDATAファイルとログファイルのバックアップが構成されました。 ログファイルは15分ごと、または特定のサイズに達したときにアーカイブされました。

データベースの復旧時間を短縮するために、ストレージシステムとテープライブラリに基づいて2レベルのバックアップストレージをセットアップしました。 運用コピーはディスクに追加され、平日はいつでも回復できる可能性があります。 バックアップが1週間以上経過すると、アーカイブ、テープライブラリに転送され、さらに30日間保存されます。

181 GBデータベースのいずれかの完全バックアップは、1時間54分で完了します。

バックアップを設定するときに、SAP backintインターフェイスが使用されたため、サードパーティのバックアップシステムをSAP HANA Studioと統合できます。 したがって、バックアップはSAPコンソールから直接管理できます。 これにより、新しい管理画面に慣れる必要のないSAP管理者の作業が楽になります。

バックアップ管理は、標準のCommvaultクライアントコンソールからクライアントでも利用できます。



今日は以上です。 コメントで質問してください。