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

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

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

バックアップの実行は、あらゆるデータ保護戦略に欠かせない要素です。バックアップは定期的にスケジュールされ、システム障害からリカバリできます。これは最も分かりやすいユースケースですが、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バックアップをディザスタリカバリサイトでも使用できるようになり、ディザスタリカバリテスト用の新しいボリュームを作成できるようになります。