Skip to main content
NetApp Solutions SAP
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

TR-4614 ：『 SAP HANA Backup and Recovery with SnapCenter 』

共同作成者
PDF

ネットアップ Nils Bauer

今日の企業には、 SAP アプリケーションを中断なく継続的に利用できることが求められています。データ量が増え続け、システムバックアップなどの日常的な保守作業が必要になった場合に、一貫したパフォーマンスレベルが期待されます。SAP データベースのバックアップは重要な作業であり、本番用 SAP システムのパフォーマンスに大きく影響する可能性があります。

バックアップウィンドウは短くなっている一方で、バックアップするデータの量は増加しています。そのため、ビジネスプロセスへの影響を最小限に抑えながらバックアップを実行できるタイミングを見つけ出すのは困難です。本番環境と非本番環境の SAP システムのダウンタイムは、データの損失とビジネスコストを削減するために最小化する必要があるため、 SAP システムのリストアとリカバリに要する時間が重要になります。

SAP のバックアップとリカバリに関する課題を以下にまとめます。

  • * 本番用 SAP システムのパフォーマンスへの影響。 * 通常、従来のコピーベースのバックアップは、データベースサーバ、ストレージシステム、ストレージネットワークに大きな負荷がかかるため、本番用 SAP システムのパフォーマンスが大幅に低下します。

  • * バックアップ・ウィンドウの短縮 * 従来のバックアップは 'SAP システムでの対話またはバッチ・アクティビティが少ない場合にのみ可能ですSAP システムが 24 時間稼働していると、バックアップのスケジュール設定がさらに難しくなります。

  • * データの急増。 * データの急増とバックアップ・ウィンドウの短縮には、バックアップ・インフラへの継続的な投資が必要です。つまり、より多くのテープドライブを調達し、追加のバックアップディスクスペースを確保し、より高速なバックアップネットワークを構築する必要があります。また、これらのテープ資産の格納と管理にかかる継続的なコストについても説明する必要があります。こうした問題には差分バックアップで対処することもできますが、リストアプロセスが煩雑で非常に時間がかかるうえ、複雑なため検証も難しくなります。このようなシステムでは、通常、 Recovery Time Objective （ RTO ；目標復旧時間）と Recovery Point Objective （ RPO ；目標復旧時点）が長くなり、ビジネスには受け入れられません。

  • * ダウンタイムのコスト増加。 * SAP システムの計画外のダウンタイムは、通常、ビジネスの財務に影響を及ぼします。計画外停止の大部分は、 SAP システムのリストアとリカバリの要件に応じて消費されます。そのため、必要な RTO は、バックアップとリカバリのアーキテクチャの設計を決定します。

  • * SAP アップグレード・プロジェクトのバックアップ / リカバリ時間。 * SAP アップグレードのプロジェクト計画には、 SAP データベースのバックアップが 3 つ以上含まれています。これらのバックアップにより、アップグレードプロセスにかかる時間が大幅に短縮されます。通常、続行するかどうかは、以前に作成したバックアップからデータベースをリストアおよびリカバリするのに要する時間に基づいて判断します。システムを以前の状態にリストアするだけでなく、アップグレード中に発生する可能性のある問題を迅速にリストアすることで解決できます。

NetApp 解決策の略

ネットアップの Snapshot テクノロジを使用すれば、データベースのバックアップを数分で作成できます。Snapshot コピーではストレージプラットフォーム上の物理データブロックは移動されないため、 Snapshot コピーの作成に要する時間はデータベースのサイズに左右されません。また、 Snapshot コピーの作成時やアクティブファイルシステムのデータが変更されたときにデータブロックの移動やコピーが NetApp Snapshot テクノロジによって行われないため、稼働中の SAP システムのパフォーマンスに影響がありません。そのため、 Snapshot コピーの作成スケジュールは、対話形式またはバッチでのアクティビティのピーク期間を気にせずに作成できます。SAP とネットアップのお客様は、通常、複数のオンライン Snapshot バックアップを 1 日に行うようにスケジュールを設定します。たとえば、一般に 4 時間ごとなどです。作成された Snapshot バックアップをプライマリストレージシステムに 3~5 日間保持しています。

Snapshot コピーは、リストア処理とリカバリ処理にも大きなメリットがあります。NetApp SnapRestore データリカバリソフトウェアを使用すると、データベース全体または利用可能な Snapshot コピーに基づいて、データベースの一部を任意の時点にリストアできます。このようなリストアプロセスは、データベースのサイズに関係なく数分で完了します。オンラインの Snapshot バックアップは 1 日に数回作成されるため、従来のバックアップ方式に比べて、リカバリプロセスに要する時間が大幅に短縮されます。24 時間以内ではなく数時間前の Snapshot コピーを使用してリストアできるため、適用するトランザクションログの数を少なくする必要があります。そのため、従来のシングルサイクルのテープバックアップでは数時間かかるのに対し、 RTO が数分に短縮されます。

Snapshot コピーバックアップは、アクティブなオンラインデータと同じディスクシステムに格納されます。セカンダリストレージへのバックアップに代わる手段としてではなく、補助的な用途で使用することを推奨します。リストアとリカバリのほとんどはプライマリストレージシステムで SnapRestore を使用して実行されます。セカンダリストレージからのリストアが必要になるのは、 Snapshot コピーが格納されているプライマリストレージシステムが損傷している場合のみです。セカンダリストレージは、たとえば月末のバックアップのように、 Snapshot コピーからは提供されなくなったバックアップをリストアする必要がある場合にも使用できます。

セカンダリストレージへのバックアップは、プライマリストレージに作成された Snapshot コピーがベースとなります。そのため、プライマリストレージシステムから直接データが読み取られ、 SAP データベースサーバに負荷は生成されません。プライマリストレージはセカンダリストレージと直接通信し、 NetApp SnapVault のディスクツーディスクバックアップを使用してバックアップデータをデスティネーションに送信します。

SnapVault には、従来のバックアップに比べて大きな利点があります。最初のデータ転送でソースからデスティネーションにすべてのデータが転送され、以降のバックアップでは変更されたブロックだけがセカンダリストレージにコピーされます。そのため、プライマリストレージシステムへの負荷およびフルバックアップに要する時間が大幅に削減されます。SnapVault では変更されたブロックだけがデスティネーションに格納されるため、データベースのフルバックアップに必要なディスクスペースも少なくて済みます。

解決策 は、ハイブリッドクラウド運用モデルにシームレスに拡張することもできます。ディザスタリカバリやオフサイトのバックアップを目的としたデータレプリケーションは、オンプレミスの NetApp ONTAP システムから、クラウドで実行されている Cloud Volumes ONTAP インスタンスに実施できます。SnapCenter は、 SAP HANA システムをオンプレミスで実行する場合でも、クラウドで実行する場合でも、データ保護とデータレプリケーションを一元的に管理するツールとして使用できます。次の図に、バックアップ解決策 の概要を示します。

エラー：グラフィックイメージがありません

Snapshot バックアップの実行時間

次のスクリーンショットは、ネットアップストレージ上で SAP HANA を実行しているお客様の HANA Studio を示しています。Snapshot コピーを使用して HANA データベースをバックアップしている。この図では、 Snapshot バックアップテクノロジを使用して、 HANA データベース（約 2.3TB のサイズ）を 2 分 11 秒でバックアップしています。

メモ 全体的なバックアップワークフローランタイムの最大の部分は、 HANA のバックアップセーブポイント処理を実行するために必要な時間です。この手順は、 HANA データベースの負荷によって異なります。ストレージ Snapshot バックアップ自体は、数秒で完了します。

エラー：グラフィックイメージがありません

目標復旧時間の比較

このセクションでは、ファイルベースとストレージベースの Snapshot バックアップの RTO 比較を示します。RTO は、データベースのリストアに必要な時間と、データベースの起動およびリカバリに必要な時間の合計によって定義されます。

データベースのリストアに必要な時間

ファイルベースのバックアップでは、リストア時間はデータベースのサイズとバックアップインフラによって異なり、リストア速度は 1 秒あたりのメガバイト数で定義されます。たとえば、インフラで 250MBps の高速なリストア処理がサポートされている場合、データベースのサイズが 1TB にリストアされるまでに約 1 時間 10 分かかります。

ストレージ Snapshot コピーバックアップでは、リストア時間はデータベースのサイズに左右されず、プライマリストレージからリストアを実行できる数秒の範囲になります。セカンダリストレージからのリストアが必要になるのは、プライマリストレージが使用できなくなったときに災害が発生した場合だけです。

データベースの起動に必要な時間

データベースの開始時間は、行および列ストアのサイズによって異なります。列ストアの場合、開始時間は、データベースの起動時にプリロードされるデータの量によっても異なります。次の例では、開始時間は 30 分であると想定しています。開始時刻は、ファイルベースのリストアとリカバリ、および Snapshot に基づくリストアとリカバリで同じです。

データベースのリカバリに要する時間

リカバリ時間は、リストア後に適用する必要があるログの数によって異なります。この数は、データバックアップを実行する頻度によって決まります。

ファイルベースのデータバックアップでは、通常、バックアップスケジュールは 1 日に 1 回となります。バックアップによって本番環境のパフォーマンスが低下するため、通常はバックアップ頻度を高くすることはできません。したがって、最悪の場合は、フォワードリカバリ時に 1 日中に書き込まれたすべてのログを適用する必要があります。

ストレージ Snapshot コピーのデータバックアップは、通常、 SAP HANA データベースのパフォーマンスに影響しないため、頻繁にスケジュールされます。たとえば、 Snapshot コピーのバックアップを 6 時間ごとに実行するようにスケジュールした場合、最大でファイルベースのバックアップのリカバリ時間の 4 分の 1 （ 6 時間 /24 時間 = ¼ ）というリカバリ時間がかかります。

次の図に、ファイルベースのデータバックアップを使用する場合の 1TB データベースの RTO の例を示します。この例では、バックアップが 1 日に 1 回作成されます。RTO は、リストアとリカバリの実行タイミングによって異なります。バックアップの作成直後にリストアとリカバリを実行した場合の RTO は、主にリストア時間に基づきます。この例では、 1 時間 10 分です。リカバリ時間は、次のバックアップが作成される直前にリストアとリカバリが実行され、最大 RTO は 4 時間 30 分になりました。

エラー：グラフィックイメージがありません

次の図に、 Snapshot バックアップの使用時の 1TB データベースの RTO の例を示します。ストレージベースの Snapshot バックアップでは、データベースのサイズに関係なく数秒でリストアが完了するため、 RTO はデータベースの開始時間と転送リカバリ時間にのみ左右されます。また、リストアとリカバリの実行タイミングによってもフォワードリカバリの時間が長くなりますが、バックアップの頻度が高い（この例では 6 時間ごと）ため、最大で 43 分までリカバリ時間が短縮されます。この例では、最大 RTO は 1 時間 13 分です。

エラー：グラフィックイメージがありません

次の図に、データベースサイズや Snapshot バックアップの頻度に応じた、ファイルベースとストレージベースの Snapshot バックアップの RTO 比較を示します。緑のバーは、ファイルベースのバックアップを示しています。その他のバーには、バックアップ頻度が異なる Snapshot コピーのバックアップが表示されます。

1 日に 1 回の Snapshot コピーでデータをバックアップする RTO は、ファイルベースのデータバックアップに比べてすでに 40% 短縮されています。1 日に 4 つの Snapshot バックアップを作成すると、削減率は 70% になります。また、 Snapshot のバックアップ頻度を 1 日あたり 4~6 個の Snapshot バックアップに増やすと、この図ではフラットな状態になります。したがって、お客様は通常、 1 日に 4~6 個の Snapshot バックアップを作成します。

エラー：グラフィックイメージがありません

メモ このグラフには、 HANA サーバの RAM サイズが表示されます。メモリ内のデータベースサイズは、サーバの RAM サイズの半分になるように計算されます。
メモ リストアとリカバリの所要時間は、次の前提に基づいて計算します。データベースは 250MBps でリストアできます。1 日のログファイルの数は、データベースサイズの 50% です。たとえば、 1TB のデータベースでは、 1 日 500MB のログファイルが作成されます。リカバリは 100Mbps で実行できます。