Commvault を使用したバックアップ: いくつかの統計とケース

以前の投稿で、セットアップ手順を共有しました コピーを予約 и レプリケーション Veeamに基づいています。 今日は Commvault を使用したバックアップについて話したいと思います。 説明はありませんが、お客様がすでに何をどのようにバックアップしているかを説明します。

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

それはどのように動作しますか？

Commvault は、アプリケーション、データベース、ファイル システム、仮想マシン、物理サーバーのバックアップ プラットフォームです。 この場合、初期データは、当社のクライアント側、別の商用データセンター、クラウドなど、どのサイトにでも置くことができます。

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

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

DataLine 側では、iData Agent からのデータが受信されます。 メディアエージェントサーバー そして、それをストレージ システムやテープ ライブラリなどのストレージに送信します。これらすべては、によって管理されます。 コムサーブ。 この構成では、メイン コントロール サーバーは OST サイトに配置され、バックアップ サーバーは NORD サイトに配置されます。

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

Commvault バックアップ システムの運用スキーム。

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

クライアントにとって何が重要ですか?

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

コンソール。 顧客はバックアップを自分で管理したいと考えています。 すべての基本的な操作は Commvault コンソールで実行できます。

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

重複排除。 重複排除を使用すると、バックアップ プロセス中に重複したデータ ブロックを見つけて削除できます。 したがって、ストレージ システム上のスペースを節約し、転送されるデータ量を減らし、帯域幅の要件を軽減します。 重複排除を行わないと、バックアップには元のデータの最大 XNUMX ～ XNUMX 倍のサイズが必要になります。

Commvault の場合、重複排除はクライアント側または Media Agent 側で構成できます。 最初のケースでは、固有でないデータ ブロックはメディア エージェント サーバーに転送されません。 XNUMX 番目の場合、繰り返しブロックは破棄され、ストレージ システムには書き込まれません。

このようなブロックの重複排除はハッシュ関数に基づいています。 各ブロックにはハッシュが割り当てられ、データベース (重複排除データベース、DDB) の一種であるハッシュ テーブルに格納されます。 データを送信するとき、ハッシュはこのベースを通じて「パンチ」されます。 このようなハッシュがデータベースにすでに存在する場合、ブロックは非一意としてマークされ、メディア エージェント サーバーに転送されず (前者の場合)、データ ストレージ システムに書き込まれません (後者の場合)。

重複排除のおかげで、ストレージ容量を最大 78% 節約できます。 現在、166,4 TB がストレージに保存されています。 重複排除がなければ、744 TB を保存する必要があります。

権利を区別する可能性。 Commvault には、バックアップ管理へのさまざまなレベルのアクセスを設定する機能があります。 いわゆる「役割」によってどのようなアクションが行われるかが決まります 許可された バックアップ オブジェクトに関連するユーザー。 たとえば、開発者はデータベースを含むサーバーを特定の場所に復元することしかできませんが、管理者は同じサーバーに対して順不同バックアップを実行し、新しいユーザーを追加することができます。

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

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

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

いくつかの統計

27 月中旬までに、Commvault の支援により、65 のクライアントがバックアップされるようになりました。 そのほとんどは小売店や金融機関です。 原本データの総量は XNUMX TB です。

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

最も重要なのは、Windows ファイル システム、SQL Server、および Exchange データベースは Commvault を通じてバックアップされることです。

そして今、約束されたケース。 個人的ではありませんが (NDA は挨拶します :))、顧客が Commvault ベースのバックアップを何をどのように使用するかについてのアイデアを提供します。 以下は、単一のバックアップ システム (共有ソフトウェア、メディア エージェント サーバー、ストレージ システムなど) を使用するお客様向けのケース スタディです。

ケース1

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

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

初期データはロシア全土 (10 都市以上) のオフィスにあります。 DataLine サイトにバックアップし、その後、会社のオフィスでデータを復元する必要があります。
同時に、クライアントはアクセス制御による完全な自己管理を望んでいました。
ストレージの深さ - 年。 Exchange Online の場合、オンライン コピーの場合は 3 か月、アーカイブの場合は XNUMX 年です。

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

クライアントのリモート オフィスからのチャネルの品質により、常に最適な時間枠でのバックアップと復元が可能になるとは限りませんでした。 送信トラフィックの量を減らすために、クライアント側で重複排除が構成されました。 彼女のおかげで、オフィスが離れていることを考慮して、完全バックアップの時間を許容できるようになりました。 たとえば、サンクトペテルブルクからの 131 GB のデータベースの完全バックアップは 16 分で完了します。 エカテリンブルグからは、340 GB のデータベースが 1 時間 45 分間バックアップされます。

顧客はロールを通じて、開発者に対してバックアップまたは復元のみのさまざまな権限を構成しました。

ケース2

お客様。 ロシアの子供用品店チェーン。
チャレンジ。 バックアップの構成:
4 台の物理サーバーに基づく高負荷の MS SQL クラスター。
Web サイト、アプリケーション サーバー、1C、Exchange、およびファイル サーバーを備えた仮想マシン。
クライアントの指定されたインフラストラクチャ全体が、OST サイトと NORD サイトの間に配置されます。
SQL サーバーの RPO - 30 分、残りの RPO - 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 分ごと、または特定のサイズに達したときにアーカイブされました。

データベースのリカバリ時間を短縮するために、ストレージ システムとテープ ライブラリに基づいてバックアップの 1 レベルのストレージを設定しました。 オンライン コピーがディスクに追加され、週中いつでもリカバリできるようになります。 バックアップが 30 週間より古くなると、バックアップはアーカイブのテープ ライブラリに移動され、そこでさらに XNUMX 日間保存されます。

181 GB データベースの 1 つの完全バックアップは 54 時間 XNUMX 分で実行されます。

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

クライアントは、標準の Commvault クライアント コンソールを通じてバックアップ管理を行うこともできます。

それが今日のすべてです。 コメントで質問してください。

出所： habr.com