NetApp Snapshot テクノロジーを使用すると、数分でデータベースのバックアップを作成できます。スナップショット コピーではストレージ プラットフォーム上の物理データ ブロックが移動されないため、スナップショット コピーの作成に必要な時間はデータベースのサイズとは無関係です。さらに、スナップショット テクノロジを使用すると、すべての操作がストレージ システムで実行されるため、ライブ SAP システムのパフォーマンスに影響はありません。したがって、ピーク時のダイアログまたはバッチ アクティビティ期間を考慮せずに、スナップショット コピーの作成をスケジュールできます。NetApp上の SAP の顧客は通常、1 日中に複数のオンライン スナップショット バックアップをスケジュールします。たとえば、6 時間ごとにスケジュールするのが一般的です。これらのスナップショット バックアップは通常、プライマリ ストレージ システムに 3 ～ 5 日間保存された後、削除されるか、長期保存のためにより安価なストレージに階層化されます。

スナップショット コピーは、復元および回復操作にも重要な利点をもたらします。復元操作では、バックアップの状態に基づいてファイル システム内のデータが復元されます。リカバリ操作は、データベース ログ バックアップを使用して、データベースの状態を特定の時点までロールフォワードするために使用されます。

NetApp SnapRestoreテクノロジーにより、現在利用可能なスナップショット バックアップに基づいて、データベース全体またはデータベースの一部のみを復元できます。復元プロセスは、データベースのサイズに関係なく、数秒で完了します。1 日中に複数のオンライン スナップショット バックアップを作成できるため、従来の 1 日 1 回のバックアップ アプローチと比較して、回復プロセスに必要な時間が大幅に短縮されます。最大 24 時間ではなく、最大数時間前のスナップショット コピーを使用して復元を実行できるため、フォワード リカバリ中に適用する必要があるトランザクション ログが少なくなります。従来のストリーミング バックアップと比較して、復元と回復に必要な時間が大幅に短縮されます。

スナップショット バックアップはアクティブなオンライン データと同じディスク システムに保存されるため、 NetApp、スナップショット コピー バックアップをセカンダリ ロケーションへのバックアップの代わりとしてではなく補足として使用することをお勧めします。ほとんどの復元およびリカバリ アクションは、プライマリ ストレージ システム上のSnapRestoreを使用して管理されます。セカンダリ ロケーションからの復元は、スナップショット コピーを含むプライマリ ストレージ システムが使用できない場合にのみ必要です。プライマリ ストレージで使用できなくなったバックアップを復元する必要がある場合は、セカンダリ バックアップを使用することもできます。

セカンダリ ロケーションへのバックアップは、プライマリ ストレージに作成されたスナップショット コピーに基づいています。したがって、SAP データベース サーバーとそのネットワークに負荷をかけることなく、データはプライマリ ストレージ システムから直接読み取られます。プライマリ ストレージはセカンダリ ストレージと直接通信し、 SnapVaultまたは ANF バックアップ機能を使用してバックアップ データを宛先に複製します。

SnapVaultと ANF バックアップは、従来のバックアップに比べて大きな利点があります。すべてのデータがソースから宛先に転送される最初のデータ転送の後、後続のすべてのバックアップでは、変更されたブロックのみがセカンダリ ストレージに複製されます。 変更されたブロックのみが保存先に保存されるため、追加の完全データベース バックアップでは消費されるディスク領域が大幅に削減されます。プライマリ ストレージ システムの負荷およびフル バックアップに要する時間は大幅に削減されます。デスティネーションには変更されたブロックだけが格納されるため、データベースのフル バックアップを追加しても、消費するディスク スペースが大幅に少なくて済みます。

次の図は、スナップショット バックアップ操作を使用する顧客の HANA Studio を示しています。この画像は、HANA データベース (サイズ約 4 TB) がスナップショット バックアップ テクノロジを使用して 1 分 20 秒でバックアップされ、ファイルベースのバックアップ操作では 4 時間以上かかっていることを示しています。

バックアップ ワークフロー全体の実行時間のうち最も大きな部分は、HANA データベース スナップショット操作の実行に必要な時間です。ストレージ スナップショット バックアップ自体は、HANA データベースのサイズに関係なく、数秒で完了します。

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

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

SAP HANA システムのアップグレードは、アップグレード前のオンデマンド バックアップと、アップグレードが失敗した場合に実行可能な復元操作が、全体的な計画ダウンタイムに大きな影響を与える例です。4 TB のデータベースの例では、計画されたダウンタイムを 8 時間短縮できます。つまり、スナップショット ベースのバックアップと復元操作を使用することで、エラーの分析と修正にさらに 8 時間かけることができます。

もう 1 つのユース ケースは、異なるデータ セットまたはパラメーターを使用して複数の反復でテストを実行する必要がある一般的なテスト サイクルです。高速バックアップおよび復元操作を活用すると、テスト サイクル内で保存ポイントを簡単に作成し、テストが失敗した場合や繰り返す必要がある場合に、システムを以前の保存ポイントのいずれかにリセットできます。これにより、テストをより早く終了したり、同時により多くのテストを実行できるようになり、テスト結果が向上します。

スナップショット バックアップが実装されると、HANA データベースのコピーを必要とする他の複数のユース ケースに対応するために使用できるようになります。利用可能なスナップショット バックアップの内容に基づいて新しいボリュームを作成できます。この操作の実行時間は、ボリュームのサイズに関係なく数秒です。

最も一般的な使用ケースは、実稼働システムのデータをテスト システムまたは QA システムにコピーする必要がある SAP システム リフレッシュです。ONTAPまたは ANF のクローン機能を利用すると、実稼働システムの任意の Snapshot コピーからテスト システムのボリュームを数秒でプロビジョニングできます。次に、新しいボリュームをテスト システムに接続し、HANA データベースを回復する必要があります。

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

最後のユースケースは、レプリケーションを停止せずに、したがって災害復旧セットアップの RTO と復旧ポイント目標 (RPO) に影響を与えずに災害復旧フェールオーバー テストを実行する機能です。ONTAP SnapMirrorレプリケーションまたは ANF クロスリージョン レプリケーションを使用してデータを災害復旧サイトに複製すると、実稼働スナップショット バックアップも災害復旧サイトで使用できるようになるため、災害復旧テスト用の新しいボリュームの作成に使用できるようになります。