本日は、Veeamが“Running Exchange on VMware”というウェビナーを配信しました。授業は、仮想化されたExchangeのバックアップとリカバリーについて集中します。ウェビナーを準備しながら (Anton から助力を受けて)、教える情報はいいブログになると気付きました。Microsoft Exchangeのバックアップとリカバリーに関する要点、Veeam Backup & Replication v5がそれをどう対応するか下記とします。
Microsoftによりますと、Exchangeサーバーをバックアップおよびリストアするには３つの基本的ルールがあります。:
Exchangeサーバーに適合するように、VSSを使ったバックアップアプリケーションは、シャドウ・コピー・バックアップの完全性と復元可能性を確保する為に、３つの基本的な要件に従わなくてはなりません。要件を充足していない場合、Microsoftはバックアップとリストアに関する問題をトラブルシュートできなくなります。
ルール 1: ExchangeをExchange VSS Writerで排他的にバックアップする必要です。
ルール 2: バックアップアプリケーションの整合性検証が完了するまで、バックアップを信頼すべきではありません。
ルール 3: 元ロケーションへのリストアをExchange VSS Writerで排他的に行われなければなりません。
ルール１： VSS Awareバックアップ
Veeamは、VMware Tools VSS integrationコンポネントに頼ることの代わりに、Microsoft専有のVSS integrationを実施します。
- 全自動と透過的（展開／設定／更新／監視するエージェントがない）
- VMWareではなく、Veeamが直接にサポートする（責任追及にならない）
- VMware Tools VSS無制限：トランザクション・ログ処理、全てのESX(i)とWindowsバージョン、 ダイナミック ディスク、IDEディスク、UUID無しのVM等をサポートする
詳しい情報は：
- Veeam Backup v5 FAQ： http://tinyurl.com/v5FAQ
- VMware VSS 制限： http://www.sys-con.com/node/1544145
ルール２：信頼する前に検証
SureBackupリカバリー検証
- 高柔軟性 （カスタム・スクリプトをサポートする
- あなたにとって十分な検証方法を選択する：テストVMにeseutilまたはisintegをリモート実行する（生産にストレスは掛からない）HTTPS でのメールボックスのテスト、およびメール・メッセージのクエリ・テストを行なう為にログする
DC依存性に留意
- Exchangeは、孤立した環境において適切にブートする為に、DCを見つける必要があります。これに関しては、SureBackup Application Groupsが対応します。
ルール３: VSS Aware リストア
元ロケーションへのリストアをExchange VSS Writerで排他的に行ない、かつ正しい順次に行われなければなりません。
- メールボックス・ストアが実装されていない状態でExchange VMをブートする
- VSSスナップショットからリストアを行なうことをExchange VSS Writer に指示する
- メールボックス・ストーアを実装する
Veeamは、下記の要件を実施します
- ほとんどのイメージ・レベル・バックアップの販売者これを行なわない、Exchangeは存在しないようにVMをブートする
- 現在のソリューションを確認する為にテスト・リストアを行ない、復元されたExchangeサーバーに下記イベントが含まれているか確認します。下記イベントが含まれていなかったら販売者は上記ルール３を実施していないことです。
| イベント・タイプ： 情報
イベント・ソース： MSExchangeIS イベント・カテゴリー： Exchange VSS Writer イベントID： 9620 ユーザ: N/A コンピューター: ServerName.contoso.com 一般： Exchange VSS Writer (instance GUID)がプレ・リストアのイベントを成功に処理しました。 |
イベント・タイプ： 情報
イベント・ソース： MSExchangeIS イベント・カテゴリー： Exchange VSS Writer イベントID： 9618 ユーザ: N/A コンピューター: ServerName.contoso.com 一般： Exchange VSS Writer (instance GUID)がプレ・リストアのイベントを成功に処理しました。 |
トランザクション・ログ
バックアップ後、トランザクション・ログファイルの一部を切除しなかったら、ログファイルはディスク空き容量が満杯になるまで蓄積されます。Exchange VSS Writerはトランザクション・ログ縮小の能力を実施しますが、VMware Tools VSSの場合は、バックアップアプリケーションではないため、バックアップは成功に完了したかどうか確認できません。つまり、設計によりトランザクション・ログを処理できません。
- 専有VSS統合を提供するの代わりに、VMware Tools VSSを使用するどのアプリケーションもログを切り捨てることはできません。
- いくつかのソリューションはトランザクションログ縮小処理を提供しますが、スナップショットを取ってからログを縮小することが行なわれます。
このアプローチは、縮小よりも深刻です。なぜうかというと、バックアップは成功に完了できなかったら、適切なバックアップは生成されない、全部のトランザクション・ログは失われます。障害が発生した場合、復元できなくなります。
イメージ・レベルを確認するには、バックアップのテストを行ないます。（実際サーバーではなく、テスト用Exchangeサーバで行ないます。）
- バックアップを行ない、バックアップは成功に完了するまで待ち、トランザクション・ログが縮小されたかどうか確認します。
- もう一つのバックアップを行ない、この時ジョブを実行しながら（仮想ディスクコピー開始後に）バックアップサーバーをリセットします。トランザクションログは縮小されるべきではありません。
以下スクリーンショットのように、Veeamはデフォルトで成功したバックアップを祝勝し、v5はトランザクション・ログの対応オプションを提供します。
Granular リカバリーのチャレンジ
通常はイメージ・レベル・バックアップからGranularリカバリーを実行することが難しくて、種々の項目を復元可能になる前に、孤立した環境にまずアクティブディレクトリとExchangeサーバー全体を復元しなければなりません。この処理は時間のかかり、人的・資源集約的です。Exchangeデータ・ストーアを実装するその他のサードパーティのツールがありますが、先にデータ・ストアを抽出する必要があり（時間とディスク空き容量）、関連する追加のライセンス費用もかかります（大抵、メールボックスごとになります）。
Exchangeデータがバックアップできるエージェント・ベース・ソリューションは数年に存在しますが、仮想環境においてExchange をバックアップすることに最も効率的な方法ではありません。さらに、エージェント・ベースをイメージベースに合わせたら、同じデータは二度にバックアップされてしまって、追加リソースとストレージ・メディアを消費します。
vPower™でGranular リカバリー
Veeamの特許出願中のアプローチは、既存の仮想インフラストラクチャを利用します。Veeamのアプリケーション・グループと仮想研究所機能は孤立した環境を自動的に作成し、vPowerで、抽出処理を行なわずにバックアップファイルから直接にADとExchangeサーバーを実行する可能になります。
VeeamのExchange AIR (Application Item Recovery)ウィザードは、Microsoft Exchange API を使用し、両方の孤立と実際環境に接続し、時間ではなく数分でExchangeのアイテム・レベルのリカバリーを実行します。
関連するその他の製品・ソリューションはこちら
Microsoft 365のデータの包括的なバックアップをサポートする「Veeam Backup for Microsoft Office 365」。製品概要や利用シーン、成功事例はこちら。
Windowsベースのシステム、物理サーバー、クラウドインスタンス向けの包括的なバックアップおよび復元ソリューション「Agent for Microsoft Windows」。製品概要やエディション比較、成功事例はこちら。
SharePointのオブジェクトを迅速かつ簡単にリストアできる「Veeam Explorer for SharePoint」。製品概要や新機能、エディション比較、特長はこちら。
投資対効果が高く安全で、エンタープライズにも対応している、Microsoft Azureのバックアップ専用製品「Veeam Backup for Microsoft Azure」。製品概要や成功事例などはこちら。
