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

Amazon FSX for ONTAP を使用したバックアップとリカバリ

共同作成者

NetApp Snapshotテクノロジを使用すれば、データベースのバックアップを数分で作成できます。

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

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

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

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

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

Snapshotバックアップおよびリストア処理の実行時間

次の図に、Snapshotバックアップ操作を使用したお客様のHANA Studioを示します。図に示すように、HANAデータベース(約4TBのサイズ)は、Snapshotバックアップテクノロジを使用して1分20秒以内にバックアップされ、ファイルベースのバックアップ処理を実行して4時間以上経過しています。

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

入力/出力ダイアログを示す図、または書き込まれた内容を表す図

目標復旧時間の比較

ここでは、ファイルベースとストレージベースのSnapshotバックアップのRecovery Time Objective(RTO;目標復旧時間)を比較します。RTOは、データベースのリストア、リカバリ、および起動に必要な時間の合計によって定義されます。

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

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

ストレージSnapshotコピーバックアップでは、リストア時間はデータベースのサイズに左右されず、常に数秒の範囲になります。

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

データベースの開始時間は、データベースのサイズと、データをメモリにロードするのに必要な時間によって異なります。次の例では、データを1000Mbpsでロードできると仮定しています。4TBのメモリをメモリに装着するには、約1時間10分かかります。開始時間は、ファイルベースおよびSnapshotベースのリストア処理とリカバリ処理の場合と同じです。

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

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

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

Snapshotバックアップは通常、SAP HANAデータベースのパフォーマンスに影響しないため、頻繁にスケジュールされます。たとえば、Snapshotバックアップが6時間ごとにスケジュールされている場合、最悪の場合、ファイルベースのバックアップに関しては、リカバリ時間の4分の1(6時間/24時間=.25)になります。

次の図に、リストア処理とリカバリ処理の比較を示します。毎日のファイルベースのバックアップとSnapshotバックアップでスケジュールが異なります。

最初の2つのバーは、1日に1つのSnapshotバックアップを作成した場合でも、Snapshotバックアップからのリストア処理の速度が原因で、リストアとリカバリが43%に削減されることを示しています。1日に複数のSnapshotバックアップを作成すると、フォワードリカバリで適用するログが少なくなるため、ランタイムがさらに短縮されます。

また、次の図では、1日に4~6つのSnapshotバックアップを作成することを推奨しています。頻度を高くしても、全体的な実行時間に大きな影響はありません。

入力/出力ダイアログを示す図、または書き込まれた内容を表す図

バックアップとクローニング処理の高速化のユースケースと価値

バックアップの実行は、あらゆるデータ保護戦略に欠かせない要素です。バックアップは定期的にスケジュールされ、システム障害からリカバリできます。これは最も分かりやすいユースケースですが、SAPライフサイクル管理タスクにはバックアップとリカバリの高速化が不可欠なものもあります。

SAP HANAシステムのアップグレードは、たとえば、アップグレード前のオンデマンドバックアップと、アップグレードが失敗した場合のリストア処理が計画的停止全体に大きく影響する例です。4TBのデータベースの例を使用すると、Snapshotベースのバックアップおよびリストア処理を使用して、計画的なダウンタイムを8時間短縮できます。

別のユースケース例としては、一般的なテストサイクルが挙げられます。このテストサイクルでは、異なるデータセットまたはパラメータを使用して複数のイテレーションを行ってテストを実施する必要があります。高速バックアップおよびリストア操作を利用すると、テストサイクル内にセーブポイントを簡単に作成し、テストに失敗した場合やテストを繰り返す必要がある場合に、システムをこれらの以前のセーブポイントのいずれかにリセットできます。これにより、テストを早期に完了させることも、より多くのテストを同時に実行してテスト結果を改善することもできます。

入力/出力ダイアログを示す図、または書き込まれた内容を表す図

Snapshotバックアップを実装したら、HANAデータベースのコピーを必要とするその他の複数のユースケースに対応できます。FSX for ONTAP を使用すると、使用可能な任意のSnapshotバックアップの内容に基づいて新しいボリュームを作成できます。この処理は、ボリュームのサイズに関係なく数秒で実行されます。

最も一般的なユースケースはSAPシステムの更新です。本番用システムのデータをテストシステムまたはQAシステムにコピーする必要があります。FSX for ONTAP クローニング機能を利用すると、本番用システムの任意のSnapshotコピーから、わずか数秒でテストシステム用のボリュームをプロビジョニングできます。その後、新しいボリュームをテストシステムに接続し、HANAデータベースをリカバリする必要があります。

2つ目のユースケースは、リペアシステムを作成したもので、本番システムでの論理的な破損に対処するために使用されます。この場合、本番用システムの古いSnapshotバックアップを使用して修復システムが開始されます。これは、破損が発生する前のデータと同一の、本番システムのクローンです。その後、リペアシステムを使用して問題を分析し、破損する前に必要なデータをエクスポートします。

最後のユースケースは、レプリケーションを停止することなくディザスタリカバリのフェイルオーバーテストを実行できるため、ディザスタリカバリの設定のRTOとRecovery Point Objective(RPO;目標復旧時点)に影響を及ぼすことなく、FSX for ONTAP NetApp SnapMirrorレプリケーションを使用してデータをディザスタリカバリサイトにレプリケートすると、本番用Snapshotバックアップをディザスタリカバリサイトでも使用できるようになり、ディザスタリカバリテスト用の新しいボリュームを作成できるようになります。

入力/出力ダイアログを示す図、または書き込まれた内容を表す図