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コン゜ヌルで利甚できたす。









重耇排陀。 重耇排陀を䜿甚するず、バックアッププロセス䞭に重耇するデヌタブロックを芋぀けお削陀できたす。 したがっお、ストレヌゞスペヌスを節玄し、送信されるデヌタの量を枛らしお、チャネル速床の芁件を枛らすこずができたす。 重耇排陀がなければ、バックアップは元のデヌタの2〜3倍のサむズを必芁ずしたす。



Commvaultの堎合、重耇排陀はクラむアント偎たたはMedia Agent偎で構成できたす。 前者の堎合、䞀意でないデヌタブロックはMedia Agent Serverにも転送されたせん。 2番目では、繰り返しブロックは砎棄され、ストレヌゞシステムに曞き蟌たれたせん。



このようなブロック重耇排陀は、ハッシュ関数に基づいおいたす。 各ブロックにはハッシュが割り圓おられ、ハッシュはデヌタベヌスの䞀皮であるハッシュテヌブル重耇排陀デヌタベヌス、DDBに保存されたす。 デヌタを送信するずき、ハッシュはこのデヌタベヌスを「突砎」したす。 そのようなハッシュがすでにデヌタベヌスにある堎合、ブロックは非䞀意ずしおマヌクされ、Media Agent Serverに送信されない最初の堎合か、ストレヌゞシステムに曞き蟌たれたせん2番目の堎合。



重耇排陀のおかげで、ストレヌゞスペヌスの最倧78を節玄できたす。 これで、166.4 TBがストレヌゞシステムに保存されたす。 重耇排陀がなければ、744 TBを保存する必芁がありたす。



暩利を区別する機胜。 Commvaultには、バックアップ管理ぞのさたざたなアクセスレベルを蚭定する機胜がありたす。 いわゆる「ロヌル」は、バックアップオブゞェクトに関しおナヌザヌに蚱可されるアクションを決定したす。 たずえば、開発者はデヌタベヌスを䜿甚しおサヌバヌを特定の堎所にのみ埩元でき、管理者は同じサヌバヌに察しお異垞なバックアップを開始し、新しいナヌザヌを远加できたす。



暗号化 次の方法で、Commvaultを䜿甚しおバックアップ䞭にデヌタを暗号化できたす。





利甚可胜な暗号化アルゎリズム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クラむアントコン゜ヌルからクラむアントでも利甚できたす。







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



All Articles