ドキュメントの変更をリクエスト
GitHub で編集
寄稿者向けガイド
利用可能なPDF
Azure NetApp Files を使用したバックアップとリカバリ
寄稿者
Azure NetApp Files （ANF）Snapshotテクノロジを使用すると、データベースのバックアップを数秒で作成できます。Snapshot コピーではストレージプラットフォーム上の物理データブロックは移動されないため、 Snapshot コピーの作成に要する時間はデータベースのサイズに左右されません。また、 Snapshot テクノロジを使用しても、稼働中の SAP システムのパフォーマンスには影響しません。そのため、対話形式またはバッチでのアクティビティのピーク期間を考慮せずに、 Snapshot コピーの作成をスケジュールできます。SAP on ANFを利用しているお客様は、通常、オンラインのSnapshotバックアップを1日に複数回（4~6時間おきなど）スケジュールを設定します。作成された Snapshot バックアップをプライマリストレージシステムに 3~5 日間保持しています。
Snapshot コピーは、リストア処理とリカバリ処理にも大きなメリットがあります。ボリュームのリバート処理を使用すると、使用可能な Snapshot コピーに基づいて、任意の時点までのデータベース全体をリストアできます。このようなリストアプロセスは、データベースのサイズに関係なく数秒で完了します。オンラインの Snapshot バックアップは 1 日に数回作成されるため、従来のバックアップ方式に比べて、リカバリプロセスに要する時間が大幅に短縮されます。24 時間以内ではなく数時間前の Snapshot コピーを使用してリストア処理を実行できるため、適用するトランザクションログの数を少なくする必要があります。そのため、従来のシングルサイクルバックアップでは数時間かかっていた RTO が数分に短縮されます。
Snapshot コピーバックアップは、アクティブなオンラインデータと同じディスクシステムに格納されます。セカンダリストレージへのバックアップに代わる手段としてではなく、補助的な用途で使用することを推奨します。リストアとリカバリのほとんどはプライマリストレージシステムでボリュームリバート処理を使用して実行されます。セカンダリストレージからのリストアが必要になるのは、 Snapshot コピーが格納されているプライマリストレージシステムが損傷している場合のみです。セカンダリストレージは、 Snapshot コピーから削除したバックアップをリストアする必要がある場合に使用できます。
HANA の追加のファイルベースのバックアップを使用して、セカンダリサイトにバックアップできます。これらのファイルベースのバックアップは、はるかに低い頻度でスケジュール設定できるため、本番システムのパフォーマンスへの影響が少なくなります。
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ベースのリストア処理とリカバリ処理の開始時刻は同じです。
|
Azure NetApp Files では、ボリュームのスループットを動的に調整できます。HANAを起動する前に、HANAデータベースを起動したあとは、HANAデータボリュームのスループットを日 々 の処理の値にまで増減できます。 |
データベースのリカバリに要する時間
リカバリ時間は、リストア後に適用する必要があるログの数によって異なります。この数は、データバックアップを実行する頻度によって決まります。
ファイルベースのデータバックアップでは、通常、バックアップスケジュールは 1 日に 1 回となります。バックアップによって本番環境のパフォーマンスが低下するため、通常はバックアップ頻度を高くすることはできません。したがって、最悪の場合は、フォワードリカバリ時に 1 日中に書き込まれたすべてのログを適用する必要があります。
Snapshotバックアップは通常、SAP HANAデータベースのパフォーマンスに影響しないため、頻繁にスケジュールされます。たとえば、Snapshotバックアップが6時間ごとにスケジュールされている場合、リカバリ時間は、最悪の場合、ファイルベースのバックアップのリカバリ時間の4分の1（6時間/ 24時間= 0.25）になります。
次の図に、リストア処理とリカバリ処理の比較を示します。毎日のファイルベースのバックアップとSnapshotバックアップでスケジュールが異なります。
最初の2つのバーは、Snapshotバックアップからのリストア処理が高速になるため、1日に1つのSnapshotバックアップがあっても、リストアとリカバリが43%に短縮されることを示しています。1日に複数のSnapshotバックアップが作成される場合は、フォワードリカバリ時に適用するログが少なくて済むため、ランタイムをさらに短縮できます。
また、次の図では、1日に4~6個のSnapshotバックアップが最適であることも示されています。頻度を高くしても、実行時間全体に大きな影響はありません。
